Perjalanan Microsoft Teams menuju .NET Core

Microsoft Teams "MiddleTier" adalah layanan internal yang mendukung berbagai skenario di Microsoft Teams. Ini adalah salah satu layanan terbesar yang terdiri dari 700+ API yang dikelola oleh 10+ tim di Microsoft. Selama dua tahun terakhir, 50+ proyek (perpustakaan, pengujian, aplikasi) dalam layanan ini telah dikonversi ke .NET Standard 2.0 dan .NET Core 3.1, dan mendapatkan performa dan fungsi yang hampir sama (atau lebih baik), dan kini hampir seluruhnya berjalan di .NET Core 3.1 pada produksi dan akan berpindah ke .NET 6. Sebelum migrasi ini, layanan berjalan di .NET Framework 4.6.2 menggunakan alur ASP.NET Core 2.2 MVC. Layanan ini berjalan di Azure Service Fabric dengan penyebaran di 35 pusat data Azure.

Cakupan migrasi ini besar karena MiddleTier adalah layanan ekstra besar dari segi fungsionalitas yang disediakan dan ada ratusan pengembang yang mengerjakannya setiap hari.

Motivasi untuk melakukan migrasi

Tim termotivasi untuk berpindah ke .NET Core 3.1 karena alasan berikut:

• Peningkatan performa dan efisiensi biaya
• .NET Framework 4.6.2 kemungkinan akan segera berakhir masa pakainya
• Dukungan lintas platform
• Beralih ke kerangka kerja modern untuk mendapatkan pengalaman pengembang yang lebih baik

Manfaat setelah melakukan migrasi ke .NET Core 3.1

Setelah melakukan migrasi ke .NET Core 3.1, tim telah melihat peningkatan berikut:

• Peningkatan CPU sebesar 25%
• Pengurangan biaya infrastruktur sekitar 25%
• Peningkatan percakapan kumpulan thread
• Mengurangi upaya dan biaya teknis mendatang untuk beralih ke rilis .NET tahunan

Bagan berikut menunjukkan perbandingan antara .NET Framework dan .NET Core. Di masa mendatang, kita akan melihat peningkatan lebih lanjut dengan .NET 6.

Pendekatan

Migrasi keseluruhan dibagi menjadi tiga tahap:

Mereka juga memilih untuk melakukan multi-target aplikasi ke .NET Framework dan .NET Core sehingga kedua biner akan tersedia, dan mereka dapat terus meluncurkan .NET Core secara perlahan.

Pembelajaran

OData dan REST API lain tidak dapat memilki prefiks rute yang sama

Layanan mereka juga memiliki sedikit titik akhir OData bersama dengan banyak titik akhir REST. Keduanya berbagi prefiks perutean yang sama untuk titik akhir. Hal ini sebelumnya berfungsi dengan baik di .NET Framework, tetapi karena perubahan perutean, hal berhenti berfungsi di .NET Core. Mereka harus memindahkan API OData ke prefiks rute yang berbeda untuk menyelesaikan masalah ini.

Masalah performa dengan pustaka klien OData

Pola HttpWebRequest dengan klien OData untuk melakukan panggilan ke hilir API OData menghasilkan latensi yang lebih tinggi dibandingkan dengan .NET Framework. Ini karena regresi dalam .NET Core yang membuat kerangka kerja tidak melakukan cache koneksi. Hal ini teratasi di versi .NET yang lebih baru.

Masalah dengan SDK Azure Service Bus

SDK Azure Service Bus harus ditingkatkan sebagai bagian dari migrasi ini karena versi lama tidak kompatibel dengan .NET Standard. Versi terbaru SDK Azure Service Bus mengirimkan payload permintaan dalam format JSON sedangkan SDK yang lebih lama mengirimkan payload dalam format XML. Untuk terus menggunakan payload XML, hal tersebut harus menggunakan DataContractSerializer.

Masalah dalam proyek Service Fabric untuk multi-penargetan

Proyek Service Fabric (sfproj) tidak mendukung multi-penargetan secara inheren. Mereka harus melakukan penyelesaian dalam alur build untuk menghasilkan paket Service Fabric untuk kedua kerangka kerja target.

Masalah dengan MimeKit NuGet versi lama

Versi lama MimeKit dapat mengalami masalah dengan karakter byte ganda sehingga validasi khusus bahasa disarankan dalam skenario ini. Mereka menemukan masalah serupa saat meluncurkan penyebaran yang berlokasi di wilayah Asia.

Kekurangan ASP.NET klasik

• Harus menghapus penggunaan beberapa kelas .NET Framework yang ditandai internal di .NET Core.
• Akhiran asinkron MVC dihilangkan dari nama tindakan seperti yang disebutkan dalam artikel perubahan penting ASP.NET Core untuk versi 3.0 dan 3.1. Jika salah satu jalur kode bergantung pada nama tindakan, hal ini dapat menyebabkan perubahan perilaku.
• Operasi IO sinkron secara default dinonaktifkan pada semua server yang dimulai pada .NET Core 3.0 seperti yang disebutkan di masalah GitHub dotnet/aspnetcore#7644.
• Header Content-Length tidak diatur di Content.Headers saat mengirim StreamContent sebagai konten permintaan HTTP. Ini dapat mengakibatkan kesalahan dari panggilan hilir.
• Tidak seperti .NET Core, .NET Framework menghasilkan kode hash yang stabil untuk string.
• Atribut Wajib dari namespace System.ComponentModel.DataAnnotations berperilaku secara berbeda di .NET Core. Pada .NET Framework, atribut ini tidak melakukan validasi model apa pun untuk bidang non-null, tetapi akan melakukannya pada .NET Core.

Masa mendatang

Setiap rilis baru .NET hadir dengan peningkatan produktivitas dan kinerja luar biasa yang senantiasa membantu pencapaian tujuan kami dalam membangun layanan yang tangguh, dapat diskalakan, berkinerja baik, dan aman. Tim akan terus memanfaatkan peningkatan yang dilakukan di .NET dengan memutakhirkan ke .NET 6.