Bagaimana Anda menangani konsep bersama dalam arsitektur layanan mikro?

Saya sedang meneliti pola arsitektur untuk aplikasi yang saya kembangkan dan pendekatan layanan- mikro sepertinya itu akan menjadi pilihan yang baik tetapi saya tidak yakin bagaimana menangani interaksi antara layanan.

Aplikasi ini terutama berkaitan dengan pengguna, profil yang dimiliki oleh pengguna, foto, dan tag yang mewakili satu hingga banyak profil dalam foto. Mungkin akan ada metode untuk mengembalikan foto yang diunggah oleh pengguna, mengembalikan foto yang berisi profil yang ditandai, dll.

Ini adalah langkah pertama saya dalam mendesain arsitektur berbasis layanan-mikro dan saya berasal dari model domain yang terinspirasi sejarah monolitik . Di dunia itu, pengontrol akan menyatukan objek-objek domain ini, tetapi saya mengalami kesulitan membungkus kepala saya di sekitar bagaimana ini akan bekerja dengan cara microservcey.

— anjunatl
sumber

Jawaban:

Biasanya, layanan memanggil layanan lain ketika mereka perlu mengakses data mereka. Setiap bagian data harus dimiliki oleh layanan tertentu yang akan menjadi satu-satunya titik masuk untuk mengakses data ini dan memodifikasinya. Beberapa layanan akan sederhana dan biasanya terkait erat dengan model domain Anda (misalnya layanan untuk menangani pengguna) sementara yang lain akan tingkat tinggi dan menggunakan data dari layanan lain (misalnya menampilkan daftar foto bersama dengan informasi tentang pengguna yang mengunggahnya) ).

Dalam kasus penggunaan Anda, Anda harus mulai dari luar dan memikirkan operasi apa yang ingin Anda sediakan untuk pengguna Anda melalui API (jika itu adalah layanan backend) atau operasi apa yang harus tersedia di GUI jika itu adalah aplikasi web. Perhatikan bahwa bagian GUI sering merupakan aplikasi reguler dengan pengontrolnya sendiri: operasi dapat dipanggil melalui REST (seperti di AngularJS), tetapi titik akhir ini hanya dirancang untuk penggunaan aplikasi GUI dan bukan layanan mikro dalam akal sehat.

Misalkan Anda ingin menampilkan foto bersama dengan informasi tentang pengunggah. Anda dapat memiliki layanan pengguna yang mengembalikan informasi tentang pengguna yang diberikan ID pengguna dan layanan foto yang dapat membuat daftar foto (misalnya dengan mencari berdasarkan beberapa kriteria). Daftar foto akan berisi untuk setiap foto ID dari pengguna yang mengunggah. Dengan cara ini kedua layanan ini tidak digabungkan - layanan foto hanya mengetahui tentang ID pengguna tetapi tidak mengetahui data pengguna itu sendiri. Di atas kedua layanan ini, Anda dapat membuat layanan ketiga dengan operasi seperti "daftar foto dengan informasi tentang pengunggah" yang akan memanggil dua layanan lainnya dan menggabungkan data yang mereka kembalikan. Atau, operasi ini dapat dilakukan oleh aplikasi web Anda, bukan layanan.

— Michał Kosmulski
sumber

Ini sangat membantu saya. Saya mulai dengan menulis beberapa use case UI yang akan menjalankan stack dan semuanya sebagian besar jatuh ke tempatnya.

— anjunatl

Dalam contoh khusus ini, apakah kita seharusnya melakukan mis. 10 panggilan ke layanan pengguna untuk mendapatkan data pengguna jika kami memiliki 10 foto dalam daftar kami? Bukankah itu menambah banyak overhead?

— Ricardo Souza

@rcdmk Anda dapat menambahkan titik akhir REST yang mendapatkan daftar beberapa ID sebagai input dan mengembalikan beberapa foto sebagai output. Ini sering dilakukan dalam praktek karena alasan kinerja. Terkadang, desain API merupakan kompromi antara kemurnian dan pertimbangan praktis.

— Michał Kosmulski

@ MichałKosmulski Saya harus memulai diskusi, tetapi desain StackExchange tidak mendukung mereka :) Yang tidak saya sukai tentang pendekatan layanan mikro dalam contoh khusus ini adalah bahwa kueri langsung ke basis data yang mendasarinya (tempat pengguna dan gambar disimpan) bisa jauh lebih efisien. Bayangkan jika layanan hulu ini bergantung pada layanan hulu lainnya dan seterusnya. Permintaan langsung ke penyimpanan data jauh lebih aman. hanya 5 sen saya - tidak lebih. Sekali lagi saya benar-benar ingin melakukan diskusi yang produktif mengenai topik ini, tetapi StackExachange bukan tempat yang baik untuk itu (dapatkah Anda merekomendasikan forum diskusi layanan microser?)

— ajukraine

@ajukraine Saya pikir ada obrolan di stackexchange yang mungkin merupakan tempat yang bagus untuk diskusi. Adapun kinerja: 1. Layanan Microsoft memang datang dengan biaya kinerja, dan 2. Layanan Microsoft baik untuk beberapa situasi tetapi tidak untuk yang lain. Adapun dependensi: dalam arsitektur microservice Anda sering membuat salinan data lokal dan menggunakan pesan asinkron untuk mengurangi jumlah dependensi. Ini adalah perubahan arsitektur nyata, tidak hanya secara otomatis mengubah setiap modul aplikasi ke aplikasi terpisah.

— Michał Kosmulski

Aplikasi ini terutama berkaitan dengan pengguna, profil yang dimiliki oleh pengguna, foto, dan tag yang mewakili satu hingga banyak profil dalam foto. Mungkin akan ada metode untuk mengembalikan foto yang diunggah oleh pengguna, mengembalikan foto yang berisi profil yang ditandai, dll.

Nah, layanan profil seharusnya tidak bekerja dengan objek pengguna. Mungkin hanya tahu ID pengguna yang diminta mengembalikan data, tidak lebih. Dengan cara ini Anda tidak akan memerlukan interaksi antara layanan pengguna dan layanan profil.

Jika itu tidak menjawab pertanyaan Anda, bisakah Anda menjelaskannya dengan menggambarkan situasi yang tepat yang Anda hadapi?

— Vladislav Rastrusny
sumber

Ini dan jawaban Michal membantu saya memahaminya tetapi sarannya membantu saya memetakan layanan yang saya butuhkan. Saya terjebak dalam pola pikir harus mewakili objek penuh, bukan hanya referensi ke objek (objek pengguna vs ID pengguna). Sangat dihargai, terima kasih!

— anjunatl

@anjunatl Selamat datang;)

— Vladislav Rastrusny