Mikro servisler ve saklı prosedürler

Bir mikro hizmet mimarisinde saklı yordamlar kötü uygulama olarak mı kabul edilir?

İşte düşüncelerim:

• mikro hizmetlerde bulunan çoğu kitap, mikro hizmet başına bir veritabanı önerir. Saklı yordamlar tipik olarak monolitik bir veritabanı üzerinde çalışır.

• Yine çoğu mikro hizmet mimarisi kitabı, özerk ve gevşek bir şekilde eşleşmeleri gerektiğini belirtiyor. Özellikle Oracle'da yazılan saklı yordamları kullanarak, mikro hizmeti bu teknolojiye sıkıca bağlar.

• Çoğu mikro hizmet mimarisi kitabı (okuduğum), mikro hizmetlerin iş odaklı olmasını önerir ( etki alanı odaklı tasarım (DDD) kullanılarak tasarlanmıştır ). İş mantığını veritabanındaki saklı yordamlara taşıyarak bu artık böyle olmaz.

Bunun hakkında bir düşüncen var mı?

Depolanan prosedürlerin mikro hizmetlerle kullanılmasını açıkça yasaklayan veya savunmayan hiçbir şey yoktur.

Feragatname: Bir geliştiricinin POV'sindeki saklı prosedürleri sevmiyorum, ancak bu herhangi bir şekilde mikro hizmetler ile ilgili değil.

Saklı yordamlar genellikle bir monolith veritabanı üzerinde çalışır.

Bence mantıklı bir yanlışlığa kapılıyorsun.

Saklı prosedürler günümüzde düşüşe geçiyor. Halen kullanılmakta olan çoğu saklı yordam, etrafta tutulan daha eski bir kod tabanındandır. O zamanlar, monolitik veritabanları, mikro servislerin popüler hale gelmesine kıyasla daha yaygındı.

Depolanan süreçler ve monolitik veritabanlarının her ikisi de eski kod tabanlarında meydana gelir, bu yüzden onları daha sık görüyorsunuz. Ama bu nedensel bir bağlantı değil. Sen saklanan procs kullanmayın çünkü bir monololithic veritabanı var. Monolitik bir veritabanınız yok çünkü depolanmış işlemleri kullanıyorsunuz.

mikro hizmetlerde bulunan çoğu kitap, mikro hizmet başına bir veritabanı önerir.

Bu küçük veritabanlarının saklı yordamlara sahip olmamasının teknik bir nedeni yoktur.

Bahsettiğim gibi, saklı işlemleri sevmiyorum. Onları hantal ve gelecekteki bakımlara karşı dirençli buluyorum. Sprocs'u birçok küçük veritabanına yaymanın, sevmediğim sorunları daha da kötüleştirdiğini düşünüyorum. Ancak bu yapılamayacağı anlamına gelmez.

Yine çoğu mikro hizmet mimarisi kitabı, özerk ve gevşek bir şekilde eşleşmeleri gerektiğini belirtiyor. Özellikle Oracle'da yazılan saklı yordamları kullanmak, mikro hizmeti bu teknolojiye sıkıca bağlar.

Diğer tarafta, mikro servisinizin kullandığı herhangi bir ORM için aynı argüman yapılabilir. Her ORM her veritabanını da desteklemeyecektir. Bağlama (özellikle sızdırmazlığı) göreceli bir kavramdır. Makul olabileceğin kadar gevşek olman meselesi.

Sprocs, mikro-servislerden bağımsız olarak genel olarak sıkı birleşme problemi yaşar. Genel olarak sproklara karşı tavsiyelerde bulunabilirim, ancak özellikle mikro hizmetler kullandığınız için değil. Daha önce olduğu gibi aynı argüman: Sprocs gitmek için genel yol olduğunu düşünmüyorum, ama bu sadece benim önyargı olabilir ve bu mikro hizmetler ile ilgili değildir.

Çoğu msa kitabı (okuduğum), mikro hizmetlerin iş odaklı olması gerektiğini (ddd kullanılarak tasarlanmış) önerir. İş mantığını veritabanındaki saklı yordamlara taşıyarak bu artık böyle olmaz.

Bu, her zaman sprocs hakkındaki temel yakınlığım olmuştur: veritabanındaki iş mantığı. Niyet olmasa bile, bir şekilde her zaman bu şekilde sona erme eğilimindedir.

