Layanan microser dan prosedur tersimpan

Apakah prosedur tersimpan dianggap praktik buruk dalam arsitektur layanan mikro?

Inilah pikiran saya:

• kebanyakan buku tentang layanan microser merekomendasikan satu database per layanan microser. Prosedur tersimpan biasanya bekerja pada basis data monolitik.

• lagi sebagian besar buku arsitektur microservice menyatakan bahwa mereka harus otonom dan longgar digabungkan. Menggunakan prosedur tersimpan yang ditulis, katakanlah secara khusus di Oracle, pasangkan dengan erat layanan mikro dengan teknologi itu.

• sebagian besar buku arsitektur microservice (yang telah saya baca) merekomendasikan bahwa layanan microser harus berorientasi bisnis (dirancang menggunakan desain berbasis domain (DDD)). Dengan memindahkan logika bisnis ke dalam prosedur tersimpan dalam basis data, ini tidak lagi menjadi masalah.

Ada pemikiran tentang ini?

Tidak ada yang secara eksplisit melarang atau berdebat menentang penggunaan prosedur tersimpan dengan layanan microser.

Penafian: Saya tidak suka prosedur tersimpan dari POV pengembang, tapi itu tidak terkait dengan layanan microser dengan cara apa pun.

Prosedur tersimpan biasanya bekerja pada basis data monolith.

Saya pikir Anda menyerah pada kesalahan logis.

Prosedur yang tersimpan saat ini sedang menurun. Sebagian besar prosedur tersimpan yang masih digunakan berasal dari basis kode lama yang telah disimpan. Saat itu, database monolitik juga jauh lebih lazim dibandingkan ketika layanan microser menjadi populer.

Procs tersimpan dan basis data monolitik keduanya terjadi dalam basis kode lama, itulah sebabnya Anda lebih sering melihatnya bersama. Tapi itu bukan hubungan sebab akibat. Anda tidak menggunakan procs yang disimpan karena Anda memiliki database monololitik. Anda tidak memiliki database monolitik karena Anda menggunakan procs yang disimpan.

kebanyakan buku tentang layanan microser merekomendasikan satu database per layanan microser.

Tidak ada alasan teknis mengapa database yang lebih kecil ini tidak dapat memiliki prosedur tersimpan.

Seperti yang saya sebutkan, saya tidak suka procs yang disimpan. Saya menemukan mereka rumit dan tahan terhadap pemeliharaan di masa depan. Saya berpikir bahwa menyebarkan sprocs ke banyak basis data kecil semakin memperburuk masalah yang sudah tidak saya sukai. Tetapi itu tidak berarti itu tidak dapat dilakukan.

lagi sebagian besar buku arsitektur microservice menyatakan bahwa mereka harus otonom dan longgar digabungkan. Menggunakan prosedur tersimpan yang ditulis khusus di Oracle, memasangkan dengan erat microservice ke teknologi itu.

Di sisi lain, argumen yang sama dapat dibuat untuk ORM apa pun yang digunakan layanan mikro Anda. Tidak setiap ORM akan mendukung setiap basis data. Kopling (khususnya keketatannya) adalah konsep relatif. Ini masalah menjadi longgar seperti yang Anda bisa masuk akal.

Sprocs memang menderita kopling ketat secara umum terlepas dari layanan microser. Saya akan menyarankan terhadap sprocs secara umum, tetapi tidak terutama karena Anda menggunakan microservices. Ini argumen yang sama seperti sebelumnya: Saya tidak berpikir sprocs adalah cara untuk pergi (secara umum), tapi itu mungkin saja bias saya, dan itu tidak terkait dengan layanan microser.

kebanyakan buku msa (yang telah saya baca) merekomendasikan bahwa layanan microser harus berorientasi bisnis (dirancang menggunakan ddd). Dengan memindahkan logika bisnis ke dalam prosedur tersimpan dalam basis data, ini tidak lagi menjadi masalah.

Ini selalu menjadi keluhan utama saya tentang sprocs: logika bisnis dalam database. Bahkan ketika bukan niat, itu cenderung entah bagaimana selalu berakhir seperti itu.

