Manajemen Data Terdesentralisasi - merangkum basis data ke dalam layanan-layanan mikro [ditutup]

Saya baru-baru ini mengambil kursus tentang desain Perangkat Lunak dan ada diskusi / rekomendasi baru-baru ini tentang penggunaan model 'layanan-mikro' di mana komponen-komponen layanan dipisahkan menjadi sub-komponen layanan-mikro yang se-mandiri mungkin.

Salah satu bagian yang disebutkan adalah alih-alih mengikuti model yang sangat sering terlihat yaitu memiliki database tunggal yang diajak bicara oleh semua layanan microser, Anda akan memiliki database terpisah yang berjalan untuk masing-masing layanan microser.

Penjelasan yang lebih baik dan lebih terperinci dari kata ini dapat ditemukan di sini: http://martinfowler.com/articles/microservices.html di bawah bagian Manajemen Data Terdesentralisasi

bagian paling menonjol mengatakan ini:

Layanan Microsoft lebih suka membiarkan setiap layanan mengelola basis datanya sendiri, baik contoh berbeda dari teknologi basis data yang sama, atau sistem basis data yang sama sekali berbeda - suatu pendekatan yang disebut Polyglot Persistence. Anda dapat menggunakan kegigihan polyglot dalam sebuah monolith, tetapi lebih sering muncul dengan layanan microser.

Gambar 4

Saya suka konsep ini dan, di antara banyak hal lain, melihat itu sebagai peningkatan yang kuat pada pemeliharaan dan memiliki proyek dengan banyak orang yang mengerjakannya. Yang mengatakan, saya tidak berarti seorang arsitek perangkat lunak pengalaman. Adakah yang pernah mencoba mengimplementasikannya? Apa manfaat dan rintangan yang Anda hadapi?

Mari kita bicara positif dan negatif dari pendekatan layanan-mikro.

Negatif pertama. Saat Anda membuat layanan microser, Anda menambahkan kompleksitas yang melekat pada kode Anda. Anda menambahkan overhead. Anda membuatnya lebih sulit untuk meniru lingkungan (mis. Untuk pengembang). Anda membuat masalah debugging intermiten lebih sulit.

Biarkan saya menggambarkan kerugian nyata. Pertimbangkan secara hipotesis kasus di mana Anda memiliki 100 layanan mikro yang dipanggil saat membuat halaman, yang masing-masing melakukan hal yang benar 99,9% dari waktu. Tetapi 0,05% dari waktu mereka menghasilkan hasil yang salah. Dan 0,05% dari waktu ada permintaan koneksi yang lambat di mana, katakanlah, batas waktu TCP / IP diperlukan untuk terhubung dan itu membutuhkan waktu 5 detik. Sekitar 90,5% dari waktu permintaan Anda berfungsi dengan baik. Tetapi sekitar 5% dari waktu Anda memiliki hasil yang salah dan sekitar 5% dari waktu halaman Anda lambat. Dan setiap kegagalan yang tidak dapat direproduksi memiliki penyebab yang berbeda.

Kecuali Anda menaruh banyak pemikiran di sekitar alat untuk memantau, mereproduksi, dan sebagainya, ini akan berubah menjadi berantakan. Terutama ketika satu microservice memanggil yang lain yang memanggil beberapa lapisan dalam. Dan begitu Anda memiliki masalah, itu hanya akan menjadi lebih buruk dari waktu ke waktu.

OK, ini kedengarannya seperti mimpi buruk (dan lebih dari satu perusahaan telah menciptakan masalah besar bagi diri mereka sendiri dengan menempuh jalan ini). Keberhasilan hanya mungkin Anda jelas menyadari potensi penurunan dan secara konsisten berupaya mengatasinya.

Jadi bagaimana dengan pendekatan monolitik itu?

Ternyata aplikasi monolitik mudah termodulasi sebagai layanan-mikro. Dan panggilan fungsi lebih murah dan lebih dapat diandalkan dalam praktiknya daripada panggilan RPC. Jadi Anda dapat mengembangkan hal yang sama kecuali itu lebih dapat diandalkan, berjalan lebih cepat, dan melibatkan lebih sedikit kode.

OK, lalu mengapa perusahaan pergi ke pendekatan layanan mikro?

Jawabannya adalah karena ketika Anda mengukur, ada batasan untuk apa yang dapat Anda lakukan dengan aplikasi monolitik. Setelah begitu banyak pengguna, begitu banyak permintaan, dan seterusnya, Anda mencapai titik di mana basis data tidak skala, webservers tidak dapat menyimpan kode Anda dalam memori, dan sebagainya. Lebih lanjut, pendekatan layanan mikro memungkinkan peningkatan aplikasi Anda secara independen dan bertahap. Karenanya arsitektur microservice adalah solusi untuk meningkatkan skala aplikasi Anda.