Fakat yine de, bu yakınma, mikro hizmetleri kullanıp kullanmamaya bakılmaksızın var olur. Daha büyük bir sorun gibi görünmesinin tek nedeni, mikro hizmetlerin sizi tüm mimarinizi modernize etmeye zorlaması ve sprokların artık modern mimarilerde tercih edilmemesi.

Yazılım yazmak için, sıkıca bir teknolojiye bağlanmanız gerekir.

En azından içinde geliştirilmekte olan programlama dili tarafından sağlanan çalışma ortamı.

Daha genel olarak, mikro hizmetinizin birkaç teknolojiye sıkı sıkıya bağlı olduğunu göreceksiniz:

• Ağ Hizmeti Çerçevesi, üst düzey HTTP / SSL / SOAP protokolü uygulamaları sağlamak için
• Kalıcılık sağlamak için Depo / ORM / DAO Çerçevesi.
• Veri İşleme Altyapıları veriyle çalışmak için araçlar sağlamak.
• İşlem / Threading / OS Framework, çoklu görev, dosya sistemi, bellek, GPU hesaplama, genişletme kartları, vb. Gibi OS kaynaklarına erişim sağlar ...

Ve bu, çıplak kemikli bir mikro servis yapmaktır.

Saklı yordamlar

Saklı bir prosedür, kullanmayı veya kullanmamayı seçebileceğiniz başka bir teknolojidir. Sihirli bir şekilde kodunuzu yekpare veya mikro yapmaz.

Olsa da:

• Başka bir teknoloji Uygulamada bulunan her teknoloji, herhangi bir programcının okuyabileceği, anlayabileceği ve bu teknoloji karışımı için akıllıca tasarım seçimleri yapma olasılığını azaltır.
• Farklı bir programlama paradigması kullanan bir dil. Uzman olmayanlar için kendi zorunlu, işlevsel, OO, vb. Bakış açılarını denemek ve zorlamak çok kolaydır, bu da çoğu zaman yıldız sonuçlarından daha azına neden olur.
• Bir API. Kod tabanındaki herhangi bir sınıf gibi korunmalıdır. Ayrıca, veritabanının genel olmayan bir arayüz sağladığı anlamına gelir. Bu, hem veritabanı motorunun kendisini değiştirmeyi hem de bellek önbelleğe alma gibi genel davranışları şeffaf bir şekilde uygulamanızı zorlaştırır.
• Bir eser. Bu, sürümlendirilmeli, test edilmeli ve dağıtılmalıdır. Bu yapılabilir, ancak veritabanları farklı bir yaklaşım gerektiren canlı eserlerdir. Genellikle orijinali silemez ve değiştiremezsiniz. Genellikle, sistemi istenen duruma geçirmek için zaman içinde değişikliklerin dikkatli bir şekilde yapılması gerekir.

Bunların her biri gerçek bir maliyettir. Bazı durumlarda maliyet doğrulanabilir, bazılarında ise değildir.

Bir komut dosyası altyapısını barındırarak neredeyse aynı masrafları ödüyordunuz. Tek azaltma, ana bilgisayar diliyle aynı programlama paradigmasını seçebilmenizdir.

İş mantığı

İş kurallarını veritabanına taşımak kötü bir uygulamadır. Saklı yordamlar yüzünden değil.

Bu kötü bir uygulamadır, çünkü veritabanı ve işletme mantığı farklı kesme seviyelerinde çalışır.

• Olgun uygulamalardaki bir veritabanı on yıllarca kullanılabilir. Genellikle bu sistemler motoru düzenli aralıklarla günceller, ancak veritabanının kendisi taşınır. Öldürülmedi ve baştan inşa edildi. Bir mikro hizmetin bu kadar uzun ömürlü olması için hiçbir neden yoktur.

• İş kurallarının ne kadar çabuk değiştiğine karşı yıllarca kontrast. Tecrübelerime göre eski bir iş kuralı belki birkaç yaşında, çoğu zaman çabucak değişiyor ve hangisinin değişeceğini asla söyleyemezsiniz. Bir regülatörden yeni bir gereksinim, eski bir ürünün kullanımdan kaldırılması, yazı başındaki değişiklikler, kaç çalışanın bir patron, vb.

