Di mana seharusnya logika bisnis berada dalam arsitektur layanan mikro?

Masih mencoba untuk membungkus kepala saya di sekitar arsitektur microservice karena saya sudah terbiasa dengan pendekatan monolitik

Misalkan kita mencoba membangun sistem pemesanan Uber yang sangat disederhanakan . Untuk menyederhanakan hal yang kita katakanlah kita memiliki 3 layanan dan api gateway dari klien: Booking, Drivers, Notificationdan kami memiliki alur kerja berikut:

Saat membuat pemesanan baru:

1. Periksa apakah pengguna yang sudah ada sudah melakukan pemesanan
2. Dapatkan daftar driver yang tersedia
3. Kirim pemberitahuan kepada pengemudi untuk mengambil pesanan
4. Sopir mengambil pesanan

Katakanlah semua olahpesan dilakukan melalui panggilan http daripada bus olahpesan seperti kafka untuk menjaga hal-hal sederhana.

Jadi dalam hal ini, saya berpikir bahwa Bookinglayanan dapat melakukan pengecekan untuk pemesanan yang ada. Tetapi kemudian siapa yang seharusnya mendapatkan daftar driver dan notifikasi yang tersedia? Saya sedang berpikir untuk melakukannya di tingkat gateway tetapi kemudian sekarang logika dibagi menjadi dua tempat:

• Gateway - dapatkan daftar driver yang tersedia + kirim pemberitahuan
• Booking - periksa pemesanan yang ada

Dan saya cukup yakin gateway bukan tempat yang tepat untuk melakukannya tetapi saya merasa jika kita melakukannya dalam Bookinglayanan, itu menjadi sangat erat?

Untuk membuatnya lebih rumit, apa yang terjadi jika kita memiliki proyek lain yang ingin menggunakan kembali sistem pemesanan tetapi dengan logika bisnis sendiri di atasnya? Itu sebabnya saya berpikir untuk melakukannya di tingkat gateway sehingga gateway proyek baru dapat memiliki logika bisnis sendiri terpisah dari yang sudah ada.

Cara lain untuk melakukannya saya kira adalah untuk setiap proyek memiliki layanan pemesanan sendiri yang akan berbicara dengan layanan pemesanan inti tetapi saya tidak yakin apa pendekatan terbaik di sini :-)

Orang sering mendengar "layanan mikro" dan berpikir "layanan nano", dan ini dapat menyebabkan kebingungan. Ini adalah layanan mikro , jadi Anda tidak perlu layanan terpisah untuk setiap entitas tunggal. Segala sesuatu yang Anda coba lakukan harus dalam bookingdan notificationlayanan. Anda tidak memerlukan driverlayanan (untuk aktivitas apa pun yang Anda uraikan).

Mendapatkan daftar driver yang tersedia untuk dipesan termasuk dalam bookinglayanan. Perangkap yang umum adalah untuk tidak mengelompokkan kegiatan terkait ke layanan yang sama, ini disebut koherensi rendah, dan itu sangat buruk. Ingat, Anda mengelompokkan berbagai hal menjadi layanan berdasarkan domain masalah, bukan berdasarkan entitas.

Sekarang, seperti untuk digunakan kembali, keuntungan memiliki layanan mikro yang terpisah adalah, sekarang Anda dapat memiliki tiga tim terpisah yang membuat konsumen menghadapi aplikasi. Satu tim untuk aplikasi web html standar, aplikasi Android, dan aplikasi iOS. Semua aplikasi yang berbeda ini dapat dibangun dengan sangat berbeda, dan terlihat sesuai untuk platform khusus mereka (tanpa kode berulang). The bookingkode layanan digunakan kembali oleh ketiga aplikasi ini, karena semua tiga aplikasi membuat http panggilan ke layanan bukannya memiliki kode pemesanan mereka sendiri.

Alur pemesanan yang khas akan terlihat seperti ini:

