Pola Pengawas Agen Penjadwal

Koordinasikan serangkaian tindakan terdistribusi sebagai operasi logis tunggal sehingga operasi secara keseluruhan berhasil atau gagal. Tangani kegagalan secara transparan, atau batalkan pekerjaan yang selesai. Pendekatan ini menambah ketahanan pada sistem terdistribusi dengan memulihkan dari pengecualian sementara, kesalahan yang tahan lama, dan kegagalan proses yang mengganggu alur kerja multistep yang diorkestrasi di seluruh layanan dan sumber daya jarak jauh.

Konteks dan masalah

Aplikasi sering melakukan tugas yang mencakup beberapa langkah, dan beberapa langkah mungkin memanggil layanan jarak jauh atau mengakses sumber daya jarak jauh di bawah orkestrasi logika aplikasi. Interaksi dengan apa pun di luar proses lokal mengekspos tugas ke berbagai mode kegagalan. Logika orkestra harus menangani mode kegagalan ini tanpa kehilangan integritas operasi secara keseluruhan.

Anda dapat menangani situasi sederhana, seperti kesalahan sementara yang diselesaikan sendiri, dengan menggunakan pendekatan seperti pola Coba Lagi. Ketika kesalahan lebih permanen, atau ketika orkestrator itu sendiri gagal, sistem harus memulihkan status yang konsisten dari rekaman tahan lama dan memastikan integritas operasi keseluruhan.

Solusi

Pola Supervisor Agen Penjadwal mengoordinasikan tugas terdistribusi multitahap melalui tiga aktor logis. Aktor ini mengatur langkah-langkah yang akan dilakukan sebagai bagian dari tugas keseluruhan, dan menangani eksekusi yang berhasil dan gagal.

Scheduler

Scheduler mengatur langkah-langkah yang membentuk tugas dan mengatur eksekusinya. Scheduler bertanggung jawab untuk menggabungkan langkah-langkah ke dalam alur atau alur kerja, dan menjalankannya dalam urutan yang benar. Saat setiap langkah berlangsung, Scheduler merekam statusnya, seperti langkah belum dimulai, langkah berjalan, atau langkah selesai. Status ini juga mencakup batas waktu penyelesaian yang membatasi berapa lama langkah tersebut boleh berlangsung.

Ketika langkah memerlukan layanan atau sumber daya jarak jauh, Scheduler memanggil Agen yang sesuai dan meneruskan detail kerja ke dalamnya. Scheduler biasanya berkomunikasi dengan Agen melalui pesan permintaan/respons asinkron, sering diimplementasikan melalui antrean. Anda dapat menggunakan teknologi olahpesan terdistribusi lainnya sebagai gantinya.

Note

Scheduler melakukan fungsi serupa dengan peran Manajer Proses dalam pola Manajer Proses. Mesin alur kerja yang biasanya dikontrol Scheduler mendefinisikan dan mengimplementasikan alur kerja, memisahkan logika alur kerja bisnis dari Scheduler itu sendiri.

Agen

Agen merangkum panggilan ke layanan jarak jauh atau akses ke sumber daya jarak jauh yang dirujuk oleh langkah tugas. Setiap Agen biasanya menangani panggilan ke satu layanan atau sumber daya dan menerapkan penanganan kesalahan yang sesuai serta logika percobaan ulang dalam batas waktu penyelesaian yang ditetapkan oleh Penjadwal. Jika mekanisme percobaan ulang digunakan, Agen menggunakan pengenal yang tetap di semua percobaan ulang. Layanan hilir dapat menggunakan ini untuk deduplikasi.

Jika langkah-langkah yang berbeda dalam alur kerja menggunakan layanan atau sumber daya yang berbeda, setiap langkah dapat mereferensikan Agen yang berbeda. Pemetaan itu adalah detail implementasi pola. Untuk panduan tentang merancang strategi coba lagi, lihat Praktik terbaik untuk penanganan kesalahan sementara.

Supervisor

Supervisor memantau status langkah-langkah yang dilakukan Penjadwal. Supervisor berjalan secara berkala dengan frekuensi yang ditentukan oleh beban kerja, dan memeriksa status langkah yang dicatat oleh Scheduler. Jika Supervisor menemukan langkah-langkah yang kehabisan waktu atau gagal, Itu mengatur agar Agen yang sesuai memulihkan langkah, atau memicu tindakan perbaikan lain yang mungkin termasuk memodifikasi status langkah. Supervisor hanya meminta tindakan pemulihan ini. Penjadwal dan Agen mengimplementasikannya.

Interaksi

Scheduler, Agent, dan Supervisor adalah komponen logis, dan implementasi fisiknya tergantung pada teknologi yang Anda gunakan. Misalnya, Anda dapat mengimplementasikan beberapa Agen logis sebagai bagian dari satu layanan web atau sebagai aktivitas di dalam worker yang dihosting yang sama.