Eğer iş mantığı kesme katmanları arasında, özellikle daha yavaş ve daha uzun ömürlü bir katmana dağılmışsa, değişime direnç gösterecektir. Bu mutlaka kötü bir şey değil. Sonuçta, içinde sıfır iş mantığı olan tek veritabanı üçlü bir mağaza.

Bir tablo şeması belirleme tek eylem iş mantığını veritabanına taşıyor.

Mimari

Bir çözüm yapmak ve sürdürmek için çok fazla araca ihtiyaç duymadan, uygun sorun için uygun aracı kullanmakla, çözmeyi çok zorlaştırmayla yarışıyorsunuz.

Bu kolay değil.

Fakat düşünülemez olanı düşünelim, iş mantığını birkaç dilde nasıl dağıtırsınız?

• Bir katalog ... böylece her bir iş kuralı uygulamasının izlenmesi ve bakımı yapılabilir.
• Nerede ve nasıl uygulandığına bakılmaksızın, her iş kuralına karşı kullanılabilecek testler.
• Bir referans uygulaması .. ki, tutarsızlıklar bulunduğunda, bir gerçekliğin kaynağı (veya en azından bir tartışma kaynağı) vardır.

Fakat bunun da bir bedeli var.

• İş kurallarının birçok uygulamaya sahip olmasına izin vermek daha mı iyi? Her biri ekip becerilerinden ve çerçeve hükümlerinden faydalanabilir, ancak birçok küçük vagona sahip olmak için sıkı kalite kontrollerine mi ihtiyaç duyuyor?
• Yoksa tek bir dilde yazılmış tek bir doğru kaynağına sahip olmak daha mı iyidir? Muhtemelen daha ucuz, aynı zamanda tek bir başarısızlık kaynağı, kendisi farklı platformlar, çerçeveler veya henüz keşfedilmiş araçlar karşısında değişime direnen monolitik bir bileşen mi?

Saklı yordamları kullanan bir kaç mikro hizmeti kullandığımı söyleyerek cevabımın başını vereceğim. Ayrıca kariyerimdeki çeşitli noktalarda birçok saklı yordam yazdım ve yanlış kullanılmaları durumunda işlerin çok, çok yanlış gidebileceğine kesinlikle katılıyorum.

Yani kısa cevap, hayır, saklı yordamlar bir mikro hizmet mimarisinde doğal olarak kötü değildir. Ancak anlamanız gerekir:

1. Depolama motorlarının değişmesine engeller ekliyorsunuz. Bazı işletimsel veya performans özellikleri veya özellik sınırlamaları depolama motorlarını değiştirmenizi gerektiriyorsa, çok fazla sayıda yeni kod yazacağınız ve test edeceğiniz için maliyet daha yüksek olacaktır. Birden fazla depolama motorunun çalıştırılması (geçiş aşamasında veya performans gereksinimlerine göre etkinliklerin yalıtılması), performans sorunları olan iki aşamalı bir taahhüt (2PC) kullanmadığınız sürece tutarlılık sorunları ortaya çıkarabilir.
2. Korumak için başka bir API'niz var, yani bağımlılıklarınız bozulabilir. Prosedürlerde parametre türlerini eklemek, kaldırmak veya değiştirmek mevcut kodu bozabilir. Aynı şey tablolarda ve sorgularda da olur, ancak araçlarınız işlerin yanlış gittiği yerleri bulmakta daha az yardımcı olabilir. Saklı yordamlarla ilgili sorunlar genellikle çalışma zamanında, geliştirme / dağıtma işleminde çok geç bulunur.
3. Veritabanı izinleriniz daha da karmaşıklaştı. Bir prosedür giriş yapmış kullanıcı olarak mı yoksa başka bir rol olarak mı çalışıyor? Bunu düşünmeniz ve yönetmeniz gerekiyor (umarım otomatik bir şekilde).
4. Yeni sürümlere güvenle geçebilmeniz gerekir. Çoğu zaman bir prosedür atılmalı ve yeniden yaratılmalıdır. Bir kez daha, izinler sizin için bazı sorunlara neden olabilir.
5. Başarısız bir göçün geri alınması, ekstra çaba anlamına gelebilir. Üretim ortamı geliştiricilerden ayrıldığında, işler daha da zorlaşıyor.

