Mendesentralisasi logika alur kerja dan mendistribusikan tanggung jawab ke komponen lain dalam sistem.
Konteks dan masalah
Aplikasi berbasis cloud sering dibagi menjadi beberapa layanan kecil yang bekerja sama untuk memproses transaksi bisnis secara end-to-end. Bahkan satu operasi (dalam transaksi) dapat mengakibatkan beberapa panggilan titik-ke-titik di antara semua layanan. Idealnya, layanan tersebut harus digabungkan secara longgar. Sangat menantang untuk merancang alur kerja yang didistribusikan, efisien, dan dapat diskalakan karena sering melibatkan komunikasi antar layanan yang kompleks.
Pola umum untuk komunikasi adalah menggunakan layanan terpusat atau orkestrator. Permintaan masuk mengalir melalui orkestrator saat mendelegasikan operasi ke layanan masing-masing. Setiap layanan hanya menyelesaikan tanggung jawab mereka dan tidak mengetahui alur kerja keseluruhan.
Pola orkestrator biasanya diimplementasikan sebagai perangkat lunak kustom dan memiliki pengetahuan domain tentang tanggung jawab layanan tersebut. Manfaatnya adalah orkestrator dapat mengonsolidasikan status transaksi berdasarkan hasil operasi individu yang dilakukan oleh layanan hilir.
Namun, ada beberapa kelemahan. Menambahkan atau menghapus layanan mungkin merusak logika yang ada karena Anda perlu memutar ulang bagian jalur komunikasi. Dependensi ini membuat implementasi orkestrator kompleks dan sulit dipertahankan. Orkestrator mungkin memiliki dampak negatif pada keandalan beban kerja. Di bawah beban, ini dapat memperkenalkan penyempitan performa dan menjadi titik kegagalan tunggal. Ini juga dapat menyebabkan kegagalan berkala di layanan hilir.
Solusi
Mendelegasikan logika penanganan transaksi di antara layanan. Biarkan setiap layanan memutuskan dan berpartisipasi dalam alur kerja komunikasi untuk operasi bisnis.
Pola ini adalah cara untuk meminimalkan dependensi pada perangkat lunak kustom yang memfokuskan alur kerja komunikasi. Komponen menerapkan logika umum saat mereka membuat koreografi alur kerja di antara mereka sendiri tanpa memiliki komunikasi langsung satu sama lain.
Cara umum untuk menerapkan koreografi adalah dengan menggunakan broker pesan yang diminta buffer hingga komponen hilir mengklaim dan memprosesnya. Gambar menunjukkan penanganan permintaan melalui model penerbit-pelanggan.
Permintaan klien diantrekan sebagai pesan di broker pesan.
Layanan atau pelanggan melakukan polling broker untuk menentukan apakah mereka dapat memproses pesan tersebut berdasarkan logika bisnis yang diterapkan. Broker juga dapat mendorong pesan kepada pelanggan yang tertarik dengan pesan tersebut.
Setiap layanan berlangganan melakukan operasi mereka seperti yang ditunjukkan oleh pesan dan menanggapi broker dengan keberhasilan atau kegagalan operasi.
Jika berhasil, layanan dapat mendorong pesan kembali ke antrean yang sama atau antrean pesan yang berbeda sehingga layanan lain dapat melanjutkan alur kerja jika diperlukan. Jika operasi gagal, broker pesan bekerja dengan layanan lain untuk mengkompensasi operasi tersebut atau seluruh transaksi.
Masalah dan pertimbangan
Mendesentralisasikan orkestra dapat menyebabkan masalah saat mengelola alur kerja.
Menyerahkan kegagalan bisa menjadi tantangan. Komponen dalam aplikasi mungkin melakukan tugas atom tetapi mungkin masih memiliki tingkat dependensi. Kegagalan dalam satu komponen dapat berdampak pada komponen lain, yang dapat menyebabkan keterlambatan dalam menyelesaikan permintaan keseluruhan.
Untuk menangani kegagalan dengan anggun, menerapkan kompensasi transaksi dapat menimbulkan kompleksitas.
Pola ini cocok untuk alur kerja di mana operasi bisnis independen diproses secara paralel. Alur kerja dapat menjadi rumit ketika koreografi perlu terjadi secara berurutan. Misalnya, Service D dapat memulai operasinya hanya setelah Layanan B dan Layanan C menyelesaikan operasi mereka dengan sukses.
Pola tersebut menjadi tantangan jika jumlah layanan tumbuh pesat. Mengingat tingginya jumlah bagian yang bergerak independen, alur kerja antar layanan cenderung menjadi kompleks. Juga, pelacakan terdistribusi menjadi sulit.
Dalam desain yang dipimpin orkestrator, komponen pusat dapat berpartisipasi sebagian dan mendelegasikan logika ketahanan ke komponen lain yang mencoba kembali kegagalan sementara, nontransien, dan waktu habis, secara konsisten. Dengan pembubaran orkestrator dalam pola koreografi, komponen hilir tidak boleh mengambil tugas ketahanan tersebut. Mereka masih harus ditangani oleh penangan ketahanan. Tetapi sekarang, komponen hilir harus langsung berkomunikasi dengan penangan ketahanan, meningkatkan komunikasi titik-ke-titik.
Kapan menggunakan pola ini
Gunakan pola ini ketika:
Komponen hilir menangani operasi atom secara independen. Anggap saja sebagai mekanisme 'api dan lupa'. Komponen bertanggung jawab atas tugas yang tidak perlu dikelola secara aktif. Ketika tugas selesai, tugas mengirimkan pemberitahuan ke komponen lain.
Komponen diharapkan sering diperbarui dan diganti. Pola ini memungkinkan aplikasi dimodifikasi dengan lebih sedikit upaya dan gangguan minimal pada layanan yang ada.
Pola ini sangat cocok untuk arsitektur tanpa server yang sesuai untuk alur kerja sederhana. Komponen dapat berumur pendek dan berbasis peristiwa. Ketika peristiwa terjadi, komponen dipisahkan, melakukan tugas mereka, dan dihapus setelah tugas selesai.
Ada hambatan performa yang diperkenalkan oleh orkestrator pusat.
Pola ini mungkin tidak berguna jika:
Aplikasi ini kompleks dan memerlukan komponen pusat untuk menangani logika bersama agar komponen hilir tetap ringan.
Ada situasi di mana komunikasi titik-ke-titik antara komponen tidak dapat dihindari.
Anda perlu mengonsolidasikan semua operasi yang ditangani oleh komponen hilir, dengan menggunakan logika bisnis.
Desain beban kerja
Arsitek harus mengevaluasi bagaimana pola Koreografi dapat digunakan dalam desain beban kerja mereka untuk mengatasi tujuan dan prinsip yang tercakup dalam pilar Azure Well-Architected Framework. Contohnya:
| Pilar | Bagaimana pola ini mendukung tujuan pilar |
|---|---|
| Keunggulan Operasional membantu memberikan kualitas beban kerja melalui proses standar dan kohesi tim. | Karena komponen terdistribusi dalam pola ini otonom dan dirancang agar dapat diganti, Anda dapat memodifikasi beban kerja dengan perubahan yang kurang keseluruhan pada sistem. - Alat dan proses OE:04 |
| Efisiensi Performa membantu beban kerja Anda memenuhi tuntutan secara efisien melalui pengoptimalan dalam penskalaan, data, kode. | Pola ini memberikan alternatif ketika penyempitan performa terjadi dalam topologi orkestrasi terpusat. - Perencanaan kapasitas PE:02 - PE:05 Penskalaan dan pemartisian |
Seperti halnya keputusan desain apa pun, pertimbangkan tradeoff terhadap tujuan pilar lain yang mungkin diperkenalkan dengan pola ini.
Contoh
Contoh ini menunjukkan pola koreografi dengan membuat fungsi menjalankan beban kerja asli cloud berbasis peristiwa bersama dengan layanan mikro. Ketika klien meminta paket dikirim, beban kerja menetapkan drone. Setelah paket siap diambil oleh drone terjadwal, proses pengiriman dimulai. Saat dalam transit, beban kerja menangani pengiriman hingga mendapatkan status dikirim.
Contoh ini adalah refaktor implementasi Pengiriman Drone yang menggantikan pola Orchestrator dengan pola Koreografi.
Layanan Penyerapan menangani permintaan klien dan mengonversinya menjadi pesan termasuk detail pengiriman. Transaksi bisnis dimulai setelah mengkonsumsi pesan baru tersebut.
Satu transaksi bisnis klien memerlukan tiga operasi bisnis yang berbeda:
- Membuat atau memperbarui paket
- Menetapkan drone untuk mengirimkan paket
- Tangani pengiriman yang terdiri dari pemeriksaan dan akhirnya meningkatkan kesadaran saat dikirim.
Tiga layanan mikro melakukan pemrosesan bisnis: Layanan Paket, Penjadwal Drone, dan Pengiriman. Alih-alih orkestrator pusat, layanan menggunakan olahpesan untuk berkomunikasi di antara mereka sendiri. Setiap layanan akan bertanggung jawab untuk menerapkan protokol terlebih dahulu yang berkoordinasi dengan cara terdesentralisasi alur kerja bisnis.
Rancang
Transaksi bisnis diproses secara berurutan melalui beberapa hop. Setiap hop berbagi satu bus pesan di antara semua layanan bisnis.
Ketika klien mengirim permintaan pengiriman melalui titik akhir HTTP, layanan Penyerapan menerimanya, mengonversi permintaan tersebut menjadi pesan, lalu menerbitkan pesan ke bus pesan bersama. Layanan bisnis berlangganan akan menggunakan pesan baru yang ditambahkan ke bus. Saat menerima pesan, layanan bisnis dapat menyelesaikan operasi dengan keberhasilan, kegagalan, atau permintaan dapat kehabisan waktu. Jika berhasil, layanan merespons bus dengan kode status Ok, menaikkan pesan operasi baru, dan mengirimkannya ke bus pesan. Jika ada kegagalan atau waktu habis, layanan melaporkan kegagalan dengan mengirim kode alasan ke bus pesan. Selain itu, pesan ditambahkan ke antrean surat mati. Pesan yang tidak dapat diterima atau diproses dalam jumlah waktu yang wajar dan tepat juga dipindahkan DLQ.
Desain menggunakan beberapa bus pesan untuk memproses seluruh transaksi bisnis. Microsoft Azure Bus Layanan dan Microsoft Azure Event Grid terdiri untuk menyediakan platform layanan olahpesan untuk desain ini. Beban kerja disebarkan di Azure Container Apps yang menghosting Azure Functions untuk penyerapan, dan aplikasi yang menangani pemrosesan berbasis peristiwa yang menjalankan logika bisnis.
Desain memastikan koreografi terjadi secara berurutan. Namespace azure Bus Layanan tunggal berisi topik dengan dua langganan dan antrean yang sadar sesi. Layanan Penyerapan menerbitkan pesan ke topik tersebut. Layanan Paket dan layanan Drone Scheduler berlangganan topik dan menerbitkan pesan yang mengomunikasikan keberhasilan ke antrean. Termasuk pengidentifikasi sesi umum yang terkait dengan GUID dengan pengidentifikasi pengiriman, memungkinkan penanganan urutan pesanan yang tidak terbatas. Layanan Pengiriman menunggu dua pesan terkait per transaksi. Pesan pertama menunjukkan paket siap dikirim, dan sinyal kedua bahwa drone dijadwalkan.
Desain ini menggunakan Azure Bus Layanan untuk menangani pesan bernilai tinggi yang tidak dapat hilang atau diduplikasi selama seluruh proses pengiriman. Saat paket dikirim, paket juga menerbitkan perubahan status ke Azure Event Grid. Dalam desain ini, pengirim peristiwa tidak memiliki harapan tentang bagaimana perubahan status ditangani. Layanan organisasi hilir yang tidak disertakan sebagai bagian dari desain ini dapat mendengarkan jenis peristiwa ini, dan bereaksi menjalankan logika tujuan bisnis tertentu (yaitu, mengirim status pesanan yang dikirim melalui email kepada pengguna).
Jika Anda berencana untuk menyebarkan ini ke layanan komputasi lain seperti boilplate aplikasi pola pub-sub AKS dapat diimplementasikan dengan dua kontainer dalam pod yang sama. Satu kontainer menjalankan duta besar yang berinteraksi dengan bus pesan Preferensi Anda sementara yang lain menjalankan logika bisnis. Pendekatan dengan dua kontainer di pod yang sama meningkatkan performa dan skalabilitas. Duta besar dan layanan bisnis berbagi jaringan yang sama yang memungkinkan latensi rendah dan throughput tinggi.
Untuk menghindari operasi coba lagi berjenjang yang mungkin menyebabkan beberapa upaya, layanan bisnis harus segera menandai pesan yang tidak dapat diterima. Anda dapat memperkaya pesan tersebut menggunakan kode alasan terkenal atau kode aplikasi yang ditentukan, sehingga dapat dipindahkan ke antrean surat mati (DLQ). Pertimbangkan untuk mengelola masalah konsistensi yang menerapkan Saga dari layanan hilir. Misalnya, layanan lain dapat menangani pesan surat mati untuk tujuan remediasi hanya dengan menjalankan transaksi kompensasi, rety, atau pivot.
Layanan bisnis idempoten untuk memastikan operasi coba lagi tidak menghasilkan sumber daya duplikat. Misalnya, layanan Paket menggunakan operasi upsert untuk menambahkan data ke penyimpanan data.
Sumber daya terkait
Pertimbangkan pola-pola ini dalam desain Anda untuk koreografi.
Modularisasi layanan bisnis dengan menggunakan pola desain duta besar.
Terapkan pola perataan beban berbasis antrean untuk menangani lonjakan beban kerja.
Gunakan olahpesan terdistribusi asinkron melalui pola penerbit-pelanggan.
Gunakan kompensasi transaksi untuk membatalkan serangkaian operasi yang berhasil jika satu atau beberapa operasi terkait gagal.
Untuk informasi tentang menggunakan perantara pesan dalam infrastruktur olahpesan, lihat Opsi olahpesan asinkron di Azure.