Microservisler birbirleriyle konuşmalı mı?

Micro-Services kullanarak bir uygulama tasarlıyorum ve birden çok hizmetten veri toplamak için kullanılacak en iyi mekanizmadan emin değilim.

İki seçenek olduğuna inanıyorum:

• Servislerin doğrudan konuşmasını sağlayan bir 'servisler arası' iletişim mekanizmasını entegre edin. API Ağ Geçidi, birleştirilmiş servisi API Ağ Geçidine vermeden önce, veri toplamak için diğer servisleri çağıran ayrı bir servis arayacaktır. API daha sonra arayana cevap verir. (Bu servisB çağrısı serviceA'dan gelen bir yanıt gerektirdiğinde çağrıları senkronize etmek zorunda kalacaktır. IE Ayrı Kişi ve Adres Servisleri.)
• API Ağ Geçidinin her servisi doğrudan aramasını ve yanıtı döndürmeden önce API içindeki verileri birleştirmesini sağlayın.

İkinci seçeneğe yaslanıyorum, çünkü hizmetlerin birbiriyle konuşması eşleşmeyi sağlayacak, bu durumda sadece monolitik bir uygulama tasarlayabilirim. Ancak, bu seçenekle kafamın üstünden düşünülebilecek birkaç ciddi dezavantaj var:

• API'nin birden fazla servisi birden fazla çağrı yapmasını sağlamak, özellikle bu çağrıların bazıları engellediğinde API sunucusundaki yükü artırır.

• Bu yöntem, API'nin, uygulamanın ne yapmaya çalıştığının farkında olduğunu bilmesi gerektiği anlamına gelir (IE Logic, sırayla hizmetleri çağırmak ve ardından verileri birleştirmek için API'ye programlanmalıdır). mikro hizmetler için aptal bir 'uç nokta' gibi davranır.

Bu soruna standart yaklaşımın ne olduğunu ve eksik olduğum üçüncü bir seçenek varsa bilmek ister misiniz?

Genel olarak, mikro hizmetlerin birbirleriyle eşzamanlı iletişim kurmalarını öneriyorum, büyük sorun eşleşiyor, hizmetlerden biri şimdi birbiriyle eşleşiyor, ikincisi başarısız olursa, ikincisi şimdi tamamen ya da kısmen işlevsiz oluyor.

Durum değiştirme işlemleri ve okuma işlemleri arasında net bir ayrım yapardım (CQS Komutu Sorgu Ayırma ). Devlet değiştirme operasyonları için bir çeşit mesajlaşma altyapısı kullanır, ateşe çıkar ve unuturum. Sorgular için, Senkronize istek yanıt iletişimini kullanır ve bir http API kullanabilir veya doğrudan veri deponuza gidebilirsiniz.

Mesajlaşma kullanıyorsanız, servisler arasındaki etkinlikleri arttırmak için abone olunan abone listesine da bakabilirsiniz.

Dikkate alınması gereken bir başka husus da (işlemsel) veri paylaşımıdır (yalnızca görünümlerin okunması yerine), eğer içsel durumunuzu ortaya çıkarırsanız, okuyucunuz verilerinizin yanlış durumunu veya yanlış sürümünü alabilir ve ayrıca verilerinizi kilitleyebilir mi?

Son fakat en az değil, hizmetlerinizi özerk tutmak için elinizden geleni yapmaya çalışın (en azından mantıksal seviyede).

Umarım bu mantıklı.

Bu verilere neden ihtiyaç duyduğunuza bağlı. UI için ise, tamamen iyidir. Üstelik olması gerektiği gibi. Chris Richardson bu konsept hakkında güzel bir açıklama yaptı ve Sam Newman'ın Backends for Frontends adlı benzer konseptiyle ilgili harika bir makalesi var .

Ancak, eğer bir mantık için ihtiyacınız olursa, hizmet sınırlarının yanlış olduğu ihtimali vardır.

Sağduyu bize hizmetlerimizin sahip olması gerektiğini söyleyen bazı özellikler var . Onlar:

1. Düşük bağlantı A servisinde bazı değişiklikler yaparsanız, B servisini etkilemelerini istemezsiniz.
2. Yüksek uyum Bazı özellikler uygulamanız gerekirse, en az sayıda hizmetin etkilenmesini istersiniz.
3. Yüksek özerklik. Bazı servis başarısız olursa, tüm sistemin kapatılmasını istemezsiniz.
4. Doğru ayrıntı düzeyi. Servislerinizin fazla konuşkan olmasını istemezsiniz, çünkü ağınız düşündüğünüzden daha karmaşık bir şeydir .
5. Servisler olaylarla iletişim kurmalıdır. Hizmetinizin, sürdürülebilirliği azalttığı için birbirinden haberdar olmasını istemiyorsunuz. Yeni bir servis eklemeniz gerekirse, ne olacağını düşünün.
6. Dağıtılmış veri. Bir servis, bilgilerin saklanma şeklini paylaşmamalıdır. Tıpkı iyi bir nesne gibi, verileri değil davranışları ortaya koyar.
7. Orkestrasyon üzerinden servis koreografisi.