Bunlar, genellikle faydalı olacağını düşündüğüm saklı yordamların bazı kullanımları:

1. Düzenleme geçmişinin uygulanması (denetim kayıtları). Tetikleyiciler bu amaç için yaygın olarak kullanılır ve tetikleyiciler saklı yordamlardır. Bazı veritabanlarında ekler ve güncellemelere tamamen uygulama rolü için izin vermemek de mümkündür: müşteriler, uygun izinlerle farklı bir rol olarak çalışan ve gerekli tüm davranışları zorlayan prosedürleri uygular.
2. Kontrol kısıtlamalarının genişletilmesi. Bu, sizi iş mantığı alanına sokabilir, ancak bir veritabanının yerleşik kısıtlama araçlarının ihtiyaç duyduğunuz şey için yeterli olmadığı durumlar olabilir. Çoğu zaman çekleri ifade etmenin en iyi yolu zorunlu koddur ve uygulamanızın sizin için yapmasına bağlı olmanız durumunda, hatalı verilerin girilmesine neden olma riski vardır.
3. Bir görünüm uygunsuz veya çok karmaşık olduğunda karmaşık sorguların kapsüllenmesi. Doğru bir görünümün saklı bir prosedürde çok daha anlaşılır bir şekilde ifade edilebilen bazı son derece karmaşık SQL gerektirdiği birkaç durum gördüm. Bu muhtemelen nadirdir, ancak gerçekleşir.

Genel olarak, önce görüşlerinizi denemenizi ve yalnızca gerektiğinde prosedürlere başvurmanızı öneririm. İyi tasarlanmış görünümler aslında bir API olarak işlev görebilir ve altta yatan tabloların nasıl sorgulandığının ayrıntılarını açıklar. API'nizi (görünümlerini) saklı yordamlarla iyileştirmek bazı durumlarda anlamlı olur. Sorgu sonuçlarından uygulamanızın veri modeline tüm eşleştirme verisi karmaşasını geçerek JSON'u doğrudan bir SQL sorgusu üzerinden yayınlamak bile mümkündür. Bunun iyi bir fikir olup olmadığını kendi ihtiyaçlarınıza göre belirlemek için bir şeydir.

Bazı otomatik araçlarla veritabanı kaynaklarınızı (şema, izinler vb.) Zaten yönetmeniz gerektiğinden, saklı yordamlar mikro hizmetler için doğal olarak kötü değildir.

Saklı prosedürler uygulama detaylarıdır. Veri tabanı işlevleri, lambdalar veya dosya sisteminde bir yerde depolanan bir kabuk betiği tüm uygulama detaylarıdır ve mimariyle ilgisi yoktur.

mikro hizmetlerde bulunan çoğu kitap, mikro hizmet başına bir veritabanı önerir.

Tamam, bu veritabanlarındaki saklı yordamları kodlayabiliriz.

Yine çoğu mikro hizmet mimarisi kitabı özerk ve gevşek bir şekilde bir arada olması gerektiğini belirtiyor

İş yetenekleri arasında, geliştirme yaşam döngüleri, yönetim, dağıtımlar, ekibin konumları vb. Uygulama detayları ile ilgisi yoktur. Mikro hizmetler teknik bir sorunu çözmez (tam tersi). Yönetim ve pazara çıkış zamanı ile ilgili sorunları çözmeye geliyorlar. Bu bir strateji değil, taktik değil. Mümkün olan en düşük maliyetle hızlı başarısız olmanın bir yolu. Belirli bir iş yeteneğinin değersiz olduğu kanıtlanırsa, diğer yetenekleri, dağıtımları, proje yönetimini, sürümleri karıştırmadan bıraktık ...

"Bölünmüş" ün bir dekuplaj ajanı gibi davrandığını unutmayın. Diyelim ki iki hizmetimiz var, A Oracle ve B MongoDB tarafından desteklenmektedir. Dekuplajın altın kuralını bozmazsak, A + Oracle'ı B üzerindeki ihmal edilebilir yan etkileri ile bırakmak mümkün olmalıdır.

Özellikle Oracle'da yazılan saklı yordamları kullanmak, mikro hizmeti bu teknolojiye sıkıca bağlar.

