Gelişmeye açık olarak tasarlama
Sürekli yenilik için gelişime açık bir tasarım çok önemlidir
Tüm başarılı uygulamalar, zaman içinde gerek hataların düzeltilmesi, gerek yeni özelliklerin ve teknolojilerin eklenmesi, gerekse de mevcut sistemlerin daha ölçeklenebilir ve dayanıklı hale getirilmesi için değişir. Bir uygulamanın tüm bölümleri birbirine sıkı şekilde bağlı değilse, sistemde değişiklik yapmak çok zorlaşır. Uygulamanın bir bölümünde değişiklik yapılması başka bir bölümün bozulmasına veya kod tabanının tamamına yayılan değişikliklere yol açabilir.
Bu sorun, tek parçalı uygulamalarla sınırlı değildir. Bir uygulama çeşitli hizmetlere bölünmüş olmasına rağmen sistemin katı ve kırılgan olmasına neden olan sıkı bağ belirtilerine sahip olabilir. Hizmetler evrilecek şekilde tasarlanırsa, ekipler yenilik yapabilir ve sürekli olarak yeni özellikler sunabilir.
Mikro hizmetler, burada listelenen birçok önemli noktanın ele alınması nedeniyle evrimsel bir tasarım elde etmenin popüler bir yolu haline gelmektedir.
Öneriler
Yüksek uyum ve gevşek bağ modelini uygulayın. Bir hizmet, mantıksal olarak aynı kategoride yer alan işlevler sağlıyorsa uyumludur. Bir hizmetin diğerleri etkilenmeden değiştirilebildiği hizmetler arasında gevşek bağ vardır. Yüksek uyum genellikle, bir işlevdeki değişikliklerin ilgili tüm işlevlerin tek bir hizmette bulunduğu diğer ilgili işlevlerde değişiklik gerektirdiği anlamına gelir. Bir hizmetin güncelleştirilmesi için diğer hizmetlerde eşgüdümlü güncelleştirmeler yapılması gerektiğini fark ederseniz bu, hizmetlerinizin uyumlu olmadığına ilişkin bir işaret olabilir. Etki alanı odaklı tasarımın (DDD) hedeflerinden biri bu sınırları belirlemektir.
Etki alanı bilgisini kapsülleyin. Bir istemci bir hizmeti kullanırken etki alanının iş kurallarını uygulama sorumluluğu istemciye bırakılmamalıdır. Bunun yerine, hizmetin sorumluluğu altındaki tüm etki alanı bilgilerini kapsüllemesi gerekir. Aksi durumda, iş kurallarının tüm istemciler tarafından uygulanması gerekir ve etki alanı bilgileri uygulamanın farklı bölümlerine yayılır.
Zaman uyumsuz mesajlaşma kullanın. Zaman uyumsuz mesajlaşma, mesajın üreticisi ile tüketicisini birbirinden bağımsız hale getirme imkanı sağlar. Üretici, tüketicinin mesajı yanıtlamasına veya herhangi bir eylem gerçekleştirmesine bağımlı değildir. Bir yayım/abonelik mimarisinde üretici mesajı kimin tükettiğini bile bilmeyebilir. Mesajlar, üreticide herhangi bir değişiklik yapılmaksızın yeni hizmetler tarafından kullanabilir.
Bir ağ geçidinde yerleşik olarak etki alanı bilgilerine yer vermeyin. Ağ geçitleri, bir mikro hizmet mimarisinde istek yönlendirme, protokol çevirisi, yük dengeleme veya kimlik doğrulaması gibi şeyler için kullanışlı olabilir. Ancak, ağ geçidi bu tür altyapı işlevleriyle sınırlandırılmalıdır. Yoğun bir bağımlılık haline gelmesinin önlenmesi için hiç etki alanı bilgisi uygulamamalıdır.
Açık arabirimler sunun. Hizmetler arasında yer alan özel çeviri katmanları oluşturmamaya özen gösterin. Bunun yerine, bir hizmetin iyi tanımlanmış bir API sözleşmesine sahip bir API sunması gerekir. Geriye dönük uyumluluğu koruyarak API’yi geliştirebilmeniz için API’nin sürümü tutulmalıdır. Bu sayede, bir hizmeti buna bağımlı olan tüm yukarı akış hizmetlerinde güncelleştirme koordinasyonu sağlamanıza gerek kalmadan güncelleştirebilirsiniz. Genel erişime açık hizmetler, HTTP üzerinden bir RESTful API sunmalıdır. Arka uç hizmetleri, performans nedeniyle RPC stili bir mesajlaşma protokolü kullanabilir.
Hizmet sözleşmelerine göre tasarlayın ve test edin. Hizmetler iyi tanımlanmış API’ler sunuyorsa bunlara göre geliştirme ve test işlemleri gerçekleştirebilirsiniz. Böylece, bağımlı olunan tüm hizmetleri çalıştırmak zorunda kalmadan tek bir hizmeti geliştirebilir ve test edebilirsiniz. (Doğal olarak, yine de gerçek hizmetlerle tümleştirme ve yük testi gerçekleştirirsiniz.)
Fitness işlevlerini kullanın. Fitness işlevleri, en uygun çözüme daha yakın mı yoksa daha uzak mı olduğunu görmek için sonucu ölçer. Fitness işlevleri, zaman içinde değişiklik meydana geldikçe mimari özelliklerin korunmasına yardımcı olur. Fitness işlevi, mimari özelliklerinin nesnel bütünlük değerlendirmesini sağlayan herhangi bir mekanizmadır. Değerlendirme ölçümler, birim testleri, kaos mühendisliği gibi çeşitli mekanizmalar içerebilir. Örneğin, mimar sayfa yükleme süresini önemli bir özellik olarak tanımlayabilir. Daha sonra, iş yükünün sayfa yükleme süresini test etmek ve sürekli tümleştirmenin bir parçası olarak testi çalıştırmak için bir fitness işlevi olmalıdır.
Altyapıyı etki alanı mantığından uzakta soyutlayın. Etki alanı mantığının mesajlaşma veya kalıcılık gibi altyapıyla ilgili işlevlerle karışmasına izin vermeyin. Aksi takdirde, etki alanı mantığındaki değişiklikler altyapı katmanlarının güncelleştirilmesini gerektirir ve tersi için de aynısı geçerli olur.
Geniş kapsamlı kritik konuları ayrı bir hizmete boşaltın. Örneğin, birkaç hizmetin istek kimliklerini doğrulaması gerekiyorsa, bu işlevi ayrı bir özel hizmete taşıyabilirsiniz. Ardından, kimlik doğrulama hizmetini kullanan hizmetlerden herhangi birine dokunmadan yeni bir kimlik doğrulama akışı ekleyerek geliştirebilirsiniz.
Hizmetleri bağımsız olarak dağıtın. DevOps ekibinin uygulamadaki diğer hizmetlerden bağımsız olarak tek bir hizmet dağıtabildiği durumlarda, güncelleştirmeler daha hızlı ve güvenli bir şekilde gerçekleştirilebilir. Hata düzeltmeleri ve yeni özellikler daha düzenli bir tempoyla sunulabilir. Hem uygulamayı hem de yayın işlemini bağımsız güncelleştirmeleri destekleyecek şekilde tasarlayın.