Scheduler menyimpan kemajuan tugas dan status setiap langkah dalam penyimpanan data tahan lama yang disebut penyimpanan status. Supervisor menggunakan informasi ini untuk menentukan apakah langkah gagal. Diagram berikut menunjukkan hubungan antara Scheduler, Agen, Supervisor, dan penyimpanan state.

Di kiri atas, Scheduler mengatur dan menjalankan langkah-langkah. Garis panah ganda berlabel "Scheduler meminta Agen untuk mengakses sumber daya jarak jauh" mengarah ke Agen di sebelah kanan, dan garis panah ganda berlabel "Agen mengakses sumber daya atau layanan jarak jauh" mengarah dari Agen ke sumber daya jarak jauh. Di bawahnya, garis panah ganda menunjuk dari Scheduler ke Agen lain lalu ke layanan jarak jauh. Garis berpanah ganda lainnya berlabel "Penjadwal menjaga status langkah" mengarah ke bawah menuju penyimpanan status. Garis panah ganda berlabel "Supervisor memantau status langkah" menghubungkan penyimpanan status dan Supervisor di sebelah kanannya. Panah yang berlabel "Supervisor meminta langkah diulangi" mengarah dari Supervisor kembali ke atas dan ke kiri menuju Scheduler.

• Scheduler mengatur dan menjalankan langkah-langkah yang terdiri dari tugas sebagai alur kerja.
• Langkah dalam alur kerja dapat mengirim permintaan ke Agen untuk mengakses sumber daya jarak jauh atau memanggil layanan jarak jauh. Permintaan dan respons biasanya dikirim secara asinkron.
• Agen mengakses sumber daya atau layanan jarak jauh. Agen harus menyertakan penanganan kesalahan dan mekanisme coba ulang.
• Scheduler menjaga status setiap langkah dalam state store saat langkah tersebut dimulai dan diselesaikan.
• Penyelia memantau status setiap langkah dalam penyimpanan state, dan mungkin meminta pembaruan status suatu langkah.
• Supervisor meminta Scheduler untuk mencoba kembali langkah yang gagal.

Ketika aplikasi siap untuk menjalankan tugas, aplikasi mengajukan permintaan ke Scheduler. Scheduler merekam status awal untuk tugas dan langkah-langkahnya, seperti langkah yang belum dimulai, di penyimpanan status, lalu mulai menjalankan operasi yang ditentukan alur kerja. Saat Scheduler memulai setiap langkah, Scheduler memperbarui status langkah tersebut, seperti langkah yang berjalan, di penyimpanan status.

Jika langkah merujuk layanan jarak jauh atau sumber daya, Scheduler mengirimkan pesan ke Agen yang sesuai. Pesan memuat informasi yang diperlukan Agen untuk memanggil layanan atau mengakses sumber daya, beserta batas waktu penyelesaian dan batas percobaan ulang untuk operasi tersebut.

Agen dapat menerapkan logika coba lagi apa pun yang sesuai untuk pekerjaannya, tetapi jika Agen tidak menyelesaikan pekerjaannya dalam waktu selesai, Scheduler mengasumsikan bahwa operasi gagal dan berhenti menunggu respons. Agen harus mematuhi tenggat waktu dan tidak boleh memulai efek samping baru setelah waktunya habis, namun pekerjaan yang sudah berlangsung mungkin tetap berlanjut.

Jika Agen berhasil menyelesaikan operasinya, Agen mengembalikan respons ke Scheduler. Scheduler memperbarui status, untuk langkah selesai misalnya, dan memulai langkah berikutnya. Proses ini berlanjut sampai seluruh tugas selesai.

Scheduler harus mengabaikan respons yang terlambat, dan Agen tidak boleh mencoba pemulihan alur kerja sendiri. Jika Agen itu sendiri gagal, Scheduler juga tidak menerima respons. Status dalam penyimpanan state sengaja tidak membedakan antara langkah yang melampaui batas waktu dan langkah yang gagal.

Ketika suatu langkah mengalami habis waktu atau gagal, catatan di penyimpanan status masih menunjukkan bahwa langkah tersebut berstatus berjalan, tetapi dengan batas waktu penyelesaian yang sudah kedaluwarsa. Supervisor memindai rekaman dalam kondisi ini dan mengatur pemulihan.

Supervisor juga perlu mencegah langkah yang sama untuk mencoba kembali tanpa batas waktu. Supervisor menyimpan jumlah percobaan ulang untuk setiap langkah bersama dengan informasi status di penyimpanan status. Jika jumlahnya melebihi ambang batas yang telah ditentukan sebelumnya, Supervisor dapat diatur untuk menunggu jangka waktu yang lebih lama sebelum meminta Scheduler untuk mencoba kembali langkah tersebut, dalam hal gangguan yang mendasarinya teratasi selama interval tersebut.

