Haruskah layanan berbicara langsung satu sama lain dalam arsitektur layanan mikro?

Saya memiliki sejumlah layanan web yang membentuk aplikasi web. Klien dapat mengakses layanan ini melalui panggilan REST API.

Haruskah layanan ini dapat berbicara langsung satu sama lain? Jika demikian, bukankah itu membuat mereka berpasangan yang bertentangan dengan konsep pada layanan mikro?

Haruskah klien memanggil mereka secara langsung satu demi satu untuk mendapatkan data yang diperlukan untuk memuat halaman web pada klien?

Atau haruskah saya memiliki lapisan lain di atas layanan saya, yang menangani permintaan dari klien, mengambil data untuk permintaan itu dan kemudian mengirimkannya kembali ke klien?

Jika Anda ingin layanan Anda terlihat seperti pada gambar ini, maka ya: Ini tidak seperti Anda tidak dapat melakukannya, tetapi sebagian besar waktu itu akan memiliki konsekuensi buruk. Komunikasi melalui REST tidak akan memisahkan layanan Anda secara signifikan. Ketika beberapa antarmuka layanan berubah, semua layanan dependen kemungkinan besar harus diubah dan digunakan kembali. Juga saat memindahkan layanan, Anda harus meletakkan semua layanan dependen, yang tidak dianggap sebagai desain yang baik untuk standar ketersediaan tinggi.

Pada akhirnya, Anda akan memiliki aplikasi layanan mikro yang lebih lambat daripada aplikasi monolith alternatif, tetapi memiliki hampir semua masalah yang sama!

Saya harus tidak setuju dengan @Robert Harvey

Dalam praktiknya, bagaimanapun, satu atau lebih dari layanan microser Anda (mungkin semuanya) akan berbicara dengan beberapa pusat penyimpanan data seperti database SQL.

Database integrasi adalah antipattern yang terkenal

Solusi yang jauh lebih baik adalah dengan menggunakan pola terbitkan-berlangganan untuk membuat komunikasi antara layanan Anda tidak sinkron:

Silakan lihat cara CQRS / ES menerapkan metode komunikasi ini, Greg Young dan orang lain menawarkan banyak video bagus tentang topik ini. Hanya google untuk kata kunci "CQRS / ES". Dalam pendekatan ini, setiap layanan akan menjadi penerbit dan pelanggan pada saat yang sama, yang memungkinkan layanan menjadi lebih sedikit digabungkan.

Berikut ini adalah serangkaian artikel bagus tentang layanan mikro yang menyoroti kontroversi seputar topik tersebut. Penjelasan yang sangat rinci dengan ilustrasi yang bagus.

Anda akan mendapatkan banyak ide bagus dari membaca apa yang dikatakan Udi Dahan tentang SOA .

Layanan adalah otoritas teknis untuk kemampuan bisnis tertentu. Setiap data atau aturan harus dimiliki hanya oleh satu layanan.

Apa artinya ini adalah bahwa bahkan ketika layanan mempublikasikan dan berlangganan acara masing-masing, kita selalu tahu apa sumber kebenaran otoritatif untuk setiap bagian data dan aturan.

Juga, ketika melihat layanan dari kacamata kapabilitas bisnis, apa yang kita lihat adalah bahwa banyak antarmuka pengguna menyajikan informasi dengan kapabilitas yang berbeda - harga suatu produk bersama-sama apakah persediaan atau tidak. Agar kami mematuhi definisi layanan di atas, ini membawa kami pada pemahaman bahwa antarmuka pengguna seperti itu sebenarnya adalah gabungan - dengan masing-masing layanan memiliki fragmen UI yang berhubungan dengan data khususnya.

Khusus mengenai komposisi UI, artikel Mauro Servienti tentang Komposisi UI adalah titik awal yang baik. Lihat juga video Udi, tersedia di sini .

Haruskah layanan ini dapat berbicara langsung satu sama lain? Jika demikian, bukankah itu membuat mereka berpasangan yang bertentangan dengan konsep pada layanan mikro?

Jika dua layanan saling bertukar pesan, maka Anda akan mendapatkan beberapa sambungan. Jawaban utama di sana adalah bahwa mereka berpasangan dengan API layanan lain - kontrak yang dijanjikan layanan untuk tetap stabil bahkan ketika internalnya berubah.

Di luar itu, teknik seperti penemuan layanan dapat mengurangi ketergantungan pada penyedia layanan tertentu, dan pialang pesan dapat memisahkan produsen dan konsumen (mereka masih perlu saling memahami pesan satu sama lain, dan bagaimana berinteraksi dengan API pialang pesan - tidak ada keajaiban ).

Itu tergantung pada apa yang Anda maksud dengan "langsung".

Sangat baik, menurut arsitektur microservices, untuk memiliki microservices yang memanggil microservices lain, baik di server Anda sendiri, atau bahkan di server eksternal, melalui beberapa antarmuka seperti REST.

