Saya baru-baru ini membaca artikel yang bagus ini tentang arsitektur microservice: http://www.infoq.com/articles/microservices-intro

Ini menyatakan bahwa ketika Anda memuat halaman web di Amazon, maka 100+ layanan microsoft bekerja sama untuk melayani halaman tersebut.

Artikel itu menjelaskan bahwa semua komunikasi antara layanan microser hanya dapat melalui API. Pertanyaan saya adalah mengapa sangat buruk untuk mengatakan bahwa semua penulisan basis data hanya dapat melalui API, tetapi Anda bebas membaca langsung dari database berbagai layanan mikro. Sebagai contoh, seseorang dapat mengatakan bahwa hanya beberapa tampilan basis data yang dapat diakses di luar layanan mikro sehingga tim yang mempertahankan layanan mikro tersebut mengetahui bahwa selama mereka menjaga pandangan ini tetap utuh maka mereka dapat mengubah struktur basis data layanan mikro mereka sebanyak mungkin. ingin.

Apakah saya melewatkan sesuatu di sini? Apakah ada alasan lain mengapa data hanya dapat dibaca melalui API?

Tak perlu dikatakan, perusahaan saya secara signifikan lebih kecil dari Amazon (dan akan selalu ada) dan jumlah pengguna maksimum yang pernah kita miliki adalah sekitar 5 juta.

Database tidak pandai menyembunyikan informasi, yang cukup masuk akal, karena tugas mereka adalah untuk benar-benar membuka informasi. Tapi ini membuat mereka menjadi alat yang buruk ketika datang ke enkapsulasi. Mengapa Anda ingin enkapsulasi?

Skenario: Anda mengikat beberapa komponen ke RDBMS secara langsung, dan Anda melihat satu komponen tertentu menjadi leher botol kinerja yang Anda mungkin ingin mendenormalkan database, tetapi Anda tidak bisa karena semua komponen lain akan terpengaruh. Anda bahkan mungkin menyadari bahwa Anda akan lebih baik dengan toko dokumen atau database grafik daripada dengan RDBMS. Jika data dienkapsulasi oleh API kecil, Anda memiliki peluang yang realistis untuk mengimplementasikan kembali API tersebut dengan cara apa pun yang Anda butuhkan. Anda dapat memasukkan lapisan cache secara transparan dan yang tidak.

Meraba-raba dengan lapisan penyimpanan langsung dari lapisan aplikasi adalah kebalikan dari apa yang disarankan prinsip inversi ketergantungan lakukan.

Apa yang lebih penting dan signifikan tentang layanan mikro: API atau skema databasenya? API, karena itu adalah kontraknya dengan seluruh dunia. Skema basis data hanyalah cara mudah untuk menyimpan data yang dikelola oleh layanan, mudah-mudahan diatur dengan cara yang mengoptimalkan kinerja layanan mikro. Tim pengembang harus bebas mengatur kembali skema itu - atau beralih ke solusi datastore yang sama sekali berbeda - kapan saja. Seluruh dunia seharusnya tidak peduli. Seluruh dunia peduli ketika API berubah, karena API adalah kontrak.

Sekarang, jika Anda mengintip ke dalam basis data mereka

• Anda menambahkan ketergantungan yang tidak diinginkan pada skema mereka. Mereka tidak dapat mengubahnya tanpa berdampak pada layanan Anda.
• Anda menambahkan beban yang tidak diinginkan dan tak terduga ke internal mereka.
• Kinerja layanan Anda sendiri akan dipengaruhi oleh kinerja basis data mereka (mereka akan mencoba mengoptimalkan layanan mereka agar berkinerja baik untuk klien dan database mereka berfungsi baik hanya untuk layanan mereka)
• Anda mengikat implementasi Anda ke skema yang mungkin tidak secara akurat dan khas mewakili sumber daya di penyimpanan data mereka - mungkin memiliki detail tambahan yang hanya diperlukan untuk melacak keadaan internal atau memenuhi implementasi khusus mereka (yang Anda seharusnya tidak pedulikan).
• Anda mungkin tanpa sadar menghancurkan atau merusak kondisi layanan mereka (dan mereka tidak akan tahu Anda melakukan ini)
• Anda dapat memperbarui / menghapus / menghapus sumber daya dari database mereka tanpa mereka sadari ini telah terjadi.

