Halo, Habr. Hari ini saya melanjutkan serangkaian publikasi yang saya tulis khusus untuk memulai aliran kursus baru. .
pengenalan
Pemilihan gaya arsitektur merupakan salah satu keputusan teknis mendasar ketika membangun suatu sistem informasi. Dalam rangkaian artikel ini, saya mengusulkan untuk menganalisis gaya arsitektur paling populer untuk aplikasi bangunan dan menjawab pertanyaan kapan gaya arsitektur mana yang paling disukai. Dalam proses presentasinya, saya akan mencoba menggambar rantai logis yang menjelaskan perkembangan gaya arsitektur dari monolit hingga layanan mikro.
Terakhir kali kita membahas tentang berbagai jenis monolit dan penggunaan komponen untuk membangunnya, baik komponen pembangunan maupun komponen penerapan. Kami memahami arsitektur berorientasi layanan.
Sekarang kita akhirnya akan mendefinisikan karakteristik utama arsitektur layanan mikro.
Hubungan arsitektur
Perlu dipahami bahwa berdasarkan definisi yang diberikan pada artikel sebelumnya, layanan apa pun adalah sebuah komponen, tetapi tidak setiap layanan adalah layanan mikro.
Karakteristik Arsitektur Layanan Mikro
Karakteristik utama arsitektur layanan mikro adalah:
- Diselenggarakan berdasarkan Kemampuan Bisnis
- Produk bukan Proyek
- Titik akhir yang cerdas dan pipa bodoh
- Pemerintahan yang Terdesentralisasi
- Manajemen Data Terdesentralisasi
- Otomatisasi Infrastruktur
- Desain untuk kegagalan
- Arsitektur dengan perkembangan evolusioner (Evolutionary Design)
Poin pertama berasal dari arsitektur berorientasi layanan karena layanan mikro adalah kasus layanan khusus. Poin-poin lain patut dipertimbangkan secara terpisah.
Diselenggarakan berdasarkan Kemampuan Bisnis
Sekarang kita perlu mengingat hukum Conway: organisasi yang menciptakan sistem mengatur arsitekturnya, meniru struktur interaksi dalam organisasi-organisasi ini. Sebagai contoh, kita dapat mengingat kasus pembuatan kompiler: sebuah tim yang terdiri dari tujuh orang mengembangkan kompiler tujuh lintasan, dan tim yang terdiri dari lima orang mengembangkan kompiler lima lintasan.
Jika kita berbicara tentang monolit dan layanan mikro, maka jika pengembangan diatur oleh departemen fungsional (backend, frontend, administrator database), maka kita mendapatkan monolit klasik.
Untuk mendapatkan layanan mikro, tim harus diatur berdasarkan kemampuan bisnis (tim pesanan, pengiriman, katalog). Organisasi ini akan memungkinkan tim untuk fokus membangun bagian tertentu dari aplikasi.
Produk bukan Proyek
Pendekatan proyek di mana sebuah tim mentransfer fungsionalitas yang dikembangkan ke tim lain sama sekali tidak cocok dalam kasus arsitektur layanan mikro. Tim harus mendukung sistem sepanjang siklus hidupnya. Amazon, salah satu pemimpin dalam penerapan layanan mikro, menyatakan: “Anda membangun, Anda menjalankannya.” Pendekatan produk memungkinkan tim merasakan kebutuhan bisnis.
Titik akhir yang cerdas dan pipa bodoh
Arsitektur SOA menaruh perhatian besar pada saluran komunikasi, khususnya Enterprise Service Bus. Yang seringkali berujung pada Erronous Spaghetti Box, yaitu kompleksitas monolit berubah menjadi kompleksitas koneksi antar layanan. Arsitektur layanan mikro hanya menggunakan metode komunikasi sederhana.
Pemerintahan yang Terdesentralisasi
Keputusan penting mengenai layanan mikro harus dibuat oleh orang yang benar-benar mengembangkan layanan mikro. Di sini, keputusan penting 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 melibatkan pengelolaan data yang terdesentralisasi, termasuk penggunaan berbagai teknologi.
Otomatisasi Infrastruktur
MSA mendukung proses penerapan dan pengiriman yang berkelanjutan. Hal ini hanya dapat dicapai melalui otomatisasi proses. Pada saat yang sama, penerapan layanan dalam jumlah besar tidak lagi terlihat menakutkan. Proses penerapan akan menjadi membosankan. Aspek kedua terkait dengan manajemen layanan dalam lingkungan produk. Tanpa otomatisasi, pengelolaan 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 mudah. Arsitektur aplikasi harus tahan terhadap kegagalan tersebut. Rebecca Parsons berpendapat bahwa sangat penting bagi kita untuk tidak lagi menggunakan komunikasi dalam proses antar layanan; sebagai gantinya, kita menggunakan HTTP untuk komunikasi, yang hampir tidak dapat diandalkan.
Arsitektur dengan perkembangan evolusioner (Evolutionary Design)
Arsitektur sistem MSA harus berkembang secara evolusioner. Dianjurkan untuk membatasi perubahan yang diperlukan pada batas-batas satu layanan saja. Dampaknya terhadap layanan lain juga harus diperhitungkan. Pendekatan tradisional adalah mencoba menyelesaikan masalah ini dengan pembuatan versi, tetapi MSA menyarankan penggunaan pembuatan versi
sebagai upaya terakhir.
Kesimpulan
Setelah semua hal di atas, kita bisa merumuskan apa itu microservices. Arsitektur layanan mikro adalah pendekatan untuk mengembangkan aplikasi tunggal sebagai kumpulan layanan kecil, masing-masing berjalan dalam prosesnya sendiri dan berinteraksi melalui mekanisme ringan, sering kali berupa API sumber daya HTTP. Layanan ini dibangun berdasarkan kemampuan bisnis dan dapat diterapkan secara mandiri dengan menggunakan sepenuhnya
mekanisme penyebaran otomatis. Ada tingkat minimum manajemen terpusat dari layanan ini, yang dapat ditulis dalam bahasa pemrograman berbeda dan menggunakan teknologi penyimpanan data berbeda.
Sumber: www.habr.com