Tetapi sekali lagi, keluhan itu ada terlepas dari apakah Anda menggunakan layanan microser atau tidak. Satu-satunya alasan sepertinya masalah yang lebih besar adalah karena layanan microser mendorong Anda untuk memodernisasi seluruh arsitektur Anda, dan sprocs tidak disukai lagi dalam arsitektur modern.

Untuk menulis perangkat lunak, Anda harus berpasangan dengan teknologi.

Paling tidak ke lingkungan runtime yang disediakan oleh bahasa pemrograman yang sedang dikembangkan di dalamnya.

Lebih umum lagi meskipun Anda akan menemukan bahwa layanan mikro Anda secara erat digabungkan ke beberapa teknologi:

• Kerangka Layanan Jaringan untuk menyediakan implementasi protokol HTTP / SSL / SOAP tingkat tinggi
• Kerangka Kerja Repositori / ORM / DAO untuk memberikan kegigihan.
• Kerangka Manipulasi Data untuk menyediakan alat untuk bekerja dengan data.
• Process / Threading / OS Framework untuk menyediakan akses ke sumber daya OS seperti multi-tasking, sistem file, memori, komputasi GPU, kartu ekspansi, dll ...

Dan itu adalah membuat layanan mikro tanpa tulang.

Prosedur tersimpan

Prosedur tersimpan hanyalah teknologi lain yang bisa Anda pilih untuk digunakan atau tidak. Itu tidak secara ajaib membuat kode Anda monolitik, atau mikro.

Apa itu adalah:

• Teknologi lain. Setiap teknologi yang ada dalam aplikasi mengurangi kemungkinan yang dapat dibaca, dipahami, dan dibuat pilihan desain yang bijak untuk campuran teknologi tersebut.
• Bahasa yang menggunakan paradigma pemrograman yang berbeda. Terlalu mudah bagi non-pakar untuk mencoba dan memaksakan perspektif imperatif, fungsional, OO, dll ... mereka, yang sering mengarah pada hasil yang kurang memuaskan.
• API. Yang harus dipertahankan seperti kelas lain di basis kode. Ini juga berarti bahwa database menyediakan antarmuka non-generik. Ini membuat keduanya lebih sulit untuk mengganti mesin basis data itu sendiri, dan untuk menerapkan perilaku generik secara transparan seperti dalam cache memori.
• Artefak. Yang harus diversi, diuji, dan digunakan. Ini bisa dilakukan, tetapi database adalah artefak hidup yang membutuhkan pendekatan yang berbeda. Anda biasanya tidak bisa hanya menghapus yang asli, dan menggantinya. Seringkali orkestrasi perubahan yang hati-hati diperlukan untuk memigrasi sistem ke kondisi yang diinginkan.

Masing-masing adalah biaya nyata. Dalam beberapa kasus biayanya dapat dibenarkan, dalam kasus lain tidak.

Anda akan membayar hampir serangkaian biaya yang sama dengan hosting mesin scripting. Pengurangan satu-satunya adalah Anda dapat memilih paradigma pemrograman yang sama dengan bahasa host.

Logika bisnis

Memindahkan aturan bisnis ke dalam basis data adalah praktik yang buruk. Hanya saja bukan karena prosedur yang tersimpan.

Ini praktik yang buruk, karena basis data dan logika bisnis beroperasi pada level geser yang berbeda.

• Database dalam aplikasi yang matang dapat digunakan selama beberapa dekade. Umumnya sistem ini akan memiliki mesin diperbarui secara berkala, tetapi database itu sendiri dimigrasi. Itu tidak terbunuh dan dibangun kembali dari awal. Tidak ada alasan layanan mikro tidak bisa berumur panjang.

• Kontras dekade terhadap seberapa cepat aturan bisnis berubah. Dalam pengalaman saya, aturan bisnis lama mungkin sudah berumur beberapa tahun, namun sebagian besar berubah dengan cepat, dan Anda tidak akan pernah tahu mana yang akan berubah selanjutnya. Persyaratan baru dari regulator, produk lama dinonaktifkan, perubahan pada kepala surat, perubahan pada berapa banyak karyawan melapor kepada bos, dll, dll, dll ...