Dua poin terakhir mungkin tidak terjadi jika Anda hanya diberikan akses baca, tetapi poin lainnya lebih dari alasan yang cukup baik. Basis data bersama adalah hal yang buruk.

Adalah umum bagi pengembang yang kurang berpengalaman (atau mereka yang tidak belajar) untuk melihat database lebih penting daripada layanan, untuk melihat database sebagai hal yang nyata dan layanan hanyalah cara untuk mendapatkannya. Itu adalah cara yang salah.

Arsitektur Microservice sulit untuk dijelaskan tetapi cara terbaik untuk memikirkannya adalah perkawinan antara Arsitektur Berorientasi Komponen dan Arsitektur Berorientasi Layanan. Perangkat lunak sebagai rangkaian terdiri dari banyak komponen bisnis kecil dengan tanggung jawab domain bisnis yang sangat spesifik. Antarmuka mereka ke dunia luar baik dalam layanan yang disediakan atau layanan yang diperlukan adalah melalui API layanan yang jelas.

Menulis dan bahkan membaca dari database yang berada di luar domain bisnis komponen Anda bertentangan dengan gaya arsitektur ini.

Alasan utama untuk ini adalah bahwa API yang disediakan melalui layanan oleh komponen perangkat lunak lain memiliki ekspektasi yang masuk akal bahwa API kemungkinan besar akan kompatibel ke belakang ketika rilis baru dari komponen penyedia layanan menjadi tersedia. Jika saya adalah pengembang komponen "menyediakan" maka saya hanya perlu khawatir tentang kompatibilitas mundur ke API saya. Jika saya tahu bahwa ada tiga tim pengembangan lain yang menulis permintaan khusus terhadap database saya secara langsung, maka pekerjaan saya menjadi jauh lebih rumit.

Lebih buruk lagi, mungkin tim lain yang menulis ini adalah sprint tengah dalam proyek kritis dan mereka tidak dapat menerima perubahan ini sekarang dari komponen Anda. Sekarang pengembangan perangkat lunak untuk komponen Anda di domain bisnis yang Anda miliki sedang didorong oleh pengembangan di domain bisnis lain.

Interaksi penuh melalui layanan mengurangi sambungan antara berbagai komponen perangkat lunak sehingga situasi seperti ini tidak sering terjadi. Ketika datang ke komponen lain menggunakan tampilan dalam database, maka Anda memiliki lebih banyak kemampuan untuk membuat tampilan mundur kompatibel jika ada orang lain yang menulis pertanyaan menentangnya. Namun saya masih merasa bahwa ini harus menjadi perkecualian dan hanya boleh dilakukan untuk pelaporan atau pemrosesan batch di mana aplikasi perlu membaca dalam jumlah data yang sangat besar.

Jelas ini bekerja dengan baik di tim besar yang didistribusikan di mana tim pengembangan dipisahkan oleh domain bisnis seperti Amazon. Jika Anda adalah toko pengembangan kecil, Anda masih dapat memanfaatkan model ini, terutama jika Anda perlu meningkatkan proyek besar dengan cepat, tetapi juga jika Anda harus berurusan dengan perangkat lunak vendor.

Selama 20 tahun terakhir saya telah melihat beberapa desain database modular besar dan saya telah melihat skenario yang disarankan oleh David beberapa kali sekarang di mana aplikasi memiliki akses tulis ke skema mereka sendiri / set tabel dan membaca akses ke skema lain / mengatur tabel. Paling sering data ini yang aplikasi / modul mendapat akses read-only dapat digambarkan sebagai "data master" .

Pada waktu itu saya belum melihat masalah yang disarankan oleh jawaban sebelumnya, saya seharusnya sudah melihat, jadi saya pikir ada baiknya melihat lebih dekat pada poin yang diajukan dalam jawaban sebelumnya secara lebih rinci.

Skenario: Anda mengikat beberapa komponen ke RDBMS secara langsung, dan Anda melihat satu komponen tertentu menjadi leher botol kinerja

