DTO'yu mikro hizmetler arasında paylaşmanın yolları?

Senaryom şu şekilde.

Çeşitli sensör türlerinden veri almak için tasarlanmış bir sistem tasarlıyorum ve daha sonra çeşitli ön uç ve analitik servisleri tarafından kullanılmak üzere dönüştürüp devam ettiriyorum.

Her hizmeti mümkün olduğunca bağımsız olacak şekilde tasarlamaya çalışıyorum, ancak biraz sorun yaşıyorum. Ekip, kullanmak istediğimiz bir DTO'ya karar verdi. Dışa bakan hizmetler (sensör verisi alıcıları) verileri kendi benzersiz yollarıyla alır, ardından bir JSON nesnesine (DTO) dönüştürür ve Message Broker'a gönderir. Mesajların tüketicileri daha sonra sensör veri mesajlarının nasıl okunacağını tam olarak bileceklerdir.

Sorun, aynı DTO'yu birkaç farklı hizmette kullanmamdır. Bir güncelleme birden fazla yerde gerçekleştirilmelidir. Açıkçası, burada DTO’da birkaç ilave veya eksik alan olacak ve servisler güncellenene kadar pek bir sorun olmayacak şekilde tasarladık, ancak bu beni hala rahatsız ediyor ve kendimi bana hissettiriyor. Hata yapmak. Kolayca baş ağrısına dönüşebilir.

Sistemi yanlış mı inşa edeceğim? Değilse, bunun çevresinde ya da en azından endişelerimi hafifletmek için bazı yollar nelerdir?

Benim tavsiyem? Bu DTO'ları herhangi bir kütüphane içindeki uygulamalar arasında paylaşmayın . Ya da en azından şu anda bunu yapmayın.

Biliyorum, çok sezgisel görünüyor. Kod kopyalıyorsunuz, değil mi? Ancak bu bir iş kuralı değildir, bu yüzden daha esnek olabilirsiniz.

DTO'yu gönderen hizmetin bir Rest API'sı gibi mesaj sözleşmesinde katı olması gerekir. Hizmet, DTO'yu, bilgileri zaten tüketen diğer hizmetleri DTO'dan kesebilecek şekilde değiştiremez.

Yeni bir alan eklendiğinde DTO yapın, yalnızca yeni alana ihtiyaç duymaları durumunda bu DTO'yu kullanan diğer servisleri güncelleyin . Aksi takdirde, unut gitsin. JSON'u içerik türü olarak kullanarak, bu yeni alanları DTO'nun gerçek sürümlerinde eşleştirmeyen hizmetlerin kodunu bozmadan yeni özellikler oluşturma ve gönderme esnekliğine sahipsiniz.

Ancak bu durum sizi gerçekten rahatsız ediyorsa, Üç Kural'ı takip edebilirsiniz :

Yeniden kullanımda iki "Üç Kural" vardır: (a) Tek kullanımlık bileşenler olarak yeniden kullanılabilir bileşenleri oluşturmak üç kat daha zordur ve (b) yeniden kullanılabilir bir bileşen, yeterince genel hale gelmeden önce üç farklı uygulamada denenmelidir. yeniden kullanım kitaplığına kabul etmek.

Bu DTO'yu servisler arasında paylaşmadan önce biraz daha beklemeye çalışın.

Microservices söz konusu olduğunda, hizmetlerin gelişim yaşam döngüleri de bağımsız olmalıdır. ^*

Farklı SLDC ve farklı geliştirme ekipleri

Gerçek bir MS sisteminde, her biri bir veya daha fazla hizmetten sorumlu olan ekosistemin geliştirilmesinde yer alan birkaç ekip olabilir. Buna karşılık, bu takımlar farklı ofislerde, şehirlerde, ülkelerde, planlarda yer alabilirler ... Belki de birbirlerini tanımıyorlar, bilgi ya da kod paylaşmayı çok zorlaştıran (mümkünse). Ancak bu çok uygun olabilir çünkü paylaşılan kod aynı zamanda bir çeşit paylaşım mantığı anlamına gelir ve hatırlamak için önemli olan şey, belirli bir takım için anlamlı olanın başka bir takım için yapması gerekmediğidir. Örneğin, DTO Müşterisi göz önüne alındığında, oyundaki hizmete bağlı olarak farklı olabilir, çünkü müşteriler her hizmetten farklı yorumlanır (veya görülür).

Farklı ihtiyaçlar, farklı teknolojiler

İzole edilmiş SLDC'ler ayrıca ekiplerin kendi gereksinimlerine en uygun yığını seçmelerini sağlar. Belirli bir teknolojide uygulanan DTO'ların uygulanması, ekiplerin seçme kapasitelerini sınırlandırıyor.

DTO'lar iş kuralları veya hizmet sözleşmeleri değildir

