Mengidentifikasi batas layanan mikro
Berapa ukuran yang tepat untuk layanan mikro? Anda sering mendengar sesuatu untuk efek, "tidak terlalu besar dan tidak terlalu kecil" - dan sementara itu pasti benar, itu tidak terlalu membantu dalam praktik. Tetapi jika Anda memulai dari model domain yang dirancang dengan hati-hati, jauh lebih mudah untuk alasan tentang layanan mikro.
Artikel ini menggunakan layanan pengiriman drone sebagai contoh yang sedang berjalan. Anda dapat membaca lebih lanjut tentang skenario dan implementasi referensi yang sesuai di sini.
Dari model domain ke layanan mikro
Di artikel sebelumnya, kami mendefinisikan sekumpulan konteks terikat untuk aplikasi Pengiriman Drone. Kemudian kita melihat lebih dekat pada salah satu konteks terikat ini, konteks terikat Pengiriman, dan mengidentifikasi sekumpulan entitas, agregat, dan layanan domain untuk konteks terikat tersebut.
Sekarang kita siap untuk pergi dari model domain ke desain aplikasi. Berikut adalah pendekatan yang dapat Anda gunakan untuk mendapatkan layanan mikro dari model domain.
Mulailah dengan konteks terikat. Secara umum, fungsionalitas dalam layanan mikro tidak boleh mencakup lebih dari satu konteks terikat. Menurut definisi, konteks terikat menandai batas model domain tertentu. Jika Anda menemukan bahwa layanan mikro mencampur model domain yang berbeda bersama-sama, itu adalah tanda bahwa Anda mungkin perlu kembali dan memperbaiki analisis domain Anda.
Selanjutnya, lihat agregat dalam model domain Anda. Agregat seringkali merupakan kandidat yang baik untuk layanan mikro. Agregat yang dirancang dengan baik menunjukkan banyak karakteristik layanan mikro yang dirancang dengan baik, seperti:
- Agregat berasal dari persyaratan bisnis, bukan masalah teknis seperti akses data atau olahpesan.
- Agregat harus memiliki kohesi fungsional yang tinggi.
- Agregat adalah batas persistensi.
- Agregat harus digabungkan secara longgar.
Layanan domain juga merupakan kandidat yang baik untuk layanan mikro. Layanan domain adalah operasi tanpa status yang dilakukan di berbagai agregat. Contoh umumnya adalah alur kerja yang melibatkan beberapa layanan mikro. Kita akan melihat contoh ini di aplikasi Pengiriman Drone.
Terakhir, pertimbangkan persyaratan non-fungsi. Lihat faktor-faktor seperti ukuran tim, jenis data, teknologi, persyaratan skalabilitas, persyaratan ketersediaan, dan persyaratan keamanan. Faktor-faktor ini dapat menyebabkan Anda menguraikan lebih lanjut layanan mikro menjadi dua atau lebih layanan yang lebih kecil, atau melakukan kebalikannya dan menggabungkan beberapa layanan mikro menjadi satu.
Setelah Anda mengidentifikasi layanan mikro dalam aplikasi Anda, validasi desain Anda terhadap kriteria berikut:
- Setiap layanan memiliki satu tanggung jawab.
- Tidak ada panggilan cerewet antar layanan. Jika memisahkan fungsionalitas menjadi dua layanan menyebabkan mereka terlalu cerewet, mungkin merupakan gejala bahwa fungsi-fungsi ini termasuk dalam layanan yang sama.
- Setiap layanan cukup kecil sehingga dapat dibangun oleh tim kecil yang bekerja secara independen.
- Tidak ada inter-dependensi yang akan memerlukan dua atau beberapa layanan untuk disebarkan dalam langkah kunci. Seharusnya selalu dimungkinkan untuk menyebarkan layanan tanpa menyebarkan ulang layanan lain.
- Layanan tidak digabungkan dengan erat, dan dapat berkembang secara independen.
- Batas layanan Anda tidak akan menciptakan masalah dengan konsistensi atau integritas data. Terkadang penting untuk menjaga konsistensi data dengan menempatkan fungsionalitas ke dalam satu layanan mikro. Yang mengatakan, pertimbangkan apakah Anda benar-benar membutuhkan konsistensi yang kuat. Ada strategi untuk mengatasi konsistensi akhir dalam sistem terdistribusi, dan manfaat layanan penguraian sering kali melebihi tantangan dalam mengelola konsistensi akhir.
Yang terpenting, penting untuk menjadi pragmatis, dan ingat bahwa desain berbasis domain adalah proses berulang. Ketika ragu, mulailah dengan layanan mikro yang lebih kasar. Memisahkan layanan mikro menjadi dua layanan yang lebih kecil lebih mudah daripada merefaktor fungsionalitas di beberapa layanan mikro yang ada.
Contoh: Menentukan layanan mikro untuk aplikasi Pengiriman Drone
Ingat bahwa tim pengembangan telah mengidentifikasi empat agregat — Pengiriman, Paket, Drone, dan Akun — dan dua layanan domain, Scheduler dan Supervisor.
Pengiriman dan Paket adalah kandidat yang jelas untuk layanan mikro. Penjadwal dan Supervisor mengoordinasikan aktivitas yang dilakukan oleh layanan mikro lainnya, sehingga masuk akal untuk menerapkan layanan domain ini sebagai layanan mikro.
Drone dan Akun menarik karena termasuk dalam konteks terikat lainnya. Salah satu opsinya adalah agar Scheduler memanggil konteks terikat Drone dan Akun secara langsung. Opsi lain adalah membuat layanan mikro Drone dan Akun di dalam konteks terikat Pengiriman. Layanan mikro ini akan memediasi antara konteks terikat, dengan mengekspos API atau skema data yang lebih cocok untuk konteks Pengiriman.
Detail konteks terikat Drone dan Akun berada di luar cakupan panduan ini, jadi kami membuat layanan tiruan untuk mereka dalam implementasi referensi kami. Tetapi berikut adalah beberapa faktor yang perlu dipertimbangkan dalam situasi ini:
Apa overhead jaringan panggilan langsung ke konteks terikat lainnya?
Apakah skema data untuk konteks terikat lainnya cocok untuk konteks ini, atau apakah lebih baik memiliki skema yang disesuaikan dengan konteks terikat ini?
Apakah konteks terikat lainnya adalah sistem warisan? Jika demikian, Anda dapat membuat layanan yang bertindak sebagai lapisan anti-korupsi untuk diterjemahkan antara sistem warisan dan aplikasi modern.
Apa struktur timnya? Apakah mudah untuk berkomunikasi dengan tim yang bertanggung jawab atas konteks terikat lainnya? Jika tidak, membuat layanan yang menengahi antara kedua konteks dapat membantu mengurangi biaya komunikasi lintas tim.
Sejauh ini, kami belum mempertimbangkan persyaratan non-fungsi. Memikirkan persyaratan throughput aplikasi, tim pengembangan memutuskan untuk membuat layanan mikro Penyerapan terpisah yang bertanggung jawab untuk menyerap permintaan klien. Layanan mikro ini akan menerapkan perataan beban dengan memasukkan permintaan masuk ke dalam buffer untuk diproses. Scheduler akan membaca permintaan dari buffer dan menjalankan alur kerja.
Persyaratan non-fungsional membuat tim membuat satu layanan tambahan. Semua layanan sejauh ini telah tentang proses penjadwalan dan pengiriman paket secara real time. Tetapi sistem juga perlu menyimpan riwayat setiap pengiriman dalam penyimpanan jangka panjang untuk analisis data. Tim mempertimbangkan untuk membuat ini menjadi tanggung jawab layanan Pengiriman. Namun, persyaratan penyimpanan data sangat berbeda untuk analisis historis versus operasi dalam penerbangan (lihat Pertimbangan data). Oleh karena itu, tim memutuskan untuk membuat layanan Riwayat Pengiriman terpisah, yang akan mendengarkan peristiwa DeliveryTracking dari layanan Pengiriman dan menulis peristiwa ke dalam penyimpanan jangka panjang.
Diagram berikut menunjukkan desain pada saat ini:
Unduh file Visio arsitektur ini.
Langkah berikutnya
Pada titik ini, Anda harus memiliki pemahaman yang jelas tentang tujuan dan fungsionalitas setiap layanan mikro dalam desain Anda. Sekarang Anda dapat merancang sistem.