Saya setuju dengan komentar ini kecuali ini juga merupakan argumen untuk memiliki salinan data secara lokal untuk dibaca oleh microservice. Yaitu, sebagian besar basis data dewasa mendukung replikasi dan karenanya tanpa upaya pengembang apa pun "data master" dapat secara fisik direplikasi ke basis data layanan mikro jika diinginkan atau diperlukan.

Beberapa mungkin mengenali ini dalam kedok yang lebih lama sebagai "Basis data perusahaan" yang mereplikasi tabel inti menjadi "Basis data departemen". Suatu titik di sini adalah bahwa secara umum adalah baik jika suatu database melakukan ini untuk kita dengan replikasi data yang telah diubah (hanya delta, dalam bentuk biner dan dengan biaya minimal ke basis data sumber).

Sebaliknya, ketika pilihan basis data kami tidak memungkinkan ini dukungan replikasi 'dari rak' maka kita bisa masuk ke situasi di mana kami ingin mendorong "data master" ke database layanan mikro dan ini dapat menghasilkan sejumlah besar upaya pengembang dan juga menjadi mekanisme yang secara substansial kurang efisien.

mungkin ingin mendenormalkan basis data, tetapi Anda tidak bisa karena semua komponen lain akan terpengaruh

Bagi saya pernyataan ini tidak benar. Denormalisasi adalah perubahan "aditif" dan bukan "perubahan putus" dan tidak ada aplikasi yang harus rusak karena denormalisasi.

Satu-satunya cara memecah aplikasi ini adalah ketika kode aplikasi menggunakan sesuatu seperti "pilih * ..." dan tidak menangani kolom tambahan. Bagi saya itu akan menjadi bug dalam aplikasi?

Bagaimana denormalisasi dapat merusak aplikasi? Kedengarannya seperti FUD bagi saya.

Ketergantungan skema:

Ya, aplikasi sekarang memiliki ketergantungan pada skema database dan implikasinya adalah ini seharusnya menjadi masalah besar. Sambil menambahkan ketergantungan ekstra jelas tidak ideal pengalaman saya adalah bahwa ketergantungan pada skema basis data belum menjadi masalah, jadi mengapa demikian? Apakah saya baru saja beruntung?

Data master

Skema yang biasanya kita inginkan agar layanan mikro memiliki akses hanya baca adalah yang paling umum saya gambarkan sebagai " data master " untuk perusahaan. Ini memiliki data inti yang penting bagi perusahaan.

Secara historis ini berarti skema yang kami tambahkan ketergantungan sudah matang dan stabil (agak mendasar bagi perusahaan dan tidak berubah).

Normalisasi

Jika 3 desainer database pergi dan merancang skema db yang dinormalisasi mereka akan berakhir pada desain yang sama. Ok, mungkin ada beberapa variasi 4NF / 5NF tetapi tidak banyak. Terlebih lagi ada serangkaian pertanyaan yang dapat ditanyakan perancang untuk memvalidasi model sehingga perancang dapat yakin bahwa mereka sampai pada 4NF (Apakah saya terlalu optimis? Apakah orang-orang berjuang mendapatkan 4NF?).

update: Dengan 4NF di sini saya maksudkan semua tabel dalam skema mencapai bentuk normal tertinggi hingga 4NF (semua tabel mendapat normalisasi hingga 4NF).

Saya percaya proses desain normalisasi adalah mengapa perancang basis data umumnya merasa nyaman dengan ide untuk bergantung pada skema database yang dinormalisasi.

Proses normalisasi membuat desain DB menjadi desain yang "benar" dan variasi dari sana harus dinormalisasi untuk kinerja.

1. Mungkin ada variasi berdasarkan pada tipe DB yang didukung (JSON, ARRAY, Geo type support, dll)
2. Beberapa mungkin berpendapat variasi berdasarkan pada 4NF / 5NF
3. Kami mengecualikan variasi fisik (karena itu tidak masalah)
4. Kami membatasi ini untuk desain OLTP dan bukan desain DW karena itu adalah skema yang ingin kami berikan akses hanya baca

Jika 3 programmer di mana diberikan desain untuk mengimplementasikan (sebagai kode) harapan akan untuk 3 implementasi yang berbeda (berpotensi sangat berbeda).

Bagi saya ada potensi pertanyaan "iman dalam normalisasi".

