External Configuration
Bir servis tipik olarak farklı servisleri ve veritabanlarını kullanabilir. Dev, QA, UAT, prod gibi her ortam için uç nokta URL’si veya bazı yapılandırma özellikleri farklı olabilir. Bu özelliklerin herhangi birindeki bir değişiklik, servisin yeniden derlenmesi ve yeniden dağıtılmasını gerektirebilir.
Kod değişikliğini önlemek için harici konfigürasyon kullanılabilir. Uç nokta URL’leri ve kimlik bilgileri dahil tüm yapılandırmayı harici konfigürasyonlar içinde tutmalıyız. Uygulama bunları başlangıçta veya anında yüklemelidir. Bunlara başlangıçta uygulama tarafından erişilebilir veya sunucuyu yeniden başlatmadan yenilenebilir.
Service Discovery Pattern
Container teknolojisi ile IP adresleri dinamik olarak servislere(Instance) tahsis edilir. Adres her değiştiğinde, etkileşimde olan diğer servisler bozulabilir ve manuel değişikliklere ihtiyaç duyabilirler.
Her bir aktif (production) servisin meta verilerini ve her biri için erişim spesifikasyonu saklayacak bir servis kaydının oluşturulması gerekir. Bir servis örneği, başlatılırken ayrı bir sisteme kaydolmalı ve kapatılırken kaydı silinmelidir. İki tür servis discovery yaklaşımı vardır.
Client Side;
Server Side;
Circuit Breaker Pattern
Bir servis genellikle verileri almak için diğer servislere istek yapar ve bazı durumlarda istek yapılan servisin çalışmama ihtimali vardır. Bununla ilgili iki sorun var: Birincisi, istek, hizmet dışı servise gitmeye devam edecek, ağ kaynaklarını tüketecek ve performansı yavaşlatacaktır. İkincisi, kullanıcı deneyimi kötü ve öngörülemez olacaktır.
Tüketici, bir devre kesici(Circuit Breaker) benzer şekilde davranan bir proxy aracılığıyla bir uzak servisi çağırmalıdır. Birbirini izleyen arızaların sayısı bir eşiği(threshold) aştığında, devre kesici alarm verir ve bir zaman aşımı süresi boyunca, tüm uzak servisi başlatma girişimleri hemen başarısız olur. Zaman aşımı süresi dolduktan sonra devre kesici, sınırlı sayıda test talebinin geçmesine izin verir. Bu istekler başarılı olursa, devre kesici normal çalışmasına devam eder. Aksi takdirde, bir arıza varsa, zaman aşımı süresi yeniden başlar.
Bu model, bir uygulamanın uzak bir servisi başlatmaya çalışmasını veya bu işlemin başarısız olma olasılığı yüksekse paylaşılan bir kaynağa erişmesini engellemek için uygundur.
Blue-Green Deployment Pattern
Mikro servis mimarisinde, bir uygulama birçok mikro servis sahip olabilir. Tüm servisleri durdurur ve ardından yeni bir sürümü devreye alırsak, kesinti çok büyük olur ve işi etkileyebilir. Ayrıca, geri dönüş(rollback) bir kabus olacak. Blue-Green Deployment Modeli bundan kaçınmamızı sağlar.
Blue-Green Deployment stratejisi, kesinti süresini azaltmak veya ortadan kaldırmak için uygulanabilir. Bunu, Blue ve Green olmak üzere iki özdeş üretim ortamını çalıştırarak gerçekleştirebiliriz. Green’in mevcut canlı ortam ve Blue’nun uygulamanın yeni sürümü olduğunu varsayalım. Herhangi bir zamanda, tüm production trafiğine hizmet eden bir canlı ortam vardır.
