Microsoft Teams "MiddleTier"는 Microsoft Teams의 다양한 시나리오를 지원하는 내부 서비스입니다. Microsoft의 10개 이상의 팀에서 유지 관리하는 700개 이상의 API로 구성된 가장 큰 서비스 중 하나입니다. 지난 2년 동안 이 서비스에 속한 50개 이상의 프로젝트(라이브러리, 테스트, 애플리케이션)가 .NET 표준 2.0 및 .NET Core 3.1로 변환되었으며 기능 및 성능이 동일하거나 그 이상이며 이제 거의 완전히 실행되고 있습니다. 프로덕션에서 .NET Core 3.1을 사용하고 다음에는 .NET 6으로 이동하려고 합니다. 이 마이그레이션 전에 서비스는 ASP.NET Core 2.2 MVC 파이프라인을 사용하여 .NET Framework 4.6.2에서 실행되었습니다. 35개의 Azure 데이터 센터에 배포된 Azure Service Fabric에서 실행됩니다.
MiddleTier는 매일 작업하는 수백 명의 개발자에게 제공하는 기능 면에서 초대형 서비스이기 때문에 이 마이그레이션의 범위가 컸습니다.
팀은 다음과 같은 이유로 .NET Core 3.1로 전환하게 되었습니다.
.NET Core 3.1로 마이그레이션한 후 팀은 다음과 같은 향상된 기능을 발견했습니다.
다음 차트는 .NET Framework와 .NET Core 간의 비교를 보여줍니다. 앞으로 .NET 6에서는 더 많은 개선 사항을 볼 수 있을 것입니다.
전체 마이그레이션은 세 단계로 나뉩니다.
또한 두 이진 파일을 모두 사용할 수 있도록 하고 .NET Core를 천천히 롤아웃할 수 있도록 애플리케이션을 .NET Framework 및 .NET Core에 다중 대상으로 지정하기로 했습니다.
해당 서비스에는 많은 REST 엔드포인트와 함께 OData 엔드포인트가 거의 없습니다. 이 두 가지는 끝점에 대해 동일한 라우팅 접두사를 공유했습니다. 이것은 .NET Framework에서 제대로 작동했지만 라우팅 변경으로 인해 .NET Core에서 작동이 중지되었습니다. 이 문제를 해결하기 위해 OData API를 다른 경로 접두사로 옮겨야 했습니다.
OData 클라이언트가 다운스트림 OData API를 호출하는 HttpWebRequest 패턴은 .NET Framework에 비해 대기 시간이 더 길어집니다. 이는 프레임워크가 연결을 캐시하지 않는 .NET Core의 회귀 때문이었습니다. 이 문제는 최신 버전의 .NET에서 이미 해결되었습니다.
Azure Service Bus SDK는 이전 버전이 .NET 표준과 호환되지 않으므로 이 마이그레이션의 일부로 업그레이드해야 했습니다. 최신 버전의 Azure Service Bus SDK는 요청 페이로드를 JSON 형식으로 보내는 반면 이전 SDK는 페이로드를 XML 형식으로 보냅니다. XML 페이로드를 계속 사용하려면 DataContractSerializer를 사용해야 했습니다.
Service Fabric 프로젝트(sfproj)는 기본적으로 다중 대상 지정을 지원하지 않습니다. 두 대상 프레임워크에 대한 Service Fabric 패키지를 생성하기 위해 빌드 파이프라인에서 해결 방법을 수행해야 했습니다.
MimeKit의 이전 버전에는 2바이트 문자에 문제가 있을 수 있으므로 이 시나리오에서는 언어별 유효성 검사가 권장됩니다. 아시아 지역에 배포할 때 유사한 문제를 발견했습니다.
.NET의 모든 새 릴리스에는 복원력, 확장 가능, 성능 및 보안 서비스를 구축하려는 우리의 목표를 달성하는 데 계속 도움이 되는 엄청난 생산성 및 성능 개선 사항이 제공됩니다. 팀은 다음에 .NET 6으로 업그레이드하여 .NET의 개선 사항을 계속 활용할 것입니다.
단계별 자습서는 컴퓨터에서 ASP.NET을(를) 실행하는 데 도움이 될 것입니다.
