Pola sebar-kumpulkan

Niat

Pola scatter-gathering adalah pola perutean pesan yang melibatkan penyiaran permintaan serupa atau terkait ke beberapa penerima, dan menggabungkan tanggapan mereka kembali ke dalam satu pesan dengan menggunakan komponen yang disebut agregator. Pola ini membantu mencapai paralelisasi, mengurangi latensi pemrosesan, dan menangani komunikasi asinkron. Sangat mudah untuk menerapkan pola scatter-gathering dengan menggunakan pendekatan sinkron, tetapi pendekatan yang lebih kuat melibatkan penerapannya sebagai perutean pesan dalam komunikasi asinkron, baik dengan atau tanpa layanan pesan.

Motivasi

Dalam pemrosesan aplikasi, permintaan yang mungkin membutuhkan waktu lama untuk diproses secara berurutan dapat dibagi menjadi beberapa permintaan yang diproses secara paralel. Anda juga dapat mengirim permintaan ke beberapa sistem eksternal melalui panggilan API untuk mendapatkan respons. Pola scatter-gathering berguna ketika Anda membutuhkan masukan dari berbagai sumber. Scatter-gathering mengumpulkan hasil untuk membantu Anda membuat keputusan berdasarkan informasi atau untuk memilih respons terbaik untuk permintaan tersebut.

Pola scatter-gathering terdiri dari dua fase, seperti namanya:

• Fase pencar memproses pesan permintaan dan mengirimkannya ke beberapa penerima secara paralel. Selama fase ini, aplikasi menyebarkan permintaan di seluruh jaringan dan terus berjalan tanpa menunggu tanggapan segera.

• Selama fase pengumpulan, aplikasi mengumpulkan tanggapan dari penerima, dan menyaring atau menggabungkannya menjadi respons terpadu. Ketika semua tanggapan telah dikumpulkan, mereka dapat digabungkan menjadi satu respons atau yang terbaik dapat dipilih untuk diproses lebih lanjut.

Penerapan

Gunakan pola scatter-gathering saat:

• Anda berencana untuk menggabungkan dan mengkonsolidasikan data dari berbagai API untuk membuat respons yang akurat. Pola tersebut mengkonsolidasikan informasi dari sumber yang berbeda menjadi keseluruhan yang kohesif. Misalnya, sistem pemesanan dapat mengajukan permintaan ke beberapa penerima untuk mendapatkan penawaran dari beberapa mitra eksternal.

• Permintaan yang sama harus dikirim ke beberapa penerima secara bersamaan untuk menyelesaikan transaksi. Misalnya, Anda dapat menggunakan pola ini untuk menanyakan data inventaris secara paralel untuk memeriksa ketersediaan produk.

• Anda ingin menerapkan sistem yang andal dan terukur di mana load balancing dapat dicapai dengan mendistribusikan permintaan ke beberapa penerima. Jika satu penerima gagal atau mengalami beban tinggi, penerima lain masih dapat memproses permintaan.

• Anda ingin mengoptimalkan kinerja saat menerapkan kueri kompleks yang melibatkan beberapa sumber data. Anda dapat menyebarkan kueri ke database yang relevan, mengumpulkan sebagian hasil, dan menggabungkannya menjadi jawaban yang komprehensif.

• Anda menerapkan jenis pemrosesan pengurangan peta di mana permintaan data dirutekan ke beberapa titik akhir pemrosesan data untuk sharding dan replikasi. Hasil sebagian disaring dan digabungkan untuk menyusun respons yang tepat.

• Anda ingin mendistribusikan operasi tulis di ruang kunci partisi dalam beban kerja berat tulis di database nilai kunci. Agregator membaca hasilnya dengan menanyakan data di setiap pecahan, dan kemudian mengkonsolidasikannya menjadi satu respons.

Masalah dan pertimbangan

• Toleransi kesalahan: Pola ini bergantung pada beberapa penerima yang bekerja secara paralel, jadi penting untuk menangani kegagalan dengan anggun. Untuk mengurangi dampak kegagalan penerima pada keseluruhan sistem, Anda dapat menerapkan strategi seperti redundansi, replikasi, dan deteksi kesalahan.

• Batas penskalaan: Ketika jumlah total node pemrosesan meningkat, overhead jaringan terkait juga meningkat. Setiap permintaan yang melibatkan komunikasi melalui jaringan dapat meningkatkan latensi dan berdampak negatif pada manfaat paralelisasi.