Aturan pribadi saya adalah bahwa beralih dari kode dalam bahasa scripting (misalnya Python) ke C ++ yang dioptimalkan umumnya dapat meningkatkan 1-2 urutan besarnya pada kinerja dan penggunaan memori. Pergi ke arah lain ke arsitektur terdistribusi menambah besarnya persyaratan sumber daya tetapi memungkinkan Anda skala tanpa batas. Anda dapat membuat karya arsitektur terdistribusi, tetapi melakukannya lebih sulit.

Karena itu saya akan mengatakan bahwa jika Anda memulai proyek pribadi, pergilah monolitik. Pelajari cara melakukannya dengan baik. Jangan didistribusikan karena (Google | eBay | Amazon | dll) adalah. Jika Anda mendarat di perusahaan besar yang didistribusikan, perhatikan baik-baik cara kerjanya dan jangan mengacaukannya. Dan jika Anda akhirnya harus melakukan transisi, berhati-hatilah karena Anda melakukan sesuatu yang sulit yang mudah didapat sangat, sangat salah.

Pengungkapan, saya memiliki hampir 20 tahun pengalaman di perusahaan dari semua ukuran. Dan ya, saya telah melihat arsitektur monolitik dan didistribusikan dari dekat dan pribadi. Hal ini didasarkan pada pengalaman yang saya katakan kepada Anda bahwa arsitektur microservice terdistribusi benar-benar sesuatu yang Anda lakukan karena Anda perlu, dan bukan karena itu entah bagaimana lebih bersih dan lebih baik.

Saya sepenuh hati setuju dengan jawaban btilly, tetapi hanya ingin menambahkan positif lain untuk layanan Microsoft, yang saya pikir adalah inspirasi asli di baliknya.

Dalam dunia Microservices, layanan diselaraskan dengan domain, dan dikelola oleh tim terpisah (satu tim dapat mengelola beberapa layanan). Ini berarti bahwa setiap tim dapat merilis layanan sepenuhnya secara terpisah dan independen dari layanan lain (dengan asumsi versi yang benar, dll).

Sementara itu mungkin tampak seperti manfaat sepele, pertimbangkan sebaliknya di dunia Monolitik. Di sini, di mana salah satu bagian dari aplikasi perlu sering diperbarui, itu akan berdampak pada seluruh proyek, dan tim lain yang mengerjakannya. Anda kemudian perlu memperkenalkan penjadwalan, ulasan dll, dan seluruh proses melambat.

Jadi untuk pilihan Anda, serta mempertimbangkan persyaratan penskalaan Anda, pertimbangkan juga struktur tim yang diperlukan. Saya akan setuju dengan rekomendasi btilly bahwa Anda memulai Monolitik dan kemudian mengidentifikasi di mana Microservices mungkin menjadi bermanfaat, tetapi perlu diketahui bahwa skalabilitas bukan satu-satunya manfaat.

Saya bekerja di tempat yang memiliki cukup banyak sumber data independen. Mereka memang memasukkan semuanya ke dalam satu basis data, tetapi ke skema berbeda yang diakses oleh layanan web. Idenya adalah bahwa setiap layanan hanya dapat mengakses jumlah data minimum yang mereka perlukan untuk melakukan pekerjaan mereka.

Itu tidak banyak overhead dibandingkan dengan database monolitik, tapi saya kira ini sebagian besar karena sifat data yang sudah ada dalam kelompok terisolasi.

Layanan web dipanggil dari kode server web yang menghasilkan halaman, jadi ini sangat mirip dengan arsitektur layanan mikro Anda, meskipun mungkin tidak mikro seperti kata yang disarankan dan tidak didistribusikan, meskipun mungkin saja (perhatikan bahwa satu WS memanggil untuk mendapatkan data dari layanan pihak ke-3, jadi ada 1 layanan data terdistribusi di sana). Perusahaan yang melakukan ini lebih tertarik pada keamanan daripada skala, namun, layanan ini dan layanan data memberikan permukaan serangan yang lebih aman sehingga cacat yang dapat dieksploitasi dalam satu orang tidak akan memberikan akses penuh ke seluruh sistem.

Roger Sessions dalam buletin Objectwatch yang sangat bagus menggambarkan sesuatu yang mirip dengan konsep Software Fortresses (sayangnya buletin tidak lagi online, tetapi Anda dapat membeli bukunya).