Pola koreografi

Mintalah setiap layanan memutuskan kapan dan bagaimana memproses operasi bisnis, alih-alih bergantung pada orkestrator pusat. Pendekatan ini mendesentralisasi logika alur kerja dan mendistribusikan tanggung jawab di seluruh komponen sistem.

Konteks dan masalah

Anda biasanya membagi aplikasi berbasis cloud menjadi beberapa layanan kecil yang bekerja sama untuk memproses transaksi bisnis end-to-end. Satu operasi dalam transaksi dapat mengakibatkan beberapa panggilan langsung di antara berbagai layanan. Idealnya, layanan tersebut digabungkan secara longgar. Sangat menantang untuk merancang alur kerja yang terdistribusi, efisien, dan dapat diskalakan karena melibatkan komunikasi antar layanan yang kompleks.

Pola umum untuk komunikasi adalah menggunakan layanan terpusat atau orkestrator. Permintaan masuk mengalir melalui orkestrator dengan mendelegasikan operasi ke layanan yang sesuai. Setiap layanan menyelesaikan tanggung jawab mereka dan tidak mengetahui alur kerja keseluruhan.

Di sebelah kiri, panah yang mewakili permintaan klien mengarah dari ikon klien ke ikon orkestrator di tengah diagram. Tiga panah dua arah menghubungkan ikon dan ikon orkestrator untuk layanan A, layanan B, dan layanan C, disusun secara vertikal di sebelah kanan. Panah ini menunjukkan bagaimana orkestrator mengirim permintaan ke layanan dan menerima respons. Diagram ini menggambarkan bagaimana komponen orkestrator pusat berkoordinasi dan mengelola komunikasi dengan semua layanan hilir.

Anda biasanya menerapkan pola orkestrator sebagai perangkat lunak kustom yang memiliki pengetahuan domain tentang tanggung jawab layanan dalam sistem. Salah satu manfaat dari pendekatan ini adalah bahwa orkestrator dapat mengonsolidasikan status transaksi berdasarkan hasil operasi individu yang dilakukan layanan hilir.

Pendekatan ini juga menciptakan beberapa hambatan. 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 berdampak negatif pada keandalan beban kerja. Di bawah beban, ini dapat memperkenalkan hambatan performa dan menjadi titik kegagalan tunggal (SPoF). Ketika orkestrator gagal atau menjadi kelebihan beban, kegagalan dapat menyebar ke semua layanan hilir dependen.

Solusi

Mendelegasikan logika penanganan transaksi di antara layanan. Biarkan setiap layanan berpartisipasi dalam alur kerja komunikasi untuk operasi bisnis dan memutuskan kapan dan bagaimana memprosesnya.

Pola Koreografi 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 langsung berkomunikasi satu sama lain.

Cara umum untuk menerapkan koreografi adalah dengan menggunakan broker pesan yang menampung permintaan hingga komponen hilir mengklaim dan memprosesnya. Gambar berikut menunjukkan penanganan permintaan melalui model penerbit-pelanggan.

Diagram menunjukkan implementasi pola koreografi yang menggunakan broker pesan untuk mengoordinasikan komunikasi layanan. Di sebelah kiri, panah menunjuk dari ikon permintaan klien ke tiga simbol amplop dalam kotak yang mewakili broker pesan pusat. Tiga panah dua arah menghubungkan broker pesan dan layanan A, layanan B, dan layanan C. Panah ini menunjukkan bahwa layanan menerima pesan dari dan mengirim respons ke broker.

1. Klien meminta antrean yang berisi pesan di broker pesan.

2. Layanan atau subskriber melakukan polling pada broker untuk menentukan apakah dapat memproses pesan tersebut berdasarkan logika bisnis yang telah diimplementasikan. Broker juga dapat menyampaikan pesan kepada subscriber yang tertarik dengan pesan tersebut.

3. Setiap layanan berlangganan melakukan operasinya seperti yang ditunjukkan pesan dan merespons broker dengan pesan keberhasilan atau kegagalan operasi.

4. Jika operasi berhasil, layanan dapat menerbitkan pesan ke antrean yang sama atau antrean pesan yang berbeda sehingga layanan lain dapat melanjutkan alur kerja jika diperlukan. Jika operasi gagal, layanan menerbitkan pesan kegagalan. Layanan yang berlangganan pesan tersebut dapat menjalankan tindakan kompensasi yang telah ditentukan sebelumnya untuk operasi yang gagal atau seluruh transaksi.

Masalah dan pertimbangan

Pertimbangkan poin-poin berikut saat memutuskan cara menerapkan pola ini:

