Jika arsitektur microservice membutuhkan basis data terpisah per microservice maka itu terlalu mahal & tidak terkelola. Mengapa kita membutuhkannya?

Saya membaca tentang layanan microser dan tampaknya tidak masuk akal bagi saya untuk membuat DB terpisah per layanan hanya untuk mencapai isolasi. Saya dapat mencapai hal yang sama hanya menggunakan layanan web dan satu basis data. Mengapa kita membutuhkannya? Hal yang memisahkan database tidak dapat dibicarakan. Atau saya salah? Bisakah Anda membimbing saya dalam hal ini?

Mengapa kita membutuhkannya?

Kamu tidak.

Membuat database terpisah untuk setiap layanan membantu menegakkan batasan domain, tetapi hanya satu pendekatan. Tidak ada yang menghentikan Anda dari memiliki semua layanan Anda berbagi database yang sama.

Selama layanan Anda berperilaku dan tidak melakukan hal-hal yang tidak terduga pada data yang dimiliki oleh layanan lain, Anda akan baik-baik saja.

Saya tidak tahu apa yang Anda baca, tetapi Anda harus sadar bahwa ada banyak pendapat berbeda tentang arsitektur layanan mikro. Inilah posting blog yang bagus tentang topik ini.

Saya telah melihat orang-orang merujuk pada ide ini sebagian, secara sepele, sebagai "setiap layanan mikro harus memiliki dan mengendalikan database sendiri dan tidak ada dua layanan yang boleh berbagi database." Idenya masuk akal: jangan berbagi database tunggal di seluruh layanan karena Anda akan mengalami konflik seperti bersaing pola baca / tulis, konflik model-data, tantangan koordinasi, dll.

Tetapi satu database tidak memberi kita banyak keamanan dan kemudahan: transaksi ACID, satu tempat untuk dilihat, dipahami dengan baik (agak?), Satu tempat untuk dikelola, dll.

Perjalanan ke layanan-mikro hanya itu: sebuah perjalanan . Ini akan berbeda untuk setiap perusahaan. Tidak ada aturan yang keras dan cepat, hanya pengorbanan.

Bagian Tersulit Tentang Layanan Mikro: Data Anda

Dan Dan Wilson menjawab, Anda tidak benar-benar membutuhkannya. Layanan mikro adalah hal panas yang baru, dan seperti semua hal panas yang baru, orang menggunakannya di banyak tempat bahkan ketika mereka tidak memberikan banyak nilai.

Layanan microser memungkinkan Anda untuk menggunakan dan skala hal secara mandiri di tingkat "mikro". Granularity itu memberikan banyak manfaat teknis dan bahkan lebih banyak manfaat non-teknis karena memungkinkan Anda untuk memisahkan tim pengembangan, melepaskan sesuai kebutuhan daripada satu rilis besar, mencoba teknologi atau proses baru secara terpisah, dll. Memiliki DB yang terbunuh membunuh banyak karena ketergantungan pada DB. Jika Anda tidak dapat menggunakan layanan Anda tanpa khawatir tentang data layanan lain, Anda telah kehilangan.

Hal yang memisahkan database tidak dapat dibicarakan. Atau saya salah?

Yang mengatakan, Anda juga salah.

Ketika Anda bekerja di cloud, basis data itu murah. Gratis biasanya! Tentu, server membutuhkan uang, tetapi kita tidak berbicara tentang satu server per microservice (setidaknya, tidak pada awalnya). Sebuah server tunggal dengan sekelompok database (logis) baik-baik saja selama Anda rajin menghindari pertanyaan lintas-basis data (yang memperkenalkan dependensi yang membahayakan "dapat digunakan secara mandiri dan dapat diskalakan"). Hell, cross DB queries tidak mungkin di beberapa layanan basis data cloud seperti Azure SQL. Anda bahkan tidak perlu rajin ke sana ...

