Dalam microservice, apakah basis data tunggal atau basis data tunggal untuk setiap layanan?

Saya mengerti bahwa setiap layanan dalam arsitektur microservice harus memiliki database sendiri. Namun, dengan memiliki databasenya sendiri, apakah itu berarti hanya memiliki database lain dalam instance database yang sama atau secara harfiah memiliki instance database lain?

Dengan ini, saya tidak bermaksud berbagi database, yang merupakan contoh tidak-tidak, melainkan contoh basis data.

Misalnya, jika saya menggunakan AWS dan memiliki 3 layanan, apakah saya membuat 3 basis data untuk setiap layanan pada instance RDS tunggal atau apakah saya membuat 3 RDS instance yang masing-masing berisi basis data yang digunakan secara independen oleh masing-masing 3 layanan?

Jika menggunakan banyak basis data pada satu contoh RDS adalah ide yang lebih baik, apakah itu akan mengalahkan tujuan memiliki layanan independen karena untuk:

1. Sumber daya instance RDS akan dibagikan di antara layanan. Apakah Layanan A yang mungkin memiliki penggunaan basis data berat pada waktu tertentu berdampak pada Layanan B yang menggunakan basis data yang berbeda tetapi pada contoh RDS yang sama?

2. Semua layanan akan tergantung pada versi database pada instance RDS itu.

Ini benar-benar tergantung pada persyaratan skalabilitas Anda, dan bagaimana / jika instance layanan mikro Anda perlu bekerja sama untuk memberikan hasil tunggal. Ini membantu untuk mengetahui apa timbal baliknya:

Menyimpan semuanya dalam satu basis data

• Konfigurasi lebih mudah
• Tidak diperlukan koordinasi atau komunikasi dengan layanan lain dari layanan Anda
• Lebih mudah untuk menemukan dataset lengkap Anda
• Kinerja sistem dibatasi oleh kinerja basis data

Memisahkan basis data

• Jawaban lengkap untuk permintaan dapat tersebar di seluruh layanan microservice
• Dalam hal ini Anda telah meningkatkan komunikasi dan negosiasi untuk menyelesaikan permintaan
• Menangani data ketika Anda kehilangan simpul microservice itu (bahkan ketika database masih naik, Anda tidak bisa mendapatkannya sampai yang baru dengan konfigurasi yang tepat berdiri kembali)
• Kompleksitas konfigurasi yang meningkat

Apa masalah yang Anda selesaikan?

Dalam beberapa kasus, Anda hanya khawatir tentang data fana. Jika database turun, itu bukan masalah besar. Dalam kasus-kasus itu, Anda bahkan mungkin tidak memerlukan database. Simpan saja semua itu dalam ingatan dan buat semuanya sangat cepat. Ini adalah solusi termudah untuk dikerjakan.

Dalam kasus lain, Anda memerlukan integritas data, tetapi database Anda mampu memperluas kapasitasnya berdasarkan jumlah node yang dimilikinya. Dalam hal ini, satu database mungkin lebih dari cukup, dan mengelola responsnya secara mandiri adalah jawaban yang tepat.

Ada beberapa kasus di antaranya. Misalnya, Anda mungkin memiliki basis data yang spesifik kawasan, jadi untuk setiap instance layanan Anda di wilayah yang berbeda, Anda memiliki basis data yang terpisah. Basis data yang biasanya tidak berfungsi dengan baik di seluruh wilayah, jadi ini adalah cara untuk melokalisasi data sedikit dan mengendalikan koordinasi Anda sendiri.

Ajaran dan Realitas

Saya telah membaca sejumlah artikel tentang layanan microser dan bagaimana modularnya seharusnya. Rekomendasi berkisar dari menjaga ujung depan, layanan mikro, dan tingkat data sebagai satu kesatuan untuk berbagi basis data dan / atau kode ujung depan untuk semua contoh. Biasanya, lebih banyak isolasi memberikan skalabilitas terbesar, tetapi hal itu terjadi dengan meningkatnya kompleksitas.

Jika microservice Anda adalah perhitungan yang berat, masuk akal untuk memungkinkan jumlah skala microservice tersebut sesuai kebutuhan - berbagi database atau bahkan kode front-end tidak melukai atau menghalangi pendekatan ini.

Kenyataannya adalah bahwa kebutuhan spesifik proyek Anda akan membutuhkan serangkaian kompromi yang berbeda untuk menyelesaikan pekerjaan tepat waktu dan menangani beban sistem yang Anda ukur (ditambah sedikit lagi). Pertimbangkan trio front-end, microsrervice, dan tier data yang sepenuhnya terisolasi sebagai tujuan mulia. Semakin banyak permintaan pada sistem Anda, semakin dekat dengan tujuan yang mungkin Anda butuhkan. Kita tidak semua [insert name of highly successful web entity here], dan mereka tidak memulai dari mana mereka sekarang. Terkadang Anda hanya perlu memulai dengan situasi yang kurang sempurna, dan bahagia dengan itu.