• Kompleksitas penanganan kegagalan. Komponen dalam aplikasi mungkin mengelola tugas atomik dan bergantung pada bagian lain dari sistem. Kegagalan dalam satu komponen dapat memengaruhi komponen lain, yang dapat menyebabkan keterlambatan dalam menyelesaikan permintaan keseluruhan.

  Untuk menangani kegagalan dengan anggun, Anda menerapkan logika penanganan kegagalan, yang memperkenalkan kompleksitas. Logika penanganan kegagalan, seperti mengimbangi transaksi, juga rentan terhadap kegagalan.

  

  Diagram alur menunjukkan penanganan kesalahan dan logika kompensasi dalam pola koreografi yang memiliki dependensi layanan berurutan. Di bagian atas, node awal menunjuk ke layanan A. Layanan A terhubung ke simbol berlian yang menunjuk ke layanan B di sebelah kiri dan layanan C di sebelah kanan. Panah menunjuk dari masing-masing layanan ini ke berlian keputusan yang menanyakan apakah permintaan gagal. Jalur yang diberi label ya bercabang ke atas dalam sebuah perulangan yang kembali ke bentuk berlian yang menghubungkan ketiga layanan tersebut. Jalur berlabel tidak berlanjut ke kotak yang menyatakan kedua layanan berhasil. Dari status keberhasilan ini, alur berlanjut ke layanan D, yang terhubung ke belah ketupat keputusan akhir yang menanyakan apakah permintaan gagal. Jalur ya dari berlian ini kembali ke atas untuk masuk kembali ke aliran sebelum layanan D, dan jalur tidak berlanjut ke bawah menuju node akhir.

• Proses berurutan. Pola ini sesuai dengan alur kerja yang memproses operasi bisnis independen secara paralel. Alur kerja dapat menjadi rumit ketika koreografi perlu terjadi secara berurutan. Misalnya, Layanan D dapat memulai operasinya hanya setelah Layanan B dan Layanan C berhasil menyelesaikan operasi mereka.

  

  Diagram menunjukkan alur pesan dalam pola koreografi di mana layanan memproses operasi secara paralel dan berurutan. Di bagian atas ada lima komponen yang diatur secara horizontal: layanan A, broker pesan, layanan B, layanan C, dan layanan D. Di ujung kiri, pengguna mengirim permintaan ke layanan A. Layanan A mengonversi permintaan menjadi pesan m1_a dan menerbitkannya ke broker pesan. Di bawah broker pesan, garis waktu vertikal menunjukkan bagaimana setiap layanan menangani pesan. Di dalam wilayah berbayang dilabeli sebagai par untuk pemrosesan paralel, pengantara pesan mengirimkan m1_a ke layanan B dan layanan C secara simultan melalui panah putus-putus. Layanan B memproses pesan dan mengembalikan m1_b ke broker pesan. Layanan C memproses pesan dan mengembalikan m1_c ke broker pesan. Di sisi kanan diagram, dua kotak kecil mewakili kondisi tunggu untuk layanan D. Kondisi pertama menyatakan Tunggu hingga m1_b dan m1_c, yang menunjukkan bahwa layanan D tidak dapat dilanjutkan hingga menerima kedua pesan. Kondisi kedua menyatakan Tunggu hingga m1_b. Setelah pemrosesan paralel selesai dan layanan B dan layanan C merespons, broker pesan mengirim m1_c ke layanan D, diikuti oleh m1_b. Layanan D memproses pesan ini dan mengembalikan m1_d ke broker pesan. Di bawah diagram, legenda menjelaskan setiap notasi. Permintaan mengacu pada permintaan HTTP asli yang dikirim ke titik akhir publik. M1_a adalah permintaan HTTP yang dikonversi menjadi pesan. M1_b adalah pesan yang diproses dan dikirim kembali ke broker pesan dari layanan B. M1_c adalah pesan yang diproses dan dikirim kembali ke broker pesan dari layanan C, dan m1_d menunjukkan bahwa m1_b dan m1_c diproses dan dikirim kembali sebagai konfirmasi akhir ke broker pesan. Panah solid menunjukkan terbitkan pesan, dan panah putus-putus menunjukkan pesan berlangganan.

• Observabilitas dalam skala besar. Pola ini menghadirkan tantangan jika jumlah layanan tumbuh pesat. Banyak bagian bergerak independen mempersulit alur kerja antar layanan. Tanpa orkestrator pusat yang memegang status transaksi penuh, tidak ada satu komponen pun yang memiliki pandangan lengkap tentang operasi bisnis dalam penerbangan. Anda harus secara konsisten menggunakan pelacakan terdistribusi dan pengidentifikasi korelasi untuk menjaga pengamatan.