Salah satu strategi Supervisor yang mungkin adalah memperpanjang nilai complete-by dan mengirim pesan ke Scheduler yang mengidentifikasi langkah yang batas waktunya telah habis, sehingga Scheduler dapat mencobanya lagi. Desain ini mengharuskan logika langkah bersifat idempoten, karena pekerjaan yang sama mungkin dilakukan lebih dari sekali.

Atau, Supervisor dapat meminta Scheduler untuk membatalkan seluruh tugas dengan memicu transaksi kompensasi. Pendekatan ini tergantung pada Penjadwal dan Agen yang memberikan informasi yang cukup untuk menerapkan operasi kompensasi untuk setiap langkah yang telah berhasil diselesaikan. Log kompensasi memerlukan pengurutan serta durabilitas, karena operasi kompensasi biasanya dijalankan dalam urutan terbalik dari langkah-langkah yang telah selesai. Operasi kompensasi yang itu sendiri gagal membuat tugas berada dalam keadaan yang tidak selesai maupun tidak dikembalikan ke kondisi semula secara bersih. Penyimpanan state harus dapat merepresentasikan kondisi ini agar operator dapat menemukannya dan menyelidikinya.

Note

Supervisor tidak memantau Penjadwal dan Agen dan memulai ulang jika gagal. Peran itu milik infrastruktur hosting. Supervisor juga tidak perlu mengetahui operasi bisnis yang dijalankan oleh Scheduler, termasuk cara melakukan kompensasi jika operasi tersebut gagal. Pengetahuan itu milik logika alur kerja yang dijalankan Scheduler. Supervisor hanya bertanggung jawab untuk mendeteksi bahwa suatu langkah gagal dan mengatur agar langkah tersebut diulangi atau seluruh tugas yang memuat langkah yang gagal tersebut dibatalkan.

Dalam implementasi aktual dari pola ini, beberapa instans Scheduler mungkin berjalan bersamaan, masing-masing menangani subset tugas. Sistem juga dapat menjalankan beberapa instans setiap Agen, atau beberapa Supervisor. Ketika lebih dari satu Supervisor aktif, Supervisor harus berkoordinasi sehingga mereka tidak bersaing untuk memulihkan langkah atau tugas yang gagal yang sama. Pola Pemilihan Pemimpin adalah salah satu cara untuk mengoordinasikan Supervisor.

Manfaat utama dari pola ini adalah bahwa sistem tetap tahan terhadap kegagalan sementara dan tidak dapat dipulihkan, dan Anda dapat membangunnya menjadi penyembuhan diri. Jika Agen atau Penjadwal mengalami kegagalan, Anda dapat menjalankan instans baru, dan Supervisor dapat mengatur agar tugas yang terdampak dapat dilanjutkan kembali. Jika Supervisor itu sendiri mengalami kegagalan, instance lain dapat mengambil alih dan melanjutkan dari titik tempat instance sebelumnya berhenti. Saat Supervisor berjalan secara terjadwal, instans baru akan dimulai secara otomatis pada interval berikutnya. Anda juga dapat mereplikasi penyimpanan status untuk ketahanan yang lebih tinggi.

Masalah dan pertimbangan

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

• Kompleksitas implementasi. Pola ini sulit diterapkan dan memerlukan pengujian menyeluruh dari setiap mode kegagalan yang dapat dialami sistem. Rencanakan pengujian injeksi kesalahan bersama dengan pengujian fungsional.

• Coba lagi amplifikasi. Batas percobaan ulang yang independen pada lapisan Agent, runtime orkestrasi, pustaka klien, perpesanan, dan Supervisor melipatgandakan jumlah panggilan ke dependensi yang mengalami kegagalan. Tetapkan Scheduler sebagai pemilik anggaran percobaan ulang end-to-end yang persisten, dan konfigurasikan atau nonaktifkan mekanisme percobaan ulang di lapisan lain agar total maksimum gabungannya tidak melebihi anggaran tersebut.

• Kontrol penerimaan. Pola tidak membatasi berapa banyak pekerjaan yang dapat dilakukan dalam penerbangan sekaligus. Karena Scheduler dirancang agar tidak pernah kehilangan tugas yang diterimanya, layanan hilir yang lambat atau gagal akan menghasilkan jumlah record pemrosesan yang terus bertambah, alih-alih menimbulkan tekanan balik yang terlihat bagi pihak yang mengirimkan tugas. Jalur pengajuan memerlukan mekanisme kontrol masuknya sendiri, seperti antrean berkapasitas terbatas, batas jumlah tugas yang sedang diproses secara bersamaan, atau penolakan pengajuan baru ketika jumlah tugas tertunda melampaui ambang batas. Backpressure ini membantu memastikan bahwa gangguan pada sistem downstream tidak menyebabkan backlog pada state store bertambah tanpa batas tanpa disadari.

