Asosiasi banyak ke banyak dalam layanan microser

Saat ini saya memiliki dua layanan microser. Kami akan memanggil mereka Adan B.

Database di bawah microservice Amemiliki tabel berikut:

A
|-- users

Database di bawah microservice Bmemiliki tabel berikut:

B
|-- trackers

Persyaratan menyatakan itu usersdan trackersmemiliki hubungan banyak-ke-banyak.

Saya tidak yakin bagaimana menangani dengan benar ini dalam arsitektur layanan microser.

Saya bisa melihat ini bekerja dengan satu dari tiga cara:

1. Sebuah user_trackerstabel ditambahkan ke microservice A. Tindakan ini mirip dengan tabel gabungan yang berisi "kunci asing" ke usersdan trackers.
2. Sebuah ownerstabel ditambahkan ke microservice B. Tabel ini bertindak mirip dengan tabel gabungan polimorfik. Ini akan memungkinkan layanan apa pun untuk membuat asosiasi dengan pelacak. Ini mungkin terlihat seperti ini: B |-- trackers |-- owners |-- owner_id |-- owner_type |-- tracker_id
3. Menyimpan catatan untuk usersdan trackersdi setiap layanan microser. Tetap sinkronkan dengan semacam sistem pubsub.

Saya awalnya akan pergi dengan opsi 2 karena saya suka itu mempertahankan batas transaksi. Saya dapat membuat pelacak dan mengaitkannya dengan sesuatu secara atom. Namun, tampaknya di luar ruang lingkup untuk layanan Microsoft B. Mengapa harus Blayanan microservice bahwa microservice Aingin membuat asosiasi?

Saya merasa mungkin ada pola yang baik di sini yang tidak saya sadari. Apakah ada opsi yang saya paparkan masuk akal? Apakah ada opsi lain yang lebih masuk akal?

Pertama-tama, saya akan mulai dengan deskripsi domain. Anda belum menyebutkan tentang apa (saya bisa menebak, tapi itu hanya tebakan). Setelah itu saya akan mencoba menguraikannya menggunakan analisis rantai nilai atau pemetaan kapabilitas bisnis . Dan hanya setelah itu saya akan memikirkan implementasi.

Mempertimbangkan masalah Anda, hal pertama yang terlintas dalam pikiran saya adalah Anda salah mengidentifikasi batas-batas layanan Anda, hanya karena mereka membutuhkan data masing-masing. Anda tidak ingin berakhir dengan monolit terdistribusi , bukan?

Hal kedua adalah bahwa Anda mungkin belum mengerjakan domain Anda dengan cukup baik. Konsep apa yang direpresentasikan dengan userstabel? Apakah ini registered user, dengan semua informasi dan perilaku yang diperlukan untuk pendaftaran? Apakah Anda yakin itu konsep yang tepat untuk berkomunikasi dengan trackers(apa pun itu)? Jadi jika saya melakukannya dengan benar, pilihan Anda 2 persis tentang itu: memperkenalkan ownerkonsep yang jauh lebih dekat ke domain Anda. Jika memang benar begitu, saya juga memilih opsi 2.

Namun, tampaknya di luar ruang lingkup untuk layanan mikro B. Mengapa layanan microser B harus peduli bahwa layanan mikro A ingin membuat asosiasi?

Ini semua tentang batasan. Saya kira Anda ingin membentuk layanan microsoft di sekitar entitas. Di situlah SOA gagal dengan arsitektur layanan berlapisnya . Pendekatan yang lebih baik adalah menciptakan layanan yang mewakili beberapa fungsi bisnis, sehingga mereka merangkum data dan perilaku. Dari sudut pandang yang lebih praktis, ini tentang menciptakan layanan seputar proses bisnis atau kasus penggunaan. Misalnya, Anda dapat memiliki satu layanan untuk pendaftaran pengguna. Ini berisi data dan perilaku pengguna yang diperlukan untuk mendaftarkan pengguna. Dengan demikian konsep userterbentuk secara alami, dan itu hanya milik layanan A. Dan ini membawa saya ke titik berikutnya: cara lain untuk berpikir tentang layanan dibatasi konteks . Ini adalah praktik yang baik untuk menyelaraskan layanan dan konteks terbatas.