• Kemacetan waktu respons: Untuk operasi yang mengharuskan semua penerima diproses sebelum pemrosesan akhir dilakukan, kinerja sistem secara keseluruhan dibatasi oleh waktu respons penerima yang paling lambat.

• Respons sebagian: Ketika permintaan tersebar ke beberapa penerima, beberapa penerima dapat time out. Dalam kasus ini, implementasi harus berkomunikasi dengan klien bahwa responsnya tidak lengkap. Anda juga dapat menampilkan detail agregasi respons dengan menggunakan frontend UI.

• Konsistensi data: Saat Anda memproses data di beberapa penerima, Anda harus mempertimbangkan dengan cermat teknik sinkronisasi data dan resolusi konflik, untuk memastikan bahwa hasil agregat akhir akurat dan konsisten.

Implementasi

Arsitektur tingkat tinggi

Pola scatter-gathering menggunakan root controller untuk mendistribusikan permintaan ke penerima yang akan memproses permintaan. Selama fase pencar, pola ini dapat menggunakan dua mekanisme untuk mengirim pesan ke penerima:

• Scatter by distribution: Aplikasi ini memiliki daftar penerima yang diketahui yang harus dipanggil untuk mendapatkan hasilnya. Penerima dapat berupa proses berbeda yang memiliki fungsi unik atau satu proses yang telah diskalakan untuk mendistribusikan beban pemrosesan. Jika salah satu node pemrosesan habis waktu atau menunjukkan keterlambatan dalam merespons, pengontrol dapat mendistribusikan kembali pemrosesan ke node lain.

• Scatter by auction: Aplikasi menyiarkan pesan ke penerima yang tertarik dengan menggunakan pola berlangganan publikasi. Dalam hal ini, penerima dapat berlangganan pesan atau menarik diri dari langganan kapan saja.

Sebarkan dengan distribusi

Dalam metode pencar dengan distribusi, pengontrol root membagi permintaan yang masuk menjadi tugas independen dan menetapkannya ke penerima yang tersedia (fase pencar). Setiap penerima (proses, wadah, atau fungsi Lambda) bekerja secara independen dan paralel pada perhitungannya, dan menghasilkan sebagian dari respons. Ketika penerima menyelesaikan tugas mereka, mereka mengirim tanggapan mereka ke agregator (fase pengumpulan). Agregator menggabungkan sebagian tanggapan dan mengembalikan hasil akhir ke klien. Diagram berikut menggambarkan alur kerja ini.

Pengontrol (prosesor file data) mengatur seluruh rangkaian pemanggilan, dan mengetahui semua titik akhir pemesanan untuk dipanggil. Ini dapat mengonfigurasi parameter batas waktu untuk mengabaikan respons yang memakan waktu terlalu lama. Ketika permintaan telah dikirim, agregator menunggu tanggapan kembali dari setiap titik akhir. Untuk menerapkan ketahanan, setiap layanan mikro dapat digunakan dengan beberapa instance untuk penyeimbangan beban. Agregator mendapatkan hasilnya, menggabungkannya menjadi satu pesan respons, dan menghapus data duplikat sebelum diproses lebih lanjut. Tanggapan bahwa time out diabaikan. Pengontrol juga dapat bertindak sebagai agregator alih-alih menggunakan layanan agregator terpisah.

Scatter dengan lelang

Jika pengontrol tidak mengetahui penerima atau penerima digabungkan secara longgar, Anda dapat menggunakan metode pencar dengan lelang. Dalam metode ini, penerima berlangganan topik dan pengontrol menerbitkan permintaan ke topik tersebut. Penerima mempublikasikan hasil ke antrian respons. Karena pengontrol root tidak mengetahui penerima, proses pengumpulan menggunakan agregator (pola pesan lain) untuk mengumpulkan tanggapan dan menyaringnya menjadi satu pesan respons. Agregator menggunakan ID unik untuk mengidentifikasi sekelompok permintaan.

Misalnya, dalam diagram berikut, metode pencar dengan lelang digunakan untuk menerapkan layanan pemesanan penerbangan untuk situs web maskapai penerbangan. Situs web ini memungkinkan pengguna untuk mencari dan menampilkan penerbangan dari maskapai penerbangan sendiri dan operator mitranya, dan harus menampilkan status pencarian secara real time. Layanan pemesanan penerbangan terdiri dari tiga layanan mikro pencarian: penerbangan non-stop, penerbangan dengan pemberhentian, dan maskapai mitra. Pencarian maskapai mitra memanggil titik akhir API mitra untuk mendapatkan tanggapan.