• Ketahanan status pemulihan. Logika pemulihan dan percobaan ulang Scheduler bersifat kompleks dan bergantung pada state yang disimpan dalam penyimpanan state. Anda mungkin juga perlu merekam informasi yang diperlukan untuk menjalankan transaksi kompensasi dalam penyimpanan persisten, dan transaksi kompensasi itu sendiri dapat gagal. Perlakukan penyimpanan status dan log transaksi kompensasi apa pun sebagai aset tahan lama kelas satu. Aset ini harus lebih lama dari Scheduler, Agen, dan Supervisor, dan mereka harus dapat dipulihkan secara independen dari pekerja yang menulis kepada mereka.

  Important

  Log kompensasi harus mewarisi klasifikasi data data yang perlu dilacak. Jika langkah menerima data pelanggan atau pembayaran, log transaksi kompensasi mewarisi sensitivitas tersebut dan aturan retensi yang menyertainya.

• Masalah penulisan ganda. Mengajukan tugas biasanya melibatkan lebih dari satu operasi tulis persisten. Misalnya, sebuah tugas mungkin perlu menulis rekaman aplikasi ke dalam basis data bisnis dan rekaman awal ke dalam penyimpanan status. Penulisan ini tidak berbagi transaksi, jadi jika hanya satu penulisan yang selesai, rekaman aplikasi mungkin tidak memiliki catatan penyimpanan status atau catatan penyimpanan status mungkin tidak memiliki catatan aplikasi. Pola saat ini sendiri tidak mengatasi masalah penulisan ganda ini. Solusi umum mencakup melakukan penulisan dalam orkestrasi yang persisten dengan penghapusan kompensasi jika terjadi kegagalan, menerapkan pola Outbox Transaksional, atau menggunakan pengenal yang stabil seperti ID tugas milik aplikasi itu sendiri agar setiap penulisan dapat diulangi dengan aman.

• Pembuatan versi alur kerja dan status. Tugas yang berjalan lama dapat mencakup penyebaran, sehingga perubahan pada logika alur kerja atau status yang bertahan dapat mencegah pemutaran ulang, pemulihan, atau kompensasi untuk pekerjaan dalam penerbangan. Beri versi pada kedua kontrak, dan pertahankan penanganan kode dan state yang kompatibel hingga tidak ada lagi tugas aktif yang bergantung pada keduanya.

• Hasil kompensasi. Transaksi kompensasi dapat selesai, gagal, atau terhenti di tengah jalan. Mesin status yang dikelola Scheduler perlu mewakili semua status ini. Jika Error adalah satu-satunya keadaan terminal, proses kompensasi yang macet akan tampak sama dengan langkah yang gagal sebelum kompensasi dijalankan, dan operator kehilangan sinyal yang mereka perlukan untuk melakukan intervensi. Membedakan kompensasi yang sedang berlangsung, kompensasi selesai, dan kompensasi gagal dalam skema penyimpanan status daripada menciutkannya menjadi satu status Kesalahan .

• Siklus penyelia Seberapa sering Supervisor dijalankan merupakan kompromi yang disengaja. Proses ini harus berjalan cukup sering agar langkah yang gagal atau melampaui batas waktu tidak menghambat pekerjaan dalam jangka waktu yang lama, tetapi jangan terlalu sering sehingga menjadi sumber beban dan biaya bagi penyimpanan status. Sesuaikan interval berdasarkan durasi langkah yang umum dan penundaan deteksi yang dapat diterima untuk langkah yang macet, lalu tinjau kembali seiring bertambahnya volume alur kerja.

• Idempotensi langkah. Agen mungkin menjalankan langkah lebih dari sekali. Misalnya, Supervisor mungkin memperpanjang batas waktu penyelesaian dan meminta Scheduler untuk menjalankan ulang langkah yang eksekusi awalnya telah menimbulkan dampak yang tidak pernah diketahui Scheduler. Oleh karena itu, logika yang mengimplementasikan setiap langkah harus idempoten.

• Visibilitas operasional. Perilaku pola saat dijalankan tercermin dalam transisi pada penyimpanan status, bukan dalam respons sinkron. Operator hanya dapat melihat apa yang dihasilkan oleh penyimpanan status dan pekerja. Tentukan apa yang harus dipancarkan Oleh Penjadwal, Agen, dan Supervisor, dan ambang batas mana yang harus memicu pemberitahuan.