Satıcının kilitlenmesine neden olabilir. Çoğu zaman, satıcı tarihsel ya da sözleşmeden kaynaklanan nedenlerden dolayı iş tarafından empoze edilir ¹ . Kodumuzu satıcıya nasıl kilitleyemeyeceğimizi bilmek önemlidir. Örneğin, bazı ORM ve çerçeveler veritabanı yerleşik işlevlerini ve özelliklerini gizleyen yeni bir sorgu dili uygular.

Her ne kadar hizmetlerimiz yeterince mikro olsa da, satıcı kilitlenmesi, bütünün küçük bir bölümünü etkilediğinden artık bir sorun değil. Çabuk değiştirilebilecek (veya izole edilmiş) küçük bir parça.

MSA kitaplarının çoğu (okuduğum), mikro hizmetlerin iş odaklı olması gerektiğini (DDD kullanılarak tasarlanmış) önermektedir.

İş odaklı olmalı ve burada bir şey olmalı . Tüm işletmeler DDD'den faydalanmıyor. DDD ve mikro servisler birçok noktada üst üste gelir, ancak bunlar sebep sonuç değildir. Anemik hizmetlerden oluşan bir mikro hizmet ekosistemi ile sonuçlanabiliriz. Veya her ikisinin bir karışımından oluşur: karmaşık bir etki alanı uygulayan hizmetler ve POJ'leri doğrudan DB'den sağlayan aptal anemik hizmetler. Bunda yanlış bir şey yok.

Kitaplarla ilgili olarak, yalnızca stratejinin yürütülmesine odaklanırlar. Taktikleri - dağıtık hesaplamanın avantajlarından nasıl yararlanılacağı - başarının işe yaraması için nasıl yapılır, ancak bunlar (genellikle) stratejiye agnostiktir. Stratejiler şirketten şirkete değişir ve nadiren geliştiricilere bağlıdır. Bu nedenle, kitapların söylediklerini özel ihtiyaçlarımız, gereksinimlerimiz ve kısıtlamalarımıza göre tahmin etmek ve uyarlamak zorundayız. Amaç, iş stratejisini karlı ve sürdürülebilir hale getirmektir.

Her zaman bir mimarinin bir sonuca ulaşmak için bir araç olduğunu daima aklınızda bulundurun. İş kuralları. Moda için veya sanata aşk için mikro hizmet ekosistemleri inşa etmiyoruz.

Mikro-servislerle hiçbir ilgisi yok.

Saklanan prosedürler, servisinizde veri tabanının ve iş mantığı katmanlarının da yer aldığı veri tabanı ve iş mantığı katmanlarının yer aldığı “eski stil” katmanlı bir mimariye sahipse mantıklı olabilir. Hizmet ile servis arasındaki veritabanı, bu tür bir mimaride, hizmetin en iç detaylarına çok özeldir. Tipik olarak, her bir desteklenen veritabanı türü için hizmete özel uyarlayıcılar olacaktır ve bağdaştırıcı tarafından sunulan API'nin özgüllüğü, temel katmanlarda saklı yordamların kullanılmasını mümkün kılar.

Bunun gibi mimarilerle ilgili birçok sorun var. En önemlisi, mantığın çoğunu ünite testini zorlaştırır. Bu mimariler artık lehine değil.

Yeni stil "temiz mimari", "soğan mimarisi" veya benzerini kullanıyorsanız, veritabanı dış katmanlarda belirtilen enjekte edilmiş bir bağımlılık olacaktır . Dış katmanlarda tanımlandığından, veritabanı için sağlanan arayüz genel olmalıdır . O olamaz bu ayrıntılar gerektiğinden, hizmetin en içteki ayrıntıları yansıtır gizli mimarisinin en dıştaki katmanlardan. Herhangi bir veritabanı veya ünite test kablo demeti ile çalışabilecek genel bir saklı yordam arayüzü tanımlamak inanılmaz derecede zordur ve gerçekten gerekli değildir, bu nedenle saklı yordamlar bu tür mimarilerde genellikle pratik değildir.

Mikro hizmetlerle olan ilişki sadece mikro hizmetlerin yeni ve yükselen olması - artık monolit yapmıyoruz - ve bu yeni mimari stillerin de yükselişe geçti - artık düz katmanlar yapmıyoruz.