Jika logika bisnis didistribusikan di seluruh lapisan geser, terutama ke lapisan yang lebih lambat dan berumur panjang, itu akan menghasilkan resistensi terhadap perubahan. Ini belum tentu hal yang buruk. Lagi pula, satu-satunya database yang tidak memiliki logika bisnis di dalamnya adalah triple store.

Tindakan hanya menentukan skema tabel adalah memindahkan logika bisnis ke dalam database.

Arsitektur

Anda bersaing dengan menggunakan alat yang sesuai untuk masalah yang tepat, tanpa membutuhkan terlalu banyak alat, atau membuatnya terlalu sulit untuk diselesaikan, untuk membuat dan memelihara solusi.

Ini tidak mudah.

Tapi mari kita pikirkan yang tidak terpikirkan, bagaimana Anda mempertahankan logika bisnis yang didistribusikan di beberapa bahasa?

• Katalog ... sehingga setiap implementasi aturan bisnis dapat dilacak dan dipelihara.
• Tes ... yang dapat digunakan terhadap setiap aturan bisnis tanpa memperhatikan di mana dan bagaimana penerapannya.
• Implementasi referensi .. sehingga ketika ditemukan perbedaan, sumber kebenaran ada (atau setidaknya sumber perdebatan).

Tetapi ini memiliki biaya juga.

• Apakah lebih baik membiarkan aturan bisnis memiliki banyak implementasi? Itu masing-masing dapat mengambil keuntungan dari keterampilan tim, dan ketentuan kerangka kerja, tetapi membutuhkan kontrol kualitas yang ketat untuk menangkal memiliki banyak tingkah kecil?
• Atau lebih baik memiliki satu sumber kebenaran, yang ditulis dalam satu bahasa? Bisa dibilang lebih murah untuk diimplementasikan, namun juga sumber kegagalan tunggal, itu sendiri merupakan komponen monolitik yang menolak perubahan dalam menghadapi platform, kerangka kerja, atau yang belum menjadi alat yang baru ditemukan?

Saya akan mengawali jawaban saya dengan mengatakan bahwa saya benar-benar memelihara beberapa layanan microser yang menggunakan prosedur tersimpan. Juga saya telah menulis banyak prosedur tersimpan di berbagai titik dalam karier saya, dan saya setuju bahwa segala sesuatunya bisa sangat, sangat keliru jika digunakan secara tidak benar.

Jadi jawaban singkatnya adalah, tidak, prosedur tersimpan tidak secara inheren buruk dalam arsitektur layanan mikro. Tetapi Anda perlu memahami:

1. Anda menambahkan hambatan pada penggantian mesin penyimpanan. Jika beberapa karakteristik operasional atau kinerja atau batasan fitur mengharuskan Anda untuk beralih mesin penyimpanan, biayanya akan lebih besar karena Anda akan menulis dan menguji banyak kode baru. Menjalankan lebih dari satu mesin penyimpanan (baik selama fase migrasi atau untuk mengisolasi kegiatan berdasarkan kebutuhan kinerja) dapat menimbulkan masalah konsistensi kecuali jika Anda menggunakan komitmen dua fase (2PC), yang memiliki masalah kinerja itu sendiri.
2. Anda punya API lain untuk dirawat, yang artinya dependensi Anda dapat rusak. Menambahkan, menghapus, atau mengubah jenis parameter pada prosedur dapat merusak kode yang ada. Hal yang sama terjadi dengan tabel dan kueri, tetapi alat Anda mungkin kurang membantu melacak di mana hal-hal yang salah. Masalah dengan prosedur tersimpan biasanya ditemukan saat runtime, sangat terlambat dalam proses mengembangkan / menyebarkan.
3. Izin basis data Anda semakin rumit. Apakah prosedur berjalan sebagai pengguna yang masuk atau sebagai peran lain? Anda perlu memikirkan ini, dan mengelola ini (semoga dengan cara otomatis.)
4. Anda harus dapat bermigrasi ke versi baru dengan aman. Seringkali suatu prosedur harus dibatalkan dan dibuat kembali. Sekali lagi, izin mungkin menyebabkan beberapa masalah bagi Anda.
5. Kembalikan dari migrasi yang gagal dapat berarti usaha ekstra. Ketika lingkungan produksi terpisah dari pengembang, segalanya menjadi lebih menantang.

