Microservices Mimarisi: Tasarım, İletişim ve Dağıtım
Microservices mimarisi, büyük uygulamaları küçük, bağımsız servisler halinde böler. Bu rehberde microservices tasarım ilkelerini, servisler arası iletişimi ve dağıtım stratejilerini anlatıyoruz.
Son güncelleme:Microservices Nedir?
Microservices, tek bir büyük uygulamayı (monolith) küçük, bağımsız ve deploy edilebilir servisler halinde bölen bir mimari yaklaşımdır.
Her servis, belirli bir iş fonksiyonunu (business capability) yerine getirir. User service, order service, payment service gibi.
Bağımsız deploy: Her servis bağımsız olarak deploy edilebilir. Bir servisteki değişiklik, diğer servisleri etkilemez.
Teknoloji çeşitliliği: Her servis farklı teknoloji stack'i kullanabilir. Node.js, Python, Go, Java aynı sistemde birlikte çalışabilir.
Servisler Arası İletişim
Synchronous (senkron): REST API veya gRPC ile doğrudan iletişim. Basit ama coupling (bağımlılık) oluşturur.
Asynchronous (asenkron): Message queue (RabbitMQ, Kafka, SQS) ile event-driven iletişim. Loose coupling sağlar.
API Gateway: Tüm servislerin tek giriş noktası. Routing, authentication, rate limiting, load balancing yapar.
Service mesh: Servisler arası iletişimi yöneten altyapı katmanı. Istio, Linkerd gibi araçlar traffic management, observability, security sağlar.
Circuit breaker: Servis arızalarında cascade failure'ı önler. Hystrix veya resilience4j ile implement edilir.
Veri Yönetimi
Database per service: Her servis kendi veritabanına sahiptir. Bu, servis bağımsızlığını korur.
Event sourcing: Durum değişikliklerini event olarak saklayın. Event store'dan durumu yeniden oluşturabilirsiniz.
CQRS (Command Query Responsibility Segregation): Okuma ve yazma işlemlerini ayırın. Farklı veri modelleri ve optimizasyonlar kullanın.
Saga pattern: Distributed transaction'ları yönetin. Choreography (event-based) veya orchestration (central coordinator) ile.
Data consistency: Eventual consistency kabul edin. Strong consistency yerine eventual consistency, microservices'da daha pratiktir.
Dağıtım ve Ölçekleme
Containerization: Her servisi Docker container olarak paketleyin. Kubernetes ile orchestration yapın.
Auto-scaling: Servis yüküne göre otomatik ölçekleme. Kubernetes HPA (Horizontal Pod Autoscaler) kullanın.
Service discovery: Servisler birbirini dinamik olarak bulsun. Consul, Eureka veya Kubernetes DNS kullanın.
Load balancing: Servis instance'ları arasında yükü dağıtın. Round-robin, least connections veya consistent hashing algoritmaları.
Blue-green deployment: Sıfır downtime deploy. Yeni versiyonu paralel ortamda çalıştırın, trafik geçişini yapın.
İzleme ve Observability
Distributed tracing: İstekleri servisler arası takip edin. Jaeger, Zipkin veya OpenTelemetry kullanın.
Centralized logging: Tüm servis loglarını merkezi bir yere (ELK Stack, Loki) toplayın. Correlation ID ile istek takibi.
Metrics: Servis metriklerini toplayın (Prometheus) ve görselleştirin (Grafana). Latency, error rate, throughput izleyin.
Health checks: Her servis health endpoint'i (/health) sunmalı. Kubernetes liveness ve readiness probe'ları ile entegre edin.
Alerting: Kritik metrikler için alert kuralları tanımlayın. PagerDuty veya Opsgenie ile on-call yönetimi.
Mikroservis Anti-Pattern'leri
Distributed monolith: Servisler birbirine sıkı bağlı (tight coupling). Değişiklik yapmak zor. Bağımsız deploy imkansız.
Shared database: Tüm servisler aynı veritabanını kullanır. Bu, servis bağımsızlığını yok eder.
Chatty services: Servisler arası çok fazla network çağrısı. Latency artar, performans düşer.
Nano-services: Çok küçük servisler. Overhead (network, serialization) faydayı aşar.
Premature optimization: Monolith'ten başlamadan microservices'e geçmek. Önce monolith ile başlayın, ihtiyaç olduğunda bölün.