Layanan microser dan penyimpanan data

Saya sedang mempertimbangkan memindahkan REST API monolitik ke arsitektur layanan mikro, dan saya agak bingung tentang penyimpanan data. Seperti yang saya lihat, beberapa manfaat dari layanan microser adalah:

• Dapat diskalakan secara horizontal - Saya dapat menjalankan beberapa salinan berlebihan dari layanan microser untuk mengatasi beban dan / atau server turun.
• Digabungkan secara longgar - Saya dapat mengubah implementasi internal dari layanan microser tanpa harus mengubah yang lain, dan saya dapat secara mandiri menggunakan dan mengubahnya dll ...

Masalah saya adalah dengan penyimpanan data. Seperti yang saya lihat ada beberapa opsi:

1. Layanan Database tunggal yang dibagikan oleh semua layanan microser - ini tampaknya sepenuhnya menghilangkan manfaat dari kopling longgar.
2. Contoh basis data yang dipasang secara lokal pada setiap layanan mikro - Saya tidak dapat melihat cara penskalaan secara horizontal, jadi saya tidak berpikir itu akan menjadi pilihan.
3. Setiap microservice memiliki layanan basis datanya sendiri - ini tampaknya yang paling menjanjikan, karena mempertahankan manfaat dari kopling longgar dan penskalaan horizontal (menggunakan salinan database yang berlebihan dan / atau membagikan beberapa)

Bagi saya, opsi ketiga tampaknya menjadi satu-satunya pilihan, tetapi tampaknya sangat berat bagi saya, dan solusi yang sangat direkayasa. Jika saya memahaminya dengan benar, maka untuk aplikasi sederhana dengan 4-5 microservices saya harus menjalankan 16-20 server - dua instance microservice aktual per microservice (jika terjadi kegagalan server, dan untuk penyebaran tanpa downtime), dan dua contoh layanan database per microservice (dalam hal kegagalan server dll ...).

Sejujurnya, ini agak konyol. 16-20 server untuk menjalankan API sederhana, mengingat bahwa proyek realistis mungkin akan memiliki lebih dari 4-5 layanan? Apakah ada konsep mendasar yang saya lewatkan yang akan menjelaskan ini?

Beberapa hal yang mungkin membantu saat menjawab:

• Saya adalah satu-satunya pengembang di proyek ini, dan akan berada di masa mendatang.
• Saya menggunakan Node.js dan MongoDB, tetapi saya akan tertarik pada jawaban bahasa-agnostik - jawabannya bahkan mungkin karena saya hanya menggunakan teknologi yang salah!

Dari tiga opsi Anda, yang pertama (satu, database bersama) dan yang ketiga ("layanan database") adalah yang paling umum.

Yang pertama disebut basis data integrasi . Ini umumnya tidak dilihat sebagai solusi yang baik dalam arsitektur layanan mikro. Itu menambah kopling ke layanan Anda. Ini juga membuatnya sangat mudah untuk satu layanan untuk hanya memotong layanan lain dan permintaan ke database secara langsung. Anda bisa kehilangan integritas atau validasi data apa pun yang disediakan oleh tingkat aplikasi yang tidak ditegakkan di tingkat basis data.

Ide ketiga Anda disebut database aplikasi . Dan Anda benar - ini memungkinkan Anda untuk menerapkan kopling longgar di tingkat API antara layanan dan memungkinkan Anda untuk lebih mudah mengukur layanan di tingkat basis data. Ini juga memudahkan untuk mengganti teknologi basis data yang mendasarinya dengan sesuatu yang sesuai dengan setiap layanan, sama seperti Anda dapat mengubah teknologi atau detail implementasi lainnya dari setiap layanan. Sangat fleksibel.

Namun, saya akan mengusulkan solusi perantara.

Alih-alih berdiri layanan database untuk setiap layanan Microsoft, berdiri skema untuk setiap layanan. Jika Anda menggunakan beberapa teknologi basis data, Anda mungkin perlu membagi sedikit berbeda, tetapi idenya adalah untuk meminimalkan jumlah server basis data yang Anda jalankan, tetapi membuatnya sangat mudah untuk membagi layanan ke dalam server basis data sendiri jika dan ketika itu menjadi perlu. Selama Anda hanya mengizinkan database untuk mengakses skema sendiri, Anda memiliki kelebihan dari database aplikasi tetapi tanpa overhead server database yang ada untuk setiap aplikasi atau layanan.

