Beberapa kata untuk membela monolit

Kami membandingkan fitur-fitur dari microservice dan arsitektur monolitik, kelebihan dan kekurangannya. Artikel ini disiapkan untuk Habr berdasarkan bahan meta Hot Backend kami , yang diadakan di Samara pada 9 Februari 2019. Kami mempertimbangkan faktor-faktor pilihan arsitektur tergantung pada tugas spesifik.

Bahkan 5 tahun yang lalu, tidak ada yang pernah mendengar tentang layanan microser. Namun, popularitas mereka meningkat dari tahun ke tahun, menurut statistik dari Google Trends.

Monolith dan layanan mikro: contoh

Jika proyek menggunakan arsitektur monolitik, maka pengembang hanya memiliki satu aplikasi, semua komponen dan modul yang bekerja dengan basis tunggal.



Arsitektur microservice melibatkan penguraian menjadi modul yang dijalankan sebagai proses terpisah dan dapat memiliki server terpisah. Setiap microservice bekerja dengan basis datanya sendiri, dan semua layanan ini dapat berkomunikasi satu sama lain baik secara sinkron (http) maupun secara tidak sinkron. Selain itu, untuk mengoptimalkan arsitektur, diharapkan untuk meminimalkan hubungan antar layanan.

Diagram di bawah ini disederhanakan, itu mencerminkan, pertama-tama, komponen bisnis.

Layanan Mikro: manfaat

Setidaknya ada empat keunggulan arsitektur layanan mikro:

Penskalaan dan Penerapan Independen

Penyebaran independen disediakan untuk setiap layanan mikro, dan ini nyaman saat memperbarui modul individu. Jika beban pada modul meningkat, microservice yang sesuai dapat diskalakan tanpa mempengaruhi yang lain. Ini memungkinkan Anda untuk secara fleksibel mendistribusikan beban dan menghemat sumber daya.

Pengembangan mandiri

Setiap perangkat mikro (misalnya, modul memori) dapat dikembangkan oleh satu tim untuk meningkatkan kecepatan pembuatan produk perangkat lunak.

Keberlanjutan

Kegagalan satu microservice tidak mempengaruhi kinerja modul lainnya.

Heterogenitas

Setiap tim bebas memilih bahasa dan teknologinya sendiri untuk mengimplementasikan layanan-layanan microser, namun diharapkan memiliki antarmuka yang kompatibel.

Di antara pengembang, Anda dapat mendengar pendapat bahwa arsitektur monolitik sudah ketinggalan zaman, sulit untuk mempertahankan dan skala, itu tumbuh dengan cepat di "benjolan besar kotoran" dan praktis antipernah, yaitu, keberadaannya dalam kode tidak diinginkan. Perusahaan besar, seperti Netflix, yang beralih ke arsitektur microservice dalam proyek mereka, sering dikutip sebagai bukti pendapat ini.

Mari kita lihat apakah semua orang benar-benar harus beralih dari monolith ke layanan microser mengikuti contoh merek terbesar?

Beralih ke layanan microser: kemungkinan kesulitan

Masalah Satu: Dekomposisi

Idealnya, aplikasi harus dibagi ke dalam layanan-layanan mikro sehingga mereka saling berinteraksi sesedikit mungkin, jika tidak, aplikasi tersebut akan sulit dipertahankan. Pada saat yang sama, dekomposisi sulit diimplementasikan pada awal pengembangan, ketika masalah bisnis dan bidang studi masih dapat berubah dengan munculnya persyaratan baru. Refactoring itu mahal.

Jika menjadi perlu untuk mentransfer bagian dari fungsi dari layanan A ke layanan B, maka kesulitan mungkin terjadi di sini: misalnya, layanan dieksekusi dalam berbagai bahasa, panggilan internal ke layanan menjadi jaringan, perpustakaan lain harus terhubung. Kami dapat memverifikasi kebenaran refactoring hanya dengan bantuan tes.



Masalah Dua: Transaksi

