Pelajari tentang perbedaan antara Cloud Services dan Service Fabric sebelum memigrasikan aplikasi.
Microsoft Azure Service Fabric adalah platform aplikasi cloud generasi berikutnya untuk aplikasi terdistribusi yang sangat dapat diskalakan dan sangat andal. Ini memperkenalkan banyak fitur baru untuk pengemasan, penyebaran, peningkatan, dan pengelolaan aplikasi cloud terdistribusi.
Ini adalah panduan pengantar untuk memigrasikan aplikasi dari Cloud Services ke Service Fabric. Ini terutama berfokus pada perbedaan arsitektur dan desain antara Cloud Services dan Service Fabric.
Aplikasi dan infrastruktur
Perbedaan mendasar antara Cloud Services dan Service Fabric adalah hubungan antara VM, beban kerja, dan aplikasi. Beban kerja di sini didefinisikan sebagai kode yang Anda tulis untuk melakukan tugas tertentu atau menyediakan layanan.
- Cloud Services adalah tentang menerapkan aplikasi sebagai VM. Kode yang Anda tulis digabungkan erat ke instans VM, seperti Peran Web atau Pekerja. Untuk menerapkan beban kerja di Cloud Services adalah dengan menerapkan satu atau beberapa instans VM yang menjalankan beban kerja. Tidak ada pemisahan aplikasi dan VM, sehingga tidak ada definisi formal dari aplikasi. Aplikasi dapat dianggap sebagai sekumpulan instans Peran Web atau Pekerja dalam penyebaran Cloud Services atau sebagai seluruh penyebaran Cloud Services. Dalam contoh ini, aplikasi ditampilkan sebagai sekumpulan instans peran.
- Service Fabric adalah tentang menyebarkan aplikasi ke VM atau mesin yang ada yang menjalankan Service Fabric di Windows atau Linux. Layanan yang Anda tulis benar-benar dipisahkan dari infrastruktur yang mendasarinya, yang diabstraksikan oleh platform aplikasi Service Fabric, sehingga aplikasi dapat digunakan ke beberapa lingkungan. Beban kerja dalam Service Fabric disebut "layanan," dan satu atau beberapa layanan dikelompokkan dalam aplikasi yang ditentukan secara resmi yang berjalan pada platform aplikasi Service Fabric. Beberapa aplikasi dapat disebarkan ke satu kluster Service Fabric.
Service Fabric sendiri adalah lapisan platform aplikasi yang berjalan pada Windows atau Linux, sedangkan Cloud Services adalah sistem untuk menyebarkan VM yang dikelola Azure dengan beban kerja terpasang. Model aplikasi Service Fabric memiliki sejumlah keunggulan:
- Waktu penyebaran yang cepat. Membuat instans VM bisa memakan waktu. Dalam Service Fabric, VM hanya digunakan sekali untuk membentuk kluster yang menjadi tuan rumah platform aplikasi Service Fabric. Sejak saat itu, paket aplikasi dapat disebarkan ke kluster dengan sangat cepat.
- Hosting dengan kepadatan tinggi. Di Cloud Services, VM Peran Pekerja menyelenggarakan satu beban kerja. Dalam Service Fabric, aplikasi terpisah dari VM yang menjalankannya, yang berarti Anda dapat menyebarkan sejumlah besar aplikasi ke sejumlah kecil VM, yang dapat menurunkan biaya keseluruhan untuk penyebaran yang lebih besar.
- Platform Service Fabric dapat berjalan di mana saja yang memiliki mesin Windows Server atau Linux, baik itu Azure atau lokal. Platform ini menyediakan lapisan abstraksi di atas infrastruktur yang mendasarinya sehingga aplikasi Anda dapat berjalan pada lingkungan yang berbeda.
- Manajemen aplikasi terdistribusi. Service Fabric adalah platform yang tidak hanya menyelenggarakan aplikasi terdistribusi, tetapi juga membantu mengelola siklus hidupnya secara independen dari VM hosting atau siklus hidup komputer.
Arsitektur aplikasi
Arsitektur aplikasi Cloud Services biasanya mencakup banyak dependensi layanan eksternal, seperti Service Bus, Azure Table dan Blob Storage, SQL, Redis, dan lainnya untuk mengelola status dan data aplikasi dan komunikasi antara Peran Web dan Pekerja dalam penyebaran Cloud Services. Contoh aplikasi Cloud Services lengkap mungkin terlihat seperti ini:
Aplikasi Service Fabric juga dapat memilih untuk menggunakan layanan eksternal yang sama dalam aplikasi lengkap. Dengan menggunakan contoh arsitektur Cloud Services ini, jalur migrasi paling sederhana dari Cloud Services ke Service Fabric adalah mengganti hanya penerapan Cloud Services dengan aplikasi Service Fabric, menjaga arsitektur keseluruhan tetap sama. Peran Web dan Pekerja dapat diportkan ke layanan stateless Service Fabric dengan perubahan kode minimal.
Pada tahap ini, sistem harus terus bekerja sama seperti sebelumnya. Memanfaatkan fitur Service Fabric yang canggih, penyimpanan status eksternal dapat diinternalisasi sebagai layanan stateful jika berlaku. Ini lebih terlibat daripada migrasi sederhana Peran Web dan Pekerja ke layanan stateless Service Fabric, karena memerlukan penulisan layanan kustom yang menyediakan fungsionalitas yang setara dengan aplikasi Anda seperti layanan eksternal sebelumnya. Manfaat melakukannya termasuk:
- Menghapus dependensi eksternal
- Menyatukan model penyebaran, manajemen, dan pemutakhiran.
Contoh yang menghasilkan arsitektur internalisasi layanan ini bisa terlihat seperti ini:
Komunikasi dan alur kerja
Sebagian besar aplikasi Cloud Service terdiri dari lebih dari satu tingkatan. Demikian pula, aplikasi Service Fabric terdiri dari lebih dari satu layanan (biasanya banyak layanan). Dua model komunikasi umum adalah komunikasi langsung dan melalui penyimpanan tahan lama eksternal.
Komunikasi langsung
Dengan komunikasi langsung, tingkatan dapat berkomunikasi langsung melalui titik akhir yang diekspos oleh setiap tingkatan. Dalam lingkungan tanpa status seperti Cloud Services, ini berarti memilih contoh peran VM, baik secara acak maupun round-robin untuk menyeimbangkan beban, dan menghubungkan ke titik akhir secara langsung.
Komunikasi langsung adalah model komunikasi umum dalam Service Fabric. Perbedaan utama antara Service Fabric dan Cloud Services adalah bahwa di Cloud Services Anda terhubung ke VM, sedangkan dalam Service Fabric Anda terhubung ke layanan. Ini adalah perbedaan penting karena beberapa alasan:
- Layanan dalam Service Fabric tidak terikat dengan VM yang menghostingnya; layanan dapat bergerak di sekitar dalam kluster, dan pada kenyataannya, diharapkan untuk bergerak karena berbagai alasan: Penyeimbangan sumber daya, failover, peningkatan aplikasi dan infrastruktur, dan batasan penempatan atau beban. Ini berarti alamat instans layanan dapat berubah kapan saja.
- VM dalam Service Fabric dapat menghosting beberapa layanan, masing-masing dengan titik akhir yang unik.
Service Fabric menyediakan mekanisme penemuan layanan, yang disebut Naming Service, yang dapat digunakan untuk menyelesaikan alamat titik akhir layanan.
Antrean
Mekanisme komunikasi umum antara tingkatan di lingkungan stateless seperti Cloud Services adalah menggunakan antrean penyimpanan eksternal untuk menyimpan tugas kerja secara tahan lama dari satu tingkat ke tingkat lainnya. Skenario umum adalah tingkat web yang mengirim pekerjaan ke Azure Queue atau Service Bus di mana instans Peran Pekerja dapat menghapus antrean dan memproses pekerjaan.
Model komunikasi yang sama dapat digunakan dalam Service Fabric. Ini dapat berguna saat memigrasikan aplikasi Cloud Services yang ada ke Service Fabric.
Paritas
Cloud Services mirip dengan Service Fabric dalam tingkat kontrol versus kemudahan penggunaan, tetapi sekarang legacy service dan Service Fabric direkomendasikan untuk pengembangan baru; berikut ini adalah perbandingan API:
| Cloud Service API | Service Fabric API | Catatan |
|---|---|---|
| RoleInstance.GetID | FabricRuntime.GetNodeContext.NodeId atau .NodeName | ID adalah properti dari NodeName |
| RoleInstance.GetFaultDomain | FabricClient.QueryManager.GetNodeList | Filter pada NodeName dan gunakan Properti FD |
| RoleInstance.GetUpgradeDomain | FabricClient.QueryManager.GetNodeList | Filter pada NodeName, dan gunakan properti Upgrade |
| RoleInstance.GetInstanceEndpoints | FabricRuntime.GetActivationContext atau Naming (ResolveService) | CodePackageActivationContext yang disediakan baik oleh FabricRuntime.GetActivationContext maupun dalam replika melalui ServiceInitializationParameters.CodePackageActivationContext yang disediakan selama .Initialize |
| RoleEnvironment.GetRoles | FabricClient.QueryManager.GetNodeList | Jika Anda ingin melakukan jenis pemfilteran berdasarkan jenis yang sama, Anda bisa mendapatkan daftar jenis node dari manifes kluster melalui FabricClient.ClusterManager.GetClusterManifest dan ambil jenis peran/node dari sana. |
| RoleEnvironment.GetIsAvailable | Connect-WindowsFabricCluster atau buat FabricRuntime yang menunjuk ke node tertentu | * |
| RoleEnvironment.GetLocalResource | CodePackageActivationContext.Log/Temp/Work | * |
| RoleEnvironment.GetCurrentRoleInstance | CodePackageActivationContext.Log/Temp/Work | * |
| LocalResource.GetRootPath | CodePackageActivationContext.Log/Temp/Work | * |
| Role.GetInstances | FabricClient.QueryManager.GetNodeList atau ResolveService | * |
| RoleInstanceEndpoint.GetIPEndpoint | FabricRuntime.GetActivationContext atau Naming (ResolveService) | * |
Langkah berikutnya
Jalur migrasi paling sederhana dari Cloud Services ke Service Fabric adalah mengganti hanya penyebaran Cloud Services dengan aplikasi Service Fabric, menjaga arsitektur keseluruhan aplikasi Anda kurang lebih sama. Artikel berikut ini menyediakan panduan untuk membantu mengonversi Peran Web atau Pekerja ke layanan Stateless Service Fabric.