Mikroservis Mimarisi: Kavramlar, Güdüler ve Uygulama Kalıpları

1. Giriş & Genel Bakış

Bu içerik, Software Engineering Radio podcast'inin (bölüm 213) bir bölümünden türetilmiştir ve Johannes Thönes ile James Lewis'in mikroservisler konusundaki tartışmasını içermektedir. Konuşma, büyük, monolitik uygulamaların bakım zorluklarına bir yanıt olarak 2015'in başlarında önemli bir ivme kazanan bu mimari tarzın tanımını, motivasyonlarını ve pratik hususlarını araştırmaktadır.

2. Mikroservisleri Tanımlamak

Bir mikroservis, küçük, odaklanmış bir uygulama bileşeni olarak kavramsallaştırılır.

3. Mikroservislerin Yükselişi

4. Benimseme & Uygulama Kalıpları

5. Temel İçgörüler & Analiz

6. Teknik Çerçeve & Matematiksel Modeller

Podcast konuşma şeklinde olsa da, altında yatan ilkeler resmileştirilebilir. Temel bir model, ekip büyüklüğü (N), iletişim yolları ve mimari bağlantı arasındaki ilişkidir.

N ekipli monolitik bir mimaride, potansiyel iletişim yolları $O(N^2)$ ile ölçeklenir, çünkü bir modüldeki değişiklikler birçok diğerini etkileyebilir. Bu, koordinasyon yükü yaratır. Mikroservisler, sınırlı bağlamlar ve API'ler zorlayarak bunu azaltmayı amaçlar. Amaç, servisler arası iletişim maliyeti olan $C_{comm}$'i ağ çağrıları yoluyla açıkça yüksek yaparak, değişim maliyeti $C_{internal}$'in düşük olduğu bir servis içinde güçlü modülerliği teşvik etmektir.

Değişim yayılma olasılığı ($P_{prop}$) için basitleştirilmiş bir model şöyle olabilir:

$P_{prop} \approx \frac{C_{comm}}{C_{comm} + C_{internal}}$

Burada iyi tasarlanmış bir mikroservis mimarisi, $C_{comm}$'i (ağ gecikmesi, API sürümleme) sınır ötesi değişiklikler için baskın faktör yaparak, ilgisiz değişiklikler için $P_{prop}$'u en aza indirir.

7. Deneysel Sonuçlar & Vaka Çalışmaları

Podcast, Netflix'i birincil bir vaka çalışması olarak gösterir. 2015 yılına gelindiğinde, Netflix monolitik arka ucunu yüzlerce mikroservise ayrıştırarak şunları mümkün kılmıştı:

• Bağımsız Ölçeklendirme: Film önerisi veya faturalandırma gibi servisler, pik yükler sırasında bağımsız olarak ölçeklendirilebilir.
• Hızlı İnovasyon: Ekipler, tam yığın koordinasyonu olmadan servislerini günde birkaç kez dağıtabilir.
• Teknoloji Heterojenliği: Farklı servisler, görevleri için en uygun dilde yazılabilir (örneğin, Java, Node.js).

Grafik Açıklaması (Varsayımsal): Monolitik bir uygulamayı mikroservis mimarisiyle iki eksende karşılaştıran bir çubuk grafik: (1) Dağıtım Sıklığı (Günlük Dağıtım): Monolit düşük bir çubuk gösterir (örneğin, 0.1), Mikroservisler yüksek bir çubuk gösterir (örneğin, 50+). (2) Bir hatadan Kurtarma İçin Ortalama Süre (MTTR): Monolit yüksek bir çubuk gösterir (örneğin, 4 saat), Mikroservisler daha düşük bir çubuk gösterir (örneğin, 30 dakika), çünkü hatalar belirli servislere izole edilebilir.

Sonraki çalışmalar, örneğin DevOps Raporlarının Durumu'nda referans verilenler, gevşek bağlı, servis odaklı mimarileri daha yüksek yazılım teslim performansı ile istatistiksel olarak ilişkilendirmiştir.

8. Analiz Çerçevesi: Pratik Bir Örnek

Senaryo: Bir e-ticaret monoliti güncellemelerde zorlanıyor. "Ödeme" özelliği değişiklikleri tam regresyon testi gerektiriyor ve "ürün kataloğu" güncellemeleriyle çakışıyor.

Çerçeve Uygulaması:

1. Sınırlı Bağlamları Belirleyin: Alan Odaklı Tasarım kullanarak temel alanları belirleyin: Sipariş, Katalog, Envanter, Kullanıcı Yönetimi, Ödeme.
2. Servis Sınırlarını Tanımlayın: Her bağlam için bir mikroservis oluşturun. Sipariş Servisi, ödeme mantığına ve sipariş verilerine sahiptir.
3. Sözleşmeleri Belirleyin: Net API'ler tanımlayın. Sipariş Servisi, Ödeme Servisi'nin processPayment(orderId, amount) API'sini ve Envanter Servisi'nin reserveStock(itemId, quantity) API'sini çağıracaktır.
4. Veri Sahipliği: Her servis kendi veritabanına sahiptir. Sipariş Servisi'nin kendi "orders" tablosu vardır; Envanter veritabanını doğrudan sorgulamaz.
5. Dağıtım & Gözlemlenebilirlik: Her servis konteynerleştirilir, bağımsız olarak dağıtılır ve metrikleri (gecikme, hata oranı) merkezi bir panoya yayınlar.

Sonuç: Ödeme ekibi artık, katalog veya envanter ekiplerini dahil etmeden Sipariş Servisi'ne güncellemeler dağıtabilir, bu da koordinasyon yükünü önemli ölçüde azaltır ve dağıtım sıklığını artırır.

9. Gelecekteki Uygulamalar & Araştırma Yönleri

Mikroservislerin evrimi, 2015 bakış açısının ötesinde devam etmektedir:

• Servis Ağları: Istio ve Linkerd gibi teknolojiler, kesen ilgileri (güvenlik, gözlemlenebilirlik, trafik yönetimi) altyapı katmanında ele almak için ortaya çıkmıştır, böylece bireysel servislerin kod yükünü azaltır.
• Sunucusuz & FaaS: Fonksiyon-olarak-servis (örneğin, AWS Lambda), mikroservislerin aşırı bir formunu temsil eder, operasyonel karmaşıklığı tamamen bulut sağlayıcısına iter ve daha da ince taneli ölçeklendirmeyi mümkün kılar.
• AI/ML Entegrasyonu: Mikroservisler, ML modellerini bağımsız tahmin servisleri olarak dağıtmak için fiili kalıp haline gelmektedir, bu da A/B testi ve algoritmaların hızlı yinelemesine izin verir.
• Kenar Bilişimi: IoT ve gerçek zamanlı analiz senaryolarında düşük gecikmeli işleme için hafif mikroservislerin kenar cihazlarına dağıtılması.
• Araştırma Odağı: Gelecekteki araştırmalar, otomatik servis ayrıştırma araçlarında, dağıtık sistemlerde akıllı hata tahmininde ve servis koreografilerindeki etkileşimlerin resmi doğrulamasında gereklidir.

10. Referanslar

1. Lewis, J., & Fowler, M. (2014). Microservices. MartinFowler.com. Şu adresten alındı: https://martinfowler.com/articles/microservices.html
2. Newman, S. (2015). Building Microservices. O'Reilly Media.
3. Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
4. Conway, M. E. (1968). How Do Committees Invent? Datamation, 14(5), 28-31.
5. Google Cloud. (2019). The 2019 Accelerate State of DevOps Report. DORA.
6. Netflix Technology Blog. (Various). https://netflixtechblog.com/