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.
В kami menangani monolit dan sampai pada kesimpulan bahwa monolit memiliki sejumlah masalah: ukuran, konektivitas, penerapan, skalabilitas, keandalan, dan kekakuan.
Kali ini saya mengusulkan untuk berbicara tentang kemungkinan pengorganisasian sistem sebagai sekumpulan modul/perpustakaan (arsitektur berorientasi komponen) atau layanan (arsitektur berorientasi layanan).
Arsitektur berorientasi komponen
Arsitektur berorientasi komponen melibatkan pelaksanaan sistem sebagai sekumpulan komponen yang dapat digunakan baik dalam proyek saat ini maupun di masa depan. Saat memecah sistem menjadi beberapa komponen, hal-hal berikut ini diperhitungkan: dapat digunakan kembali, dapat diganti, independensi konteks, ekstensibilitas, enkapsulasi, dan independensi.
Dengan penggunaan komponen yang tepat, masalah “bola kotoran besar” (ukuran besar + kopling tinggi) terpecahkan, dan komponen itu sendiri dapat mewakili unit perakitan (modul, perpustakaan) dan unit penerapan (layanan). Unit penerapan tidak selalu dipetakan ke proses yang sedang berjalan: misalnya, aplikasi web dan database disebarkan secara bersamaan.
Paling sering, monolit dikembangkan sebagai satu set modul. Pendekatan ini mengarah pada pengembangan yang independen, namun masalah penskalaan dan penerapan independen, toleransi kesalahan, dan independensi dari keseluruhan teknologi masih tetap ada. Itulah sebabnya modul merupakan komponen yang sebagian independen.
Masalah terbesar dengan monolit semacam itu adalah bahwa pembagian menjadi modul-modul adalah murni logis dan dapat dengan mudah dilanggar oleh pengembang. Modul inti mungkin muncul, yang lambat laun berubah menjadi tempat pembuangan sampah, grafik ketergantungan antar modul dapat bertambah, dan seterusnya. Untuk menghindari masalah seperti itu, pengembangan harus dilakukan oleh tim yang sangat matang, atau di bawah bimbingan seorang "arsitek" yang terlibat dalam peninjauan kode penuh waktu dan menangani pengembang yang melanggar struktur logis.
Monolit "ideal" adalah sekumpulan modul yang dipisahkan secara logis, yang masing-masing melihat ke dalam databasenya sendiri.
Arsitektur berorientasi layanan
Jika sistem seharusnya diatur dalam bentuk sekumpulan layanan, maka kita berbicara tentang arsitektur berorientasi layanan. Prinsip-prinsipnya adalah interoperabilitas aplikasi yang berpusat pada pengguna, penggunaan kembali layanan bisnis, kemandirian tumpukan teknologi, dan otonomi (evolusi independen, skalabilitas, dan penerapan).
Arsitektur berorientasi layanan (SOA = arsitektur berorientasi layanan) menyelesaikan semua masalah monolit yang teridentifikasi: hanya satu layanan yang terpengaruh ketika terjadi perubahan, dan API yang terdefinisi dengan baik mendukung enkapsulasi komponen yang baik.
Namun tidak semuanya berjalan mulus: SOA menimbulkan masalah baru. Panggilan jarak jauh lebih mahal dibandingkan panggilan lokal, dan mendistribusikan ulang tanggung jawab antar komponen menjadi jauh lebih mahal.
Omong-omong, kemungkinan penerapan independen adalah fitur yang sangat penting dari layanan ini. Jika layanan harus disebarkan secara bersamaan atau, terlebih lagi, dalam urutan tertentu, maka sistem tersebut tidak dapat dianggap berorientasi layanan. Dalam hal ini, mereka berbicara tentang monolit terdistribusi (dianggap sebagai anti-pola tidak hanya dari sudut pandang SOA, tetapi juga dari sudut pandang arsitektur layanan mikro).
Arsitektur berorientasi layanan didukung dengan baik oleh komunitas arsitektur dan vendor. Hal ini menyiratkan adanya banyak kursus dan sertifikasi, pola yang berkembang dengan baik. Yang terakhir ini mencakup, misalnya, bus layanan perusahaan yang terkenal (ESB = bus layanan perusahaan). Pada saat yang sama, ESB adalah bagasi dari vendor; tidak harus digunakan dalam SOA.
Popularitas arsitektur berorientasi layanan mencapai puncaknya sekitar tahun 2008, setelah itu mulai menurun, dan menjadi jauh lebih dramatis setelah munculnya layanan mikro (~2015).
Kesimpulan
Setelah kita membahas kemungkinan pengorganisasian sistem informasi dalam bentuk layanan dan modul, saya mengusulkan untuk akhirnya beralih ke prinsip-prinsip arsitektur layanan mikro dan memberikan perhatian khusus pada perbedaan antara arsitektur layanan mikro dan arsitektur berorientasi layanan di bagian selanjutnya.
Sumber: www.habr.com