Ini adalah beberapa penggunaan prosedur tersimpan yang saya pikir sering bermanfaat:

1. Penegakan riwayat edit (log audit). Pemicu biasanya digunakan untuk tujuan ini, dan pemicu adalah prosedur tersimpan. Di beberapa basis data juga dimungkinkan untuk melarang sisipan dan pembaruan sepenuhnya untuk peran aplikasi: klien menjalankan prosedur yang dijalankan sebagai peran berbeda dengan izin yang sesuai dan yang menegakkan semua perilaku yang diperlukan.
2. Perpanjangan kendala pemeriksaan. Ini mungkin membawa Anda ke wilayah logika bisnis, tetapi ada kasus di mana alat kendala bawaan database mungkin tidak cukup untuk apa yang Anda butuhkan. Sering kali cara terbaik untuk mengekspresikan cek adalah dengan kode imperatif, dan Anda berisiko membiarkan data buruk masuk jika Anda bergantung pada aplikasi Anda untuk melakukannya untuk Anda.
3. Enkapsulasi kueri kompleks ketika tampilan tidak sesuai atau terlalu rumit. Saya telah melihat beberapa kasus di mana tampilan yang benar membutuhkan beberapa SQL yang sangat kompleks yang dapat diekspresikan jauh lebih dimengerti dalam prosedur tersimpan. Ini mungkin jarang terjadi, tetapi itu memang terjadi.

Secara umum, saya sarankan Anda mencoba tampilan terlebih dahulu, dan beralih ke prosedur hanya jika diperlukan. Tampilan yang dirancang dengan baik sebenarnya bisa berfungsi sebagai API, mengabstraksi rincian tentang bagaimana tabel yang mendasarinya dipertanyakan. Menambah API Anda (tampilan) dengan prosedur tersimpan sangat masuk akal dalam beberapa keadaan. Bahkan dimungkinkan untuk memancarkan JSON langsung dari kueri SQL, mem-bypass seluruh kekacauan pemetaan data dari hasil kueri ke model data aplikasi Anda. Apakah itu ide yang baik adalah sesuatu untuk Anda tentukan berdasarkan kebutuhan Anda sendiri.

Karena Anda seharusnya sudah mengelola sumber daya basis data Anda (skema, izin, dll.) Melalui beberapa alat otomatis, tidak, prosedur yang tersimpan tidak buruk pada dasarnya untuk layanan-layanan microser.

Prosedur tersimpan adalah detail implementasi. Fungsi basis data, lambdas, atau skrip shell yang tersimpan di suatu tempat di sistem file semuanya detail implementasi dan tidak relevan untuk arsitektur.

kebanyakan buku tentang layanan microser merekomendasikan satu database per layanan microser.

Oke, jadi kita bisa membuat kode prosedur tersimpan di basis data ini.

lagi kebanyakan buku arsitektur microservice menyatakan bahwa mereka harus otonom dan longgar digabungkan

Antara kapabilitas bisnis, siklus hidup pengembangan, manajemen, penyebaran, lokasi tim, dll. Tidak ada hubungannya dengan detail implementasi. Layanan Microsoft tidak menyelesaikan masalah teknis (justru sebaliknya). Mereka datang untuk memecahkan masalah dengan manajemen dan waktu ke pasar. Itu strategi, bukan taktik. Cara gagal-cepat dengan biaya serendah mungkin. Jika kemampuan bisnis tertentu terbukti tidak berharga, kami menjatuhkannya tanpa mengacaukan kemampuan lain, penyebaran, manajemen proyek, rilis ...

Perhatikan bahwa "split" sudah bertindak seperti agen decoupling. Katakanlah kita memiliki dua layanan, A didukung oleh Oracle dan B oleh MongoDB. Jika kita tidak melanggar aturan emas decoupling, harus dimungkinkan untuk menjatuhkan A + Oracle dengan efek samping yang dapat diabaikan pada B.

