Autonomous Microservices, antrian acara, dan penemuan layanan

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).

1. Arsitektur layanan mikro berjalan baik dengan desain berbasis domain. Biasanya satu MS mewakili satu konteks terbatas.
2. 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.
3. Komunikasi sinkron antara layanan-mikro (permintaan HTTP langsung) buruk, karena itu menentang tujuan layanan-mikro, dan memperkenalkan sambungan antar komponen.
4. 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.
5. 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 .
6. 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 ".
7. 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.
8. 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?

Kesimpulan Anda tampaknya sebagian besar didasarkan dan meringkas dengan sangat baik cara untuk mencari layanan-layanan mikro.

Namun saya tidak sepenuhnya mendukung 2, 5 dan 8:

• 2) Ketergantungan sederhana seharusnya tidak secara otomatis mengarah pada merger. Anda harus mempertimbangkan frekuensi panggilan tergantung tersebut dan juga frekuensi panggilan dari layanan lain.

  Jadi jika microservice A membutuhkan fungsionalitas dalam microservice B sangat sering, dan microservice B jarang dibutuhkan oleh microservice lain, Anda harus menantang struktur yang dibayangkan dan bertanya apakah tidak akan lebih tepat untuk mengelompokkan kedua microservice.

• 5) tentu saja, Anda perlu menghindari bersepeda tanpa akhir dalam penanganan pesan.

  Tetapi menambahkan perantara tidak akan mencegahnya: A dapat meluncurkan pesan yang ditangani oleh C yang meluncurkan pesan yang ditangani oleh B, yang meluncurkan pesan yang ditangani oleh A dan di sini Anda terjebak dalam satu lingkaran.

  Masalahnya tidak dapat dinilai hanya dengan mempertimbangkan tingkat layanan mikro: pertanyaannya adalah benar-benar tentang jenis pesan dan konten yang dapat menyebabkan siklus. Grafik yang memodelkan distribusi dan pemrosesan pesan di seluruh layanan karena itu harus dianalisis secara keseluruhan (sebenarnya ini bisa rumit, sehingga Anda bisa membayangkan layanan pemantauan mikro yang mendeteksi siklus tersebut dan memutusnya).

• 8) ya, setiap layanan Microsoft akan memiliki penyimpanan / database khusus.

  Minimal replikasi diperlukan untuk memungkinkan layanan menjadi mandiri. Namun saya tidak akan sampai sejauh ini untuk mengatakan bahwa replikasi yang diinginkan: itu harus dijaga agar tetap minimum untuk menghindari kopling tersembunyi melalui proses replikasi.

  Layanan microsoft adalah tentang kopling longgar. Ini kadang-kadang dapat lebih efektif dicapai dengan memanggil layanan microsoft lain untuk mengambil data terkait, daripada mereplikasi data.

Dua penegasan tak bernomor terakhir terlalu luas untuk dijawab dengan tegas di sini. Saya pikir saran Anda adalah titik awal yang baik, tetapi itu benar-benar tergantung pada persyaratan dan kendala arsitektur.

Layanan mikro adalah tentang memisahkan domain fungsionalitas yang berbeda. Setiap layanan dapat dikembangkan pada kecepatan yang berbeda, oleh tim yang berbeda, menggunakan tumpukan teknologi yang berbeda. Ini menciptakan fleksibilitas organisasi. Pertukarannya adalah kompleksitas operasional, di mana setiap layanan tambahan menciptakan satu hal lagi yang harus dikelola dalam lingkungan operasional. Jadi, trade-off mendasar monolith vs layanan mikro bukan tentang menghindari ketergantungan, ini adalah tentang menghindari pengembangan langkah-kunci dan penyebaran di mana semuanya harus dikirimkan sekaligus, tetapi dengan biaya harus mengirim lebih sering karena ada lebih banyak bagian yang bergerak.

Layanan tidak boleh memiliki pengetahuan tentang layanan lain dalam sistem. Mereka hanya mengetahui konteks dan acara yang harus mereka publikasikan atau berlangganan?

