Mikro hizmet için doğru boyut nedir? "Çok büyük değil ve çok küçük değil" etkisiyle ilgili bir şeyler duyarsınız ve bu kesinlikle doğru olsa da pratikte çok yararlı değildir. Ancak dikkatle tasarlanmış bir etki alanı modeliyle başlarsanız, mikro hizmetler hakkında düşünmek çok daha kolaydır.
Bu makalede çalışan bir örnek olarak insansız hava aracı teslim hizmeti gerçekleştirilir. Senaryo ve buna karşılık gelen başvuru uygulaması hakkında daha fazla bilgiyi burada okuyabilirsiniz.
Etki alanı modelinden mikro hizmetlere
Önceki makalede İnsansız Hava Aracı ile Teslimat uygulaması için sınırlanmış bağlamlar kümesi tanımladık. Ardından bu sınırlanmış bağlamlardan birine, Gönderim sınırlanmış bağlama daha yakından baktık ve bu sınırlanmış bağlam için bir varlık, toplama ve etki alanı hizmetleri kümesi belirledik.
Artık etki alanı modelinden uygulama tasarımına geçmeye hazırız. Aşağıda, etki alanı modelinden mikro hizmetleri türetmek için kullanabileceğiniz bir yaklaşım bulabilirsiniz.
Sınırlanmış bir bağlamla başlayın. Genel olarak, bir mikro hizmetteki işlevsellik birden fazla sınırlanmış bağlamı kapsamamalıdır. Sınırlanmış bağlam, tanımına göre belirli bir etki alanı modelinin sınırlarını belirler. Bir mikro hizmetin farklı etki alanı modellerini birlikte kullandığını fark ederseniz bu, geri dönüp etki alanı analizinizi daraltmanız gerektiğine ilişkin bir işarettir.
Daha sonra etki alanı modelinizdeki toplamalara göz atın. Toplamalar, mikro hizmetler için genellikle iyi adaylardır. İyi tasarlanmış bir toplama, iyi tasarlanmış bir mikro hizmetin özelliklerinin çoğuna sahiptir. Örneğin:
- Toplamalar, veri erişimi veya mesajlaşma gibi teknik sorunlar yerine iş gereksinimlerinden türetilir.
- Toplamalar yüksek düzeyde işlevsel bir uyuma sahip olmalıdır.
- Toplamalar, kalıcılık sınırlarıdır.
- Toplamalar gevşek bir şekilde eşlenmelidir.
Etki alanı hizmetleri de mikro hizmetler için iyi adaylardır. Etki alanı hizmetleri, birden çok toplama genelinde durum bilgisi olmayan işlemlerdir. Bunun tipik bir örneği birkaç mikro hizmet içeren bir iş akışıdır. Bunun örneğini İnsansız Hava Aracı Teslimatı uygulamasında göreceğiz.
Son olarak, işlevsel olmayan gereksinimleri göz önünde bulundurun. Takım boyutu, veri türleri, teknolojiler, ölçeklenebilirlik gereksinimleri, kullanılabilirlik gereksinimleri ve güvenlik gereksinimleri gibi etkenlere göz atın. Bu etkenler, bir mikro hizmeti daha küçük parçalara ayırmanıza veya tam tersi şekilde birkaç mikro hizmeti birleştirmenize neden olabilir.
Uygulamanızdaki mikro hizmetleri tanımladıktan sonra tasarımınızı aşağıdaki ölçütlere göre doğrulayın:
- Her hizmetin tek bir sorumluluğu vardır.
- Hizmetler arasında gevevelemeli arama yoktur. İşlevleri iki hizmete bölmek aşırı gevevelemelere neden oluyorsa, bu işlevlerin aynı hizmete ait olduğunu gösteren bir belirti olabilir.
- Her hizmet, bağımsız çalışan küçük bir ekip tarafından oluşturulabilecek kadar küçük.
- Kilit adımında iki veya daha fazla hizmetin dağıtılması gereken bağımlılıklar arasında hiçbir şey yoktur. Diğer hizmetleri yeniden dağıtmadan bir hizmeti dağıtmak her zaman mümkün olmalıdır.
- Hizmetler sıkı bir şekilde birbirine bağlı değildir ve bağımsız olarak geliştirilebilir.
- Hizmet sınırlarınız veri tutarlılığı veya bütünlüğüyle ilgili sorunlar oluşturmaz. Bazen işlevleri tek bir mikro hizmete yerleştirerek veri tutarlılığını korumak önemlidir. Buna göre, gerçekten güçlü tutarlılık gerekip gerekmediğini düşünün. Dağıtılmış bir sistemde nihai tutarlılığı ele almak için stratejiler vardır ve ayrıştırma hizmetlerinin avantajları genellikle nihai tutarlılığı yönetmenin güçlüklerinden daha ağır basar.
Hepsinden önemlisi faydacı olmak ve etki alanı odaklı tasarımın yinelemeli bir süreç olduğunu unutmamaktır. Emin olamadığınızda işe daha az ayrıntılı mikro hizmetlerle başlayın. Bir mikro hizmeti iki küçük hizmete ayırmak, mevcut birkaç mikro hizmette işlevselliği yeniden düzenlemekten daha kolaydır.
Örnek: İnsansız Hava Aracı ile Teslimat uygulaması için mikro hizmetler tanımlama
Geliştirme ekibinin dört toplamayı (Teslimat, Paket, İnsansız Hava Aracı ve Hesap) ve Scheduler ve Supervisor olmak üzere iki etki alanı hizmetini tanımladığını hatırlayın.
Teslim ve Paket, mikro hizmetler için belirgin adaylardır. Zamanlayıcı ve Gözetmen, diğer mikro hizmetler tarafından gerçekleştirilen etkinlikleri koordine eder, bu nedenle bu etki alanı hizmetlerini mikro hizmetler olarak uygulamak mantıklıdır.
İnsansız Hava Aracı ve Hesap, diğer sınırlanmış bağlamlara ait olduklarından ilginçtir. Bir seçenek Zamanlayıcının İnsansız Hava Aracı ve Hesap sınırlanmış bağlamlarını doğrudan çağırmasıdır. Bir diğer seçenek de Gönderim sınırlanmış bağlamında İnsansız Hava Aracı ve Hesap mikro hizmetleri oluşturmaktır. Bu mikro hizmetler, Sınırlanmış bağlamlar arasında, Sevkiyat bağlamı için daha uygun OLAN API'leri veya veri şemalarını ortaya çıkararak aracılık eder.
İnsansız Hava Aracı ve Hesap sınırlanmış bağlamlarının ayrıntıları bu kılavuzun kapsamı dışında olduğundan, referans uygulamamızda onlar için sahte hizmetler oluşturduk. Ancak bu durumda dikkate alınması gereken bazı faktörler şunlardır:
Doğrudan diğer sınırlanmış bağlama çağırmanın ağ yükü nedir?
Diğer sınırlanmış bağlamın veri şeması bu bağlam için uygun mu yoksa bu sınırlanmış bağlama göre uyarlanmış bir şemaya sahip olmak daha mı iyi?
Diğer sınırlanmış bağlam eski bir sistem mi? Bu durumda, eski sistemle modern uygulama arasında çeviri yapmak için bozulma önleyici katman işlevi gören bir hizmet oluşturabilirsiniz.
Ekip yapısı nedir? Diğer sınırlanmış bağlamdan sorumlu ekiple iletişim kurmak kolay mı? Aksi takdirde, iki bağlam arasında aracılık eden bir hizmet oluşturmak, ekipler arası iletişimin maliyetini azaltmaya yardımcı olabilir.
Şu ana kadar işlevsel olmayan gereksinimleri dikkate almadık. Uygulamanın aktarım hızı gereksinimlerini düşünen geliştirme ekibi, istemci isteklerinin alımından sorumlu olan ayrı bir alım mikro hizmeti oluşturmaya karar verdi. Bu mikro hizmet, gelen istekleri işlenmek üzere arabelleğe yerleştirerek yük dengeleme gerçekleştirir. Zamanlayıcı arabellekten istekleri okur ve iş akışını yürütür.
İşlevsel olmayan gereksinimler ekibin bir ek hizmet oluşturmasına neden oldu. Şimdiye kadarki tüm hizmetler, paketleri gerçek zamanlı olarak zamanlama ve teslim etme süreciyle ilgili olmuştur. Ancak sistemin ayrıca veri analizi için her teslimin geçmişini uzun vadeli depolama alanında depolaması gerekir. Ekip bunu Teslimat hizmetinin sorumluluğunda yapmayı düşündü. Bununla birlikte, veri depolama gereksinimleri geçmiş analiz ve sürüm içi işlemler için oldukça farklıdır (bkz. Verilerle ilgili dikkat edilmesi gerekenler). Bu nedenle ekip, Delivery hizmetinden DeliveryTracking olaylarını dinleyen ve olayları uzun vadeli depolama alanına yazan ayrı bir Teslim Geçmişi hizmeti oluşturmaya karar verdi.
Aşağıdaki diyagramda bu noktadaki tasarım gösterilmektedir:
Bu mimarinin bir Visio dosyasını indirin.
Sonraki adımlar
Bu noktada, tasarımınızdaki her mikro hizmetin amacını ve işlevselliğini net bir şekilde anlamanız gerekir. Artık sistemin mimarisini oluşturabilirsiniz.