• Penjadwal memulai ulang dan memulihkan. Jika Scheduler dimulai ulang setelah kegagalan, atau alur kerja yang dijalankan Scheduler berakhir secara tak terduga, Scheduler harus dapat menentukan status tugas apa pun yang ditanganinya ketika gagal dan melanjutkan tugas dari titik tersebut. Detail implementasi pemulihan ini biasanya khusus sistem. Misalnya, Scheduler yang dibangun pada runtime orkestrasi yang di-checkpoint dapat mengandalkan runtime untuk memutar ulang riwayat dan melanjutkan, sedangkan Scheduler kustom harus membangun kembali status dalam penerbangan dari penyimpanan status itu sendiri. Jika tugas tidak dapat dipulihkan, pekerjaan yang sudah dilakukan untuk tugas tersebut mungkin perlu dibatalkan, yang dapat memerlukan transaksi kompensasi.

Kapan menggunakan pola ini

Gunakan pola ini ketika:

• Proses berjalan dalam beban kerja terdistribusi dan harus tetap tahan terhadap kegagalan komunikasi dan kegagalan operasional di seluruh layanan dan sumber daya yang dikoordinasikannya.

• Pekerjaan latar belakang mengatur alur kerja multistep yang langkah-langkahnya melibatkan layanan atau sumber daya jarak jauh, dan alur kerja secara keseluruhan harus diselesaikan atau dibatalkan dengan bersih. Contoh umum termasuk pemrosesan pesanan dan provisi sumber daya. Untuk informasi selengkapnya, lihat Praktik terbaik untuk pekerjaan latar belakang.

Pola ini mungkin tidak cocok ketika:

• Tugas tidak memanggil layanan jarak jauh atau mengakses sumber daya jarak jauh. Tidak ada permukaan kegagalan terdistribusi untuk peran Scheduler, Agent, dan Supervisor untuk dimitigasi. Overhead koordinasi dari pola ini menambah biaya tanpa memberikan manfaat resiliensi.

Desain beban kerja

Evaluasikan cara menggunakan pola Scheduler Agent Supervisor dalam desain beban kerja untuk memenuhi tujuan dan prinsip yang dibahas dalam pilar Azure Well-Architected Framework. Tabel berikut memberikan panduan tentang bagaimana pola ini mendukung tujuan setiap pilar.

Prinsip Dasar	Bagaimana pola ini mendukung tujuan pilar
Keputusan desain Keandalan membantu beban kerja Anda menjadi tangguh tidak berfungsi dan memastikan bahwa memulihkan ke keadaan yang berfungsi penuh setelah kegagalan terjadi.	Pola ini menggunakan penyimpanan status persisten dan proses supervisor berkala untuk mendeteksi langkah-langkah yang melewati batas waktu atau gagal serta untuk menjalankan pemulihan. - RE:05 Redundansi - RE:07 Perlindungan Diri
Efisiensi Performa membantu beban kerja Anda memenuhi permintaan secara efisien melalui pengoptimalan dalam penskalaan, data, dan kode.	Pola ini memisahkan orkestrasi pekerjaan multi-langkah yang berjalan dalam waktu lama dari Agen yang menjalankan langkah-langkah tersebut, sehingga langkah-langkah itu dapat dialokasikan kepada Agen yang memiliki kapasitas. Pekerjaan berprioritas lebih tinggi dapat dijadwalkan sebelum pekerjaan berprioritas lebih rendah ketika implementasi memberikan sinyal prioritas eksplisit. - PE:05 Penskalaan dan pemartisian - PE:09 Alur Kritis

Jika pola ini memperkenalkan kompromi di dalam pilar, bandingkan dengan tujuan pilar lain.

Example

Contoh ini menyebarkan aplikasi web yang menerapkan sistem e-niaga pada Microsoft Azure. Pengguna menelusuri produk dan melakukan pemesanan melalui front end web, dan pekerja latar belakang di jalur pemrosesan pesanan memanggil layanan jarak jauh yang rentan terhadap kesalahan sementara dan tahan lama. Pemrosesan pesanan menerapkan pola Pengawas Agen Penjadwal dengan menggunakan Durable Functions, Azure Service Bus, dan Azure Cosmos DB.

Aktivitas pengajuan menulis ke database pesanan dan penyimpanan status di Cosmos DB, orkestrator Durable Functions mengambil rekaman status tertunda dan mendistribusikan tugas kepada Agen melalui sepasang antrean permintaan dan respons di Bus Layanan, dan Supervisor memindai penyimpanan status untuk waktu CompleteBy yang kedaluwarsa.

Diagram berikut menunjukkan tampilan tingkat tinggi solusi Azure.

