Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Komunikasi asinkron
Sebaliknya, dalam komunikasi asinkron, klien mengeluarkan permintaan ke layanan tetapi tidak menerima tanggapan langsung. Dalam hal ini, klien biasanya hanya menerima pengakuan bahwa permintaan tersebut diterima.
Manfaat komunikasi asinkron meliputi:
-
Dukungan arsitektur berbasis peristiwa — Kesesuaian alami untuk pola event-sourcing dan command query responsibility segregation (CQRS).
-
Manajemen sumber daya yang lebih baik — Kemampuan layanan untuk memproses permintaan berdasarkan kapasitas mereka.
-
Isolasi kesalahan yang ditingkatkan - Pemisahan layanan, yang mencegah kegagalan kaskade.
-
Penanganan beban puncak - Penanganan lonjakan lalu lintas yang lebih baik melalui antrian pesan.
Kelemahan termasuk kompleksitas. Contoh:
-
Jika klien membutuhkan hasil operasi asinkron, menerapkan mekanisme untuk mengambil atau menerima hasil itu membutuhkan lebih banyak usaha.
-
Akan lebih sulit untuk memecahkan masalah operasi asinkron, karena pemecahan masalah memerlukan pemeriksaan log di beberapa sistem.
-
Ini bisa lebih sulit untuk menguji operasi asinkron, karena pengujian memerlukan koordinasi antara beberapa sistem dan layanan.
Pendekatan untuk komunikasi asinkron termasuk api dan lupa, cek klaim, panggilan balik, dan komunikasi dua arah.
Api dan lupakan
Dalam pola fire and forget, klien mengeluarkan permintaan ke server dan secara sinkron menerima pengakuan yang menunjukkan bahwa server telah menerima pesan dan akan memprosesnya. Namun, pemrosesan yang sebenarnya belum terjadi, dan klien tidak memiliki visibilitas kapan atau bagaimana hal itu akan dilakukan. Diagram berikut menggambarkan pola ini.
Dalam hal ini, layanan tidak boleh mengirim pengakuan sampai objek bertahan lama. Persistensi ini dapat diimplementasikan sebagai operasi penulisan database atau dengan menempatkan item dalam antrian.
Pertimbangan tambahan:
-
Menerapkan idempotensi untuk menangani pesan duplikat. Artinya, setiap pesan harus diproses hanya sekali.
-
Pertimbangkan antrian surat mati untuk pemrosesan yang gagal.
-
Pantau tingkat keberhasilan pemrosesan pesan.
Cek klaim
Jika klien membutuhkan hasil panggilan layanan, Anda dapat membangun layanan untuk mengeluarkan cek klaim saat menerima permintaan. Diagram berikut menggambarkan pola ini. Pemeriksaan klaim diimplementasikan sebagai pengidentifikasi bahwa layanan kembali dalam pengakuannya. Klien dapat menggunakan pengenal ini nanti untuk memeriksa status permintaan dan untuk mengambil hasilnya ketika permintaan selesai.
Klien harus menerapkan mekanisme untuk polling untuk hasil. Ini dapat diotomatisasi (misalnya, pemeriksaan dapat dilakukan setiap n menit) atau diimplementasikan secara manual, di mana pemeriksaan dilakukan sebagai respons terhadap peristiwa lain atau tindakan pengguna. Layanan yang menerapkan pola pemeriksaan klaim harus eksplisit tentang lamanya waktu pemeriksaan klaim valid.
Praktik terbaik:
-
Menerapkan backoff eksponensial untuk polling.
-
Tetapkan waktu yang tepat untuk hidup (TTL) untuk pemeriksaan klaim.
-
Berikan titik akhir status untuk pelacakan kemajuan.
Callback
Dalam pola callback, klien mengeluarkan permintaan ke layanan dan menyediakan lokasi untuk layanan untuk dihubungi saat pemrosesan selesai. Klien tidak menunggu hasilnya, dan pemrosesan berlanjut. Layanan bertanggung jawab untuk menghubungi lokasi saat pemrosesan selesai dan memberikan hasilnya. Jenis lokasi yang umum untuk respons adalah REST APIs atau antrian. Diagram berikut menggambarkan pola callback.
Implementasi:
-
Menerapkan mekanisme coba ulang untuk callback yang gagal.
-
Amankan lokasi panggilan balik seperti yang Anda lakukan pada layanan lainnya.
-
Menangani batas waktu panggilan balik.
Komunikasi dua arah
Untuk menerapkan komunikasi dua arah, Anda harus membuat koneksi stateful antara klien dan layanan, yang memungkinkan klien dan layanan untuk mengirim dan memproses pesan. Ini diilustrasikan dalam diagram berikut. Meskipun komunikasi tidak sinkron, layanan harus dapat mendukung koneksi terbuka untuk setiap klien.
Pertimbangan implementasi:
-
Pemesanan pesan
-
Nomor urut
-
Strategi partisi
-
Pemesanan pesan
-
-
Manajemen negara
-
Pola sumber acara
-
Rekonsiliasi negara
-
Model konsistensi
-
-
Penanganan kesalahan
-
Coba lagi kebijakan
-
Strategi mundur
-
Pemantauan dan observabilitas
-
Korelasi IDs
-
Pelacakan pesan
-
Metrik kinerja
-
Indikator kesehatan sistem
-