Dan saya bahkan melihat layanan microser di mana mereka berbagi database, tetapi setiap layanan memiliki skema sendiri. Sekali lagi, Anda harus rajin menghindari pertanyaan yang melewati batas data.

Banyak tempat yang tidak rajin. Mereka memiliki dev tingkat pemula, atau orang yang tidak menghargai pendekatan layanan-mikro, atau memiliki tim yang buruk, atau memiliki tekanan waktu yang menyebabkan orang mengambil jalan pintas.

Memiliki database terpisah adalah cara terbersih untuk menegakkan decoupling yang memungkinkan independensi layanan, tetapi itu bukan satu-satunya cara. Dan itu bukan yang mahal - terutama bila Anda membandingkannya dengan waktu / gaji menghabiskan mencoba untuk menegakkan batas-batas data dalam database bersama.

Mengapa kita membutuhkannya?

Manfaat besar dari layanan-mikro - dan lebih besar lagi, SOA - adalah tingkat abstraksi internal yang tinggi - tidak hanya implementasinya, tetapi juga teknologi yang digunakan. Misalnya, jika suatu sistem dikembangkan dalam bentuk lima layanan-mikro oleh lima tim, satu tim dapat memutuskan untuk pindah ke tumpukan teknologi yang sama sekali berbeda (misalnya dari tumpukan Microsoft ke LAMP) tanpa meminta pendapat tim lain.

Lihatlah Amazon AWS atau Twilio. Apakah Anda tahu jika layanan mereka diterapkan di Jawa atau Ruby? Apakah mereka menggunakan Oracle atau PostgreSQL atau Cassandra atau MongoDB? Berapa banyak mesin yang mereka gunakan? Apakah Anda peduli tentang hal itu; dengan kata lain, apakah pilihan teknologi itu mempengaruhi cara Anda menggunakan layanan itu? ... Dan yang lebih penting, jika mereka pindah ke database yang berbeda, apakah Anda harus mengubah aplikasi klien Anda sesuai?

Sekarang, apa yang terjadi jika dua layanan menggunakan database yang sama? Berikut adalah sebagian kecil dari masalah yang mungkin timbul:

• Tim yang mengembangkan layanan 1 ingin pindah dari SQL Server 2012 ke SQL Server 2016. Namun, tim 2 bergantung pada fitur usang yang telah dihapus di SQL Server 2016.

• Layanan 1 adalah kesuksesan besar. Hosting database pada dua mesin (master dan failover) bukan pilihan lagi. Tetapi penskalaan cluster ke beberapa mesin membutuhkan strategi seperti sharding. Sementara itu, tim 2 senang dengan skala saat ini, dan tidak melihat alasan untuk pindah ke hal lain.

• Layanan 1 harus pindah ke UTF-8 sebagai penyandian standarnya. Namun, Layanan 2 senang menggunakan Kode Halaman 1252 Windows Latin 1.

• Layanan 1 memutuskan untuk menambahkan pengguna dengan nama tertentu. Namun, pengguna ini sudah ada, dibuat beberapa bulan yang lalu oleh tim kedua.

• Layanan 1 membutuhkan banyak fitur berbeda. Layanan 2 adalah komponen yang sangat penting dan perlu menjaga fitur database seminimal mungkin untuk mengurangi risiko serangan.

• Layanan 1 membutuhkan ruang penyimpanan 15 TB; kecepatannya tidak penting, jadi hard disk biasa baik-baik saja. Layanan 2 membutuhkan paling banyak 50 GB, tetapi harus mengaksesnya secepat mungkin, artinya data harus disimpan pada SSD.

• ...

Setiap pilihan kecil memengaruhi semua orang. Setiap keputusan harus diambil secara kolaboratif, oleh orang-orang dari setiap tim. Kompromi harus dibuat. Bandingkan dengan kebebasan penuh untuk melakukan apa pun yang Anda inginkan dalam konteks SOA.

