Tidak ada solusi yang jelas karena ini sepenuhnya tergantung pada konteks Anda - khususnya, di mana dimensi sistem Anda seharusnya skala dan apa masalah Anda yang sebenarnya. Apakah database benar-benar menjadi hambatan Anda?
Jawaban ini (sayangnya agak panjang) akan berbunyi seperti "layanan microser buruk, monolit seumur hidup!", Tapi itu bukan maksud saya. Maksud saya adalah bahwa microservices dan database terdistribusi dapat menyelesaikan berbagai masalah, tetapi tidak tanpa memiliki masalah mereka sendiri. Untuk membuat argumen yang kuat untuk arsitektur Anda, Anda harus menunjukkan bahwa masalah ini tidak berlaku, dapat dikurangi, dan bahwa arsitektur ini adalah pilihan terbaik untuk kebutuhan bisnis Anda.
Data yang didistribusikan sulit.
Fleksibilitas yang sama yang memungkinkan penskalaan yang lebih baik adalah sisi lain dari jaminan yang lebih lemah. Khususnya, sistem terdistribusi jauh lebih sulit untuk dipikirkan.
Pembaruan atom, transaksi, konsistensi / integritas referensial, dan daya tahan sangat berharga dan tidak boleh diabaikan dengan gegabah. Ada sedikit gunanya memiliki data jika tidak lengkap, ketinggalan zaman, atau salah total. Ketika Anda memiliki ACID sebagai persyaratan bisnis tetapi menggunakan teknologi database yang tidak dapat menawarkannya secara otomatis (mis. Banyak basis data NoSQL, atau arsitektur DB-per-microservice), maka aplikasi Anda harus mengisi kesenjangan dan memberikan jaminan tersebut.
Ini bukan tidak mungkin dilakukan, tetapi sulit untuk dilakukan dengan benar. Sangat rumit. Terutama dalam pengaturan terdistribusi di mana ada banyak penulis untuk setiap basis data. Kesulitan ini diterjemahkan menjadi kemungkinan besar bug, mungkin termasuk data yang jatuh, data yang tidak konsisten, dan sebagainya.
Sebagai contoh, pertimbangkan untuk membaca analisis Jepsen dari sistem basis data terdistribusi yang terkenal , mungkin dimulai dengan analisis Cassandra . Saya tidak mengerti setengah dari analisis itu, tetapi TL; DR adalah bahwa sistem terdistribusi sangat sulit bahkan proyek-proyek industri terkemuka kadang-kadang salah, dengan cara yang tampak jelas di belakang.
Sistem terdistribusi juga menyiratkan upaya pengembangan yang lebih besar. Untuk tingkat tertentu, ada trade-off langsung antara biaya pengembangan atau menjatuhkan uang pada perangkat keras yang lebih besar.
Contoh: referensi menggantung
Dalam praktiknya, Anda tidak boleh melihat pada ilmu komputer tetapi pada persyaratan bisnis Anda untuk melihat apakah dan bagaimana ACID bisa santai. Misalnya, banyak hubungan kunci asing mungkin tidak sepenting kelihatannya. Pertimbangkan hubungan kategori - produk n: m. Dalam RDBMS kita dapat menggunakan batasan kunci asing sehingga hanya produk yang ada dan kategori yang ada yang dapat menjadi bagian dari hubungan itu. Apa yang terjadi jika kami memperkenalkan layanan produk dan kategori terpisah, dan produk atau kategori dihapus?
Dalam hal ini, itu mungkin bukan masalah besar dan kita dapat menulis aplikasi kita sehingga menyaring semua produk atau kategori yang tidak ada lagi. Tapi ada pengorbanan!
Perhatikan bahwa ini mungkin memerlukan tingkat aplikasi JOINlebih dari beberapa basis data / layanan mikro, yang hanya memindahkan pemrosesan dari server database ke aplikasi Anda. Ini meningkatkan total muatan dan harus memindahkan data tambahan melalui jaringan.
Ini dapat mengacaukan pagination. Misalnya Anda meminta 25 produk berikutnya dari suatu kategori, dan memfilter produk yang tidak tersedia dari respons itu. Sekarang aplikasi Anda menampilkan 23 produk. Secara teori, halaman dengan nol produk juga dimungkinkan!
Anda ingin sesekali menjalankan skrip yang membersihkan referensi yang menggantung, baik setelah setiap perubahan yang relevan atau secara berkala. Perhatikan bahwa skrip semacam itu cukup mahal karena mereka harus meminta setiap produk / kategori dari basis data dukungan / layanan mikro untuk melihat apakah masih ada.
Ini harus jelas, tetapi untuk kejelasan: jangan menggunakan kembali ID. ID gaya kenaikan otomatis mungkin atau mungkin tidak baik-baik saja. GUID atau hash memberi Anda lebih banyak fleksibilitas, misalnya dengan mampu memberikan ID sebelum item dimasukkan ke dalam database.
Contoh: pesanan bersamaan
Sekarang alih-alih pertimbangkan hubungan produk-pesanan. Apa yang terjadi pada pesanan jika suatu produk dihapus atau diubah? Ok, kita cukup menyalin data produk yang relevan ke dalam entri pesanan agar tetap tersedia - memperdagangkan ruang disk untuk kesederhanaan. Tetapi bagaimana jika harga produk berubah atau produk menjadi tidak tersedia sebelum pesanan untuk produk itu dibuat? Dalam sistem terdistribusi, efek membutuhkan waktu untuk disebarkan dan pesanan kemungkinan akan berlanjut dengan data yang sudah ketinggalan zaman.
Sekali lagi, cara pendekatan ini tergantung pada kebutuhan bisnis Anda. Mungkin pesanan usang dapat diterima, dan Anda kemudian dapat membatalkan pesanan jika tidak dapat dipenuhi.
Tapi mungkin itu bukan pilihan, misalnya untuk pengaturan yang sangat bersamaan. Pertimbangkan 3000 orang yang terburu-buru untuk membeli tiket konser dalam 10 detik pertama, dan mari kita asumsikan perubahan ketersediaan akan membutuhkan 10 ms untuk disebarkan. Berapa probabilitas menjual tiket terakhir ke banyak orang? Bergantung pada bagaimana tabrakan itu ditangani, tetapi menggunakan distribusi Poisson dengan λ = 3000 / (10s / 10ms) = 3kami mendapatkan P(k > 1) = 1 - P(k = 0) - P(k = 1) = 80%peluang tabrakan per interval 10 ms. Apakah menjual dan kemudian membatalkan sebagian besar pesanan Anda adalah mungkin tanpa melakukan penipuan dapat menyebabkan percakapan yang menarik dengan departemen hukum Anda.
Pragmatisme berarti memetik ceri fitur terbaik.
Berita baiknya adalah Anda tidak harus pindah ke model database terdistribusi, jika itu tidak diperlukan sebaliknya. Tidak ada yang akan mencabut keanggotaan Microservice Club Anda jika Anda tidak melakukan layanan microser "dengan benar", karena tidak ada klub seperti itu - dan tidak ada satu cara yang benar untuk membangun layanan microser.
Pragmatisme menang setiap saat, jadi padukan dan padukan berbagai pendekatan saat mereka memecahkan masalah Anda. Ini bahkan bisa berarti layanan microser dengan basis data terpusat. Sungguh, jangan melalui rasa sakit dari database terdistribusi jika Anda tidak perlu.
Anda dapat mengatur skala tanpa layanan microser.
Layanan Microsoft memiliki dua manfaat utama:
- Manfaat organisasi yang dapat dikembangkan dan digunakan secara independen oleh tim yang terpisah (yang pada gilirannya membutuhkan layanan untuk menawarkan antarmuka yang stabil).
- Manfaat operasional bahwa setiap layanan mikro dapat diskalakan secara independen .
Jika penskalaan independen tidak diperlukan, layanan microsoft jauh kurang menarik.
Server database sudah merupakan jenis layanan yang Anda dapat skala (agak) secara mandiri, misalnya dengan menambahkan replika baca. Anda menyebutkan prosedur tersimpan. Mengurangi mereka mungkin memiliki efek besar sehingga diskusi skalabilitas lainnya diperdebatkan.
Dan sangat mungkin untuk memiliki monolith yang dapat diskalakan yang mencakup semua layanan sebagai perpustakaan. Anda kemudian dapat meningkatkan dengan meluncurkan lebih banyak instance dari monolith, yang tentu saja mengharuskan setiap instance menjadi stateless.
Ini cenderung berfungsi dengan baik sampai monolith terlalu besar untuk digunakan secara wajar, atau jika beberapa layanan memiliki persyaratan sumber daya khusus sehingga Anda mungkin ingin skala mereka secara mandiri. Domain masalah yang melibatkan sumber daya tambahan mungkin tidak melibatkan model data terpisah.
Apakah Anda memiliki kasus bisnis yang kuat?
Anda mengetahui kebutuhan bisnis organisasi Anda, dan karenanya dapat membuat argumen untuk arsitektur basis data per layanan-mikro, berdasarkan analisis:
- bahwa skala tertentu diperlukan, dan arsitektur ini adalah pendekatan yang paling hemat biaya untuk mendapatkan skalabilitas itu, dengan mempertimbangkan upaya pengembangan yang meningkat untuk pengaturan dan solusi alternatif semacam itu; dan
- bahwa persyaratan bisnis Anda memungkinkan jaminan ACID yang relevan untuk dilonggarkan, tanpa mengarah ke berbagai masalah seperti yang dibahas di atas.
Sebaliknya, jika Anda tidak dapat menunjukkan ini, khususnya jika desain basis data saat ini mampu mendukung skala yang cukup di masa depan (seperti yang diyakini oleh rekan kerja Anda), maka Anda juga memiliki jawaban.
Ada juga komponen YAGNI besar untuk skalabilitas. Dalam menghadapi ketidakpastian, ini adalah keputusan bisnis strategis untuk membangun skalabilitas sekarang (biaya total lebih rendah, tetapi melibatkan biaya peluang dan mungkin tidak diperlukan) dibandingkan menunda beberapa pekerjaan pada skalabilitas (total biaya lebih tinggi jika diperlukan, tetapi Anda memiliki yang lebih baik ide skala aktual). Ini terutama bukan keputusan teknis.