Hangi DTO'lar gerçekten? Verileri bir taraftan diğerine taşımaktan başka bir amacı olmayan nesneleri düzleyin. Çanta ve alıcılar. Genel olarak, hiçbir bilgiye sahip olmadığından, yeniden kullanıma değecek bir tür "bilgi" değildir. Uçuculukları ayrıca kuplaj için onları kötü adaylar yapıyor.

Dherik’in söylediklerinin aksine, bir hizmetin DTO’larını değiştirmesi, aynı zamanda başka hizmetlerin de değişmesi gerekmeden mümkün olmalıdır . Servisler toleranslı okuyucular, toleranslı yazarlar olmalı ve toleranssız olmalıdır . Aksi takdirde, hizmet mimarisini bir anlam ifade etmeyecek şekilde birleştirmeye neden olurlar. Bir kez daha ve Dherik'in cevabının tersine, eğer üç hizmet aynı DTO'lara ihtiyaç duyuyorsa, hizmetlerin ayrıştırılması sırasında bir şeyler ters gitmiştir.

Farklı iş, farklı yorumlar

Hizmetler arasında çapraz kavramlar olsa (ve olacak olsa da), tüm hizmetleri aynı şekilde yorumlamaya zorlamak için kanonik bir model uygulamak zorunda olduğumuz anlamına gelmez.

Vaka Analizi

Diyelim ki şirketimiz Müşteri Hizmetleri , Satış ve Nakliye olmak üzere üç bölümden oluşmaktadır . Bu sürümlerin her birinin bir veya daha fazla hizmet olduğunu söyleyin.

Onun yüzünden Müşteri Hizmetleri, etki alanı dili , müşteriler, kavramı etrafında uygular hizmetleri müşterilerin olan kişiler . Örneğin, müşteriler isim , soyadı , yaş , cinsiyet , e-posta , telefon vb. Olarak modellenmiştir .

Şimdi, Sales and Shipping hizmetlerini kendi alan dillerine göre de modelliyor. Bu dillerde, konsept müşteri de belirleyici bir farklılık göstermektedir. Onlara göre, müşteriler (mutlaka) kişi değildir . İçin Satış , müşteriler bir olan Belge numarası Bir Kredi Kartı ve fatura adresi için, Nakliye bir tam adını ve gönderim adresi de.

Sales and Shipping'i Müşteri Hizmetinin kanonik veri modelini benimsemeye zorlarsak , tüm temsili sürdürmeleri ve müşteri verilerini müşteri hizmetleri ile senkronize tutmaları gerekiyorsa gereksiz karmaşıklığa neden olabilecek gereksiz verilerle uğraşmaya zorluyoruz. .

İlgili Bağlantılar

• Mikroservisler ve Kanonik model
• Kanonik Veri Modelinden Kaçının

^{* İşte bu mimarinin gücünün dayandığı yer}

Her hizmeti mümkün olduğunca bağımsız olacak şekilde tasarlamaya çalışıyorum

Etkinlikler yayınlıyor olmalısın . Olaylar, belirli bir zamanda gerçekleşen bir şey hakkında sağlam bir gerçeği temsil eden belirli mesaj türleridir.

Her hizmetin çok iyi tanımlanmış bir sorumluluğu olmalı ve bu sorumlulukla ilgili olayları yayınlama sorumluluğuna sahip olmalıdır.

Ayrıca, etkinliklerinizin teknik etkinlikleri değil işle ilgili etkinlikleri temsil etmesini istiyorsunuz. Örneğin tercih OrderCancelledbir olay OrderUpdatedile status: "CANCELLED".

Bu şekilde, bir hizmet iptal edilmiş bir siparişe tepki vermesi gerektiğinde, yalnızca o olayla ilgili verileri taşıyan belirli bir mesaj türünü dinlemesi yeterlidir. Örneğin, OrderCancelledmuhtemelen sadece bir ihtiyacı var order_id. Buna tepki vermesi gereken hizmet, hangi veri deposundaki sipariş hakkında bilmesi gerekenleri zaten depolamıştır.

Ancak hizmetin yalnızca OrderUpdateddinleyeceği olaylar olsaydı, olayların akışını yorumlaması gerekirdi ve şimdi bir siparişin iptal edildiğinde doğru şekilde sonuçlandırılması için teslimat siparişine bağlıydı.

Senin sensör verileri yayınlamaya olarak sizin durumda, bununla birlikte, bu bir hizmet olması mantıklı olabilir, olayları dinlemek ve örneğin "iş etkinlikleri", yeni bir akışı yayınlamak TemperatureThresholdExceeded, TemperatureStabilised.

Ve çok fazla mikro servis oluşturma konusunda dikkatli olun. Mikro servisler karmaşıklığı kapsama almak için harika bir yol olabilir, ancak uygun servis sınırlarını bulamazsanız, karmaşıklığınız servis entegrasyonundadır. Ve bu korumak için bir kabus.

Çok az, çok büyük hizmetlere sahip olmak, çok çok küçük hizmetlere sahip olmaktan iyidir.