Bölme hakkında konuşun: monolitik uygulamalardan mikro hizmetlere düşük riskli evrim
Yazar | Christian Posta
Çevirmen | Hai Song
Orijinal başlık | Düşük riskli Monolith'ten Mikro Hizmet Evrimi'ne Bölüm I
Kaynak | Resmi Hesap EAWorld
İki günlük mikro hizmet seminerinde, monolit uygulamanın ayrışmasını nasıl açıklayacağımı ve mikro hizmetlere geçişten sonra nasıl olacağını düşünüyordum. Bu makale konunun küçük bir parçası, ancak sizlerle paylaşmak ve geri bildirim almak istiyorum (seminerde, monolitik uygulamaları parçalamamız gerekip gerekmediğini daha ayrıntılı olarak tartışacağız!). Bu makalede, son birkaç yılda Kuzey Amerika'daki birçok Red Hat müşterisi ile bazı kişisel deneyimleri ve çalışma deneyimlerini özetledim. Buradaki ilk bölüm esas olarak mimariyi tartışıyor ve yayınlanacak ikinci bölüm çok yardımcı olabilecek bazı teknolojileri tanıtacak. En son güncellemeler ve tartışmalar için beni Twitter'da (@christianposta) veya takip edin.
Tartışmaya girmeden önce aşağıdaki varsayımları yapalım:
-
Mikro hizmet mimarisi her zaman uygulanabilir değildir (daha sonra ayrıntılı olarak tartışılacaktır).
-
Bir mikro hizmet mimarisi benimsememiz gerektiğinde, monolitte hangi değişikliklerin olacağını doğrulamalıyız.
-
Nadir durumlarda, monolitik uygulamalar olduğu gibi bölünecektir. Diğer çoğu durumda, ya yeni özellikler oluşturmanız ya da mevcut iş süreçlerini monolitik uygulamalar etrafında yeniden uygulamanız gerekir (bu, eğilime biraz aykırıdır)
-
Fonksiyonları bölme veya yeniden uygulama ihtiyacı durumunda, göz ardı edilemeyecek bir gerçek, monolitik uygulamaların günümüzde hala üretimde kullanılıyor ve büyük ticari değer getirmesidir.
-
Bu sorunu çözmeye çalışmak için, sistemin genel iş değerine müdahale etmemesini de sağlamalıyız.
-
Monolitik uygulama bir bütün olduğu için altındaki veri modelini veya veritabanını değiştirmek çok zor hatta imkansızdır.
-
Birden fazla dağıtım ve sürüm gerektirebilecek evrim riskini azaltmalıyız.
Mikro hizmetleri ayıklayın
Bu konudaki toplantılarda veya blog yayınlarında aşağıdaki öneriler sunulur:
-
İsimler etrafında organize edin
-
Bir şey yap, bir şeyi iyi yap
-
Tek sorumluluk ilkesi
-
bu zor
Ancak bu öneriler işe yaramaz.
Geçerli bir öneri şu şekilde görünmelidir:
-
Tanımlama modülü (mevcut veya yeni modül)
-
Bu modüllere karşılık gelen tabloları bölün ve servislerle paketleyin
-
Daha önce doğrudan veritabanı tablosuna dayanan kodu güncelleyin ve yeni hizmeti çağırmak için kullanın
-
Yukarıdaki işlemi tekrarlayın (Durulayın ve tekrarlayın)
Özellikle:
1. Adım: Modülü tanımlayın
Süreç, can sıkıcı monolitik uygulamalarla başlar. Yukarıdaki şekilde, ilgili olabilecek farklı modülleri ve veritabanı tablolarını temsil etmek için bunu basitleştirdim. Monolitik uygulamadan hangi modülleri ayırmak istediğimizi belirlemeli, ilgili tabloları bulmalı ve devam etmeliyiz. Elbette gerçek şu ki, monolitik uygulamalar modüllerle (varsa) kolayca karıştırılabilir.
Adım 2: Veritabanı tablosunu bölün, servislerle sarın, bağımlılıkları güncelleyin
İkinci adım, Foo modülü tarafından hangi tabloların kullanıldığını belirlemek, onları bölmek ve ardından bunları modülün hizmetine eklemektir. Bu hizmet artık bu Foo tablolarına erişebilen tek hizmettir. Başka paylaşılan tablo yok! Bu iyi birşey. Foo'ya başvurmak için kullanılan tüm işlevler şimdi yeni oluşturulan hizmetin API'sinden geçmelidir. Yukarıdaki şekilde Bar ve Peynir hizmetlerini güncelledik.Foo'ya ihtiyaç duyduklarında, Foo hizmetine başvuracaklar.
3. Adım: Yukarıdaki işlemi tekrarlayın
Son adım, tüm monolitik uygulamalar kaybolana kadar bu işlemi tekrar etmektir. Yukarıdaki şekilde, aynı işlemi Bar servisi için de yaptık ve onu bir mimariye taşıdık.Burada, servisin kendi verileri ve açık API'si var, bu da bir mikro hizmete çok benziyor.
Bu genellikle iyi bir kılavuzdur, ancak yukarıdaki adımlar aslında göz ardı etmememiz gereken birçok gerçeği ortadan kaldırır. Örneğin, zamanın duraklatılmasını isteyip ardından tabloyu veritabanından silemeyiz. aynı:
-
Tek bir uygulamayı düzgün ve güzel bir şekilde modüler hale getirmek nadiren mümkündür
-
Tablolar arasındaki ilişki oldukça standart hale getirilebilir ve varlıklar arasında yakın bağlantı veya bütünlük kısıtlamaları vardır.
-
Monolitik uygulamada hangi tabloların bazı kodlarla çağrıldığını tam olarak anlamamız imkansızdır.
-
Tabloyu yeni bir hizmete çıkarmış olsak da bu, mevcut iş sürecinin durdurulduğu anlamına gelmez, yeni hizmete tek tek geçmelerine izin verebiliriz.
-
Bazı sinir bozucu geçiş adımları havadan kaybolmayacak
-
Azalan getiri sağlayan bazı ödül puanları olabilir. Bu noktadan sonra, bir şeyi tek bir uygulamadan ayırmanın anlamı yoktur.
Vs vs
Şimdi bu yöntemin / modun neye benzediğini ve mevcut seçeneklerin neler olduğunu görmek için belirli bir örneğe bakalım.
Belirli örnekler
Bu örnek, yukarıda bahsedilen seminerden alınmıştır. Bölünmüş hizmeti analiz ederken biraz parlatma yapacağım, ancak seminerde tartışılan alan odaklı tasarım, bağlantı modeli ve fiziksel veya mantıksal mimari gibi daha fazla içerik burada belirtilmeyecek. Yüzeyde, bu yöntem yalnızca mevcut monolitik uygulamaların işlevlerini ayrıştırmak için kullanılabilir, ancak aslında monolitik uygulamalara yeni işlevler de ekleyebilir. İkincisinin olasılığı daha yüksek olabilir, çünkü monolitik uygulamayı doğrudan değiştirme riski oldukça büyüktür.
Monolitik uygulamaları anlayın
Bu monolitik uygulamadır (Monolith). Developers.redhat.com adresindeki TicketMonster öğreticisine dayanmaktadır. Öğretici başlangıçta yalnızca tipik bir Java EE uygulamasının nasıl oluşturulacağını tartıştı, ancak sonunda iyi bir örnek oldu: çok karmaşık değil ve bazı önemli noktaları göstermemiz için yeterli içerik var. Yayınlanacak genel konunun ikinci bölümünde, teknik çerçeveye veya platforma gireceğiz.
Bu resimde, monolitik uygulama tüm modülleri / bileşenleri / kullanıcı arayüzünü birlikte monolitik bir veritabanına yerleştirir. Değişmeye çalıştığımızda tüm vücudumuzu etkiler. Bu uygulamanın 10 yıldan fazla bir süredir kullanıldığını hayal edin, bu yüzden şimdi değiştirmek çok zor (teknik nedenlerin yanı sıra ekip veya organizasyon yapısı nedenleri var). Yeni müşteri değeri ve iş değeri sunmak için iş değişikliklerini daha hızlı ve daha bağımsız hale getirmek için kullanıcı arayüzünü ve temel hizmetleri bölmeyi umuyoruz.
Önlemler
-
Monolitik uygulamaların (kod ve veritabanı şeması) değiştirilmesi zordur
-
Değişiklikler tüm yeniden konuşlandırmayı ve ekipler arasında yüksek derecede koordinasyonu gerektirir
-
Regresyon analizi için birçok test yapmamız gerekiyor
-
Tam otomatik bir dağıtım yöntemine ihtiyacımız var
Kullanıcı Arayüzünü Çıkar
Bu adımda, UI'yi monolitik uygulamadan ayıracağız. Aslında bu mimaride ondan hiçbir şey silmedik. Riski azaltmak için, kullanıcı arayüzünü içeren yeni bir dağıtım ekledik. Bu mimarideki yeni UI bileşenlerinin, monolitik uygulamada aynı UI'ye çok yakın (veya hatta tamamen tutarlı) olması ve REST API'sini çağırması gerekir. Bu, monolitik uygulamanın harici kullanıcı arayüzünün kullanımı için makul bir API'ye sahip olduğu anlamına gelir. Ancak durumun böyle olmadığını görebiliriz: genellikle bu tür API'ler daha çok "dahili" API'ler gibi olabilir. Burada, ayrı UI bileşenlerini ve arka uç monolitik uygulamaları entegre etmenin yanı sıra halka açık API'ler oluşturmayı düşünmemiz gerekir. Daha kullanışlı.
Bu yeni UI bileşenini mimariye yerleştirebilir ve trafiği bu yeni mimariye yavaşça yönlendirmek için platformu kullanabiliriz ve yine de trafiğin bir kısmını eski monolitik uygulamaya yönlendirebiliriz. Bu şekilde durmamıza gerek yok. Benzer şekilde bu konunun ikinci bölümünde bunu nasıl yapacağımızı daha detaylı göreceğiz. Her durumda, karanlık başlatma / kanarya / yuvarlanan sürüm gibi kavramlar burada (ve sonraki adımlarda) çok önemlidir.
Önlemler
-
Başlangıçta monolitik uygulamayı değiştirmeyin; sadece kullanıcı arayüzünü kopyalayın veya ayrı bir bileşene aktarın
-
Kullanıcı arabirimi ile monolitik uygulama arasında uygun bir uzak API olması gerekir, ancak tüm durumların güvenlik yüzeyini genişletmesi gerekmez
-
Karanlık başlatma / kanarya / yuvarlanan sürümü desteklemek için kontrollü bir şekilde yeni bir kullanıcı arayüzüne veya monolitik uygulamaya trafiği yönlendirmek veya ayırmak için bir yöntem olması gerekir.
Monolitik uygulamalardan kullanıcı arayüzünü kaldırın
Önceki adımda, bir kullanıcı arayüzü tanıttık ve trafiği yeni kullanıcı arayüzüne (monolitik uygulama ile doğrudan iletişim kuran) yavaşça aktardık. Bu adımda, benzer bir dağıtım stratejisi benimseyeceğiz, ancak fark şu ki, kullanıcı arayüzü silindikten sonra, monolitik bir uygulamanın yeni bir dağıtımını yavaşça yayınlıyoruz. Bir sorun bulursak, yavaşça dışarı akmasına izin verebilir ve sonra geri alabiliriz. Kullanıcı arayüzünü silmiş olan monolitik uygulamaya (bundan sonra arka uç-Arka uç olarak anılacaktır) tüm trafiği göndererek monolitik uygulama dağıtımını tamamen silebiliriz. Kullanıcı arayüzünü ayırarak, artık monolitik uygulamanın küçük ölçekli bir ayrıştırmasını gerçekleştirdik ve riski azaltmak için karanlık başlatma / kanarya / yuvarlanma sürümüne güveniyoruz.
Önlemler
-
UI bileşenlerini monolitik uygulamalardan kaldırın
-
Monolitik uygulamada minimum değişiklik gerektirir (kullanımdan kaldırılmış / kaldırılmış / devre dışı bırakılmış kullanıcı arayüzü)
-
Kesintisizlik öncülüğünde, bu değişikliği tanıtmak için kontrollü yönlendirme / düzeltme yöntemini tekrar kullanın
Yeni hizmetleri tanıtın
Bir sonraki adımda, birleştirme ve alan odaklı tasarımın ayrıntılarını atladık ve yeni bir hizmet başlattık: Siparişler hizmeti. Bu kritik hizmette, iş bölümü diğer uygulamalardan daha sık değişmeyi umuyor, ancak aynı zamanda yazma modeli oldukça karmaşık. Bu modeli CQRS (bir kazı) gibi mimari kalıpları keşfetmek için de kullanabiliriz.
Mevcut Arka Uçtaki uygulamaya dayalı olarak Siparişler hizmetinin sınırlarına ve API'sine odaklanmamız gerekir. Aslında, bu uygulamanın mevcut kodu kullanmak için bir bağlantı noktasından ziyade bir yeniden yazma olma olasılığı daha yüksektir, ancak fikirler veya yöntemler aynıdır. Bu mimaride, Siparişler hizmetinin kendi veri tabanı olduğunu unutmayın. Bu çok iyi, hala birkaç adım uzakta olmasına rağmen, tam bir ayrışmaya ulaşmaktan uzak değil. Aşağıdaki adımların daha sonra dikkate alınması gerekir.
Aynı zamanda, hizmetin tüm hizmet mimarisindeki rolünü düşünmek için de iyi bir zamandır.Yapılması gereken, yayınlayabileceği veya tüketebileceği olaylara odaklanmaktır. Event Storming gibi olayları yürütmenin ve işlemsel iş yüklerini işlemeye başladığımızda yayınlamamız gereken olayları düşünmenin zamanı geldi. Bu olaylar, diğer sistemleri entegre ederken ve hatta monolitik uygulamaları geliştirirken kullanışlı olacaktır.
-
Çıkarılan hizmetin API tasarımına veya sınırına dikkat etmemiz gerekiyor
-
Monolitik uygulamada bazı içerikleri yeniden yazmanız gerekebilir
-
API belirlendikten sonra, hizmet için basit bir çerçeve (iskele) / yer tutucu uygulanacaktır.
-
Yeni Siparişler hizmetinin kendi veri tabanı olacaktır
-
Yeni Siparişler hizmeti şu anda herhangi bir trafik taşımıyor
API'yi uygulamaya bağlayın
Burada, hizmetin API ve etki alanı modelini ve modelin kodda nasıl uygulanacağını çıkarmaya devam etmeliyiz. Bu hizmet, yeni işlem iş yüklerini veritabanında depolar ve veritabanını diğer hizmetlerden ayırır. Hizmet, bu verilere erişirken API üzerinden geçmelidir.
Göz ardı edilemeyecek olan şey, yeni hizmetin ve verilerinin monolitik uygulamadaki verilerle yakından ilişkili olmasıdır (bazı yerlerde tam olarak aynı olmasa da). Aslında bu çok sakıncalıdır. Yeni bir hizmet oluşturmaya başladığınızda, Arka uç hizmeti veritabanındaki mevcut verilerin desteğine ihtiyacınız vardır. Bu, standardizasyon, FK kısıtlamaları ve veri modelindeki ilişkiler nedeniyle yanıltıcı olabilir. Mevcut API, monolitik bir uygulamada / arka uçta yeniden kullanılırsa, ayrıntı düzeyi çok kaba olabilir ve bu, belirli veri formlarını elde etmek için bazı tekniklerin yeniden icat edilmesini gerektirir.
Yapmamız gereken, temel API aracılığıyla arka uçtan salt okunur modda veri elde etmek ve verileri yeni hizmetin etki alanı modeline uyarlamak için yeniden şekillendirmektir. Bu mimaride arka uç veritabanına bağlanıp verileri doğrudan sorgulayacağız. Bu adım, veritabanına doğrudan erişimi yansıtan bir tutarlılık modeli gerektirir.
Başlangıçta bazı insanlar bu yöntemi benimsemekten korkabilir. Ancak gerçek şu ki, bu yöntem kesinlikle uygulanabilir ve kritik sistemlerde başarılı uygulama örnekleri olmuştur. Daha da önemlisi, bu nihai mimari değildir (nihai mimari olabileceğini düşünmeyin). Arka uç veritabanına bağlanmanın, verileri sorgulamanın ve verileri yeni hizmet etki alanı modeli için gereken doğru biçime getirmenin çok sayıda olgunlaşmamış, yığınlanmış kod içereceğini düşünebilirsiniz. Ancak bunun geçici olduğunu düşünüyorum, bu yüzden monolitik uygulamaların evriminde bu sorun olmayabilir, yani önce teknik borcu kullanın ve sonra hızla geri ödeyin. Ancak daha iyi bir yol var. Bu konunun ikinci bölümünde tartışacağım.
Veya herkes şöyle diyecektir: "Peki, yalnızca arka uç veritabanının önünde bir REST API kurmanız gerekir ve daha sonra daha düşük düzeyde veri erişimi sağlayabilir ve ardından onu çağırmak için yeni hizmeti kullanabilirsiniz." Bu aynı zamanda uygulanabilir bir yöntemdir, ancak sakıncaları da vardır. Yine bunu ikinci bölümde daha detaylı tartışacağım.
Önlemler
-
Çıkarılan / yeni hizmetin veri modeli, tanım gereği monolitik uygulama veri modeli ile yakından ilişkilidir.
-
En olası senaryo, monolitik uygulama tarafından sağlanan API'nin doğru düzeyde veri elde edememesidir.
-
Verileri alsak bile, verilerin biçimini dönüştürmek için çok sayıda kod örneğine ihtiyacımız var
-
Salt okunur sorgular için arka uç veritabanına geçici olarak bağlanabiliriz
-
Monolitik uygulamalar veritabanlarını nadiren değiştirir
Yeni mikro hizmete gölge trafiği gönderin (karanlık başlatma)
Ardından, yeni mikro hizmete trafik eklemeniz gerekir. Bunun ağır bir sürüm olmadığını unutmayın. Açıkçası bunu üretim akışına atmak yeterli değil (özellikle bu örnekte siparişleri kabul eden "sipariş" servisi kullanıldığı düşünüldüğünde! Elbette bu süreçte herhangi bir soruna neden olmak istemiyoruz!). Altta yatan monolitik uygulama veritabanını değiştirmek kolay olmasa da, mümkünse, monolitik uygulamayı yeni sipariş hizmetini çağırmak için dikkatlice değiştirmeyi deneyebilirsiniz. Hangi yöntemin en iyi olduğunu bilmiyorsanız, Michael Feather'ın "Eski Kodun Etkili Kullanımı" na bir göz atmanızı şiddetle tavsiye ederim . Sprout Yöntemi / Sınıfı veya Sarma Yöntemi / Sınıfı gibi modlar da size yardımcı olabilir.
Monolitik uygulamayı / arka ucu değiştirirken, eski kod yolunu korumak istiyoruz. Bu, hem yeni hem de eski kod yollarının paralel olarak çalışmasına izin verecek kadar kod eklemeyi gerektirir. İdeal olarak, monolitik uygulamanın değişiklikten sonraki yeni sürümü, çalışma zamanında yeni sipariş hizmetine trafik mi, eski kod yolunu mu yoksa her ikisini birden mi kullanacağımızı seçmemize izin vermelidir. Hangi çağrı yolu kombinasyonu kullanılırsa kullanılsın, yeni ve eski yürütme yolları arasındaki olası sapmaları anlamalıyız.
Unutulmaması gereken bir diğer nokta da, monolitik uygulamanın eski kod yoluna yürütme komutları göndermesine izin verilirse ve yeni hizmeti çağırmak için kullanılırsa, işlemi veya yeni hizmet çağrısını "sentetik" çağrı olarak işaretlemek için bir yola ihtiyacımız vardır. . Yeni hizmetiniz bu örnek kadar önemli değilse ve yinelenen içeriği işleyebiliyorsa, bu yapay isteği tanımlamak o kadar önemli olmayabilir. Yeni hizmetiniz daha fazla salt okunur trafik sunma eğilimindeyse, artık hangilerinin sentetik işlem olduğunu belirlemenize gerek kalmayabilir. Ancak, entegre işlemlerin öncülüğünde, depolama ve veritabanları dahil olmak üzere tüm hizmeti uçtan uca çalıştırabilmek isteyeceksiniz. Bu noktada, verileri işaretlemek ve depolamak için "sentetik" bayrağı kullanmayı veya veri deposu tarafından destekleniyorsa işlemi geri almayı seçebilirsiniz.
Unutulmaması gereken son nokta, monolitik uygulamayı / Arka Ucu değiştirdiğimizde, tekrar karanlık başlatma / kanarya / yuvarlanan sürümü kullanmayı umuyoruz. Ancak altyapı bunu desteklemeli. İkinci bölümde detaylı olarak tartışacağız.
Burada akış, monolitik uygulamalara geri dönmeye zorlanır. Kanarya geçersiz olduğunda hızlı bir şekilde geri dönebilmemiz için ana çağrı akışını kesintiye uğratmamaya çalışıyoruz. Diğer yandan, ağ geçitlerinin veya kontrol bileşenlerinin konuşlandırılması bir rol oynayabilir, monolitik uygulamaya çağırmayı empoze etmek yerine, yeni hizmetlerin daha ince bir ayrıntı düzeyinde başlatılmasını kontrol edebilirler. Bu durumda, ağ geçidi kontrol mantığına sahip olacaktır, yani işlemin monolitik uygulamaya mı, yeni hizmete mi yoksa her ikisine birden mi gönderileceğini seçebilir.
Önlemler
-
Kod yoluna yeni sipariş hizmetlerinin dahil edilmesi risklidir
-
Yeni hizmetlere kontrollü bir şekilde trafik göndermek
-
Trafiğin yeni hizmetlere ve eski kod yollarına yönlendirilebileceğini umuyoruz
-
Yeni hizmetlerin etkisini ölçmek ve izlemek için
-
Daha sorunlu iş tutarlılığı sorunlarını önlemek için "sentetik" şeyleri işaretlemeye çalışın
-
Yeni özellikleri belirli gruplara veya kullanıcılara dağıtmak istiyorsanız
Kanarya testi veya yeni mikro hizmetleri kullanıma sunma
Önceki adımların işlem yolu üzerinde olumsuz bir etkisi olmayacaksa ve aynı zamanda arka plan trafiğiyle ilgili testleri ve ilk üretim deneylerini geçebileceğimizden çok eminiz, o zaman artık monolitik uygulamayı "gölge DEĞİL" olarak ayarlayabiliriz, Ve trafiği yeni mikro hizmete gönderin. Şu anda, her zaman mikro hizmete aktarılması için belirli bir grup veya kullanıcı belirtmelisiniz. Aynı zamanda eski kod yolundan geçen gerçek üretim trafiğini de yavaş yavaş ihraç ediyoruz. Tüm kullanıcılar yeni sipariş mikro hizmetine aktarılıncaya kadar Arka Uç hizmetinin sıralı yayın sıklığını artırabiliriz.
Burada bir risk olduğunu hatırlatmam gerekiyor: gerçek zamanlı trafiği (gölge olmayan veya sentetik trafik) mikro hizmetlere aktarmaya başladığımızda, grupla eşleşen kullanıcıların her zaman bu mikro hizmeti aramasını bekliyoruz. Çünkü artık eski ve yeni kod yolları arasında geçiş yapamayız. Şu anda, bir geri dönüş uygulamak istiyorsak, çok fazla koordinasyon içerecek, böylece yeni işlem yeni işten eski iş birimine geçerken kullanılabilir. Umarım bu durum olmaz, ancak tetikte olmalı ve önceden plan yapmalı ve ilgili testleri yaptırmalıyız.
Önlemler
-
Grubu belirleyin ve yeni mikro hizmete gerçek zamanlı işlem trafiği gönderin
-
Veritabanına doğrudan bağlantı hala gereklidir, çünkü bu süre zarfında işlem iki kod yolundan geçecektir.
-
Tüm trafik mikro hizmetlere aktarıldıktan sonra, eski özellikleri terk etme zamanı geldi
-
Mikro hizmetlere gerçek zamanlı trafik gönderdikten sonra, eski kod yoluna geri dönmenin zorluklarla karşılaşacağını ve koordinasyon gerektireceğini lütfen unutmayın.
Çevrimdışı veri ETL / taşıma
Bu noktada sipariş mikro hizmeti gerçek zamanlı üretim trafiğini taşımaya başladı. Monolitik uygulama veya Arka Uç hala diğer ihtiyaçlarla ilgileniyor, ancak hizmet işlevini yekpare uygulamadan başarıyla çıkardık. Acil olarak ilgilenilmesi gereken bir sonraki konu, yeni mikro hizmet ile Arka uç hizmeti arasında doğrudan bir veritabanı bağlantısı kurulduğunda ortaya çıkan teknik borçtur. Bunun, tek bir veritabanından yeni bir hizmete tek seferlik bir ETL'yi (Dönüştürme Yükünü Çıkarma) içermesi muhtemeldir. Monolitik uygulamaların yine de bu verileri salt okunur olarak kaydetmesi gerekebilir (örneğin, uyumluluk nedeniyle vb.). Paylaşılan referans verileri ise (salt okunur gibi), bu iyi olmalıdır. Monolitik uygulamadaki ve yeni mikro hizmetteki bireysel verilerin paylaşılmamasını sağlamak gerekir. Eğer öyleyse, sonunda veri veya veri sahipliğiyle ilgili sorunlar olacaktır.
Önlemler
-
Yeni sipariş mikro hizmetimiz yakında tamamen özerk olacak
-
Sipariş hizmeti veri tabanını Arka uç veri tabanına bağlarken ödenmesi gereken teknik borcun ödenmesi gerekir
-
Sipariş hizmetinde kalan veriler için tek seferlik bir ETL uygulanmalıdır
-
Çeşitli veri sorunlarına dikkat edin
Ayrılmış veri depolama
Önceki adımı tamamladıktan sonra, yeni sipariş mikro hizmeti hizmet mimarisine eklenmeye hazırdır. Bu makalede açıklanan adımların kendi düşünceleri, avantajları ve dezavantajları vardır. Amacımız, tüm adımları tamamlamak ve teknik borca olan ilgiden kaçınmak olmalıdır. Elbette bu model ile fiili işlem arasında farklılıklar olabilir, ancak yöntemle ilgili bir sorun yoktur.
Bir sonraki takip blog yazısında, yukarıdaki adımları tamamlamak için daha önce bahsedilen örnek hizmetin nasıl kullanılacağını göstereceğim ve hangi araçların, çerçevelerin ve altyapının yararlı olduğunu derinlemesine inceleyeceğim. Kubernetes, Istio, özellik işaretleme çerçevesi, veri görüntüleme araçları ve test çerçevelerine bir göz atacağız. Lütfen bizi izlemeye devam edin!
***
Daha yüksek kaliteli teknik kuru ürünler almayı dört gözle bekliyorum, grup asistanı Xiaobobo QR kodunu taramaya ve yaklaşık 10.000 teknik kişiyle eaworld topluluğundaki mikro hizmetler, DevOps uygulamaları ve diğer teknik içerikler hakkında düzenli mikro sınıflara, video paylaşımına ve tartışmalara katılmaya hoş geldiniz. Grup gizli kodunu girin: 1201