Namun, sebagai pengembang solo, saya akan menantang seluruh gagasan layanan mikro pada saat ini - Martin Fowler menulis tentang Monolith First dan Premium Layanan Mikro , Simon Brown berbicara tentang monolit modular , dan pembicaraan DHH tentang Majestic Monolith. Saya tidak yakin seberapa baik monolit Anda diorganisir, tetapi refactor dan aturlah. Identifikasi komponen dan buat pemisahan yang bersih di antara mereka untuk mengekstraksi potongan ke dalam layanan dengan mudah. Hal yang sama berlaku untuk struktur basis data Anda. Fokus pada arsitektur berbasis komponen yang baik, bersih, yang dapat mendukung refactoring ke dalam layanan. Layanan Microsoft menambahkan banyak overhead untuk dibangun oleh satu pengembang dan dukungan dalam operasi. Namun, begitu Anda benar-benar memiliki kebutuhan untuk menskala bagian dari sistem, gunakan sistem pemantauan dan pelaporan Anda untuk mengidentifikasi hambatan, ekstrak ke layanan, dan skala yang diperlukan.

Setiap microservice memiliki layanan basis datanya sendiri - ini tampaknya yang paling menjanjikan, karena mempertahankan manfaat dari kopling longgar dan penskalaan horizontal (menggunakan salinan database yang berlebihan dan / atau membagikan beberapa)

Setuju. The ketiga pilihan adalah pilihan alami untuk layanan mikro. Jika layanan mikro dimaksudkan untuk benar-benar independen (dan bukan bagian dari monolit terdistribusi ), adalah normal bahwa mereka memiliki, masing-masing, sebuah database.

[...] dua instance microservice aktual per microservice (dalam hal kegagalan server, dan untuk penggelaran tanpa downtime), dan dua instance layanan basis data per microservice (jika terjadi kegagalan server, dll ...).

Anda benar tentang jumlah layanan mikro yang berjalan jika Anda ingin memiliki keseimbangan beban. Jika Anda berencana untuk memiliki 4 layanan mikro, Anda harus menyiapkan setidaknya 2 contoh dari masing-masing layanan mikro (total 8), seperti yang sudah Anda jelaskan.

Tetapi dua basis data per layanan mikro? Ini benar-benar dipertanyakan. Saya tidak tahu detail tentang masalah bisnis yang akan dihadiri layanan mikro Anda, tetapi memiliki redundansi basis data yang cukup banyak untuk sebagian besar produk / proyek. Saya akan merekomendasikan untuk memulai dengan satu basis data tunggal dengan cadangan yang baik dan meminimalkan (paling tidak pada awalnya) kompleksitas infrastruktur Anda.

Sejujurnya, ini agak konyol. 16-20 server untuk menjalankan API sederhana, mengingat bahwa proyek realistis mungkin akan memiliki lebih dari 4-5 layanan? Apakah ada konsep mendasar yang saya lewatkan yang akan menjelaskan ini?

Untuk API sederhana angka ini tidak cocok. Memperhatikan jika Anda tidak jatuh ke salah satu dari "MICROSERVICE Pertama" perangkap .

Layanan Microsoft adalah bentuk Arsitektur Berorientasi Layanan, mungkin secara ekstrim. Tujuan umum mereka adalah untuk mengurangi sambungan dan memungkinkan pengembangan & penerapan independen.

Secara kasar berbicara dalam istilah arsitektur, microservices adalah istilah yang berlaku, katakanlah, pada tingkat yang logis. Layanan-layanan mikro secara logis terpisah satu sama lain. Dari perspektif ini, setiap layanan microser harus memiliki dan menyediakan penyimpanannya sendiri, yang harus dipisahkan dari penyimpanan layanan microser lainnya. Untuk layanan microser, independensi penyimpanan ini adalah kunci untuk tujuan modularitas dan kopling longgar.

