Decomposition Patterns— Mikro Servis Mimarisi

Decompose by Business Capability

Mikro servisler, tek sorumluluk ilkesini(single responsibility principle) uygulayarak servisleri gevşek bir şekilde(loosely coupled) birleştirmekle ilgilidir. İş yeteneklerine(Business Capability) göre ayrışır. İş yeteneğine karşılık gelen servisleri tanımlamak istersek, bir iş konusu, iş mimarisi(Business Arch.) modellemesinden gelen bir kavramdır. Diğer bir yandan değer üretmek için yaptığı bir işlem veya tamamlayıcı servistir. Bir iş konusu genellikle bir iş nesnesine(Business Object) karşılık gelir.

Örneğin;

  • Siparişlerden Sipariş Yönetim Sistemi sorumludur
  • Müşterilerden Müşteri Yönetimi Sistemi sorumludur

Decompose by Subdomain

İş konularını kullanarak bir uygulamayı ayrıştırmak iyi bir başlangıç ​​olabilir, ancak ayrıştırılması kolay olmayacak sözde “Tanrı Objeleri/Sınıflar”(bakınız) ile karşılaşacaksınız. Bu sınıflar, birden çok servis arasında ortak kullanılmaktadır.

Domain-Driven Design (DDD) da alt etki alanlarına(subdomain) karşılık gelen servisleri tanımlamak istersek, DDD, etki alanı(subdomain) olarak uygulamanın sorunlu alanını(Domain), yani işi ifade eder. Bir alan(Domain), birden çok alt alan adından oluşur. Her alt alan, işletmenin farklı bir bölümüne karşılık gelir.

Alt alanlar şu şekilde sınıflandırılabilir:

  • Çekirdek — iş için anahtar özellikleri içerir ve uygulamanın en değerli kısmıdır
  • Destekleyici — işletmenin yaptıklarıyla ilgilidir, ancak farklılaştırıcı değildir. Bunlar şirket içinde veya dış kaynak olarak uygulanabilir
  • Genel — işletmeye özgü değildir ve ideal olarak hazır yazılım kullanılarak uygulanır

Bir Sipariş yönetiminin alt alanları şunları içerir:

  • Ürün kataloğu hizmeti
  • Envanter yönetimi hizmetleri
  • Sipariş yönetimi hizmetleri
  • Teslimat yönetimi hizmetleri

Decompose by Transactions / Two-phase commit (2pc) pattern

Servisleri işlemler(transactions) üzerinden ayrıştırabilirsiniz. Daha sonra sistemde birden fazla işlem(transaction) olacaktır. Dağıtık bir işlemin önemli katılımcılarından biri işlem koordinatörüdür. Dağıtılmış işlem iki adımdan oluşur:

  • Hazırlık aşaması — bu aşamada, işlemin(transaction) tüm katılımcıları onay/kaydet/bitir için hazırlanır ve koordinatöre işlemi tamamlamaya hazır olduklarını bildirir(Notification).
  • Teslim etme veya Geri alma aşaması — bu aşamada, işlem(transaction) koordinatörü tarafından tüm katılımcılara bir kesinleştirme veya bir geri alma komutu verilir.

Mikro servisler arasındaki işlemi koordine etmek, aynı ağda(network) olsalar bile sistemi gerçekten yavaşlatabilir, bu nedenle bu yaklaşım genellikle yüksek yük senaryosunda(High load) kullanılmaz.

Strangler Pattern

Yukarıda bahsettiğimiz tasarım kalıpları Greenfield(planlanan) uygulamalarına çözüm sağlayabiliyordu, ancak yaptığınız işin %80 i, monolitik uygulamalar (eski kod tabanı) olan brownfield uygulamalarıyla ilgili. Strangler modeli bu tür legacy yapılara için çözümle gelir.

Bu yaklaşım, aynı URI alanında yan yana yaşayan iki ayrı uygulama oluşturmaktır. Zamanla, yeniden düzenlenen yeni uygulama orijinal uygulamayı “boğar”(Strangle) veya sonunda monolitik uygulamayı kapatana kadar orijinal uygulamayı değiştirir. Strangler Uygulaması adımları dönüştürür, birlikte var olur ve ortadan kaldırır şeklindedir.

  • Dönüştür (Transform)— Modern yaklaşımlarla paralel yeni bir site oluşturulur.
  • Yan Yana Var olma (Co-exist)— Mevcut siteyi bir süreliğine olduğu yerde bırakın. Var olan siteden yenisine yönlendirin, böylece işlevsellik aşamalı olarak uygulanır.
  • Ortadan Kaldırma (Eliminate)— Eski işlevselliği mevcut siteden kaldırılır.

Bulkhead Pattern

Bir uygulamanın bölümlerini farklı pool lara ayırın, böylece biri başarısız olursa diğerleri çalışmaya devam eder. Bu model, bir gemi gövdesinin kesitli bölümlerine benzediği için Bulkhead olarak adlandırılmıştır. Müşteri yükü ve kullanılabilirlik gereksinimlerine göre servis örneklerini farklı gruplara ayırın. Bu tasarım, arızaları/kesintileri izole etmeye yardımcı olur ve bir arıza sırasında bile bazı tüketiciler için servis işlevselliğini sürdürmenize olanak tanır.

Burada dikkat edilmesi gereken konu, bölümlere ayrılan uygulamanın kesinti gören kısımlarının diğer bölümlerin çalışmasını engelemiyor olmasıdır.

Sidecar Pattern

İzolasyon ve kapsülleme sağlamak için bir uygulamanın bileşenlerini ayrı bir işlemci container larına dağıtabiliriz. Bu model, uygulamaların heterojen bileşenlerden ve teknolojilerden oluşmasını da sağlayabilir. Bir motosiklete bağlı bir sepete benzediği için Sidecar olarak adlandırılmıştır.

Modelde, sepet bir üst uygulamaya eklenir ve uygulama için destekleyici özellikler sağlar. Sepet ayrıca üst uygulamayla aynı yaşam döngüsünü paylaşır, üst uygulamayla birlikte oluşturulur ve kullanımdan kaldırılır. Yan araba modeli bazen yardımcı desen olarak adlandırılabilir.