1. Layanan pemesanan penerbangan (pengontrol) mengambil kriteria pencarian sebagai masukan dari klien, dan memproses serta menerbitkan permintaan ke topik.

2. Pengontrol menggunakan ID unik untuk mengidentifikasi setiap kelompok permintaan.

3. Klien mengirimkan ID unik ke agregator untuk langkah 6.

4. Layanan mikro pencarian pemesanan yang telah berlangganan topik pemesanan menerima permintaan.

5. Layanan mikro memproses permintaan dan mengembalikan ketersediaan kursi untuk kriteria pencarian yang diberikan ke antrian respons.

6. Agregator mengumpulkan semua pesan respons yang disimpan dalam database sementara, mengelompokkan penerbangan dengan ID unik, membuat respons terpadu tunggal, dan mengirimkannya kembali ke klien.

Implementasi menggunakan AWS layanan

Sebarkan dengan distribusi

Dalam arsitektur berikut, pengontrol root adalah prosesor file data (Amazon ECS) yang membagi data permintaan masuk menjadi bucket Amazon Simple Storage Service (Amazon S3) individual dan memulai alur kerja. AWS Step Functions Alur kerja mengunduh data dan memulai pemrosesan file paralel. ParallelNegara menunggu semua tugas untuk mengembalikan respons. Suatu AWS Lambda fungsi mengumpulkan data dan menyimpannya kembali ke Amazon S3.

Diagram berikut menggambarkan alur kerja Step Functions dengan status. Parallel

Scatter dengan lelang

Diagram berikut menunjukkan AWS arsitektur untuk pencar dengan metode lelang. Layanan pemesanan penerbangan root controller menyebarkan permintaan pencarian penerbangan ke beberapa layanan mikro. Saluran berlangganan publikasi diimplementasikan dengan Amazon Simple Notification Service (Amazon SNS), yang merupakan layanan pesan terkelola untuk komunikasi. Amazon SNS mendukung pesan antara aplikasi microservice yang dipisahkan atau komunikasi langsung ke pengguna. Anda dapat menerapkan layanan mikro penerima di Amazon Elastic Kubernetes Service (Amazon EKS) atau Amazon Elastic Container Service (Amazon ECS) Service Elastic Container (Amazon ECS) untuk pengelolaan dan skalabilitas yang lebih baik. Layanan hasil penerbangan mengembalikan hasilnya kepada klien. Ini dapat diimplementasikan di AWS Lambda atau layanan orkestrasi kontainer lainnya seperti Amazon ECS atau Amazon EKS.

1. Layanan pemesanan penerbangan (controller) mengambil kriteria pencarian sebagai masukan dari klien, dan memproses serta menerbitkan permintaan ke topik SNS.

2. Pengontrol menerbitkan ID unik ke database Amazon Aurora untuk mengidentifikasi permintaan.

3. Klien mengirimkan ID unik ke klien untuk langkah 6.

4. Layanan mikro pencarian pemesanan yang telah berlangganan topik pemesanan menerima permintaan.

5. Layanan mikro memproses permintaan dan mengembalikan ketersediaan kursi untuk kriteria penelusuran yang diberikan ke antrian respons di Amazon Simple Queue Service (Amazon SQS). Agregator mengumpulkan semua pesan respons dan menyimpannya dalam database sementara.

6. Layanan hasil penerbangan mengelompokkan penerbangan dengan ID unik, menciptakan respons terpadu tunggal, dan mengirimkannya kembali ke klien.

Jika Anda ingin menambahkan pencarian maskapai penerbangan lain ke arsitektur ini, Anda menambahkan layanan mikro yang berlangganan topik SNS dan menerbitkan ke antrean SQS.

Untuk meringkas, pola scatter-gathering memungkinkan sistem terdistribusi untuk mencapai paralelisasi yang efisien, mengurangi latensi, dan menangani komunikasi asinkron dengan mulus.

GitHub repositori

Untuk implementasi lengkap arsitektur sampel untuk pola ini, lihat GitHub repositori di https://github.com/aws-samples/ asynchronous-messaging-workshop /tree/master/code/lab-3.

Lokakarya

• Laboratorium Scatter-gathering di bengkel Layanan Mikro Decoupled

Referensi blog

• Pola integrasi aplikasi untuk layanan mikro

Konten terkait

• Pola terbitkan-berlangganan