Bunu başarmak için hizmet sınırlarınızı iş yetenekleri olarak kabul edin . Hizmet sınırlarının belirlenmesi için resmi bir süreç aşağıdaki gibidir:

1. Daha yüksek seviyeli sınırları belirleyin. Onları, kuruluşunuzun işletme hedefine ulaşmak, işletme değerini elde etmek için atması gereken bir adım olarak düşünmeyi seviyorum. Porter'ın Değer zincirine bakarak basit adımlar hakkında fikir edinebilirsiniz .
2. Her hizmetin içinde daha derine inin. Çocuk kendi kendine yeten birimleri kendi sorumlulukları ile belirleyin.
3. İletişim kurmalarına dikkat et. Doğru servisler öncelikle olaylarla iletişim kurar. Organizasyonel yapınızı düşünün. İçlerindeki iletişim oldukça yoğundur, ancak genellikle birkaç harici olay ortaya çıkar.

Bu yaklaşımı uygulamanın bir örneği ilgi çekici olabilir.

"API ağ geçidinizde" olmasa da, ikinci yaklaşıma da varsayılan olarak dayanıyordum, ancak tek amacı diğer mikro hizmetlere istekleri düzenlemek ve temsil etmek olan yeni bir mikro hizmet yaratmanın tamamen makul olduğunu düşünüyorum. veri daha yüksek bir formda. Bir mikro hizmetler mimarisinde, "temel" mikro hizmetlerin birbirleriyle doğrudan iletişim kurmasına karşı yaslanırdım.

Bunu biraz daha subjektif hale getirmek için , diğeri doğrudan veya dolaylı olarak veri veya hizmetleri gerektiriyorsa, bir hizmet diğerine bağlı diyelim . Matematik terimlerinde bu ilişkinin kısmi bir düzen olmasını ve ön sipariş verilmesini istemiyoruz . Diyagram formunda, bağımlılık diyagramınızı çizdiyseniz Hasse diyagramını almalısınız.ve herhangi bir (yönlendirilmiş) çevrimi yoktur. (Bir Hasse şemasında, kenarlar aşağıdan yukarıya doğru dolaylı olarak yönlendirilir.) Diğer bir kılavuz olarak, yukarıdan aşağıya yolların genellikle daha kısa olmasını istersiniz. Bu, varsayılan olarak nesnelere daha doğrudan bağlı kalmak istediğiniz anlamına gelir. Bunun nedenleri, belirli bir talep için yanlış gidebilecek şeylerin sayısını en aza indirir, genel masrafları en aza indirir ve karmaşıklığı azaltır. Dolayısıyla, bu metriğin "ideal" durumunda, Hasse diyagramı sadece iki seviyeye sahip olacaktı. Elbette, önbellekleme, birleştirme, yük dengeleme, arıza yönetimi gibi ara hizmetleri tanıtmak isteyebileceğiniz birçok neden vardır.

API Ağ Geçidinin “akıllı” olması konusundaki ikinci endişenizi ayrıntılandırmak için, şimdi Falcor ve Relay / GraphQL gibi çerçevelerle çekişe geçen bir model , "API Ağ Geçidi" nin genel olarak yapabilmesi için ne yapılacağına ilişkin daha fazla bilgi talep etmesini sağlamaktır. neyi GetTimelinegerektirdiğini bilmek zorunda kalmadan bu spesifikasyonları uygulayın . Bunun yerine, "bu kullanıcı bilgilerini kullanıcı hizmetinden iste ve bu yayınları posta hizmetinden al" gibi bir istek alır veya her neyse.

Birbirinize "arama" servisine olan gereksiniminizin, iyi bir şekilde yapılandırılmamış bir sistemle devam ettiğiniz anlamına geldiğinden şüpheliyim, çünkü bu, mikro hizmetlerin birbirlerini "arayabilmesi" gerektiğinde nadiren ortaya çıkan bir kuplaj şeklidir. mikro servisler uygun şekilde tasarlanmıştır.

Çözmeye çalıştığınız sorun hakkında daha fazla bilgi verebilir misiniz? Basit ingilizce mi?