pengantar
Pemilihan gaya arsitektur merupakan salah satu solusi teknis mendasar dalam membangun sistem informasi. Dalam rangkaian artikel ini, saya mengusulkan untuk membongkar gaya arsitektur paling populer untuk aplikasi bangunan dan menjawab pertanyaan kapan gaya arsitektur yang paling disukai. Dalam prosesnya, saya akan mencoba mengikuti rantai logis yang menjelaskan perkembangan gaya arsitektur dari monolit ke layanan mikro.
Terakhir kali kita berbicara tentang berbagai jenis monolit dan cara menggunakan komponen untuk membuatnya, baik komponen perakitan maupun komponen penerapan. Kami menemukan arsitektur berorientasi layanan.
Sekarang kita akhirnya akan menentukan karakteristik utama dari arsitektur layanan mikro.
Hubungan arsitektur
Perlu dipahami bahwa, berdasarkan data di artikel definisi sebelumnya, layanan apa pun adalah komponen, tetapi tidak setiap layanan adalah layanan mikro.
Karakteristik arsitektur layanan mikro
Karakteristik utama dari arsitektur layanan mikro adalah:
- Diorganisir seputar Kemampuan Bisnis
- Produk bukan Proyek
- Titik akhir cerdas dan pipa bodoh
- Tata Kelola Terdesentralisasi
- Manajemen Data Terdesentralisasi
- Otomatisasi Infrastruktur
- Desain untuk kegagalan
- Desain Evolusioner
Poin pertama berasal dari Arsitektur Berorientasi Layanan, karena layanan mikro adalah kasus khusus layanan. Hal-hal lain perlu dipertimbangkan secara terpisah.
Diorganisir seputar Kemampuan Bisnis
Sekarang kita perlu mengingat kembali hukum Conway: organisasi yang membuat sistem mengatur arsitekturnya, meniru struktur interaksi di dalam organisasi ini. Sebagai contoh, pertimbangkan kasus pembuatan kompilator: tim yang terdiri dari tujuh orang mengembangkan kompiler tujuh langkah, dan tim yang terdiri dari lima orang mengembangkan kompiler lima langkah.
Jika kita berbicara tentang monolith dan microservice, maka jika pengembangan diatur oleh departemen fungsional (backend, frontend, administrator database), maka kita mendapatkan monolit klasik.
Untuk mendapatkan layanan mikro, tim perlu diatur berdasarkan peluang bisnis (pesanan, pengiriman, tim katalog). Organisasi ini memungkinkan tim untuk fokus pada pembuatan bagian tertentu dari aplikasi.
Produk bukan Proyek
Pendekatan proyek di mana tim mentransfer fungsionalitas yang dikembangkan ke tim lain dalam kasus arsitektur layanan mikro sama sekali tidak sesuai. Tim harus mendukung sistem di sepanjang siklus hidupnya. Amazon, salah satu flagships dari adopsi layanan mikro, menyatakan: "Anda membangun, Anda menjalankannya". Pendekatan produk memungkinkan tim untuk merasakan kebutuhan bisnis.
Titik akhir cerdas dan pipa bodoh
Arsitektur SOA telah memberikan banyak perhatian pada saluran komunikasi, khususnya Bus Layanan Perusahaan (bus layanan perusahaan). Yang sering mengarah ke Erroneous Spaghetti Box, yaitu kompleksitas monolit berubah menjadi kompleksitas koneksi antar layanan. Arsitektur microsevice hanya menggunakan metode komunikasi sederhana.
Tata Kelola Terdesentralisasi
Keputusan kunci untuk layanan mikro harus dibuat oleh orang yang benar-benar mengembangkan layanan mikro. Di sini, keputusan utama berarti pilihan
bahasa pemrograman, metodologi penerapan, kontrak antarmuka publik, dll.
Manajemen Data Terdesentralisasi
Pendekatan standar, di mana aplikasi bergantung pada satu database, tidak dapat memperhitungkan spesifikasi setiap layanan tertentu. MSA mengasumsikan manajemen data terdesentralisasi, hingga penggunaan berbagai teknologi.
Otomatisasi Infrastruktur
MSA mendukung penyebaran dan proses pengiriman yang berkelanjutan. Ini hanya dapat dilakukan dengan mengotomatiskan proses. Pada saat yang sama, penerapan sejumlah besar layanan tidak lagi tampak menakutkan. Proses penerapan seharusnya membosankan. Aspek kedua terkait dengan manajemen layanan di lingkungan produk. Tanpa otomatisasi, mengelola proses yang berjalan di lingkungan operasi yang berbeda menjadi tidak mungkin.
Desain untuk kegagalan
Banyak layanan MSA yang rentan terhadap kegagalan. Pada saat yang sama, penanganan kesalahan dalam sistem terdistribusi bukanlah tugas yang sangat sepele. Arsitektur aplikasi harus tahan terhadap kegagalan tersebut. Rebecca Parsons merasa sangat penting bahwa kita bahkan tidak lagi menggunakan komunikasi dalam proses antar layanan, sebagai gantinya kita menggunakan HTTP untuk komunikasi, yang hampir tidak dapat diandalkan.
Desain Evolusioner
Arsitektur sistem MSA harus berkembang. Disarankan untuk membatasi perubahan yang diperlukan pada batasan satu layanan. Perlu juga dipertimbangkan dampaknya pada layanan lain. Pendekatan tradisional adalah mencoba dan memperbaiki masalah ini dengan kontrol versi, tetapi MSA menyarankan penggunaan kontrol versi sebagai
upaya terakhir.
Kesimpulan
Setelah semua hal di atas, kita bisa merumuskan apa itu microservice. Arsitektur layanan mikro adalah pendekatan untuk mengembangkan aplikasi tunggal sebagai kumpulan layanan kecil, yang masing-masing berjalan dalam prosesnya sendiri dan berinteraksi melalui mekanisme ringan, seringkali berupa API sumber daya HTTP. Layanan ini dibuat berdasarkan kapabilitas bisnis dan dapat digunakan secara independen menggunakan
mesin penyebaran otomatis. Ada tingkat minimum manajemen terpusat untuk layanan ini, yang dapat ditulis dalam bahasa pemrograman yang berbeda dan menggunakan teknologi penyimpanan yang berbeda. Baca bagian 2