Memecah perubahan skema?

Denormalisasi, menambahkan kolom, mengubah kolom untuk penyimpanan yang lebih besar, memperluas desain dengan tabel baru, dll. Semua adalah perubahan yang tidak melanggar dan desainer DB yang mencapai bentuk normal ke-4 akan yakin akan hal itu.

Melanggar perubahan jelas dimungkinkan dengan menjatuhkan kolom / tabel atau membuat perubahan jenis pemecahan. Mungkin ya, tetapi secara praktis saya tidak mengalami masalah sama sekali di sini. Mungkin karena dipahami apa yang melanggar perubahan dan ini telah dikelola dengan baik?

Saya akan tertarik untuk mendengar kasus-kasus melanggar perubahan skema dalam konteks skema read-only shared.

Apa yang lebih penting dan signifikan tentang layanan mikro: API atau skema databasenya? API, karena itu adalah kontraknya dengan seluruh dunia.

Meskipun saya setuju dengan pernyataan ini, saya pikir ada peringatan penting yang mungkin kita dengar dari Arsitek Perusahaan yaitu "Data hidup selamanya" . Artinya, sementara API mungkin menjadi hal yang paling penting, data juga agak penting bagi perusahaan secara keseluruhan dan itu akan menjadi penting untuk waktu yang sangat lama.

Misalnya, begitu ada persyaratan untuk mengisi Data Warehouse for Business intelligence , skema dan dukungan CDC menjadi penting dari perspektif pelaporan bisnis terlepas dari API.

Masalah dengan API?

Sekarang jika API sempurna dan mudah semua poin diperdebatkan karena kami selalu memilih API daripada memiliki akses hanya baca lokal. Jadi motivasi untuk mempertimbangkan akses baca-saja lokal adalah bahwa mungkin ada beberapa masalah dalam menggunakan API yang dihindari akses lokal.

What motivates people to desire local read-only access?

Optimalisasi API:

LinkedIn memiliki presentasi yang menarik (dari 2009) tentang masalah mengoptimalkan API mereka dan mengapa penting bagi mereka pada skala mereka. http://www.slideshare.net/linkedin/building-consistent-restful-apis-in-a-highperformance-environment

Singkatnya, sekali API harus mendukung banyak kasus penggunaan yang berbeda, ia dapat dengan mudah masuk ke situasi di mana ia mendukung satu kasus penggunaan secara optimal dan sisanya agak buruk dari perspektif jaringan dan perspektif basis data.

Jika API tidak memiliki kecanggihan yang sama dengan LinkedIn maka Anda dapat dengan mudah mendapatkan skenario di mana:

• API mengambil lebih banyak data daripada yang Anda butuhkan (boros)
• Chatty API di mana Anda harus memanggil API berkali-kali

Ya, kami dapat menambahkan caching ke API tentu saja tetapi pada akhirnya panggilan API adalah panggilan jarak jauh dan ada serangkaian optimisasi yang tersedia bagi pengembang ketika data bersifat lokal.

Saya menduga ada sekelompok orang di luar sana yang mungkin menambahkannya sebagai:

• Replikasi data master yang murah ke basis data layanan mikro (tanpa biaya pengembangan dan efisien secara teknis)
• Iman dalam Normalisasi dan ketahanan aplikasi untuk perubahan skema
• Kemampuan untuk dengan mudah mengoptimalkan setiap kasus penggunaan dan berpotensi menghindari panggilan API jarak jauh yang tidak berguna / boros / tidak efisien
• Ditambah beberapa manfaat lain dalam hal kendala dan desain yang koheren

Jawaban ini terlalu panjang. Permintaan maaf!!

Manajemen negara (berpotensi basis data) dapat digunakan dalam wadah Microservice dan diekspos melalui API. Basis data Microservice tidak terlihat oleh sistem lain di luar wadah - hanya API. Atau Anda dapat memiliki layanan lain (misalnya cache) mengelola negara melalui API. Memiliki semua dependensi Microservice (selain panggilan API ke layanan lain) dalam satu wadah yang dapat digunakan adalah perbedaan utama dalam arsitektur. Jika seseorang tidak mendapatkannya kembali dan pelajari arsitekturnya.