Ketika pengguna terdaftar, UserCreatedacara dapat dipancarkan. Layanan kedua Anda, saya kira tertarik di dalamnya. Jadi, ketika menerimanya, entitas yang sama sekali berbeda dapat dibuat, katakanlah, Ownerentitas (apa pun itu, baik). Saya cukup yakin ada banyak kolaborasi menarik antara itu dan trackerentitas - menyimpannya dalam satu layanan.

Berhati-hatilah dengan opsi 3. Jika Anda menyalin data, fungsionalitas akan mengikuti. Ini menghasilkan kopling ketat. Dan jangan menutup dengan istilah CQRS , ini bukan tentang sinkronisasi data antara layanan melalui acara.

Jawaban Zapadlo memiliki banyak informasi bagus dan alasan di dalamnya. Saya akan menambahkan sedikit saran praktis di sini yang mungkin membuatnya lebih mudah untuk mengatasi masalah Anda dan saran dalam jawaban itu.

Cara Anda membingkai pertanyaan desain di sekitar struktur basis data dan bagaimana menyesuaikan persyaratan baru untuk struktur Anda ke dalamnya. Ini menyiratkan bahwa Anda sedang membangun desain layanan dari model data Anda. Misalnya, yang tidak saya lihat adalah bagaimana hubungan antara pengguna dan pelacak diakses atau digunakan.

Dalam desain layanan, struktur antarmuka adalah hal yang paling penting tentang desain. Kenyataannya, implementasinya hampir tidak relevan dibandingkan khususnya dalam hal layanan-layanan mikro. Alasannya adalah begitu Anda menempatkan layanan Anda di tempat, semua ketergantungan pada layanan Anda harus ada pada antarmuka saja. Jika Anda melakukannya dengan benar, Anda harus dapat sepenuhnya menulis ulang implementasi tanpa konsumen. Dan itulah manfaat utama otonomi. Tidak ada yang peduli bagaimana Anda membangunnya. Mereka hanya perlu bekerja sesuai dengan cara Anda mengkomunikasikannya.

Sebelum siapa pun dapat menentukan bagaimana ini terlihat dalam database atau di mana Anda menginginkan ini, Anda benar-benar perlu menjelaskan bagaimana informasi ini akan digunakan. Apakah ini sesuatu yang akan diekspos melalui layanan atau itu semacam data yang ingin Anda abaikan untuk analisis?

Di samping catatan, saya akan menghindari ketergantungan dua arah di hampir semua biaya. Jika Anda memiliki dependensi, Anda benar-benar hanya ingin satu sisi tahu tentang yang lain. Setelah dependensi berada di kedua arah, layanan mereka pada dasarnya menjadi unit atom.

Banyak yang turun ke domain itu sendiri. Jika pengguna dengan nol pelacak tidak masuk akal maka layanan pengguna perlu tahu tentang pelacak. Jika pelacak harus memiliki pengguna maka pelacak perlu tahu tentang pengguna. Jika sesuatu seperti memiliki pelacak dengan beberapa pemilik atau dapat mentransfer pelacak dari satu pengguna ke pengguna lain masuk akal maka mungkin informasi ini termasuk dalam layanan lain.

Pertanyaan: Mengapa data Anda dipisahkan di sepanjang Datatables?

Saya cenderung memilih opsi 3: layanannya benar-benar terpisah dan dapat menjawab pertanyaan masing-masing yang mungkin perlu mereka jawab. Selain itu, mereka jauh lebih tangguh. Tapi hati-hati, layanan Anda dapat menyinkronkan jika mereka melewatkan acara, tetapi itu bisa diselesaikan melalui konsistensi akhirnya.

Juga, Anda dapat mempertimbangkan untuk menggabungkan kedua layanan - jika keduanya tidak dapat menjawab tanpa mengetahui satu sama lain, saya hanya akan menggabungkan mereka karena mereka mungkin merupakan bagian dari satu domain.