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.
The terakhir kali kita berurusan dengan monolit dan sampai pada kesimpulan bahwa monolit memiliki sejumlah masalah: ukuran, konektivitas, penyebaran, skalabilitas, keandalan dan konservatisme.
Kali ini saya mengusulkan untuk membahas kemungkinan pengorganisasian sistem dalam bentuk sekumpulan modul / perpustakaan (arsitektur berorientasi komponen) atau layanan (arsitektur berorientasi layanan).
Arsitektur berorientasi komponen
Arsitektur berbasis komponen menyiratkan penerapan sistem sebagai sekumpulan komponen yang dapat digunakan baik dalam proyek saat ini maupun yang akan datang. Saat membagi sistem menjadi beberapa komponen, faktor-faktor berikut diperhitungkan: kesesuaiannya untuk digunakan kembali, dapat diganti, independensinya dari konteks, ekstensibilitas, enkapsulasi, dan independensi.
Dengan penggunaan komponen yang tepat, masalah โbola besar kotoranโ (ukuran besar + konektivitas tinggi) diselesaikan, dan komponen itu sendiri dapat berupa unit perakitan (modul, perpustakaan) dan unit penyebaran (layanan). Unit penyebaran tidak selalu dipetakan ke proses yang berjalan: misalnya, aplikasi web dan database diterapkan bersama.
Paling sering, monolit dirancang sebagai satu set modul. Pendekatan ini mengarah pada memastikan kemandirian pengembangan, tetapi pada saat yang sama masalah penskalaan dan penerapan independen, toleransi kesalahan, dan independensi dari tumpukan teknologi umum tetap ada. Inilah sebabnya mengapa modul merupakan komponen independen sebagian.
Masalah terbesar dengan monolit semacam itu adalah pembagian menjadi modul sepenuhnya logis dan dapat dengan mudah dipecahkan oleh pengembang. Modul inti mungkin muncul, yang secara bertahap berubah menjadi tumpukan sampah, grafik ketergantungan antar modul dapat bertambah, dan seterusnya. Untuk menghindari masalah seperti itu, pengembangan harus dilakukan baik oleh tim yang sangat matang, atau di bawah bimbingan seorang "arsitek" yang terlibat dalam peninjauan kode secara penuh dan mengalahkan tangan pengembang yang melanggar struktur logis.
Monolit "ideal" adalah sekumpulan modul yang dipisahkan secara logis, yang masing-masing melihat ke dalam database-nya sendiri.
Arsitektur berorientasi layanan
Namun, jika seharusnya mengatur sistem sebagai satu set layanan, maka kita berbicara tentang arsitektur berorientasi layanan. Prinsip-prinsipnya adalah: interoperabilitas aplikasi berorientasi pengguna, dapat digunakan kembali layanan bisnis, kemandirian dari serangkaian teknologi dan otonomi (evolusi independen, skalabilitas, dan penyebaran).
Arsitektur berorientasi layanan (SOA) memecahkan semua masalah yang digariskan monolit: perubahan hanya memengaruhi satu layanan, dan API yang terdefinisi dengan baik mendukung enkapsulasi komponen yang baik.
Namun tidak semuanya mulus: SOA menghadirkan masalah baru. Panggilan jarak jauh lebih mahal daripada panggilan lokal, dan pendistribusian ulang tanggung jawab antar komponen menjadi jauh lebih mahal.
Ngomong-ngomong, kemampuan untuk menerapkan secara mandiri adalah fitur layanan yang sangat penting. Jika layanan akan diterapkan bersama, atau bahkan lebih dalam urutan tertentu, maka sistem 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 arsitektur layanan mikro).
Arsitektur berorientasi layanan didukung dengan baik oleh komunitas arsitektur dan vendor. Karenanya, ada banyak kursus dan sertifikasi, pola yang berkembang dengan baik. Yang terakhir ini termasuk, misalnya, bus layanan perusahaan yang tidak dikenal (ESB = bus layanan perusahaan). Pada saat yang sama, ESB adalah bagasi dari vendor, tidak harus digunakan di SOA.
Arsitektur berorientasi layanan memuncak dalam popularitas sekitar tahun 2008, setelah itu mulai menurun, yang menjadi jauh lebih tajam 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 memberi perhatian khusus pada perbedaan antara arsitektur layanan mikro dan arsitektur berorientasi layanan di bagian selanjutnya.