Masalah lain adalah bahwa layanan microser tidak memiliki konsep transaksi terdistribusi. Kami dapat menjamin integritas arsitektur operasi bisnis hanya dalam satu layanan microser. Jika operasi melibatkan beberapa layanan mikro, basis data yang berbeda dapat digunakan di sana, dan transaksi seperti itu harus ditinggalkan. Untuk mengatasi masalah ini, ada berbagai metode yang digunakan dalam bisnis ketika aksesibilitas lebih penting daripada integritas. Pada saat yang sama, mekanisme kompensasi disediakan jika terjadi kesalahan. Misalnya, jika barang tidak tersedia, Anda perlu melakukan pengembalian dana ke akun pembeli.

Jika sebuah monolith memberi kita integritas arsitektur secara otomatis, maka dengan layanan microser Anda perlu menemukan mekanisme Anda sendiri dan menggunakan perpustakaan dengan solusi yang sudah jadi. Saat mendistribusikan operasi antar layanan, lebih baik meminta data secara sinkron, dan melakukan tindakan selanjutnya secara tidak sinkron. Jika tidak mungkin mengakses salah satu layanan, tim akan antri segera setelah tersedia lagi.

Dalam hal ini, perlu untuk merevisi pendekatan ke antarmuka pengguna. Pengguna harus diberitahu bahwa beberapa tindakan tidak dilakukan segera, tetapi dalam waktu tertentu. Ketika aplikasi diproses, ia menerima undangan untuk melihat hasilnya.



Masalah Tiga: Pelaporan

Jika kami menggunakan arsitektur monolitik dengan satu basis data, untuk membuat laporan yang kompleks, Anda dapat menulis pilih dan menarik beberapa label data: cepat atau lambat akan ditampilkan. Namun, pada layanan microser data ini dapat tersebar di berbagai basis.

Misalnya, kita perlu membuat daftar perusahaan dengan metrik tertentu. Dengan daftar perusahaan yang sederhana, semuanya berfungsi. Dan jika Anda perlu menambahkan metrik yang ada di database lain? Ya, kami dapat membuat permintaan tambahan dan meminta metrik oleh TIN. Dan jika daftar ini perlu disaring dan disortir? Daftar perusahaan bisa sangat besar, dan kemudian kami harus memperkenalkan layanan tambahan dengan database sendiri - laporan.



Masalah Empat: Kompleksitas Pengembangan Tinggi

Bekerja pada layanan terdistribusi lebih rumit: semua permintaan dilakukan melalui jaringan dan dapat dimatikan, Anda perlu menyediakan mekanisme panggilan balik (akankah membuat panggilan lagi? Berapa kali?). Ini adalah "batu bata" yang secara bertahap menumpuk dan berkontribusi untuk meningkatkan kompleksitas proyek.

Layanan dapat dikembangkan oleh beberapa tim yang berbeda, dan Anda perlu mendokumentasikannya, memperbarui dokumentasinya, memperingatkan tim lain ketika mengubah versi. Ini adalah biaya tenaga kerja tambahan.

Jika setiap tim memiliki penerapan independen, Anda harus mempertahankan setidaknya versi sebelumnya dan menonaktifkannya hanya setelah semua konsumen layanan beralih ke API baru.
Tentu saja, kita dapat mengambil semua API menjadi semacam artefak yang akan tersedia untuk umum. Tetapi, pertama, layanan dapat ditulis dalam berbagai bahasa, dan kedua, ini tidak disarankan. Misalnya, di salah satu proyek kami, kami menolak ini atas permintaan pelanggan, terkait pertimbangan keamanan. Setiap microservice memiliki repositori terpisah, dan pelanggan tidak memberikan akses kepada mereka.

Dalam proses pengembangan, semuanya dapat bekerja dengan benar, dan kemudian - tidak. Itu terjadi bahwa dalam kasus pengecualian, aplikasi tanpa batas mencoba untuk memprosesnya, dan ini memberikan beban besar - seluruh sistem "meletakkan". Untuk menghindari situasi seperti itu, Anda harus mengonfigurasi semuanya, misalnya, untuk membatasi jumlah upaya, untuk tidak mengembalikan panggilan ini ke antrian di detik yang sama, dll.





Masalah kelima: kompleksitas pengujian, penelusuran dan debugging