• Komunikasi penangan ketahanan. Dalam desain yang dipandu orkestrator, komponen pusat dapat mendelegasikan tanggung jawab resiliensi, seperti penanganan percobaan ulang untuk kegagalan sementara, tidak sementara, dan kegagalan karena batas waktu, kepada penangan resiliensi khusus.

  Saat Anda menghapus orkestrator dalam desain berbasis koreografi, komponen hilir tidak mengasumsikan tanggung jawab ketahanan. Mereka dikelola secara terpusat oleh pengelola ketahanan. Tetapi komponen hilir harus berkomunikasi dengan handler tersebut secara langsung, yang meningkatkan komunikasi point-to-point.

• Evolusi skema peristiwa. Evolusi skema event dapat menyebabkan perubahan yang mengganggu pada penerima seiring waktu. Dalam pola ini, beberapa layanan independen mengkonsumsi event yang sama. Jika produsen mengubah struktur data suatu peristiwa, itu dapat memecah konsumen hilir yang bergantung pada skema lama. Gunakan registri skema untuk mengelola kontrak peristiwa dan gunakan evolusi yang mendukung kompatibilitas ke belakang saat layanan berkembang secara independen.

• Idempotensi dan urutan peristiwa. Pengiriman dan percobaan ulang setidaknya sekali dapat menghasilkan pesan duplikat, dan konsumen bersamaan dapat memproses pesan secara tidak berurutan. Rancang konsumen agar bersifat idempoten dengan melacak pengenal pesan yang stabil. Ketika pemrosesan berurutan diperlukan, gunakan fitur broker seperti sesi Bus Layanan atau sertakan data urutan atau versi yang memungkinkan konsumen menolak event usang dan mendeteksi adanya celah.

• Publikasi status dan peristiwa atomik. Layanan yang memperbarui penyimpanan datanya dan menerbitkan peristiwa dalam operasi terpisah dapat melakukan satu operasi sementara yang lain gagal. Gunakan pola Transactional Outbox atau mekanisme atomik setara untuk menyimpan perubahan status dan event secara bersamaan sebelum event dipublikasikan oleh proses terpisah.

• Perilaku yang muncul dan badai peristiwa. Topologi peristiwa terdesentralisasi dapat menciptakan perilaku yang muncul dalam skala besar. Ketika banyak layanan bereaksi terhadap peristiwa satu sama lain, sistem dapat secara tidak sengaja menghasilkan perulangan umpan balik atau badai peristiwa. Peristiwa kecil mungkin memicu kaskade reaksi hilir. Untuk mencegah rantai peristiwa melingkar, gunakan pagar pembatas seperti pemfilteran peristiwa, batas konkurensi konsumen, pembatasan, dan aturan eksplisit.

Kapan menggunakan pola ini

Gunakan pola ini ketika:

• Komponen hilir menangani operasi atom secara independen dengan pendekatan fire and forget. Setiap komponen menyelesaikan tugas dan kemudian memberi sinyal penyelesaian ke komponen lain melalui broker pesan. Layanan yang memulai tidak secara aktif mengelola atau melacak tugas setelah mengirimkannya, tetapi layanan hilir masih mengomunikasikan hasil melalui peristiwa.

• Anda berharap untuk sering memperbarui dan mengganti komponen. Pola ini memungkinkan Anda memodifikasi aplikasi dengan lebih sedikit upaya dan gangguan minimal pada layanan yang ada.

• Anda menggunakan arsitektur tanpa server untuk alur kerja sederhana. Komponen dapat berdurasi pendek dan digerakkan oleh peristiwa. Ketika peristiwa terjadi, layanan membuat komponen yang melakukan tugas, dan layanan menghapus komponen setelah menyelesaikan tugas tersebut.

• Komunikasi antara konteks terikat memerlukan konektivitas yang longgar di seluruh batas domain. Untuk komunikasi di dalam satu konteks terikat, pertimbangkan pola orkestrator sebagai gantinya, tergantung pada kompleksitas dan preferensi tim.

• Orkestrator pusat memperkenalkan hambatan performa.

Pola ini mungkin tidak cocok ketika:

• Aplikasi ini kompleks dan memerlukan komponen pusat untuk menangani logika bersama agar komponen hilir tetap ringan.

• Komunikasi titik-ke-titik antara komponen tidak dapat dihindari.

• Anda perlu menggunakan logika bisnis untuk mengonsolidasikan semua operasi yang ditangani komponen hilir.

