Veri çoğaltması olmayan mikro hizmetler

Veri çoğaltmasını veya en basit mikro hizmet tasarımı için paylaşılan bir veritabanını önlemek için zor buluyorum, bu da bir şey eksik olduğumu düşündürüyor. Karşılaştığım sorunun temel bir örneği. Birinin bir envanteri yönetmek için bir web uygulaması kullandığını varsayarsak, iki hizmete ihtiyaç duyarlar; bunlardan biri, kalemleri ve stoktaki miktarı yöneten envanter ve kullanıcı verilerini yönetecek bir kullanıcı hizmeti için. Veritabanını kimin stokladığını denetlemek istiyorsak, envanter hizmeti için kullanıcı kimliğini veritabanına son stoklama değerine göre ekleyebiliriz.

Uygulamayı kullanarak, azalmakta olan tüm öğeleri ve son kez stoklayanların bir listesini görmek isteyebiliriz, böylece tekrar stoklamalarını isteyebiliriz. Yukarıda açıklanan mimariyi kullanarak, miktarın 5'ten az olduğu tüm öğelerin öğe ayrıntılarını almak için envanter hizmetine bir istekte bulunulur. Bu, kullanıcı kimlikleri de dahil olmak üzere bir liste döndürür. Ardından, envanter hizmetinden alınan kullanıcı kimlikleri listesi için kullanıcı adı ve iletişim bilgilerini almak üzere kullanıcı hizmetine ayrı bir istekte bulunulur.

Bu çok verimsiz görünüyor ve farklı hizmetler API'larına birden fazla istek yapmadan önce birden fazla hizmet almıyor ve bu da birden fazla veritabanı sorgusu yapıyor. Bir alternatif, envanter verilerindeki kullanıcıların ayrıntılarını çoğaltmaktır. Bir kullanıcı iletişim bilgilerini değiştirdiğinde, değişikliği diğer tüm hizmetler aracılığıyla çoğaltmamız gerekir. Ancak bu, mikro hizmetlerin sınırlı bağlam fikrine uymuyor gibi görünüyor. Ayrıca tek bir veritabanı kullanabilir ve bunu farklı hizmetler arasında paylaşabiliriz ve bir entegrasyon veritabanının tüm sorunlarına sahip olabiliriz .

Bunu uygulamanın doğru / en iyi yolu nedir?

Çoğaltmanız gereken yeri tamamen özledim.

Mikro hizmetlerin merkezi bir ilkesi, hizmetin tek otorite olmasıdır. Bu, envanter ve kullanıcı yönetiminin tamamen ayrı olabileceği anlamına gelir. Kullanıcı yönetimini envanter sisteminin var olduğunu bile bilmeyecek şekilde tasarlıyorum.

Ancak envanter sistemini, kullanıcı kimliğinden başka kullanıcılar hakkında hiçbir şey saklamayacak şekilde tasarlıyorum. Bu, kullanıcı bilgisi değişikliklerini yayma sorununuzu halleder.

Hem envanter bilgileri hem de günlükler, denetimler ve çıktılar gibi kullanıcı bilgilerine ihtiyaç duyan şeylere gelince, bilgi değiştikçe güncellenmezler. Onlar ne olduğunun bir kaydı. Yine, değişikliği yaymazsınız.

Bu nedenle, her durumda, en son kullanıcı bilgisini istediğinizde, kullanıcı bilgi hizmetine sorarsınız.

Veri çoğaltma önlemek için zor buluyorum ....

Mikro hizmet mimarisi hakkındaki Microsoft e-kitabına göre , veri çoğaltmada yanlış bir şey yoktur. Temel olarak, verilerin çoğaltılması, hizmetler arasındaki ayrışmayı arttırır ve bu nedenle tek bir otorite olarak rollerini güçlendirir. İlgili bir bölüm:

Ve son olarak (ve mikro hizmet oluştururken sorunların çoğu burada ortaya çıkar), eğer başlangıç ​​mikro hizmetinizin orijinal olarak diğer mikro hizmetlere ait verilere ihtiyacı varsa, bu veriler için senkronize isteklere güvenmeyin. Bunun yerine, nihai tutarlılığı kullanarak (genellikle tümleştirme olaylarını kullanarak) bu verileri (yalnızca ihtiyacınız olan öznitelikleri) ilk hizmetin veritabanına çoğaltın veya çoğaltın ...

