Saya telah membaca banyak tentang layanan mikro belakangan ini, dan berikut adalah beberapa kesimpulan yang saya dapatkan sejauh ini (tolong perbaiki saya jika saya salah).
- Arsitektur layanan mikro berjalan baik dengan desain berbasis domain. Biasanya satu MS mewakili satu konteks terbatas.
- Jika layanan-mikro A memerlukan fungsionalitas yang berada di layanan-mikro B , model saya mungkin salah dan A dan B sebenarnya harus merupakan satu layanan-mikro / BC.
- Komunikasi sinkron antara layanan-mikro (permintaan HTTP langsung) buruk, karena itu menentang tujuan layanan-mikro, dan memperkenalkan sambungan antar komponen.
- Komunikasi asinkron antara layanan diinginkan. Layanan harus mempublikasikan acara ke antrian pesan, sehingga layanan lain dapat berlangganan dan memproses bagian dari acara tersebut, atau menggunakannya untuk mereplikasi sebagian data yang diperlukan untuk konteksnya. Dengan cara ini, layanan dapat memproses permintaan bahkan layanan lain sedang down, yang tidak akan terjadi dalam komunikasi yang sinkron.
- Jika layanan mikro A menerbitkan acara, layanan mikro B berlangganan acara itu dan menghasilkan acara baru sebagai hasilnya, layanan mikro A tidak boleh menjadi satu acara pemrosesan yang baru dibuat, karena itu akan menjadi ketergantungan sirkuler. Dalam hal ini, kita harus memperkenalkan layanan mikro ketiga, atau menggabungkan A dan B ke layanan mikro AB .
- Layanan mikro sebenarnya adalah istilah yang menyesatkan. Kita harus berjuang untuk konteks kecil, tetapi itu tidak perlu menjadi masalah. Istilah tidak boleh "layanan mikro", tetapi " cukup besar untuk melakukan layanan pekerjaan ".
- Layanan mikro memungkinkan kami untuk memperkenalkan fungsionalitas baru dengan lebih mudah dan tanpa rasa takut bahwa kami akan merusak seluruh sistem. Ini dapat dilakukan dengan memperkenalkan layanan baru, atau refactoring salah satu yang ada.
- Setiap layanan mikro harus memiliki penyimpanan data sendiri. Replikasi / duplikasi data adalah perilaku yang diinginkan dalam arsitektur ini.
Selain menegaskan pemahaman saya tentang arsitektur ini, bagian saya yang lain dari pertanyaan ini sebagian besar terkait dengan penemuan layanan. Jika layanan berkomunikasi secara asinkron, dan menggunakan antrian acara pusat seperti amazon SQS, apakah itu berarti bahwa penemuan layanan tidak memiliki tempatnya dalam arsitektur seperti itu?
Layanan tidak boleh memiliki pengetahuan tentang layanan lain dalam sistem. Mereka hanya mengetahui konteks dan acara yang harus mereka publikasikan atau berlangganan?