Microsoft Teams "MiddleTier" は、Microsoft Teams のさまざまなシナリオを強化する内部サービスです。Microsoft の 10 以上のチームによって維持管理されている 700 を超える API からなる最大級のサービスです。過去 2 年間で、このサービスの 50 以上のプロジェクト (ライブラリ、テスト、アプリケーション) が .NET Standard 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 では、さらに改善される予定です。
移行全体は次の 3 段階に分けて行われました。
また、アプリケーションを .NET Framework と .NET Core にマルチターゲット化することで、両方のバイナリを用意し、.NET Core を少しずつ展開し続けることを選択しました。
そのサービスには、いくつかの OData エンドポイントと多くの REST エンドポイントがあります。これら 2 つは、エンドポイントに対して同じルーティング プレフィックスを共有していました。これは、.NET Framework で正常に動作するために使用されましたが、ルーティングの変更により、.NET Core では動作を停止しました。これを解決するには、OData API を別のルート プレフィックスに移動する必要がありました。
ダウンストリーム OData API に対する呼び出しを行う OData クライアントとの HttpWebRequest パターンは、.NET Framework と比較して待機時間が長くなります。これは、フレームワークが接続をキャッシュしない .NET Core の回帰によるものです。これは、新しいバージョンの .NET で既に解決されています。
Azure Service Bus SDK は、以前のバージョンが .NET Standard と互換性がなかったため、この移行の一環としてアップグレードする必要がありました。最新バージョンの Azure Service Bus SDK は、要求ペイロードを JSON 形式で送信しますが、以前の SDK はペイロードを XML 形式で送信します。XML ペイロードを引き続き使用するには、DataContractSerializer を使用する必要がありました。
Service Fabric プロジェクト (sfproj) は、マルチターゲットを本質的にサポートしていません。両方のターゲット フレームワークの Service Fabric パッケージを生成するには、ビルド パイプラインで回避策を実行する必要がありました。
以前のバージョンの MimeKit では、2 バイト文字に問題があるため、このシナリオでは言語固有の検証を行うことをお勧めします。アジア地域にあるデプロイにロールアウトした場合に、同様の問題が見つかりました。
.NET の新しいリリースでは、生産性とパフォーマンスが大幅に向上し、回復性、拡張性、パフォーマンス、安全性なサービスを構築する Microsoft の目標の達成に引き続き貢献しています。チームは、次に .NET 6 にアップグレードすることで、.NET で行われた改善を引き続き活用する予定です。
このステップ バイ ステップ チュートリアルは、あなたのコンピューターで ASP.NET を実行するのに役立ちます。