Apa yang tidak baik, adalah untuk satu microservice untuk memohon yang lain menggunakan metode langsung; yang akan membuat kedua layanan microser bagian dari monolith yang sama.

Haruskah layanan ini dapat berbicara langsung satu sama lain? Jika demikian, bukankah itu membuat mereka berpasangan yang bertentangan dengan konsep pada layanan mikro?

Coupling bukan kata yang buruk. Setiap aplikasi sudah memiliki derajat kopling tertentu; aplikasi yang berbicara dengan layanan microser Anda sudah digabungkan ke layanan microser, jika tidak mereka tidak akan berfungsi.

Apa yang Anda benar-benar kejar dengan layanan microser adalah kopling longgar ; Anda dapat mencapai itu hanya dengan meminta satu layanan mikro menginterogasi yang lain melalui API publiknya atau menggunakan bus acara.

Namun dalam praktiknya, satu atau lebih layanan microser Anda (mungkin semuanya) akan berbicara dengan beberapa pusat penyimpanan data seperti database SQL. Bergantung pada bagaimana Anda ingin mencapai tujuan Anda, Anda mungkin hanya memiliki satu microservice mengubah data database dalam beberapa cara, yang akan diminta oleh microservice lain untuk mengambil perubahan.

Tampaknya ketika berbicara tentang SOA dan arsitektur pada umumnya, orang terjebak dalam semantik dan jargon. Apa yang membuat layanan "mikro"? Pada akhirnya, itu adalah serangkaian karakteristik yang, dalam "sistem penilaian" apa pun yang Anda gunakan, jelas tidak membuat layanan "non-mikro." Apa yang dikatakan hakim agung tentang ketidaksenonohan? "Aku akan tahu ketika aku melihatnya."

Saya yakin beberapa orang akan mengatakan ini bukan jawaban, tetapi kemudian mereka kehilangan intinya. Arsitektur layanan mikro dimaksudkan untuk menghindari beberapa masalah, di antaranya adalah masalah "penggabungan ketat". Jadi, jika Anda akhirnya membuat kusut layanan mikro yang bergantung pada terlalu banyak detail satu sama lain, Anda telah membuat sambungan ketat yang - apakah Anda menggunakan bus pesan pub / sub atau panggilan langsung - menghancurkan kemampuan Anda untuk menyusun solusi baru dari potongan-potongan, mengkonfigurasi ulang masing-masing potongan tanpa menjatuhkan seluruh sistem, dll

Haruskah klien memanggil mereka secara langsung satu demi satu untuk mendapatkan data yang diperlukan untuk memuat halaman web pada klien?

Tergantung; namun, saya menyarankan untuk menyediakan kemampuan yang langsung dapat digunakan untuk klien dan menyembunyikan (merangkum) perincian tentang bagaimana hasil dikumpulkan (misalnya melalui beberapa layanan mikro).

Jika terlalu banyak logika terlibat dalam menggabungkan hasil layanan-mikro individual oleh klien, yang mungkin secara tidak sengaja menyebabkan beberapa logika bisnis merayap ke dalam klien. Itu juga dapat mengekspos lebih banyak arsitektur internal Anda ke klien daripada yang Anda inginkan, menghambat refactoring nanti dari layanan microser.

Jadi, itu berarti dengan layanan microser, terkadang sangat membantu untuk memiliki layanan microser pembungkus yang memberikan klien titik akhir yang memiliki abstraksi yang berguna dan yang melakukan koordinasi tingkat yang lebih tinggi dari layanan microser lainnya (mungkin sekarang lebih internal).

(Selanjutnya, perjalanan pulang pergi ke klien kemungkinan lebih mahal daripada dari layanan microsoft Anda satu sama lain.)

Jika Anda melihat arah yang diambil oleh GraphQL, misalnya, Anda akan menemukan klien yang mengeluarkan pertanyaan yang relevan langsung ke titik akhir, yang mungkin atau mungkin tidak diterapkan sebagai kumpulan layanan mikro. Karena arsitektur microservices tersembunyi di belakang GraphQL, yang membuat arsitektur lebih mudah untuk diperbaiki dan lebih ramah kepada klien. Lihat, misalnya, https://stackoverflow.com/a/38079681/471129 .

Tujuan utama dari layanan mikro adalah untuk membuat aplikasi Anda secara longgar digabungkan. Karena itu, layanan tidak dapat saling memanggil. Kalau tidak, itu akan diikat-terikat. Tetapi apa yang akan kita lakukan jika kita memiliki dua layanan yang perlu berbagi data? Jawabannya adalah Pialang Pesan. Jadi layanan yang mendapatkan data dari klien dapat membagikan data ke pialang pesan pusat, maka layanan harus menggunakan data yang dapat mengkonsumsinya, mentransformasikannya, dan memasukkannya ke penyimpanan data sendiri. Saya merekomendasikan Kafka karena Anda dapat menggabungkan data dari berbagai topik dengan cepat dengan Kafka Stream. PS. lebih baik untuk memisahkan layanan mikro Anda dengan fitur.