Dari perspektif arsitektur, penskalaan horizontal berlaku pada level yang lebih rendah, lebih dekat ke implementasinya, katakanlah, pada level fisik. Pada level ini, kami menerapkan layanan microser, dan kami dapat menguraikan layanan microser tunggal ini, secara internal, menjadi komponen stateless yang dapat diskalakan secara horizontal, dan komponen stateful yang dibagi oleh semua komponen stateless.  Tapi jangan bingung hanya bagian stateless saja dengan microservice itu sendiri.

Jadi, ketika kita berbicara tentang masing-masing layanan mikro, kita berada pada level logis berbicara tentang API dan tanggung jawab yang terpisah dan siklus pengembangan / penyebaran yang terpisah. Dan ketika kita berbicara tentang penskalaan horizontal, kita berada pada level fisik berbicara tentang implementasi dari sebuah layanan mikro (tunggal) dan penguraiannya menjadi komponen tanpa status dan status.

Saat menerapkan beberapa layanan mikro, kami memiliki pilihan untuk menggunakan kembali teknologi basis data untuk komponen yang sah:

• pisahkan basis data per microservice
• database bersama dengan:
  • skema terpisah / pribadi per layanan microser
  • tabel terpisah / pribadi per layanan microser

Lihat lebih lanjut di sini .

Layanan Database tunggal yang dibagikan oleh semua layanan microser - ini tampaknya sepenuhnya menghilangkan manfaat dari kopling longgar.

Setuju, jika maksud Anda berbagi tabel baris & kolom, itu tidak akan benar-benar menjadi layanan microser.

Jika kita dapat memisahkan - dalam proses pemikiran kita - gagasan logis dari layanan-mikro dari gagasan yang lebih fisik tentang komponen-komponen layanan-mikro yang tanpa status dan tanpa-status dari suatu layanan-mikro, kita mungkin menemukan lebih mudah untuk mencapai sambungan longgar yang ditawarkan oleh layanan-layanan mikro, sambil tetap mempertahankan efisiensi dari layanan bersama basis data.

Secara umum, ada cukup banyak yang ditulis tentang layanan microser dan kegigihan yang kuat, lihat juga di sini .

Yah, saya sudah membaca semua posting di utas ini dan dapat memberi tahu Anda bahwa saya bingung dengan pertanyaan: ia mencampur microservice (MS) dengan layanan dengan layanan akses data (layanan DB) dengan database dan server ...

Jika MS adalah komponen independen (yang dapat digunakan) yang menyelesaikan satu tugas paling sederhana dalam keadaan tanpa kewarganegaraan, APA yang dibutuhkan oleh basis data? Jika tugas yang lebih kompleks harus diselesaikan, yang membutuhkan lebih dari satu sub-tugas paling sederhana (MS?) Untuk diselesaikan bersama-sama, apakah masih MS? Dalam SOA, itu disebut Layanan Mengatur. Ini mengimplementasikan "proses" dan mengkoordinasikan permohonan MS, sehingga perlu untuk mempertahankan negaranya (semua orkestrasi / organisator / komposer / dll. Stateful) dan membutuhkan data pribadi: tidak ada orang lain yang dapat meredam keadaan orkestra.

Namun, kami tidak berbicara tentang database tetapi tentang Akses Database MS / Layanan, dan ini adalah masalah yang sama sekali berbeda. MS mungkin memerlukan beberapa data yang dikumpulkan di perusahaan (tidak dalam Aplikasi yang beroperasi di dalamnya) dan tidak dapat meminta MS lain melalui API / antarmuka datanya. Ini adalah skenario paling umum dan realistis. Dan MS lain dari Aplikasi yang sama atau berbeda mungkin memerlukan data ini atau bahkan mengubahnya. Ya, mereka bersaing untuk mendapatkan data seperti yang selalu terjadi sebelum MS muncul.

Mengapa kita menabrak 'pintu', yang terkenal dan terbuka? Apa perbedaan dengan hal ini antara MS dan objek self-persisten reguler? Mengapa kita memerlukan basis data individual untuk MS jika harus (untuk tujuan fleksibilitas dan kompabilitas) tetap menggunakan Layanan Akses Data (DAS)? Jangan lupa bahwa DAS melindungi MS dengan tugas bisnis dari kesadaran tentang konektivitas fisik ke database. Kopling lepas dan fleksibilitas yang harus dipertahankan MS untuk berpartisipasi secara bebas dalam beberapa Aplikasi tanpa jangkar database di atasnya.