Masalah penghindaran ketergantungan adalah herring merah. Anda akan selalu memiliki dependensi di antara bagian-bagian produk Anda, dan apakah mereka berada di layanan terpisah atau bagian dari kode yang sama tidak mengubah fakta bahwa dependensi dapat terputus. Mereka dapat rusak di tingkat operasional, karena server kunci turun, dan Anda mengelolanya melalui redundansi operasional dan praktik kegagalan. Mereka juga dapat pecah di tingkat integrasi, karena bagian berubah dengan cara yang tidak kompatibel, yang Anda deteksi melalui pengujian integrasi. Pengacakan kode antar layanan tidak memecahkan masalah dependensi yang berpotensi rusak. Solusi untuk menghindari dependensi yang rusak adalah redundansi operasional dan pengujian integrasi, yang tidak ada hubungannya dengan ukuran layanan Anda.

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?

Untuk menjawab pertanyaan itu, jawab dulu pertanyaan ini: mengapa Anda ingin berkomunikasi secara tidak sinkron? Apakah ini untuk memudahkan pengembangan komponen terpisah secara independen? Apakah ini untuk meningkatkan ketersediaan operasional untuk sistem 24/7? Katakanlah ini adalah yang terakhir dan Anda ingin menggunakan antrian untuk mereplikasi data ke database lokal. Nah, sekarang data Anda bisa basi. Pada titik tertentu itu akan menjadi terlalu basi. Bagaimana Anda mengatasinya? Terlebih lagi, bagaimana Anda memastikan ketersediaan operasional antrian, yang merupakan komponen runtime lain? Dan bagaimana Anda memastikan ketersediaan basis data lokal itu? Alih-alih mengelola satu kluster basis data, sekarang Anda memiliki beberapa. Bisakah tim ops Anda menangani beban kerja ini? Dan sungguh, apakah kompleksitasnya sepadan, ketika mungkin pengguna Anda akan lebih bahagia dengan lebih banyak fitur dan beberapa jam downtime setiap bulan jika Anda membangun monolit sederhana?

Saya pikir Anda mengerti maksud saya. Desain sistem bukan tentang benar dan salah, ini tentang memilih dari berbagai trade-off. Segala sesuatu yang salah bisa benar, dan sebaliknya, jika Anda hanya melihatnya dalam konteks yang benar. Konteks Anda adalah unik untuk Anda, maka sementara kami dapat memberikan sebuah jawaban, itu tidak akan yang jawabannya. Ingat siapa audiens Anda, apa kebutuhan mereka, dan desain yang tepat akan mengungkapkan dirinya.

1. Arsitektur layanan mikro berjalan baik dengan desain berbasis domain. Biasanya satu MS mewakili satu konteks terbatas.

Tidak setuju. DDD cenderung sangat OO. pesanan dikirimkan? Order.Deliver () sedangkan Mikro-layanan akan memiliki DeliveryService.Deliver (pesanan)

2. 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.

Tidak setuju, Anda harus mencoba dan menjaga agar layanan mikro tetap mikro. membaginya menjadi lebih kecil!

3. Komunikasi sinkron antara layanan-mikro (permintaan HTTP langsung) buruk, karena itu menentang tujuan layanan-mikro, dan memperkenalkan sambungan antar komponen.

Tidak setuju. layanan tidak boleh peduli tentang siapa yang memanggil mereka dan penelepon tidak boleh peduli bahwa logika diimplementasikan dalam layanan mikro.

4. 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.

Antrian baik. Tapi alasanmu salah. satu-satunya perbedaan antara respons sinkronisasi dan async adalah Anda menunggu sinkronisasi. Anda dapat menerapkan panggilan gaya RPC dengan antrian dan beberapa pekerja tanpa masalah.

5. 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.

Tidak setuju. Ini bukan ketergantungan melingkar karena layanan mikro Anda tidak digabungkan. Anda juga ingin melayani pengiriman ulang senarios, SendEmail, EmailFailed, SendAgain tidak perlu 3 layanan mikro

6. 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".

Tidak setuju. Lihat layanan nano.

7. 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.