Diasumsikan Anda memiliki beberapa layanan yang dapat menggunakan sistem dan versi DB yang sama, jika Anda menggunakan database atau instance db yang berbeda adalah keputusan yang tidak perlu Anda buat pada waktu desain. Alih-alih, Anda harus bisa membuat keputusan pada waktu penempatan, sesuatu yang bisa Anda konfigurasi. Rancang layanan Anda untuk menjadi agnostik dari tempat di mana database layanan lain dihosting.

Selama operasi, Anda dapat mulai dengan satu instance, dan jika sistem berfungsi dengan baik, biarkan seperti itu. Namun, jika Anda perhatikan ini tidak baik untuk sistem Anda, karena database yang berbeda pada satu contoh berbagi terlalu banyak sumber daya, Anda selalu memiliki opsi untuk menggunakan contoh yang berbeda, jika itu membantu.

Jadi suatu layanan tidak melanggar arsitektur microservice hanya karena Anda membiarkan dua dari mereka berbagi beberapa sumber daya - itu melanggar ketika berbagi sumber daya menjadi wajib.

Itu tidak masalah.

Satu-satunya skenario di mana secara teoritis bisa penting adalah jika satu layanan perlu bermigrasi ke versi database yang berbeda. Tetapi meskipun demikian, tidak ada perbedaan nyata antara memiliki instance yang terpisah dari awal versus memigrasikan satu layanan dari instance bersama ke yang terpisah. Saya sebenarnya mengatakan bahwa memiliki instance yang terpisah hanya karena skenario ini adalah contoh dari YAGNI.

Contoh RDS adalah kotak tunggal. Jika Anda memiliki banyak basis data pada satu contoh maka mereka berbagi CPU / Memori dll.

Jika kinerja microservice Anda terikat oleh kinerja databasenya : kemudian gunakan beberapa salinan microservice, masing-masing menggunakan basis data yang berbeda, tetapi dengan setiap basis data pada instance RDS yang sama. Tidak ada gunanya * (kecuali untuk failover). Cluster microservice Anda akan berjalan pada kecepatan yang sama dengan satu microservice

Namun , saya akan mengatakan bahwa layanan microser yang terikat oleh kinerja database tidak biasa.

Biasanya microservice Anda akan mendapatkan data dari db, melakukan beberapa logika dan menulis beberapa info kembali ke database. Hambatan kinerja adalah logika , bukan pilih dan / atau masukkan.

Dalam hal ini, Anda dapat dengan mudah berbagi database yang sama di semua contoh layanan microser Anda

Tujuan menjaga agar basis data tetap pribadi untuk suatu layanan adalah enkapsulasi. Layanan microser Anda adalah kotak hitam yang akan digunakan layanan lain dalam sistem melalui antarmuka publik.

Ada dua pesawat tempat enkapsulasi ini beroperasi:

• Yang pertama adalah logis, pada level aplikasi. Layanan Anda memiliki beberapa objek bisnis di sistem Anda, dan perlu untuk tetap menyatakan tentang objek-objek ini. Bahwa beberapa database tertentu mendukung objek bisnis ini hanyalah detail implementasi. Dengan menyimpan database terpisah, Anda mencegah layanan lain dari memiliki akses pintu belakang ke implementasi Anda, memaksa mereka untuk menggunakan antarmuka publik Anda. Tujuannya di sini adalah arsitektur yang bersih dan pemrograman yang disiplin. Di mana tepatnya basis data hidup tidak relevan pada tingkat ini, selama layanan Anda memiliki perincian koneksi yang tepat sehingga dapat menemukannya.

• Tingkat kedua adalah operasional. Bahkan jika desain Anda adalah kotak hitam yang sempurna, seperti yang Anda tunjukkan, pekerjaan yang berbeda yang ditempatkan pada satu mesin dapat bersaing untuk sumber daya. Ini adalah alasan yang bagus untuk meletakkan database logis terpisah pada mesin yang berbeda. Seperti jawaban lain telah dicatat, jika kebutuhan Anda tidak terlalu menuntut dan anggaran Anda terbatas, ini adalah argumen pragmatis untuk colocation pada satu mesin. Namun, seperti biasa, pengorbanan: pengaturan ini mungkin memerlukan lebih banyak pengasuhan anak saat sistem Anda tumbuh. Jika anggaran memungkinkan, saya hampir selalu lebih suka dua mesin kecil yang terpisah untuk menjalankan dua tugas dibandingkan berbagi satu mesin yang lebih besar.

