Mikro hizmetler ve Kanonik model

Bu sitedeki mikro hizmetler hakkında okurken , aşağıdaki ifadeyle karşılaştım. Standart bir şema ile kastedilen nedir? Alan modeli ile aynı değil mi?

Mikro Hizmet Mimarisi modeli, kanonik şema kavramı gibi SOA'nın diğer bölümlerini de reddeder.

— Punter Vicky
kaynak

Bu ifadenin kaynağını biliyor musunuz? (bağlantı amacıyla)

— Jack

Tabii Jack, işte burada - nginx.com/blog/introduction-to-microservices/…

— Punter Vicky

Sanırım bu Wikipedia makalesi aradığınız şey. Ancak makaleyi anlaması kolay değil.

— Arseni Mourzenko

Teşekkürler @ArseniMourzenko. Mikro hizmet mimarisinde bile, istek ve yanıtın bazı veri modellerine uyması gerektiğine inanıyorum. Mikroservis mimarisi tarafından neden reddedildi olarak anıldığı henüz anlaşılamamıştır.

— Punter Vicky

Bazı veri modeli evet, ancak bana öyle geliyor ki, makale 2 veya daha fazla hizmet arasında "paylaşılan" veya "ortak" veri modellerine atıfta bulunuyor. Kanonik şema, hizmetleri çalışma zamanı veri dönüşümlerinden kurtarmak için kullanılan bir modeldir. Hizmetler arasında ortak bir "dil". Yani makale MS'in yaşadığı "ekosistem" den toplam bağımsızlığına vurgu yapıyor gibi görünüyor. Örneğin ESB'ye verdiği sözü ele alalım. ESB genellikle veri yolundaki herkes için ortak olacak bir kurumsal veri modeli (mesajlar) talep eder. MS, herhangi bir harici sistem daralmasına bağlı olmayı reddeder.

— LAIV

Yanıtlar:

@ArseniMourzenko yorumuna güvendiğiniz için özür dilerim, ama Wikipedia'yı okumaya başladığımda hemen Kanonik Şemanın ne anlama geldiğini anladım .

İşte OP'nin gerçek şüpheye odaklanan yorumu

Mikro hizmet mimarisinde bile, istek ve yanıtın bazı veri modellerine uyması gerektiğine inanıyorum.

Bazı veri modeli evet, ancak makalenin 2 veya daha fazla hizmet arasında "paylaşılan" veya "ortak" veri modellerine atıfta bulunduğu anlaşılıyor.

Kanonik Şema çalışma zamanı veri dönüşümleri gelen hizmet kurtarmak amaçlı bir kalıptır. Ayrıca kod çoğaltılmasını önler. Ancak daha sonra hizmetinizi harici bir veri modeline de bağlıyorsunuz. (Yukarıda bağlantılı Wikipedia sayfasındaki şemalara bakın)

Hizmetler arasında bir çeşit ortak "dil" dir.

Yani makale MS'in yaşadığı “ekosistem” den toplam bağımsızlığına vurgu yapıyor gibi görünüyor.

Örneğin ESB'ye verdiği sözü ele alalım.

Ayrıca ESB'leri kullanmaktan çok kaçınırlar ve bunun yerine mikro hizmetlerin kendisinde ESB benzeri işlevler uygularlar.

ESB genellikle otobüse bağlı herkes için ortak olacak bir kurumsal veri modeli (mesajlar) talep eder.

Yani, makaleye geri dönersek, yazar MS'in herhangi bir harici sisteme (ve kısıtlamalarına) bağlı olmayı reddettiğine işaret ediyor gibi görünüyor .

— LAIV
kaynak

Teşekkürler @Laiv. 9 saat içinde ödül kazanacağım - bu yüzden beni kısıtlıyor :)

— Punter Vicky

Mikro hizmetler tamamen sıkı uyum ve gevşek bağlantı ile ilgilidir. Bir mikro hizmet içinde sıkı bir kaynağınız vardır, ancak mikro hizmet arasında gevşek bağlantınız vardır ve bu nedenle paylaşılan şemalardan veya veri sözleşmelerinden kaçınmak istersiniz. Ortak bir şemayı paylaşmalarını gerektirecek şekilde birbiriyle eşzamanlı arama yapan mikro hizmetleriniz olduğunu fark ederseniz, bu hizmet sınırlarınızı yanlış tanımladığınızın bir göstergesi olabilir.

Mikro hizmetler, Etki Alanına Dayalı Tasarım bölümünde Sınırlı Bağlamlarla yakından hizalanmalıdır.

— pnschofield
kaynak

If you find that you have microservices making synchronous calls. Mutlak zaman uyumsuz çağrılar değil. ESB asenkron mesajları ile de olabilir. Paylaşılan Şemalara veya veri sözleşmelerine bağlanması gerçeğine odaklandığımı düşünüyorum. MS mimarisinde, servisler arasında herhangi bir iletişim p2p'den kaçınılması gerektiğini varsayıyorum. İletişim, herhangi bir iç (iç hizmet katmanı) veya dış (ESB, kuyruk, vb.) Katman yerine uygulamalar aracılığıyla gerçekleşmelidir

— Laiv