Mikro hizmetler için veri konuları

Bu makalede, mikro hizmetler mimarisinde verileri yönetmeye yönelik konular açıklanmaktadır. Her mikro hizmet kendi verilerini yönettiğinden, veri bütünlüğü ve veri tutarlılığı önemli güçlüklerdir.

Mikro hizmetlerin temel ilkelerinden biri, her hizmetin kendi verilerini yönetmesidir. İki hizmet bir veri deposunu paylaşmamalıdır. Bunun yerine, her hizmet kendi özel veri deposundan sorumludur ve diğer hizmetler doğrudan erişemez.

Bu kuralın nedeni, hizmetler arasında istenmeden eşlenmemek, ancak hizmetlerin aynı temel veri şemalarını paylaşmaları sonucunda ortaya kalmaktır. Veri şemasında değişiklik olursa, değişikliğin o veritabanına dayalı her bir hizmette koordine olması gerekir. Her hizmetin veri deposunu yalıtarak, değişikliğin kapsamını sınırlayabilir ve gerçekten bağımsız dağıtımlar için çevikliği koruyabilirsiniz. Diğer bir nedenden dolayı, her mikro hizmetin kendi veri modelleri, sorguları veya okuma/yazma desenleri olabilir. Paylaşılan veri deposunun kullanılması, her ekibin, belirli hizmetleri için veri depolamayı en uygun hale getirme yeteneğini sınırlar.

Bu yaklaşım, tek bir uygulama içinde birden çok veri depolama teknolojisinin kullanılması gibi çok yönlü Kalıcılık sağlar. Bir hizmet, belge veritabanının şema-okuma özelliklerini gerektirebilir. Başka bir RDBMS tarafından sağlanmış olan başvurusal bütünlüğü gerekebilir. Her ekip, Hizmetleri için en iyi seçimi yapmak ücretsizdir. Çok yönlü kalıcılığı genel prensibi hakkında daha fazla bilgi için, bkz. iş için en iyi veri deposunu kullanma.

Zorluklar

Verileri yönetmek için bu dağıtılmış yaklaşımdan bazı sorunlar ortaya çıkar. İlk olarak, birden fazla yerde görüntülenen aynı veri öğesiyle veri depolarında artıklık olabilir. Örneğin, veriler bir işlemin parçası olarak depolanabilir, ardından analiz, raporlama veya arşivleme için başka bir yerde depolanabilir. Yinelenen veya bölümlenmiş veriler, veri bütünlüğü ve tutarlılığı sorunlarına yol açabilir. Veri ilişkileri birden çok hizmeti yaydığınızda, ilişkileri zorlamak için geleneksel veri yönetimi tekniklerini kullanamazsınız.

Geleneksel veri modelleme "tek yerde bir olgu" kuralını kullanır. Her varlık şemada tam olarak bir kez görünür. Diğer varlıklar buna başvuruları tutabilir ancak yinelemeyebilir. Geleneksel yaklaşımın belirgin avantajı, güncelleştirmelerin tek bir yerde yapılabilmektir ve bu da veri tutarlılığı sorunlarını önler. Mikro hizmetler mimarisinde, güncelleştirmelerin hizmetler arasında nasıl yayılacağı ve veriler güçlü tutarlılık olmadan birden çok yerde göründüğünde nihai tutarlılığı nasıl yöneteceğiniz göz önünde bulundurmanız gerekir.

Verileri yönetmeye yönelik yaklaşımlar

Her durumda doğru olan tek bir yaklaşım yoktur, ancak mikro hizmetler mimarisinde verilerin yönetilmesi için bazı genel yönergeler aşağıda verilmiştir.

• Mümkün olduğunda nihai tutarlılık yaklaşımını benimseyin. Sisteme güçlü tutarlılık veya ACID işlemleri için gereken yerleri ve nihai tutarlılık için kabul edilebilir yerleri anlayın.