Untuk menguji masalah, Anda harus mengunduh semua layanan microsoft yang terlibat. Debugging menjadi tugas yang tidak sepele, dan semua log harus dikumpulkan di suatu tempat di satu tempat. Dalam hal ini, Anda perlu log sebanyak mungkin untuk mencari tahu apa yang terjadi. Untuk melacak masalah, Anda perlu memahami seluruh jalur yang dilalui pesan. Tes unit tidak cukup di sini, karena kesalahan mungkin terjadi di persimpangan layanan. Saat melakukan perubahan, dimungkinkan untuk memverifikasi pengoperasian hanya setelah berjalan di dudukan. Kami dapat membatasi masing-masing layanan Microsoft hingga jumlah memori tertentu (misalnya, 500 megabita), tetapi ada saat-saat beban puncak saat dibutuhkan hingga dua gigabita. Ada kalanya sistem mulai melambat. Akibatnya, sumber daya dapat dihabiskan untuk sesuatu yang bukan milik tugas langsung klien: misalnya, hanya ada dua layanan microser bisnis, dan setengah dari sumber daya dihabiskan untuk tiga layanan microser tambahan yang mendukung pekerjaan yang lain.

Layanan mikro atau monolit: kriteria seleksi

Ketika memilih antara arsitektur monolitik dan microservice, pertama-tama, Anda perlu melanjutkan dari kerumitan area subjek dan kebutuhan untuk penskalaan.

Jika area subjek sederhana, dan peningkatan global dalam jumlah pengguna tidak diharapkan, maka layanan microser dapat digunakan tanpa keraguan. Dalam kasus lain, lebih baik memulai pengembangan dengan monolit dan menghemat sumber daya jika penskalaan tidak diperlukan. Jika area subjek kompleks, dan pada tahap awal persyaratan akhir tidak ditentukan, juga lebih baik untuk memulai dengan monolith - agar tidak mengulangi layanan microsec beberapa kali. Dengan pengembangan lebih lanjut dari proyek, adalah mungkin untuk membedakan bagian-bagian individual dalam layanan-layanan microser.



Nilai plus adalah adanya batas pada awal proyek, karena hal ini akan membantu untuk tidak mematahkannya selama proses pengembangan. Masuk akal juga untuk memulai dengan satu basis data, tetapi untuk menentukan skema untuk setiap modul (misalnya, skema pembayaran). Selanjutnya, ini akan membantu menyederhanakan pembagian modul menjadi layanan microser. Dalam hal ini, kami mengamati batas-batas modul dan dapat menggunakan layanan microser.

Setiap modul harus memiliki API sendiri, sehingga nantinya dapat dialokasikan dan menjadikan modul sebagai layanan mikro.



Setelah menentukan batas-batas modul, Anda dapat melanjutkan ke dekomposisi ke dalam layanan microser, jika perlu. Dalam sekitar 90% kasus akan memungkinkan untuk tetap menggunakan monolit, tetapi jika perlu akan lebih mudah dan lebih murah untuk mengubah arsitektur.

Dalam praktik kami bekerja dengan monolit dan layanan mikro, kami sampai pada kesimpulan berikut:

• Jangan beralih ke layanan microser hanya karena digunakan oleh Netflix, Twitter, Facebook
• Mulailah dengan dua atau tiga layanan microser yang berinteraksi satu sama lain, tentukan semua persyaratan non-fungsional secara terperinci (keamanan, toleransi kesalahan, skalabilitas, dll.) Dan baru kemudian beralih ke layanan lain
• Otomatiskan semua yang mungkin
• Atur pemantauan
• Tulis autotest
• Jangan gunakan transaksi terdistribusi (tapi ini bukan alasan untuk menolak jaminan integritas data).
• Jika Anda ingin menggunakan arsitektur layanan mikro, bersiaplah untuk kenyataan bahwa pengembangan dapat dikenakan biaya sekitar 3 kali lebih banyak daripada pada monolit. Namun, kedua teknologi memiliki kelemahan dan kelebihan masing-masing, masing-masing memiliki ceruk masing-masing.