Microservice mimarisi paylaşılan etki alanı modelleri


12

Mikro hizmet mimarisini kullanan bir Spring Boot uygulamamız olduğunu varsayalım. Hizmetlerin her birinin kendi etki alanı modelleri vardır, ancak her hizmetin bir Kullanıcı etki alanı nesnesine başvurması gerekir. Bu sorunun nasıl çözüleceğine dair en iyi yaklaşım ne olurdu? Her hizmetin yalnızca bir kullanıcı kimliği olması daha iyi olur ve ardından gerektiğinde kullanıcı hizmetlerinden kullanıcı ayrıntılarını ister mi, yoksa tüm mikro hizmetler için paylaşılan bir etki alanı kitaplığına sahip olmak daha mı iyi olur?


1
Mümkün olduğunda, tek bir hakikat kaynağına sahip olmak her zaman daha iyidir .
Robert Harvey

@RobertHarvey Bu poliglot kalıcılığını nasıl etkiler? Tüm etki alanı nesnesi için paylaşılan bir kitaplık kullanmak yine de her mikro hizmetin kendi veritabanına sahip olabileceği anlamına mı gelir?
user1176999

Bu terimi daha önce hiç duymadım, ancak tanımına baktığımda, kullanıcıları koymak istediğiniz veri deposu için hangi teknolojiyi seçtiğiniz dışında, çok dilli kalıcılığı etkilemediğini söyleyebilirim.
Robert Harvey

Yanıtlar:


12

Mikro hizmetlerin ölçeklenebilirlik, gevşek bağlantı ve her hizmetin kolay bağımsız modifikasyonundan faydalanması için gittiyseniz, mümkün olan en yüksek düzeyde buna bağlı kalmalısınız.

Genel mimari

En iyi yaklaşımın şöyle olacağını düşünüyorum:

  • genel kullanıcı bilgi yönetimi için bir mikro hizmete sahip olmak;
  • mikro hizmete özgü kullanıcı bilgilerini (örneğin profiller, yetkilendirmeler, tercihler) her bir mikro hizmette saklayın (genel kimliğin referansını kullanarak)

Ek okuma:

  • Bu makalede , bu tür mimari ve mantık, spesifik yetkiler durumu ile çok iyi açıklanmaktadır.
  • Bu makalede , tüm hizmetlerin aynı veri havuzuna erişmesini önlemek için kullanıcı kimliği yönetimi için zorluklar ve çözümler açıklanmaktadır.
  • Bu makalede , hizmetler arasında kullanıcının kimliğini iletmek için JWT'nin kullanılması açıklanmaktadır (kimlik jetonunda bazı temel bilgilerin sağlandığını belirterek, en azından çok temel için, kullanıcı hizmetini bir kez daha sorgulamak zorunda kalmaz. bilgi).

Kod paylaşımı

Şimdi yukarıdaki çözümü kabul ediyorsanız, bir kullanıcı mikro hizmetimiz (kullanıcı için kapsülleyici etki alanı modeli) var ve diğer tüm hizmetler aynı mikro hizmetin tüketicileridir. Bu durumda soru, isteyip istemediğinizi bilmektir:

  • esnek ve farklı serbest bırakma döngülerine izin vermek için güçlü ayrılma dogmasını izleyerek, her bir mikro hizmetin tüketici kodunu yeniden icat etmesi,
  • veya bu temel bilginin "şasi" altyapı modelinin bir uzantısı olduğunu göz önünde bulundurarak tüketici kodunu kütüphanenin bir parçası olarak paylaşmak .

Bu kod paylaşımı konusunda düşünülmüş fikir savaşları olduğu için, bu konuda net bir pozisyon almayacağım ve nesnel bir pozisyon alabileceğimi düşünmüyorum. İşte zaten bazı ek okumalar:

  • Bu makale en iyi çözümün olmadığını düşünüyor ve hepsi hedeflerinize bağlı
  • Bu makale konumu, kod paylaşımının yalnızca güçlü bir bağlantı oluşturması ve kod paylaşımının bazı sinerjiler getirmesi durumunda kötü olmasıdır.
  • Bu makale (mikroservisleri ölçekte uygulayan kişiler), ayrı yapılara sahip olma zorunluluğu ve eski kodun potansiyel hizmetten çıkarma konularında ısrar ediyor. Sağlam sürüm yönetimi ile tüketmek için paylaşılan bir kütüphaneye sahip olmak, bu iyi uygulamaları engellemez.

Bu konuda kendi fikrim, sıkı bir bağlantı önlemek için kullanıcı sağlayıcı ve kullanıcı-tüketiciler arasında kod PAYLAŞMAMALIDIR. Ancak, güçlü bir sürüm yönetiminiz varsa, tüketiciler arasındaki kullanıcı tüketim kodunu PAYLAŞABİLİRSİNİZ. Bu yaklaşımın bazı avantajları olacaktır:

  • Paylaşılan kullanıcı tüketim kodunun farklı sürümleriyle farklı kullanıcı tüketen mikro hizmetler oluşturulabilir (sürümler bağımsız kullanıcı sağlayıcısıyla uyumlu olduğu sürece). Tekerleği yeniden icat eden esneklik, ancak daha yüksek verimlilik.
  • Kullanıcı sağlayıcı hizmetinizi, tüketicileri etkilemeden bağımsız olarak değiştirebilirsiniz.
  • Tüketim tarafında bir hata bulunursa, bir kez düzeltebilir ve tüm tüketicileri en uygun şekilde dağıtabilirsiniz (sürüm yönetimi sayesinde). Bu bile daha yüksek hizmet kalitesine yol açabilir.
  • Herhangi bir nedenle kullanıcı sağlayıcısı API'sini güncellemek zorunda kalırsanız, güncellenen kullanıcı tüketimini daha hızlı bir şekilde dağıtabilirsiniz. Geçiş sırasında eski ve yeni sağlayıcı hizmetini aktif tutarsanız, bu paylaşım olasılığı tüketici sağlayıcısının eski sürümünün daha hızlı bir şekilde hizmetten çıkarılmasına izin verebilir.

1

Mümkünse paylaşılan bir kütüphaneden kaçınırdım. Kendinize, her bir hizmetin hangi özelliklere ihtiyacı olduğunu sorun. Genellikle, bir kullanıcıyı çevreleyen davranışların çoğunun yaşayacağı temel bir etki alanı vardır ve destekleyici etki alanları genellikle yalnızca bir kullanıcı kimliği gerektirir.

Servis bir kullanıcı ile ilgili bazı diğer ayrıntıları ihtiyacı varsa, bazı öneriler de bakabilirsiniz burada böyle durumlarla başa etmeyle ilgili

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.