Di kiri atas, ikon instans aplikasi menunjuk ke ikon proses pengiriman melalui antrean pesan. Panah menunjuk dari proses pengiriman ke database pesanan di kanan atas dan ke penyimpanan status di kanan bawah. Panah ganda mengarah ke kanan dan ke bawah dari basis data pesanan ke Scheduler, dan panah ganda mengarah ke kanan dan ke atas dari penyimpanan status ke Scheduler. Panah menunjuk ke kanan dari Penjadwal ke Agen melalui antrean pesan. Sebuah panah ganda menghubungkan Agen dengan layanan jarak jauh di sebelah kanannya. Sebuah panah mengarah dari Agen kembali ke Penjadwal melalui antrean pesan. Panah ganda menghubungkan penyimpanan status dan Supervisor di sebelah kanannya.

1. Aplikasi mengirimkan permintaan ke antrean untuk memproses pesanan.
2. Proses pengajuan mengambil permintaan, memasukkan detail pesanan ke dalam basis data pesanan, dan membuat catatan untuk pesanan di penyimpanan status.
3. Scheduler mencari pesanan dengan LockedBy diatur ke null di penyimpanan status, dan logika alur kerja di Scheduler menangani pesanan.
4. Logika alur kerja mengirim permintaan ke dan menerima respons dari Agen melalui antrean pesan.
5. Tugas alur kerja menggunakan Agen untuk memanggil layanan jarak jauh.
6. Supervisor mencari pesanan dengan nilai CompleteBy yang telah kedaluwarsa dan memperbarui nilai ini agar Scheduler dapat mencoba kembali proses tersebut.

Pengajuan

Saat pelanggan membuat pesanan, frontend web mengirimkan pesan pesanan ke antrean Bus Layanan. Fungsi pengiriman menerima pesan dalam mode PeekLock, menyisipkan detail pesanan ke dalam database pesanan, dan membuat rekaman penyimpanan status untuk proses pesanan.

Karena database pesanan dan database yang dibuat dengan Azure Cosmos DB adalah sumber daya yang berbeda dan tidak berbagi transaksi, fungsi memperlakukan setiap penulisan sebagai idempoten secara independen. Fungsi ini menggunakan ID pesanan sebagai kunci yang stabil, membuat salah satu catatan jika belum ada, dan hanya menerima catatan yang sudah ada setelah memverifikasi bahwa data pesanan yang tidak dapat diubah cocok dengan pesan. Data yang bertentangan menyebabkan fungsi mematikan pesan dan memperingatkan operator, daripada menimpa rekaman.

Catatan berisi bidang berikut:

Ladang	Deskripsi
OrderID	ID pesanan dalam database pesanan, digunakan sebagai ID dokumen Azure Cosmos DB dan kunci partisi.
LockedBy	ID instans orkestrasi untuk percobaan tertentu yang menangani pesanan. Beberapa orkestrasi Scheduler mungkin sedang berjalan, tetapi transisi status bersyarat hanya memungkinkan satu upaya aktif untuk mengklaim suatu pesanan.
CompleteBy	Waktu di mana pesanan harus diproses.
ProcessState	Status terkini tugas yang bertugas menangani pesanan. Status yang mungkin adalah: - Pending: Urutan dibuat tetapi pemrosesan belum dimulai. - Processing: Pesanan saat ini sedang diproses. - Processed: Pesanan berhasil diproses. - Error: Pemrosesan pesanan gagal.
FailureCount	Jumlah upaya pemrosesan yang gagal atau melewati batas waktu yang tercatat untuk pesanan.

Ketika aktivitas pengajuan pertama kali menulis rekaman, aktivitas ini menyalin OrderID dari pesanan baru, menetapkan LockedBy dan CompleteBy ke null, menetapkan ProcessState ke Pending, dan menetapkan FailureCount ke 0.

Note

Dalam contoh ini, logika penanganan pesanan sengaja sederhana dan memiliki satu langkah yang memanggil layanan jarak jauh. Dalam skenario multistep yang lebih kompleks, aktivitas pengiriman akan membuat satu rekaman penyimpanan status per langkah, menyimpan OrderID sebagai kunci partisi, tetapi menggunakan ID item unik seperti {OrderID}:{StepID}, sehingga Penjadwal dan Pengawas dapat beralasan tentang setiap status langkah secara independen.

Scheduling

Scheduler adalah orkestrator Durable Functions. Fungsi pemula memeriksa Azure Cosmos DB untuk record yang nilai LockedBy-nya null dan ProcessState bernilai Pending. Fungsi ini membuat ID instans orkestrasi khusus untuk percobaan dari OrderID dan nomor percobaan berikutnya. Pembaruan kondisional menetapkan Processing ke LockedBy dan ProcessState ke ID instans tersebut sebelum starter menjadwalkan orkestrasi. Klaim ini mencegah dua starter menjadwalkan percobaan yang sama.