itu terlalu [...] tidak bisa diatur.

Maka Anda salah melakukannya. Saya kira Anda menggunakan secara manual .

Ini bukan bagaimana hal-hal harus dilakukan. Anda perlu mengotomatiskan penyebaran mesin virtual (atau wadah Docker) yang menjalankan database. Setelah Anda mengotomatiskannya, menggunakan dua server atau dua puluh server atau dua ribu server tidak jauh berbeda.

Hal ajaib tentang basis data terisolasi adalah sangat mudah dikelola . Sudahkah Anda mencoba mengelola basis data besar yang digunakan oleh puluhan tim? Ini mimpi buruk. Setiap tim memiliki permintaan spesifik, dan segera setelah Anda menyentuh sesuatu, itu memengaruhi seseorang. Dengan database yang dipasangkan dengan suatu aplikasi, cakupannya menjadi sangat sempit, artinya ada lebih sedikit hal untuk dipikirkan.

Jika database besar membutuhkan administrator sistem khusus, database yang hanya digunakan oleh satu tim pada dasarnya dapat dikelola oleh tim ini (DevOps juga tentang itu), membebaskan waktu administrator sistem.

itu terlalu mahal

Tentukan biaya.

Biaya lisensi tergantung pada database. Di era cloud computing, saya yakin semua pemain besar mendesain ulang lisensi mereka untuk mengakomodasi konteks di mana alih-alih satu database besar, ada banyak yang kecil. Jika tidak, Anda dapat mempertimbangkan untuk pindah ke database yang berbeda. Omong-omong, ada banyak sumber terbuka.

Jika Anda berbicara tentang kekuatan pemrosesan, mesin dan wadah virtual ramah-CPU, dan saya tidak akan terlalu setuju bahwa satu basis data besar akan mengkonsumsi lebih sedikit CPU daripada banyak yang kecil melakukan pekerjaan yang sama.

Jika masalah Anda adalah memori, maka mesin virtual bukanlah pilihan yang baik untuk Anda. Wadah adalah. Anda dapat merentang sebanyak yang Anda inginkan, mengetahui bahwa mereka tidak akan mengkonsumsi lebih banyak RAM daripada yang dibutuhkan. Sementara total konsumsi memori akan lebih tinggi untuk banyak database kecil dibandingkan dengan yang besar, saya kira perbedaannya tidak terlalu penting. YMMV.

Bergantung pada apa yang Anda anggap "mahal".

Basis data tidak harus harus berupa server basis data komersial yang mahal (pikirkan Oracle) tidak harus berupa urusan yang membutuhkan sumber daya. Tergantung pada apa kebutuhan Anda, Anda dapat menggunakan database SQLite atau bahkan sistem file sebagai penyimpanan data yang persisten.

Semua layanan tersebut juga dapat berbagi instance database / server tunggal dan hanya memiliki skema terisolasi per layanan.

Argumen utama di sini adalah bahwa layanan perlu memiliki dan mengendalikan datanya. Bagaimana cara mencapai itu, adalah soal pilihan dan detail teknis.

Cara terbaik layanan dapat memiliki dan mengendalikan datanya adalah dengan memiliki basis data "pribadi" sendiri. Hal ini memungkinkan untuk kebebasan penuh pilihan teknologi dan evolusi skema data. Satu-satunya cara layanan lain dapat mengakses data yang dimiliki oleh layanan adalah dengan meminta data dari layanan. Dengan cara ini, jika representasi data internal perlu diubah, dapat dengan mudah diubah dan tidak ada layanan lain yang akan rusak.

Jadi, untuk rekap. Tidak perlu mahal untuk memiliki basis data per layanan juga tidak perlu. Ini hanyalah sebuah keputusan yang perlu Anda buat pada titik tertentu ketika mengembangkan layanan microser. Setiap pilihan memiliki implikasi dan keterbatasannya. Pelajarilah itu dan buat pilihan sendiri.