Mikroservis mimarisi, büyük yazılımları bağımsız servisler halinde geliştirip yönetme yaklaşımıdır.
Öne çıkanlar
- Mikroservisler bağımsız geliştirilip yayına alınabilen, iş yeteneğine göre ayrılmış servislerdir.
- Erken aşamadaki ürünlerde iyi modüllenmiş bir monolit çoğu zaman daha doğru başlangıçtır.
- Yanlış çizilen sınırlar dağıtık bir monolit üretir; alan odaklı tasarım bu riski azaltır.
- İzleme, CI/CD ve dayanıklılık önlemleri hazır olmadan servis sayısını artırmak sorun büyütür.
Bu yazıda6 bölüm
Mikroservis mimarisi, büyük bir yazılımı tek parça (monolit) olarak geliştirmek yerine, her biri belirli bir iş yeteneğinden sorumlu, bağımsız olarak geliştirilip yayına alınabilen küçük servisler halinde kurgulama yaklaşımıdır. Sipariş, ödeme, stok, bildirim veya kullanıcı yönetimi ayrı servisler olabilir; her biri kendi verisine sahip olur ve diğerleriyle API'ler ya da mesajlar üzerinden konuşur. Doğru kullanıldığında ekiplerin hızını ve sistemin dayanıklılığını artırır; yanlış zamanda tercih edildiğinde ise karmaşıklığı katlar. Bu yazıda mikroservislerin ne zaman mantıklı olduğunu ve nasıl doğru kurulacağını ele alıyoruz.
Monolit ve mikroservis: temel farklar
Monolit kötü bir şey değildir. Pek çok başarılı ürün, iyi modüllere ayrılmış tek bir uygulama olarak yıllarca büyür. Fark, sistem ve ekip büyüdükçe ortaya çıkar.
| Konu | Monolit | Mikroservis |
|---|---|---|
| Yayına alma | Tüm uygulama birlikte | Her servis ayrı ayrı |
| Ölçekleme | Uygulamanın tamamı | Yalnızca yük altındaki servis |
| Veri | Genellikle tek veritabanı | Servis başına ayrı veri sahipliği |
| Hata etkisi | Bir hata tüm sistemi etkileyebilir | Doğru tasarımda hata izole kalır |
| Operasyon yükü | Düşük | Yüksek: izleme, ağ, dağıtık hata ayıklama |
| Başlangıç hızı | Yüksek | Daha düşük |
Mikroservisler ne zaman mantıklı?
Mikroservis kararı teknik olduğu kadar organizasyoneldir. Aşağıdaki işaretlerden birkaçı birlikte görülüyorsa, ayrıştırmayı düşünmek için iyi bir zamandır:
- Birden fazla ekip aynı kod tabanında çalışıyor ve birbirinin yayınlarını bekliyor.
- Sistemin belirli bir bölümü (örneğin arama veya ödeme) diğerlerinden çok farklı yük ve ölçek ihtiyacına sahip.
- Bir modüldeki küçük bir değişiklik bile tüm uygulamanın uzun test ve yayın sürecinden geçmek zorunda.
- Bazı bileşenlerin farklı bir teknoloji veya yayın sıklığı gerektirdiği netleşmiş.
Erken aşamadaki bir girişim veya ürün henüz yön ararken mikroservisle başlamak çoğu zaman gereksiz bir yüktür. Bu durumda modüler bir monolit kurup sınırları kodda netleştirmek, ileride servis ayırmayı da kolaylaştırır.
Doğru sınırları çizmek
Mikroservis projelerinin en sık başarısız olma nedeni yanlış çizilmiş servis sınırlarıdır. Servisler teknik katmanlara göre (“veritabanı servisi”, “API servisi”) değil, iş yeteneklerine göre ayrılmalıdır. Alan odaklı tasarımdaki (Domain-Driven Design) sınırlı bağlam (bounded context) kavramı burada yol göstericidir: “sipariş” kavramının satış, depo ve muhasebe için farklı anlamlar taşıması, bu alanların ayrı servisler olabileceğine işaret eder.
Her istekte birbirini senkron olarak çağırmak zorunda olan ve aynı veritabanı tablolarını paylaşan servisler mikroservis değil, dağıtık bir monolittir: monolitin bütün sorunları, ağın bütün sorunlarıyla birlikte.
İletişim, veri ve tutarlılık
Servisler birbirleriyle iki temel yolla konuşur: REST veya gRPC gibi senkron çağrılar ve mesaj kuyrukları ya da olay akışları üzerinden asenkron iletişim. Asenkron yaklaşım servisleri birbirine daha az bağımlı kılar; bir servis geçici olarak kapalıyken diğerleri çalışmaya devam edebilir.
Her servisin kendi verisine sahip olması, birden fazla servisi kapsayan işlemlerde klasik veritabanı transaction'larının kullanılamaması demektir. Bu nedenle şu desenler önem kazanır:
- Saga deseni: Çok adımlı bir iş akışı, her adımın başarısızlık durumunda telafi işlemiyle birlikte tanımlanır.
- Outbox deseni: Veri değişikliği ve yayınlanacak olay aynı yerel transaction içinde kaydedilir, böylece olay kaybolmaz.
- Nihai tutarlılık: Bazı ekranların birkaç saniye gecikmeli güncellenmesinin iş açısından kabul edilebilir olduğu baştan konuşulur.
Operasyon: görünmeyen maliyet
Mikroservisler kod karmaşıklığının bir kısmını operasyona taşır. Sağlıklı bir mikroservis ortamı için şu temellerin hazır olması gerekir:
- Her servis için otomatik test ve CI/CD hattı
- Konteynerleştirme ve tutarlı bir dağıtım ortamı (çoğu zaman Kubernetes veya yönetilen bir alternatif)
- Merkezi log toplama, metrikler ve servisler arası dağıtık izleme (tracing)
- Zaman aşımı, yeniden deneme ve devre kesici (circuit breaker) gibi dayanıklılık önlemleri
- API sürümleme ve servisler arası sözleşme testleri
Bu altyapı olmadan servis sayısını artırmak, hata ayıklamayı ve yayın süreçlerini hızla zorlaştırır.
Sonuç
Mikroservis mimarisi bir hedef değil, belirli sorunları çözen bir araçtır. Ekip yapısı, ölçek ihtiyacı ve operasyon olgunluğu birlikte değerlendirildiğinde doğru karar netleşir. Geçişte genellikle en iyi yol, monoliti bir anda yeniden yazmak yerine, en çok fayda sağlayacak bileşeni ayırarak adım adım ilerlemektir (strangler fig yaklaşımı). Dijicrea olarak yeni projelerde çoğunlukla iyi modüllenmiş bir yapıyla başlıyor, servis ayrımını gerçek ihtiyaç ortaya çıktığında ve sınırlar netleştiğinde yapıyoruz.