Menggunakan prosedur tersimpan yang ditulis khusus di Oracle, memasangkan dengan erat microservice ke teknologi itu.

Mungkin menyebabkan vendor terkunci. Sering kali, vendor dikenakan oleh bisnis karena alasan historis atau kontraktual ¹ . Penting untuk mengetahui cara tidak mengunci kode kami ke vendor. Misalnya, beberapa ORM dan kerangka kerja menerapkan bahasa permintaan baru yang menyembunyikan fungsi dan fitur bawaan database.

Meskipun, jika layanan kami cukup mikro, vendor lock-in tidak lagi menjadi masalah karena berdampak kecil pada keseluruhan. Sebagian kecil yang seharusnya dapat diganti (atau diisolasi) dengan cepat.

kebanyakan buku MSA (yang telah saya baca) merekomendasikan bahwa layanan microser harus berorientasi bisnis (dirancang menggunakan DDD).

Itu harus didorong oleh bisnis dan inilah masalahnya. Tidak semua bisnis memanfaatkan DDD. DDD dan layanan microsoft tumpang tindih di banyak titik, tetapi mereka tidak menyebabkan-efek. Kita bisa berakhir dengan ekosistem layanan mikro yang terdiri dari layanan anemia. Atau terdiri dari gabungan keduanya: layanan yang mengimplementasikan domain kompleks dan layanan anemia bodoh yang menyediakan POJO langsung dari DB. Tidak ada yang salah dengan itu.

Mengenai buku, mereka hanya fokus pada eksekusi strategi. Taktik - bagaimana memanfaatkan komputasi terdistribusi - bagaimana membuatnya bekerja untuk sukses, tetapi mereka (biasanya) agnostik terhadap strategi. Strategi bervariasi dari perusahaan ke perusahaan dan jarang tergantung pada pengembang. Jadi, kami masih harus meramalkan dan menyesuaikan apa yang dikatakan buku-buku dengan kebutuhan, persyaratan, dan kendala spesifik kami. Tujuannya adalah membuat strategi bisnis menguntungkan dan berkelanjutan.

Ingatlah selalu bahwa arsitektur apa pun merupakan sarana untuk mencapai tujuan. Aturan bisnis. Kami tidak membangun ekosistem layanan mikro untuk mode atau cinta untuk seni.

Itu tidak benar-benar ada hubungannya dengan microservices.

Prosedur tersimpan dapat masuk akal jika layanan Anda memiliki arsitektur berlapis 'gaya lama' di mana DB adalah fondasi layanan, dengan akses data dan lapisan logika bisnis di atasnya. Antarmuka antara layanan dan database dalam arsitektur seperti itu sangat spesifik untuk detail layanan yang paling dalam. Biasanya akan ada adaptor khusus layanan untuk setiap jenis database yang didukung, dan kekhususan API yang diekspos oleh adaptor memungkinkan untuk menggunakan prosedur tersimpan di lapisan yang mendasarinya.

Ada banyak masalah dengan arsitektur seperti itu. Yang paling penting itu membuat sebagian besar logika sangat sulit untuk unit test. Arsitektur ini tidak lagi disukai.

Jika Anda menggunakan "arsitektur bersih" yang lebih baru, "arsitektur bawang", atau serupa, maka basis data akan menjadi ketergantungan yang disuntikkan , ditentukan di lapisan luar. Karena itu didefinisikan di lapisan luar, antarmuka yang disediakan untuk database harus generik . Ini tidak dapat mencerminkan detail layanan yang paling dalam, karena detail tersebut harus disembunyikan dari lapisan terluar arsitektur. Mendefinisikan antarmuka prosedur tersimpan generik yang dapat bekerja dengan setiap basis data atau unit test harness sangat sulit, dan tidak terlalu diperlukan, sehingga prosedur tersimpan tidak sering praktis dalam jenis arsitektur ini.

Hubungannya dengan layanan-layanan microser hanyalah bahwa layanan-layanan microser baru dan berpengaruh - kami tidak melakukan monolit lagi - dan bahwa gaya arsitektur baru ini juga berpengaruh - kami tidak melakukan layer datar lagi.