envanter hizmetine, miktarın 5'ten az olduğu tüm öğelerin öğe ayrıntılarını alması için bir istekte bulunulur. Bu, kullanıcı kimlikleri dahil bir liste döndürür. Ardından, envanter hizmetinden elde edilen kullanıcı kimlikleri listesine ilişkin kullanıcı adı ve iletişim bilgilerini almak için kullanıcı hizmetine ayrı bir istekte bulunulur.

Gerçekten evet.

Bir monolitte, ilgili öğeleri sorguladığınız bir Envanter modeline sahip olabilirsiniz, bunu bir Kullanıcı modeline besleyebilir ve aynı verileri alabilirsiniz.

Ya da daha da ileriye götürebilirsiniz, eğer aynı ilişkisel veritabanına sahipseniz ve SQL envanter tablosu ve kullanıcı tablosunu alacaksa, biraz sihir yapar ve peşinde olduğunuz verileri alırsınız.

Nasıl yaparsanız yapın, bir yerde envanter sisteminden bir kullanıcı kimliği listesi getiren, bunları kullanıcı sistemine besleyen ve bir veri listesi derleyen bir kod olacaktır .

Cevaplamanız gereken soru performans ve bakım ve diğer "yumuşak" niteliklerdir.

Mikro hizmetlerin ana yararı ölçeklendirmedir. Bir makinede on bin kullanıcınız varsa ve biraz durgunsa, başka bir makine ekleyebilirsiniz ve sistem iki kat daha hızlı hale gelir. Sekiz tane daha ekleyin ve on kat daha hızlı. (Doğrusal ölçekleme muhtemelen iyimser, ama ideal ve değildir o umut mantıksız.)

Ve bu hizmet başına . Envanter sistemi darboğazsa, kullanıcılar hakkındaki raporlardan daha fazlası için kullanılırsa, yalnızca bu hizmete daha fazla makine ekleyebilirsiniz . Makineler de uzmanlaşabilir; Bu hizmet çok fazla belleğe ihtiyaç duyar, bu hizmet ağır hesaplamalar yapar ve daha fazla işlemci gerektirir.

Ölçeklendirmeye ihtiyacınız yoksa, mikro hizmetlerin bir başka yararı daha vardır: modülerdir . Tabii ki, monolitik uygulamalar da modüler olabilir ve normalleştirilmiş bir veritabanınız vardır ve ... ancak pratikte modüller arasındaki duvarlar en iyi durumda cam duvarlar ve en kötüde kumdaki çizgiler gibidir. Mikro hizmetler katı çelikle ayrılır.

Kullanıcı sisteminiz tam anlamıyla ateş yakarsa, bu envanter sisteminizi en ufak bir şekilde etkilemez. Kimin neyi stokladığına ilişkin güzel raporlar yazdıramazsınız, ancak müşteriler stoklanmış ürünlerin orada olduğu bilgisine güvenli bir şekilde sipariş verebilirler.

Ve mikro hizmetlerde veriyi ilişkisel veritabanında (*) yaptığınızdan daha fazla çoğaltmazsınız . İlişkisel bir veritabanında birleştirme yapabilirsiniz ve eşdeğer, açıklandığı gibi koddaki listeleri birleştirmektir.

Bir görünüm de ekleyebilirsiniz , buna eşdeğer olan sizin için birleştirme yapan yeni bir hizmet eklemektir; bu üç istekle sonuçlanacaktır; Biri yeni servise, sonra da o servis orijinal ikisini yapar. İlişkisel veritabanlarında, görünümleri optimize eden ve hizmet düzeyinde uygulanması gereken süslü şeyler bulunur. "Ücretsiz" elde edemezsiniz.

Önbellekleme veri çoğaltmasından farklıdır, çünkü iki değer uyuşmazsa hangisinin yanlış olduğunu bilirsiniz. Genellikle mikro hizmetlerde tutarlılık pahasına kullanılabilirliği sağlamak için kullanılır (CAP teoremi). İlişkisel veritabanları tutarlılık sunağı üzerinde tamamen kasap kullanılabilirliği olduğundan, bunlarda daha az yaygındır. Önbelleğe almayı kolaylaştıran mikro hizmetlerin doğasında olan hiçbir şey olmadığını söyleyebilirim, ancak pratikte önbellekleme birincil endişe kaynağıdır ve mikro hizmetlerde önbelleği kolaylaştırır .

(*) Bir mikro hizmet kümesinde veri çoğaltmak mantıklıysa, muhtemelen eşdeğer ilişkisel veritabanında mantıklı olacaktır.