• Güçlü tutarlılık garantisi gerektiğinde, bir hizmet, bir API aracılığıyla kullanıma sunulan belirli bir varlık için Truth kaynağını temsil edebilir. Diğer hizmetler, verilerin kendi kopyasını veya verilerin bir alt kümesini, sonunda ana verilerle tutarlı ancak Truth kaynağını kabul etmez. Örneğin, bir müşteri sipariş hizmeti ve öneri hizmeti içeren bir e-ticaret sistemi düşünün. Öneri Hizmeti sipariş hizmetinden olayları dinleyebilir, ancak bir müşteri iadesi isterse, bu, işlem geçmişinden oluşan, öneri hizmeti değil sipariş hizmetidir.

• İşlemler için Zamanlayıcı Aracısı gözetmen ve telafi işlemi gibi desenleri kullanarak verileri birçok hizmet arasında tutarlı tutun. Birden çok hizmet arasında kısmi hata oluşmasını önlemek için birden çok hizmete yayılan bir iş biriminin durumunu yakalayan ek bir veri parçası depolamanız gerekebilir. Örneğin, çok adımlı bir işlem devam ederken bir iş öğesini dayanıklı bir kuyrukta saklayın.

• Yalnızca bir hizmetin ihtiyacı olan verileri depolayın. Bir hizmet, yalnızca bir etki alanı varlığı hakkında bir bilgi alt kümesine gereksinim duyar. Örneğin, teslim bağlı bağlamında, hangi müşterinin belirli bir teslimatla ilişkilendirildiğini öğrenmemiz gerekir. Ancak, hesapların sınırlı bağlamı tarafından yönetilen, müşterinin faturalandırma adresine ihtiyacım yoktur. Etki alanı hakkında dikkatli olun ve DDD yaklaşımını kullanarak buradan yardım alabilirsiniz.

• Hizmetlerinizin tutarlı ve gevşek olarak bağlanmış olup olmadığını göz önünde bulundurun. İki hizmet sürekli olarak birbirleriyle bilgi değiş tokuş ediyorsa, geveze API 'Lerine yol açar, iki hizmeti birleştirerek veya işlevselliğini yeniden düzenleyerek hizmet sınırlarınızı yeniden çizmeyebilirsiniz.

• Olay temelli mimari stilikullanın. Bu mimari stilinde, genel modeller veya varlıklarda değişiklik yapıldığında bir hizmet bir olay yayımlar. İlgilendiğiniz hizmetler bu olaylara abone olabilir. Örneğin, başka bir hizmet, sorgulamak için daha uygun olan verilerin gerçekleştirilmiş bir görünümünü oluşturmak üzere olayları kullanabilir.

• Olaylara sahip olan bir hizmet, Yayımcılar ve aboneler arasında sıkı bir şekilde kurtulabilmek için olayların serileştirilmesi ve serisini kaldırmak için kullanılabilecek bir şema yayımlamalıdır. JSON şemasını veya Microsoft Bono, Protoarabellek veya avro gibi bir çerçeveyi düşünün.

• Yüksek ölçekte olaylar sistemde performans sorunlarına yol açabilir, bu nedenle toplam yükü azaltmak için toplama veya toplu işlem kullanmayı düşünün.

Örnek: drone teslim uygulaması için veri depoları seçme

Bu serideki önceki makalelerde, çalışan bir örnek olarak bir drone gönderim hizmeti ele alınmaktadır. Senaryo ve ilgili başvuru uygulamasıyla ilgili daha fazla bilgiyi buradabulabilirsiniz.

Bu uygulama, Recap için, drone tarafından zamanlanan teslimler için birkaç mikro hizmet tanımlar. Bir Kullanıcı yeni bir teslim zamanlarken, istemci isteği teslim hakkındaki bilgileri (toplama ve bırakma konumları gibi) ve paket hakkında boyut ve ağırlık gibi bilgiler içerir. Bu bilgiler bir iş birimi tanımlar.

Çeşitli arka uç Hizmetleri, istekteki bilgilerin farklı bölümlerinin yanı sıra farklı okuma ve yazma profillerine de sahiptir.

Teslimat hizmeti

Teslim hizmeti, şu anda zamanlanan veya sürmekte olan her bir teslimin bilgilerini depolar. Drones 'den olayları dinler ve sürmekte olan teslimlerin durumunu izler. Ayrıca, teslim durumu güncelleştirmeleriyle birlikte etki alanı olayları gönderir.

