Mikro hizmetler ve veri çoğaltma

Yeni bir uygulama yapıyorum ve mikro hizmetler mimarisi hakkında okuyordum. Mimarinin kendisi, geliştirme, devreye alma ve yaşam döngüsü yönetimi açısından çok anlamlı. Ancak ortaya çıkan bir sorun, ana verilerin nasıl ele alınacağıyla ilgiliydi.

Örneğin, 2 uygulamam var - Satış uygulaması ve Biletleme uygulaması. Bu uygulamaların her ikisinin de kendi mikro hizmetleri olarak oluşturulduğunu varsayın. Ancak bu uygulamaların her ikisinin de dağıtıldıklarında (ayrı olarak dağıtıldıklarını varsayarak Satışların MongoDB kullandığını ve Biletleme MariaDB kullandığını varsayarsak), Hesaplar, Ürünler gibi aynı ana veri örneklerine erişmesi gerekir. Bu, belirli bir ana veri varlığı için (örneğin Satış uygulaması olabilir Hesaplar için) bir sahip uygulaması ve ilgili bir tarafın (örneğin Biletleme uygulamasının Hesaplar hakkında bilgi sahibi olması gerektiği) olacağı anlamına gelir.

Bunu başarmanın birden fazla yolu vardır: - Master'dan ilgilenen tarafa veri çoğaltma - İlgili taraftan ustaya senkron okuma (mikro hizmetler mimarisi paradigması tarafından senkronizasyon bağımlılığı önerilmez) - Kendi merkezi deposu

Hesaplar içinde bile, hem Satış hem de Biletleme için ortak olan temel bir kısım olabilir (örneğin hesap adı, adres vb.). Bununla birlikte, Hesabın bazı yönleri SADECE Satış için, SADECE Bilet için geçerli olabilir.

Yukarıda belirtilen seçeneklerden herhangi biri hakkında herhangi bir düşünce / en iyi uygulama / fikir?

Servis otobüsü kullanarak mikro hizmet mimarisini başarıyla kuran bir ekibin parçasıydım.

Başlangıçta, mikro hizmetlerin ve olay güdümlü bir mimarinin temeldeki paylaşılan veri çamur topu veritabanını düzeltmemizi sağlayacağına inandık .

Öğrendiğimiz şey, mikro hizmetlerin ve olay güdümlü bir mimarinin , temeldeki paylaşılan veri çamur topu veritabanından kurtulmamızı gerektirmesiydi .

Paylaşılan verilerin mikro hizmetlerle iyi bir şekilde başarılmasının çok zor olduğuna inanıyorum - benim için yasak. Hizmetlerin birbirlerinin verilerini görmesine izin vermemenizi öneririm . Sorgulayamazsanız, yanlışlıkla bir bağımlılık getiremezsiniz.

Eğer varsa yapmak payı verilerini, kesinlikle sadece bir hizmet hiç bir kayıt KENDİ olabilir; kayda yazan tek hizmettir ve aynı verilerin diğer tüm kullanıcılarının salt okunur erişimi olmalıdır.

Ne yazık ki, bu az yönetilen paylaşım miktarı bile hizmetleriniz arasında önemli bir bağlantı sağlar. Bir hizmet veriyi bu şekilde istemiyorsa ne olur? Belki de bir toplama istiyor. "Sahip / yazma" hizmetinizi, başka bir hizmetin yararına toplu veriler yazıyor mu? Tavsiye etmem.

Sahip, verileri farklı bir şekilde devam ettirmek isterse ne olur? Ardından her okuyucu hizmetinin güncellenmesi gerekir. Bu bir bakım kabusu.

Sahip olduğumuz en iyi çözüm, verilerimizin önemli bir şekilde çoğaltılması ve denormalizasyonudur. Mikro hizmetler, ilgilendikleri verilerin kendi kopyalarını sakladılar.

Mesajlar genellikle onları işlemek için yeterli miktarda eşlik eden verilerle yayınlanır.

Örneğin, bir posta gönderme hizmetinin, bir şey yayınlaması gerektiğinde müşteri adresindeki değişiklikleri takip etmesi gerektiğini düşünebilirsiniz. Ancak "gönderilmeye hazır öğe" mesajınız, mesaj verilerinin bir parçası olarak hedef adresi içeriyorsa, gönderim hizmetinin artık müşterilerle ilgili değişen adresleri izlemesi gerekmez; yalnızca gönderildikçe öğelerle ilgili tam zamanlı adresler.

Senkronize verilerle çözümleri nasıl tasarlayacağımı öneremem. Veri çözümlerimiz "nihai tutarlılık" fikri üzerine inşa edilmiştir.

Dolayısıyla, bir müşteri adresini güncellediğinde, Adres hizmeti kullanıcı arabiriminden ilk komutu işler. Verileri doğru olduğunda, diğer tüm hizmetleri "Müşteri Adresi Güncellenmiş" olarak bildirmek için bir etkinlik yayınlar - tam adres veri olarak eklenir. Bu hizmetler, kendi veri depolarını, önem verdikleri verilerin bölümleriyle güncelleyecektir.

Fikir, bir hizmetin önemli bir işlem yapması gerektiğinde, bağımsız olarak izlenen veya yanıtladığı iletinin bir parçası olarak doğru şekilde hareket edecek kadar güncel bir kopyaya sahip olması gerektiğidir.

Paylaşılan veri depolama mikro hizmet mimarisine aykırıdır. Mesele şu ki, Hesaplar varsa, bunları ele alacak bir hizmet olmalı ve bu Hesapla etkileşimi tamamlamanın hizmetinden başka bir yolu olmamalıdır. Mikro hizmetlerinizin ortak depolama alanını paylaşmaları ve depolama mekanizmasında, doğrulamada veya diğer kısıtlamalarda yapılacak değişikliklerin her iki hizmette de uygulanması gerekiyorsa bağımsız olmaz. Uygulamada bu asla gerçekleşmez ve çok geçmeden her iki uygulamanın da ciddi değişikliklerden korunmasına yol açar.

Bu nedenle, verilerinize erişmenin tek yolu olarak bir hizmeti kullanın, örneğin Hesaplar. Başka bir hizmette bir özelliğin uygulanmasının Hesaplar hizmetinde bir değişiklik yapılması gerekebilir ve bu sorun değildir. Herhangi bir hizmete özgü mantığın o hizmette olması ve Hesaplar mikro hizmetine olabildiğince az özel öğe girmesi gerektiğini unutmayın.

Hesaplar, Ürünler gibi aynı ana veri örneklerine erişiminizin olması gerekir

Aynı değil. Her mikro hizmet, Hesaplar, Ürünler vb. İçin kendi eşlemelerini yapmalıdır. Her mikro hizmetin kuruluşlarla çalışmak için farklı bir yolu olacağını varsayıyoruz.

Etki Alanına Dayalı Tasarım'da bu, her sınırlı bağlamın (aynı uygulamada!) Aynı varlığı farklı bir şekilde eşleyebildiği yaygın bir durumdur.

Daha fazla bilgiye ihtiyaç duyarsanız, Mikro Hizmetlerin Geliştirilmesi: İnce Taneli Sistemlerin Tasarımı kitabını öneriyorum

Ana sete dayanan iskelet kayıtları kavramını düşündünüz mü?

Örneğin, bir mikro hizmet hesapları ve diğeri ürünleri işler. Üçüncüsü, alan adına özgü amaç için her ikisinden de kayıt tutabilir.