Tüm yazılar
Matematik16 Aralık 2024

Microservices: Tek Büyük Uygulamadan Yüzlerce Küçük Servise Geçiş

Netflix, Amazon, Spotify gibi şirketler monolit yapıdan microservice mimarisine geçti. Modern bulut çağının en popüler mimari deseni.

Matematik Karavanı 6 dk okuma 5 soru
Renkli kablo bağlantıları — microservice ağı metaforu

Klasik problem: monolit

Bir e-ticaret uygulaması düşünün:

  • Ürün katalog.
  • Sepet.
  • Ödeme.
  • Kargo.
  • Yorumlar.
  • Bildirim.

Klasik yaklaşım (monolit): hepsi tek bir kod tabanında, tek bir veritabanı, tek bir sunucu.

Avantaj: basit. Dezavantaj: büyüdükçe kaos.

  • 1000 geliştirici aynı kod tabanında.
  • Bir özellik değişikliği tüm uygulamayı etkiler.
  • Tek bir hata her şeyi düşürür.
  • Ölçeklemek zor: tüm sistem ölçeklenir.

Microservices çözümü

Uygulamayı küçük, bağımsız servislere ayır:

  • Ürün Servisi: ayrı kod, ayrı DB, ayrı takım.
  • Sepet Servisi.
  • Ödeme Servisi.
  • ...

Her servis kendi içinde tam, bağımsız deploy edilir.

Tanım (Fowler, 2014)

Martin Fowler & James Lewis: microservices = ...

  • Küçük, tek bir iş alanına odaklı servisler.
  • Akıllı endpoint, aptal pipe: iletişim basit (HTTP/REST, gRPC).
  • Bağımsız deploy.
  • Decentralized: her takım kendi teknoloji seçimi.
  • Otomatik test/deployment.
  • Hata toleransı: bir servis düşse de sistem çalışır.

Pros

  • Ölçeklenebilirlik: yalnız yüksek yük yaşayan servisleri ölçekle.
  • Takım özerkliği: her takım kendi servisini yönetir.
  • Teknoloji çeşitliliği: Python, Java, Go beraber.
  • Hata izolasyonu: bir servis çökse de diğerleri çalışır.
  • Hızlı deploy: küçük servis = hızlı CI/CD.

Cons

  • Karmaşıklık: dağıtık sistem zorlukları.
  • Network latency: artık her şey API çağrısı.
  • Tutarlılık zor: distributed transactions.
  • Operasyonel yük: 100 servis = 100 monitoring.
  • DevOps olgunluğu şart.

Mimari bileşenler

API Gateway

Tek giriş noktası. Yönlendirme, kimlik doğrulama, rate limiting.
Araçlar: Kong, NGINX, AWS API Gateway.

Service Discovery

Servisler birbirini dinamik bulur (sabit IP yok).
Araçlar: Consul, etcd, Eureka.

Service Mesh

Servis-servis trafiği yönetimi: retry, circuit breaker, observability.
Araçlar: Istio, Linkerd.

Container Orchestration

Kubernetes baskın.

Message Broker

Asenkron iletişim. Kafka, RabbitMQ.

Distributed Tracing

Bir isteğin onlarca servisten geçişini izle.
Araçlar: Jaeger, Zipkin, OpenTelemetry.

Centralized Logging

Tüm servislerin log'u tek yerde.
Araçlar: ELK (Elasticsearch + Logstash + Kibana), Splunk, Loki.

Patterns

Saga

Distributed transactions yerine kademeli adımlar + telafi.

Circuit Breaker

Bir servis sürekli hata veriyorsa isteği kesilir, kullanıcıya hızlı hata.

Bulkhead

Servisler arasında kaynak izolasyonu.

CQRS + Event Sourcing

Yazma ve okuma ayrı, durum olaylardan türetilir.

Domain-Driven Design (DDD)

Microservice sınırını çizmek zor. Eric Evans 2003 DDD kitabı:

  • Bounded context: bir iş alanı.
  • Ubiquitous language: ortak terimler.
  • Aggregate: işlem birimi.

Microservice bir bounded context = doğru sınır.

Netflix vakası

Netflix 2008'de monolitten microservice'e geçti. Sebepleri:

  • Veri merkezi yangını.
  • Bulut'a geçiş.
  • Ekip ölçeklendirme.

Sonuç: 1000+ microservice. Chaos Monkey ile dayanıklılık testi.

Netflix mimarisi modern microservice dürüstü.

Modern eleştiriler

Monolith ilk

Birçok şirket: "Mikroservis çok erken". Önce monolit yap, gerçekten sınırlar belirginleşince ayır.

Distributed monolith

Microservices yapıyorum sandığın ama servisler çok bağımlı — distributed monolith.

Microservices fatigue

Çok karmaşık geldiğinde monolit'e geri dönen şirketler (Segment, Amazon Prime Video).

Modern alternatifler

Modular monolith

Tek deploy ama iç modüler yapı.

Macroservices

Microservices arası, daha az ama daha büyük.

Function-as-a-Service (FaaS)

AWS Lambda gibi: sadece fonksiyon.

Türk endüstri örnekleri

  • Trendyol: 2000+ microservice.
  • Garanti BBVA: kurumsal microservice.
  • Yemeksepeti: tam microservice.
  • Hepsiburada: hybrid (microservice + bazı monolit).

Kim için iyi?

  • Büyük ekip (50+ geliştirici).
  • Sık deploy ihtiyacı.
  • Yüksek trafik.
  • DevOps olgunluğu.

Kim için kötü?:

  • Küçük ekip.
  • Henüz domain belirsiz.
  • DevOps zayıf.

Felsefe

Microservices temel mesajı: "Conway's Law'a uy: yazılım mimarisi organizasyon yapısını yansıtır".

Organizasyon küçük takımlardan oluşuyorsa, mimari de küçük bağımsız servislerden oluşmalı.

Kapanış

Microservices modern bulut çağının en popüler mimari deseni ama gümüş kurşun değil. Doğru durumda muhteşem, yanlış durumda felaket.

Bir yazılım mimarının olgunluk işareti: "Microservices uygulayalım mı?" sorusundan önce "Buna ihtiyacımız var mı?" sormak.

Etiketler

microservicesmimarimonolithAPI gatewayservice mesh

Kendinizi Test Edin

Cevaplarınız profilinizde istatistik olarak saklanır.

1. Microservices ile monolit farkı?

2. Service Mesh ne yapar?

3. Conway's Law?

4. Distributed monolith?

5. Ne zaman uygulanmalı?