Kullanıcıların, paketlerini beklerken bir teslimin durumunu sıkça denetlemesi beklenmektedir. Bu nedenle, teslim hizmeti, uzun vadeli depolama alanı üzerinde üretilen işi (okuma ve yazma) vurgulamadaki bir veri deposu gerektirir. Ayrıca, teslim hizmeti herhangi bir karmaşık sorgu veya analiz gerçekleştirmez, yalnızca belirli bir teslimin en son durumunu getirir. Dağıtım servisi ekibi, yüksek okuma yazma performansına yönelik Redsıs için Azure önbelleğini seçti. Redde depolanan bilgiler nispeten kısa ömürlü olur. Teslim tamamlandıktan sonra teslim geçmişi hizmeti kaydın sistemidir.

Teslimat Geçmişi hizmeti

Teslim geçmişi hizmeti teslim hizmeti 'nden teslim durumu olaylarını dinler. Bu verileri uzun süreli depolamada depolar. Bu geçmiş veriler için farklı veri depolama gereksinimlerine sahip iki farklı kullanım durumu vardır.

İlk senaryo, verileri en iyi hale getirmek veya hizmetin kalitesini artırmak için veri analizinin amacına yönelik verileri toplayarak. Teslim geçmişi hizmetinin verilerin gerçek analizini gerçekleştirmediğini unutmayın. Yalnızca Alım ve depolama alanı sorumludur. Bu senaryoda, depolama alanı, çok çeşitli veri kaynaklarına uyum sağlamak için bir okuma ile ilgili bir yaklaşım kullanarak, büyük bir veri kümesi üzerinde veri analizi için iyileştirilmelidir. Azure Data Lake Store bu senaryoya uygun bir uygulamadır. Data Lake Store, Hadoop Dağıtılmış Dosya Sistemi (bir) ile uyumlu bir Apache Hadoop dosya sistemidir ve veri analizi senaryoları için performans için ayarlanmıştır.

Diğer senaryo, kullanıcıların teslim tamamlandıktan sonra bir teslimin geçmişini bakmelerini sağlar. Azure Data Lake bu senaryo için iyileştirilmez. Microsoft, en iyi performans için zaman serisi verilerinin Tarih ile bölümlenmiş klasörlerde Data Lake depolanmasını önerir. (Bkz. performans için Azure Data Lake Store ayarlama). Ancak, bu yapı KIMLIĞE göre bireysel kayıtları aramak için en uygun değildir. Zaman damgasını da bilmiyorsanız, KIMLIĞE göre arama tüm koleksiyonun taranmasını gerektirir. bu nedenle, teslim geçmişi hizmeti daha hızlı arama için Cosmos DB geçmiş verilerin bir alt kümesini de depolar. kayıtların süresiz olarak Cosmos DB kalmalarına gerek yoktur. Daha eski teslimatlar, bir aydan sonra da arşivlenebilir. Bu işlem, zaman zaman bir toplu işlem çalıştırılarak yapılabilir.

Paket hizmeti

Paket hizmeti tüm paketlerle ilgili bilgileri depolar. Paketin depolama gereksinimleri şunlardır:

• Uzun vadeli depolama.
• Yüksek miktarda yazma performansı gerektiren yüksek bir paket hacmi işleyebilir.
• Paket KIMLIĞINE göre basit sorguları destekler. Bilgi tutarlılığı için karmaşık birleşimler veya gereksinimler yoktur.

paket verileri ilişkisel olmadığından, belge odaklı bir veritabanı uygundur ve Cosmos DB parçalı koleksiyonlar kullanarak yüksek verimlilik elde edebilir. paket hizmeti üzerinde çalışma ekibi, ortalama stack (mongodb, Express.js, AngularJS ve Node.js) hakkında bilgi sahibi olduğundan Cosmos DB için mongodb apı 'sini seçer. bu, yönetilen bir Azure hizmeti olan Cosmos DB avantajlarını alırken mongodb ile mevcut deneyimlerinden yararlanmasını sağlar.

Sonraki adımlar

Mikro hizmet mimarisinde bazı yaygın güçlükleri azaltmaya yardımcı olabilecek tasarım desenleri hakkında bilgi edinin.