Desain beban kerja

Evaluasi cara menggunakan pola Koreografi dalam desain beban kerja untuk mengatasi tujuan dan prinsip yang tercakup dalam pilar Azure Well-Architected Framework. Tabel berikut memberikan panduan tentang bagaimana pola ini mendukung tujuan setiap pilar.

Pilar	Bagaimana pola ini mendukung tujuan pilar
Keunggulan Operasional membantu memberikan kualitas beban kerja melalui proses standar dan kohesi tim.	Komponen terdistribusi dalam pola ini otonom dan dirancang agar dapat diganti, sehingga Anda dapat memodifikasi beban kerja dengan perubahan yang kurang keseluruhan pada sistem. - Alat dan proses OE:04
Efisiensi Performa membantu beban kerja Anda memenuhi permintaan secara efisien melalui pengoptimalan dalam penskalaan, data, dan kode.	Pola ini memberikan alternatif ketika penyempitan performa terjadi dalam topologi orkestrasi terpusat. - Perencanaan kapasitas PE:02 - PE:05 Penskalaan dan pemartisian

Seperti halnya pada setiap keputusan desain, pertimbangkan setiap kompromi terhadap sasaran pilar lainnya yang mungkin timbul akibat penerapan pola ini.

Example

Contoh ini menunjukkan pola Koreografi dengan membuat beban kerja berbasis peristiwa cloud-native yang menjalankan fungsi bersama layanan mikro. Ketika klien meminta untuk mengirim paket, sistem penugasan menetapkan sebuah drone. Setelah paket siap untuk diambil oleh drone terjadwal, proses pengiriman dimulai. Saat paket sedang transit, beban kerja menangani pengiriman hingga menerima status dikirim. Untuk arsitektur referensi lengkap, lihat Layanan mikro dengan Azure Container Apps.

Diagram menunjukkan implementasi koreografi berbasis peristiwa untuk sistem pengiriman drone yang menggunakan layanan Azure. Di ujung kiri, terdapat panah yang mewakili permintaan klien, mengarah dari ikon pengguna ke kotak yang berlabel 'ingestion', yang merupakan titik masuk ke lingkungan Azure Container Apps. Dalam lingkungan Container Apps, panah menghubungkan layanan penyerapan, layanan mikro paket, penjadwal drone, dan layanan mikro pengiriman melalui Azure Service Bus. Panah lain menunjuk dari layanan mikro paket ke kotak berlabel Azure Cosmos DB di atas lingkungan Container Apps. Panah berlabel 'shipped' mengalir dari layanan pengiriman menuju Azure Event Grid. Di bawah kotak berlabel "Bus Layanan", sebuah panah menunjuk ke bawah menuju antrean dead-letter (DLQ) yang diwakili oleh ikon lingkaran.

Layanan penyerapan menerima permintaan klien dan mengonversinya menjadi pesan yang menyertakan detail pengiriman. Transaksi bisnis dimulai setelah layanan menggunakan pesan baru tersebut.

Satu transaksi bisnis klien memerlukan tiga operasi bisnis yang berbeda:

• Membuat atau memperbarui paket.

• Tetapkan drone untuk mengirimkan paket.

• Tangani pengiriman, termasuk memeriksa dan mengirim pemberitahuan saat paket dikirim.

Layanan mikro paket, penjadwal drone, dan pengiriman melakukan pemrosesan bisnis. Layanan ini menggunakan olahpesan alih-alih orkestrator pusat untuk berkomunikasi satu sama lain. Setiap layanan harus menerapkan protokol terlebih dahulu yang mengoordinasikan alur kerja bisnis dengan cara yang terdesentralisasi.

Desain

Layanan memproses transaksi bisnis secara berurutan melalui beberapa hop. Setiap hop berbagi satu bus pesan tunggal di antara semua layanan bisnis.

Ketika klien mengirim permintaan pengiriman melalui titik akhir HTTP, layanan penyerapan menerimanya, mengonversinya menjadi pesan, lalu menerbitkan pesan ke bus pesan bersama. Layanan bisnis berlangganan menggunakan pesan baru yang ditambahkan ke bus. Ketika layanan bisnis menerima pesan, layanan tersebut akan berhasil menyelesaikan operasi atau permintaan akan gagal atau waktunya habis. Jika permintaan berhasil, layanan merespons bus dengan kode status Ok, mengangkat pesan operasi baru, dan mengirimkannya ke bus pesan. Jika permintaan gagal atau waktu habis, layanan melaporkan kode alasan kegagalan ke bus pesan dan surat mati pesan melalui Azure Service Bus. Layanan ini juga mematikan pesan yang tidak dapat diterima atau diproses dalam waktu tertentu.