1. Aplikasi android memanggil bookinglayanan untuk mendapatkan daftar driver yang tersedia
2. Layanan pemesanan mengembalikan daftar driver ke aplikasi
3. Pengguna kemudian memilih driver mereka dan aplikasi memanggil metode "buku" dari bookinglayanan
4. The bookingServis menyebut notificationlayanan dengan rincian pemesanan
5. The notificationlayanan mengirimkan pemberitahuan kepada sopir, memberitahukan kepadanya pemesanan
6. Aplikasi driver mengirim pesan ke notificationlayanan ketika mereka berada dalam jarak satu mil dari pelanggan
7. The notificationlayanan mengirimkan peringatan kepada pelanggan bahwa driver mereka hampir ada

Semoga ini bisa membantu; ingat, mereka adalah layanan mikro, bukan layanan nano, jangan mencoba untuk membagi domain masalah yang sama. Jadi, untuk menjawab judul pertanyaan Anda, ketika Anda menyimpan layanan mikro dengan ukuran yang sesuai, semua, atau sebagian besar, logika bisnis untuk domain masalah tersebut dapat hidup dalam layanan mikro tersebut.

Itu semua tergantung dari kebutuhan Anda.

Katakanlah Anda memiliki dua aplikasi yang melakukan pemesanan:

1. Kasus pertama: Satu aplikasi memungkinkan satu pengguna memesan beberapa kali, yang lainnya hanya mengizinkan satu pengguna. Ini berarti bahwa batasan pemesanan ada pada level aplikasi, karena itu Anda memiliki dua titik masuk dalam sistem pemesanan Anda (satu yang memungkinkan multi pemesanan, satu yang tidak) atau Anda hanya memeriksa di dalam layanan mikro dari pihak terkait aplikasi.
2. Kasus kedua: ini adalah bagian dari definisi "Pemesanan" bahwa pengguna tidak dapat memiliki banyak aplikasi apa pun, aturan ini berlaku untuk seluruh sistem: ini berarti Anda dapat memasukkan cek ke dalam layanan microser pemesanan.

Adapun sistem notifikasi, Anda dapat memiliki layanan microsoft yang berlangganan layanan pemesanan Anda untuk mendengarkan pemesanan baru. Dengan demikian, layanan pemesanan mikro akan memberi tahu semua pelanggan dan mereka akan bertindak sesuai.

Satu-satunya masalah dalam arsitektur semacam ini adalah apa yang terjadi jika sesuatu gagal setelah pemberitahuan telah diterbitkan, karena dua layanan microser tidak berfungsi seperti dua fungsi yang dieksekusi dalam transaksi basis data yang sama, Anda perlu menangani kesalahan dengan anggun dan akhirnya memutar ulang proses yang gagal (secara otomatis atau manual)

Jawaban sederhananya adalah bahwa klien layanan mikro adalah yang mengelola logika bisnis dalam arsitektur layanan mikro 'murni'. Untuk membuatnya lebih mudah dipahami, pertimbangkan contoh yang lebih sederhana. Layanan yang hanya mengembalikan aliran byte berdasarkan URI. Dengan sendirinya, itu tidak terlalu berguna. Tanpa sedikit pun tahu URI mana yang memiliki apa di dalamnya, Anda hanya bisa menebak di mana harus menarik sesuatu. Sekarang anggaplah Anda memiliki microservice berbeda yang menyediakan kemampuan pencarian. Anda mengirim permintaan dengan string kueri dan mengembalikan URI. Sekarang segalanya menjadi lebih menarik. Saya dapat menempatkan referensi ke URI untuk layanan pertama ke dalam indeks.

Tapi tetap saja, kita perlu melakukan koordinasi antara keduanya. Ada jawaban sederhana: Anda menggunakan browser untuk mengambil URI dari layanan indeks dan kemudian mengambil data dari layanan data. Baik layanan 'tahu' tentang yang lain dan sama sekali tidak ada sambungan di antara mereka. Saya dapat menggunakan layanan indeks dengan layanan data lain dan sebaliknya.

Ini tidak selalu berarti bahwa ini adalah pendekatan terbaik dalam semua skenario tetapi ada banyak manfaat untuk membangun hal-hal seperti ini terutama dapat digunakan kembali dalam skenario yang saat ini tidak diketahui.