Setiap pembaruan dari orkestrasi juga memverifikasi bahwa LockedBy masih sesuai dengan ID instansnya. Pemeriksaan ini mencegah agar upaya yang kedaluwarsa tidak mengubah status upaya penggantian. Paralelisme lintas urutan berasal dari menjalankan banyak instans orkestrasi secara bersamaan, bukan dari paralelisme di dalam satu urutan. Orkestrasi menetapkan CompleteBy dan menjalankan alur kerja.

Orkestrator mengambil detail pesanan dari database pesanan dan menjalankan alur kerja sebagai urutan fungsi aktivitas. Saat suatu langkah memerlukan layanan jarak jauh, langkah tersebut memanggil Agen.

Execution

Agen dapat berupa fungsi aktivitas ketika pekerjaannya berjalan singkat dan dijalankan dalam Function App yang sama, atau dapat berupa pekerja terpisah yang diakses melalui sepasang antrean permintaan/respons Bus Layanan ketika dijalankan dalam runtime yang berbeda atau melintasi batas kepercayaan. Dalam kedua kasus, orkestrator menjalankan pengatur waktu persisten beradu dengan respons Agen untuk mendeteksi CompleteBy tenggat waktu.

Ketika Agen dihubungi melalui Bus Layanan, fungsi yang dipicu oleh antrean menerima respons dan menggunakan klien Durable Functions untuk memicu peristiwa eksternal yang mencakup ID instans orkestrasi dan ID peristiwa yang stabil. Orkestrator menghapus duplikasi event eksternal dengan mengaktifkan deteksi duplikat dan menetapkan MessageId yang stabil pada setiap permintaan, sehingga Bus Layanan dapat membuang duplikat yang disebabkan oleh percobaan ulang.

Jika Agen menerima respons dari layanan jarak jauh sebelum timer tahan lama diaktifkan, Agen mengembalikan hasilnya ke orkestrator. Orkestrator menyelesaikan langkah dan memperbarui ProcessStateProcessed hanya jika LockedBy masih mengidentifikasi orkestrasi saat ini. Jika timer diaktifkan terlebih dahulu, orkestrator memperlakukan langkah sebagai gagal, berhenti menunggu, dan selesai tanpa mengubah rekaman status.

Agen secara kooperatif berhenti memulai efek samping baru setelah tenggat waktunya sendiri, tetapi pekerjaan yang sudah berlangsung mungkin berlanjut. Rekaman penyimpanan status kemudian tetap dalam status dengan nilai kedaluwarsa ProcessingCompleteBy , memungkinkan Supervisor untuk mengatur pemulihan. Gunakan idempotensi atau token fencing yang diberlakukan oleh target untuk mencegah percobaan yang tumpang tindih menggandakan atau menimbulkan konflik dengan efek samping.

Jika Agen mendeteksi kesalahan non-sementara yang tidak dapat dipulihkan saat menghubungi layanan jarak jauh, agen mengembalikan respons kesalahan ke orkestrator. Orkestrator mengatur ProcessState ke Error dan menaikkan peristiwa yang memperingatkan operator, yang dapat menyelidiki kegagalan dan mengirim ulang langkah pemrosesan yang gagal.

Pengawasan

Supervisor secara berkala melakukan kueri terhadap penyimpanan status Azure Cosmos DB untuk pesanan dengan status Processing dengan CompleteBy yang telah kedaluwarsa. Karena OrderID adalah kunci partisi, kueri ini mencapai setiap partisi fisik bahkan ketika ProcessState dan CompleteBy diindeks. Proses ini membatasi setiap pemindaian dengan CompleteByjendela waktu, jumlah hasil maksimum, dan paginasi token kelanjutan, serta memantau biaya request unit (RU).

Beban kerja yang lebih besar menggunakan indeks pemulihan atau antrean terpisah yang dipartisi sesuai dengan pola akses Supervisor. Ketika Supervisor menemukan catatan yang kedaluwarsa, ia menggunakan pembaruan bersyarat yang memverifikasi nilai LockedBy yang kedaluwarsa sebelum menambah FailureCount. Jika FailureCount di bawah ambang batas yang dikonfigurasi, Supervisor mengatur ulang LockedBy ke null, memperbarui CompleteBy dengan waktu kedaluwarsa baru, dan mengatur ProcessState kembali ke Pending, yang memungkinkan starter untuk menjadwalkan upaya baru. Jika FailureCount melebihi ambang batas, Supervisor menganggap kegagalan tersebut tidak bersifat sementara, menetapkan ProcessState ke Error, dan memicu suatu peristiwa yang memberi tahu operator.

Note