Desain ini menggunakan beberapa bus pesan untuk memproses seluruh transaksi bisnis. Azure Service Bus dan Azure Event Grid menyediakan platform layanan olahpesan untuk desain ini. Beban kerja berjalan pada Azure Container Apps. Layanan penyerapan berjalan sebagai fungsi Azure yang dihosting di Container Apps, sementara layanan paket, penjadwal drone, dan pengiriman berjalan sebagai layanan mikro di lingkungan Container Apps yang sama. Container Apps menangani pemrosesan berbasis peristiwa yang menjalankan logika bisnis.

Desain ini juga memastikan bahwa koreografi terjadi secara berurutan. Namespace Bus Layanan tunggal berisi topik yang memiliki dua langganan dan antrean sadar sesi. Layanan ingestsi menerbitkan pesan ke topik tersebut. Layanan paket dan layanan penjadwal drone berlangganan topik tertentu dan mengirimkan pesan yang memberi tahu antrean tentang permintaan yang berhasil. Sertakan pengidentifikasi sesi umum yang mengaitkan GUID dengan pengidentifikasi pengiriman sehingga layanan pengiriman dapat menghubungkan dua pesan yang dibutuhkan untuk setiap transaksi. Satu pesan mengonfirmasi paket siap, pesan lainnya mengonfirmasi bahwa drone dijadwalkan. Tanpa korelasi berbasis sesi ini, layanan pengiriman tidak memiliki cara untuk mengaitkan pesan terkait di seluruh hop independen, karena tidak ada koordinator pusat yang melacak status transaksi. Layanan pengiriman menunggu dua pesan terkait untuk setiap transaksi. Pesan pertama menunjukkan bahwa paket siap dikirim, dan pesan kedua menandakan bahwa drone dijadwalkan.

Dalam desain ini, Azure Bus Layanan menangani pesan bernilai tinggi yang tidak boleh hilang atau diduplikasi selama seluruh proses pengiriman. Saat paket dikirim, perubahan status diterbitkan ke Event Grid. Pengirim peristiwa tidak memiliki ekspektasi tentang bagaimana perubahan keadaan ditangani. Layanan organisasi hilir yang tidak disertakan desain ini dapat mendengarkan jenis peristiwa ini dan menjalankan logika bisnis tertentu, seperti mengirim email status pesanan kepada pengguna.

Jika Anda menerapkan pola ini di layanan komputasi lain, seperti AKS, Anda dapat menerapkan ambassador sebagai sidecar di pod yang sama dengan aplikasi bisnis. Kolokasi meminimalkan latensi komunikasi, tetapi proksi menambah beban pemrosesan dan penggunaan sumber daya serta meningkat seiring skala aplikasi. Gunakan pendekatan ini saat Anda memerlukan aspek konektivitas yang tidak bergantung pada bahasa dan tidak disediakan oleh platform.

Untuk menghindari operasi ulang bertingkat yang mungkin menyebabkan upaya berulang, layanan bisnis harus segera menandai pesan tak dapat diterima. Perkaya pesan ini dengan menggunakan kode alasan umum atau kode aplikasi yang ditentukan sehingga layanan dapat memindahkannya ke DLQ. Pertimbangkan untuk menerapkan pola Saga untuk mengelola masalah konsistensi dari layanan hilir. Misalnya, layanan lain menangani pesan surat mati untuk tujuan remediasi hanya dengan menjalankan transaksi kompensasi, coba lagi, atau pivot.

Layanan bisnis adalah idempoten untuk memastikan bahwa upaya pengulangan tidak menghasilkan duplikasi sumber daya. Misalnya, layanan paket menggunakan operasi upsert untuk menambahkan data ke penyimpanan data.

Langkah selanjutnya

• Tinjau opsi olahpesan asinkron di Azure untuk mempelajari tentang berbagai pilihan infrastruktur yang tersedia untuk menerapkan alur kerja terdesentralisasi.

Sumber daya terkait

Pertimbangkan pola-pola ini dalam desain Anda untuk koreografi:

• Gunakan pola Ambassador untuk memodularisasi komunikasi layanan bisnis dengan bus pesan.

• Terapkan pola Leveling Beban Berbasis Antrian untuk menangani lonjakan beban kerja.

• Gunakan olahpesan terdistribusi asinkron melalui polaPublisher-Subscriber.

• Gunakan transaksi kompensasi untuk membatalkan serangkaian operasi yang berhasil jika operasi terkait satu atau lebih gagal.