Tidak setuju. Ya, Anda mendapatkan decoupling, tetapi pengaturan layanan mikro dapat sama menakutkannya dengan proyek monolit mana pun

8. Setiap layanan mikro harus memiliki penyimpanan data sendiri. Replikasi / duplikasi data adalah perilaku yang diinginkan dalam arsitektur ini.

Tidak setuju. Meskipun Anda tidak boleh berbagi penyimpanan, layanan mikro Anda harus mencoba menjadi tanpa kewarganegaraan jika memungkinkan. jangan menggandakan data kecuali informasi dalam penerbangan

Kesimpulan Anda adalah aturan praktis yang bagus, tetapi tidak universal. Akan ada kasus di mana opsi terbaik adalah untuk melanggar aturan-aturan ini, bahkan dalam proyek greenfield. Dalam beberapa kasus, komunikasi sinkron adalah pilihan terbaik. Dalam beberapa kasus tidak baik untuk menggabungkan dua layanan menjadi satu bahkan jika mereka digabungkan dengan komunikasi sinkron.

Dan untuk pertanyaan Anda yang lain, penemuan layanan tidak diperlukan untuk komunikasi berbasis antrian.

Um, Anda hanya berbicara tentang pemrograman berorientasi objek. Atau setidaknya, apa yang awalnya dianggap sebagai: potongan independen kode berjalan berkomunikasi satu sama lain menggunakan pesan.

Alan Kay memahami OOP sebagai model sistem biologis, di mana sel-sel relatif independen satu sama lain dan hanya berkomunikasi melalui pesan yang dihubungkan ke antarmuka eksternal pada sel lain.

Jadi mengapa kita berhenti menganggapnya sebagai OOP hanya karena semua objek tidak berjalan di komputer yang sama? Jika ada, itu bahkan lebih berorientasi objek daripada jika mereka berada di komputer yang sama dan bagian dari aplikasi yang sama, karena jika semua objek berada di aplikasi yang sama, maka pengembang sering memecahkan OOP dengan menggunakan variabel global yang dibagi oleh semua kelas dan termasuk header yang sama di setiap file, dll. Ketika semua objek bergantung pada hal yang sama, mereka tidak dienkapsulasi seolah-olah mereka benar-benar independen satu sama lain, dan enkapsulasi adalah inti dari OOP.

Misalnya, hampir semua yang dikatakan dalam jawaban lain adalah pernyataan buku teks tentang OOP.

Karena saya sering menemukan pemahaman yang salah tentang konsep penting seperti Bounded Context dan Core Domain, saya ingin sedikit menjelaskannya.

Saya merasa sangat menguntungkan untuk menganggap sub-domain sebagai kemampuan bisnis. Kemampuan bisnis adalah sesuatu yang dilakukan organisasi Anda. Ini adalah salah satu fungsi bisnisnya. Karena tujuan kami adalah penyelarasan bisnis-TI , saya pasti ingin mereka memiliki hubungan 1: 1 dengan layanan teknis saya .

Jadi proses ini bermuara sebagai berikut. Pertama, saya mendefinisikan kapabilitas bisnis tingkat tinggi. Ini harus mengambil bentuk kata benda dan kata kerja (atau beberapa bentuk turunan). Biasanya ada kurang dari 10 kapabilitas bisnis. Lalu saya sangat mendalam, mengidentifikasi kemampuan bersarang. Begitu seterusnya, sampai tidak ada yang membelah. Kemampuan yang Anda gunakan untuk menggunakan pendekatan ini mencerminkan domain sebenarnya, cara nyata organisasi Anda. Kemampuan ini akan secara longgar digabungkan, jadi jika Anda memetakan layanan teknis Anda untuk kemampuan ini, mereka akan mandiri dan dikendalikan oleh peristiwa. Proses ini disebut pemetaan kapabilitas Bisnis , tetapi ada cara lain untuk menemukan layanan Anda, yang paling menonjol di antaranya mungkin adalah Analisis Rantai Nilai .

Berikut adalah contoh mengidentifikasi batasan layanan menggunakan pendekatan ini.