Supervisor di-host sebagai fungsi yang dipicu pengatur waktu saat pemindaian singkat dan ringan, atau sebagai job Azure Container Apps terjadwal saat pemindaian memerlukan image kontainer kustom, eksekusi berdurasi lebih lama, atau sidecar. Kedua opsi berjalan dengan jadwal bergaya cron dan cocok untuk tugas berkala berdurasi singkat yang dijalankan oleh Supervisor. Pemicu timer menggunakan kunci penyimpanan di seluruh instans yang diskalakan dalam satu aplikasi fungsi. Penyebaran independen atau pekerjaan Aplikasi Kontainer yang dapat tumpang tindih menggunakan klaim pemulihan kondisional yang dijelaskan sebelumnya, atau Anda dapat mengoordinasikannya melalui pola Pemilihan Pemimpin.

Pelaporan status

Orkestrator mungkin juga perlu terus memberi tahu aplikasi yang mengirimkan pesanan tentang kemajuan dan status akhir, yang tidak ditunjukkan dalam diagram. Aplikasi dan orkestrator sengaja dipisahkan. Aplikasi tidak tahu instans orkestrasi mana yang menangani pesanan, dan orkestrasi tidak tahu instans aplikasi mana yang mempostingnya. Karena pemisahan ini, orkestrator tidak dapat mengembalikan pembaruan kemajuan secara sinkron.

Untuk melaporkan kembali status pesanan, setiap aplikasi pengirim menyediakan antrean respons Bus Layanan privat dengan akses terkontrol. Permintaan yang dikirim ke aktivitas pengiriman mencakup pengidentifikasi antrean tersebut, yang dicatat aktivitas pengiriman pada catatan penyimpanan status pesanan sehingga orkestrator dapat memposting ke antrean yang tepat daripada menyiarkan. Orkestrator kemudian memposting pesan status seperti permintaan yang diterima, pesanan selesai, atau pesanan gagal ke antrean tersebut OrderID , termasuk sehingga aplikasi dapat menghubungkan setiap pesan dengan permintaan asli.

Teknologi pendukung

Petakan peran logis pola ke layanan yang sesuai dengan alur kerja dan persyaratan operasional Anda:

• Penjadwal: Gunakan Durable Functions untuk orkestrasi pertama kode atau Azure Logic Apps untuk alur kerja visual dan integrasi berbasis konektor.

• Olahpesan agen: Gunakan antrean Bus Layanan untuk permintaan asinkron dan pesan respons.

• Penyimpanan status: Gunakan Azure Cosmos DB untuk status dokumen atau Azure SQL Database untuk status relasional dan transaksi lintas catatan.

• Supervisor: Gunakan pemicu pengatur waktu Functions untuk pemindaian ringan atau job Container Apps saat Anda memerlukan runtime kontainer.

• Log kompensasi: Simpan rekaman kompensasi dengan status tugas atau di penyimpanan tabel Azure atau Blob Storage.

Langkah berikutnya

• Pilih antara Azure Functions dan Azure Logic Apps untuk orkestrasi alur kerja.
• Buat versi orkestrasi Durable Functions untuk melindungi alur kerja yang sedang berjalan selama penerapan.
• Cegah kehilangan pesan dan pemrosesan duplikat di Azure Service Bus dengan menggabungkan penyelesaian pesan, idempotensi, dan penanganan surat mati.

Sumber daya terkait

Pola berikut mungkin juga relevan ketika Anda menerapkan pola ini:

• Pola percobaan ulang. Agen dapat menggunakan pola ini untuk mencoba kembali operasi secara transparan yang mengakses layanan atau sumber daya jarak jauh dan sebelumnya gagal. Gunakan saat penyebab kegagalan diharapkan bersifat sementara dan dapat diperbaiki dengan coba lagi.

• Pola Pemutus Sirkuit. Agen yang terhubung ke layanan atau sumber daya jarak jauh dapat menggunakan pola ini untuk menangani kesalahan yang membutuhkan waktu variabel untuk memperbaiki, sehingga panggilan berulang tidak menumpuk terhadap dependensi yang tidak mungkin merespons.

• Pola Transaksi Kompensasi. Jika Scheduler tidak berhasil menyelesaikan alur kerjanya, pekerjaan yang sudah dilakukan mungkin perlu dibatalkan. Pola Transaksi Kompensasi menjelaskan cara membatalkan pekerjaan tersebut untuk operasi yang mengikuti model konsistensi eventual, yang umum dalam proses bisnis jangka panjang yang dikoordinasikan oleh Scheduler.

• Pola Pemilihan Pemimpin. Ketika beberapa instans Supervisor berjalan secara bersamaan, instans-instans tersebut harus berkoordinasi agar tidak saling bersaing untuk memulihkan langkah gagal yang sama. Pola Pemilihan Pemimpin menjelaskan cara memilih satu koordinator untuk pekerjaan itu.