Saya pikir mungkin membantu untuk menjadi sedikit lebih teoretis di sini. Salah satu ide yang memotivasi di balik layanan mikro adalah tidak berbagi apa pun, proses penyampaian pesan. Layanan mikro seperti aktor dalam model Aktor. Ini berarti setiap proses mempertahankan keadaan lokalnya sendiri dan satu-satunya cara bagi satu proses untuk mengakses keadaan lain adalah dengan mengirim pesan (dan bahkan kemudian proses lainnya dapat merespons namun suka dengan pesan-pesan itu). Yang dimaksud dengan "setiap layanan mikro memiliki basis datanya sendiri" adalah benar-benar keadaan suatu proses (yaitu layanan mikro) bersifat lokal dan pribadi . Sebagian besar, ini menunjukkan bahwa "database" harus dilokasikandengan microservice, yaitu "database" harus disimpan dan dieksekusi pada node logis yang sama dengan microservice. "Instance" yang berbeda dari microservice adalah proses yang terpisah dan karenanya masing-masing harus memiliki "database" sendiri.

Basis data global atau basis data yang dibagikan di antara layanan-layanan microser atau bahkan contoh-contoh dari layanan-mikro akan, dari perspektif ini, akan membentuk status bersama. Cara "tepat" untuk menangani ini dari perspektif layanan microsoft adalah memiliki database bersama dimediasi oleh layanan database "database". Layanan microser lain yang ingin tahu tentang isi database akan mengirim pesan ke "layanan database microsoft". Ini biasanya tidak akan menghilangkan kebutuhan untuk kondisi lokal (mis. Per contoh layanan "contoh" microservice) untuk layanan microser asli! Perubahan apa yang diwakili oleh negara bagian itu. Alih-alih menyimpan "User Sally adalah admin", itu akan menyimpan "Database microservice mengatakan 'User Sally adalah admin' lima menit yang lalu". Dengan kata lain, tentang keadaan layanan microser lainnya.

Manfaatnya adalah setiap layanan mikro mandiri. Ini menjadikan layanan mikro sebagai unit atom dari kegagalan. Anda (sebagian besar) tidak perlu khawatir tentang layanan microsoft dalam keadaan fungsional sebagian. Tentu saja, masalahnya telah dipindahkan ke jaringan layanan microser. Layanan Microsoft mungkin gagal untuk dapat melakukan fungsi yang diinginkan karena tidak dapat menghubungi layanan microser lainnya. Namun, manfaatnya adalah bahwa layanan mikro akan berada dalam kondisi yang terdefinisi dengan baik dan mungkin dapat menawarkan layanan yang terdegradasi atau terbatas, misalnya dengan mematikan keyakinan yang sudah ketinggalan zaman. Kelemahannya adalah sangat sulit untuk mendapatkan gambaran yang konsisten dari sistem secara keseluruhan, dan mungkin ada cukup banyak redundansi dan duplikasi yang tidak diinginkan.

Tentu saja, sarannya adalah untuk tidak memasukkan instance Oracle ke dalam setiap wadah Docker. Pertama, tidak setiap layanan mikro membutuhkan "basis data". Beberapa proses tidak memerlukan kondisi persisten untuk bekerja dengan benar. Sebagai contoh, sebuah layanan Microsoft yang menerjemahkan antara dua protokol tidak selalu memerlukan status persisten. Karena ketika keadaan gigih diperlukan, kata "database" hanyalah sebuah kata untuk "keadaan gigih". Ini bisa berupa file dengan JSON di dalamnya atau database Sqlite atau salinan Oracle yang dijalankan secara lokal jika Anda mau atau cara lain apa pun secara lokalterus-menerus menyimpan data. Jika "database" bukan lokal, maka dari perspektif layanan-mikro murni, itu harus diperlakukan seperti layanan (mikro) terpisah. Untuk tujuan ini, tidak pernah masuk akal untuk memiliki instance RDS menjadi "database" untuk layanan mikro. Sekali lagi, perspektifnya bukanlah "sekelompok layanan microser dengan basis data RDS mereka sendiri" tetapi "sekelompok layanan microser yang berkomunikasi dengan basis data RDS". Pada titik ini tidak ada bedanya apakah data disimpan dalam instance database yang sama atau tidak.

Secara pragmatis, arsitektur layanan mikro menambah kompleksitas yang sangat besar . Kompleksitas ini hanyalah harga dari berurusan dengan kegagalan parsial. Bagi banyak orang, itu adalah kerja keras yang sangat mungkin tidak sebanding dengan manfaatnya. Anda harus merasa bebas untuk merancang sistem Anda dengan cara apa pun yang tampaknya paling bermanfaat. Ada peluang bagus bahwa kekhawatiran tentang kesederhanaan dan efisiensi dapat menyebabkan penyimpangan dari arsitektur layanan-mikro murni. Biaya akan menjadi penggandeng tambahan yang memperkenalkan kompleksitasnya sendiri seperti interaksi tak terlihat antara layanan dan pembatasan kebebasan Anda untuk menyebarkan dan skala sesuka Anda.