Berapa ukuran yang tepat untuk layanan mikro? Anda sering mendengar sesuatu seperti, "tidak terlalu besar dan tidak terlalu kecil" — dan meskipun itu benar, itu tidak terlalu membantu dalam praktiknya. Tetapi jika Anda memulai dari model domain yang dirancang dengan cermat, akan lebih mudah untuk mempertimbangkan layanan mikro.
Artikel ini menggunakan layanan pengiriman drone sebagai contoh yang sedang berjalan. Anda dapat membaca selengkapnya tentang skenario dan implementasi referensi yang sesuai di sini.
Dari model domain hingga layanan mikro
Dalam artikel sebelumnya, kami mendefinisikan serangkaian konteks terbatas untuk aplikasi Pengiriman Drone. Kemudian kami melihat lebih dekat pada salah satu konteks terbatas ini, konteks terbatas Pengiriman, dan mengidentifikasi satu set entitas, agregat, dan layanan domain untuk konteks terbatas tersebut.
Sekarang kami siap untuk beralih dari model domain ke desain aplikasi. Berikut adalah pendekatan yang dapat Anda gunakan untuk mendapatkan layanan mikro dari model domain.
Mulailah dengan konteks yang terikat. Secara umum, fungsionalitas dalam layanan mikro tidak boleh mencakup lebih dari satu konteks yang terikat. Menurut definisi, konteks terikat menandai batas model domain tertentu. Jika Anda menemukan bahwa layanan mikro menggabungkan model domain yang berbeda menjadi satu, itu pertanda bahwa Anda mungkin perlu kembali dan menyempurnakan 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 pengiriman pesan.
- Agregat harus memiliki kohesi fungsional tinggi.
- Agregat adalah batas ketekunan.
- Agregat harus digabungkan secara longgar.
Layanan domain juga merupakan kandidat yang baik untuk layanan mikro. Layanan domain adalah operasi tanpa status 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-fungsional. Lihatlah faktor-faktor seperti ukuran tim, jenis data, teknologi, persyaratan skalabilitas, persyaratan ketersediaan, dan persyaratan keamanan. Faktor-faktor ini dapat mengarahkan Anda untuk menguraikan selengkapnya layanan mikro menjadi dua atau lebih layanan yang lebih kecil, atau melakukan yang sebaliknya dan menggabungkan beberapa layanan mikro menjadi satu.
Setelah Anda mengidentifikasi layanan mikro di aplikasi Anda, validasi desain Anda berdasarkan kriteria berikut:
- Setiap layanan memiliki tanggung jawab tunggal.
- Tidak ada panggilan cerewet antar layanan. Jika pemisahan fungsi menjadi dua layanan menyebabkan mereka menjadi terlalu cerewet, ini 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 mandiri.
- Tidak ada interdependensi yang membutuhkan dua atau lebih layanan untuk disebarkan dalam langkah kunci. Itu harus selalu memungkinkan untuk menyebarkan layanan tanpa menyebarkan kembali layanan lain.
- Layanan tidak digabungkan secara erat, dan dapat berkembang secara independen.
- Batasan layanan Anda tidak akan menimbulkan 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 akhirnya dalam sistem terdistribusi, dan manfaat dari layanan yang membusuk sering kali lebih besar daripada tantangan mengelola konsistensi akhirnya.
Di atas segalanya, penting untuk menjadi pragmatis, dan ingat bahwa desain berbasis domain adalah proses berulang. Jika ragu, mulailah dengan layanan mikro yang lebih kasar. Memisahkan layanan mikro menjadi dua layanan yang lebih kecil lebih mudah daripada memfaktorkan ulang fungsionalitas di beberapa layanan mikro yang ada.
Contoh: Mendefinisikan layanan mikro untuk aplikasi Pengiriman Drone
Ingatlah bahwa tim pengembangan telah mengidentifikasi empat agregat — Pengiriman, Paket, Drone, dan Akun — serta dua layanan domain, Penjadwal dan Pengawas.
Pengiriman dan Paket adalah kandidat yang jelas untuk layanan mikro. Penjadwal dan Pengawas mengoordinasikan aktivitas yang dilakukan oleh layanan mikro lain, jadi masuk akal untuk mengimplementasikan layanan domain ini sebagai layanan mikro.
Drone dan Akun menarik karena mereka termasuk dalam konteks terbatas lainnya. Salah satu opsi adalah agar Penjadwal memanggil konteks terbatas Drone dan Akun secara langsung. Opsi lainnya adalah membuat layanan mikro Drone dan Akun di dalam konteks terbatas Pengiriman. Layanan mikro ini akan menengahi antara konteks yang dibatasi, dengan mengekspos API atau skema data yang lebih sesuai dengan konteks Pengiriman.
Detail dari konteks terbatas 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:
Berapa overhead jaringan untuk menelepon langsung ke konteks terbatas lainnya?
Apakah skema data untuk konteks terbatas lainnya cocok untuk konteks ini, atau lebih baik memiliki skema yang disesuaikan dengan konteks terbatas ini?
Apakah konteks terbatas lainnya merupakan sistem warisan? Jika demikian, Anda dapat membuat layanan yang bertindak sebagai lapisan anti-korupsi untuk menerjemahkan antara sistem lama dan aplikasi modern.
Apa struktur tim? Apakah mudah untuk berkomunikasi dengan tim yang bertanggung jawab atas konteks terbatas lainnya? Jika tidak, membuat layanan yang menengahi antara dua konteks dapat membantu mengurangi biaya komunikasi lintas tim.
Sejauh ini, kami belum mempertimbangkan persyaratan non-fungsional. 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 yang masuk ke dalam buffer untuk diproses. Penjadwal akan membaca permintaan dari buffer dan menjalankan alur kerja.
Persyaratan non-fungsional memimpin tim untuk membuat satu layanan tambahan. Semua layanan selama ini 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 menganggap menjadikan ini sebagai tanggung jawab layanan Pengiriman. Namun, persyaratan penyimpanan data cukup 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 Pelacakan Pengiriman dari layanan Pengiriman dan menulis peristiwa tersebut ke dalam penyimpanan jangka panjang.
Diagram berikut menunjukkan desain pada titik 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.