Sidecar Pattern: Envoy, Dapr ve Service Mesh
Mikroservis mimarisinde her servis, kendi iş mantığına odaklanmalıdır. Ancak servisler arası iletişim, gözlemlenebilirlik, güvenlik ve dayanıklılık gibi yatay kesen endişeler (cross-cutting concerns) her serviste tekrar tekrar kodlanırsa, hem geliştirme yükü artar hem de teknoloji bağımlılığı oluşur. İşte Sidecar Pattern, bu sorunu zarif bir şekilde çözer: Yardımcı yetenekleri ayrı bir süreçte (sidecar) çalıştırarak, ana uygulamayı temiz ve odaklı tutar .
1. Sidecar Pattern Nedir?
Sidecar Pattern, bir uygulamanın temel iş mantığını içeren ana sürecin yanında, aynı yaşam döngüsünü paylaşan yardımcı bir süreç veya konteyner çalıştırma desenidir . Motosiklet yan sepetine (sidecar) benzetilen bu desen, uygulamaya ayrılmaz bir şekilde bağlıdır ancak ondan bağımsız olarak çalışır .
Temel Özellikler:
-
Yaşam Döngüsü Paylaşımı: Sidecar, ana uygulama ile birlikte başlar ve birlikte sonlanır .
-
Dil Bağımsızlığı: Sidecar, hangi dilde yazıldığından bağımsız olarak her uygulamayla çalışabilir .
-
Düşük Gecikme: Aynı host veya pod üzerinde çalıştığı için iletişim gecikmesi minimumdur .
Çözülen Problem: Monolitik yapıda yatay kesen endişeler aynı süreçte çalışır ancak izolasyon yoktur. Ayrı servisler olarak çalıştırıldıklarında ise dil bağımlılığı ve gecikme sorunları ortaya çıkar. Sidecar, bu ikisinin arasında bir denge kurar .
2. Envoy: Yüksek Performanslı Sidecar Proxy
Envoy, Lyft tarafından geliştirilen, yüksek performanslı bir L7 proxy ve iletişim veriyoludur. Sidecar Pattern'ın en yaygın implementasyonudur ve özellikle Service Mesh mimarisinin veri düzlemini (data plane) oluşturur .
Envoy'un Çalışma Prensibi:
Envoy, gelen istekleri network filter chain ve HTTP filter chain üzerinden işler. HTTP/2 codec'i (nghttp2 tabanlı) bağlantıyı çoklar (multiplexing), her istek bağımsız bir stream olarak işlenir . Router filtresi, route seçimini tamamlar, yük dengeleme yapar ve upstream bağlantı havuzunu yönetir .
Envoy'un Sağladığı Yetenekler:
-
Trafik Yönetimi: Dinamik routing, canary deployment, timeout, retry .
-
Güvenlik: mTLS, kimlik doğrulama, yetkilendirme .
-
Gözlemlenebilirlik: Metrikler, distributed tracing, loglar .
-
Dayanıklılık: Circuit breaker, retry, timeout .
3. Dapr: Uygulama Geliştiriciler için Sidecar Runtime
Dapr (Distributed Application Runtime), uygulama geliştiricilerinin dağıtık sistem karmaşıklığını yönetmesini kolaylaştıran bir sidecar runtime'ıdır . CNCF (Cloud Native Computing Foundation) projesidir.
Dapr Sidecar (daprd) Nasıl Çalışır?
Dapr, uygulamanızın yanında daprd adında ayrı bir süreç olarak çalışır. Uygulamanız, Dapr'ın building block API'lerini yerel HTTP veya gRPC üzerinden çağırır .
csharp
// Dapr State Management API'sini çağırma (HTTP)
POST http://localhost:3500/v1.0/state/statestore
{
"key": "order-123",
"value": { "status": "shipped" }
}
Dapr'ın Sağladığı Building Block'lar:
-
Service Invocation: Servisler arası çağrı (keşif, retry, mTLS dahil) .
-
State Management: Durum yönetimi (Redis, PostgreSQL, DynamoDB gibi arka uçlarla) .
-
Pub/Sub: Yayınla-abone ol mesajlaşma.
-
Secrets Management: Gizli bilgi yönetimi.
-
Observability: Dağıtık izleme ve metrikler .
Dapr'ın Temel Faydası: Geliştirici sadece API'yi çağırır; arka plandaki teknoloji (Redis mi, PostgreSQL mi?) platform ekibi tarafından yönetilir. Teknoloji değişse bile uygulama kodu değişmez .
4. Service Mesh: Sidecar'ların Orkestrasyonu
Service Mesh (Servis Ağı), sidecar proxy'leri kullanarak servisler arası iletişimi yöneten bir altyapı katmanıdır . İki bileşenden oluşur:
| Bileşen | Görevi | Örnek |
|---|---|---|
| Control Plane (Kontrol Düzlemi) | Yapılandırma, politika, sertifika yönetimi, servis keşfi | Istiod, Linkerd Controller |
| Data Plane (Veri Düzlemi) | Her pod'a enjekte edilen sidecar proxy'ler; trafiği yönetir | Envoy, Linkerd-proxy |
Service Mesh'in Sağladığı Yetenekler (Kod Değişikliği Olmadan):
-
mTLS: Servisler arası şifreli iletişim .
-
Trafik Yönetimi: Dinamik routing, A/B testi, canary deployment .
-
Dayanıklılık: Retry, timeout, circuit breaker .
-
Gözlemlenebilirlik: Metrikler, tracing .
Popüler Service Mesh Çözümleri: Istio (Envoy tabanlı), Linkerd, Consul .
Kod Tabanlı vs. Altyapı Tabanlı Dayanıklılık:
Polly gibi kod tabanlı çözümler belirli bir HTTP isteğine odaklanır ancak yüzlerce eşzamanlı isteği yönetmek zordur. Linkerd gibi altyapı tabanlı çözümler ise tüm cluster'ı görerek sistemik kararlar alır; örneğin, hedef servise maksimum %20 ek yük bindirecek şekilde retry yapar .
5. .NET Ekosisteminde Sidecar Kullanımı
Dapr ile .NET:
Dapr, .NET SDK'sı sunar. Uygulamanız Dapr sidecar'ına yerel HTTP/gRPC üzerinden bağlanır.
csharp
// Dapr .NET SDK ile State Management
var daprClient = new DaprClientBuilder().Build();
await daprClient.SaveStateAsync("statestore", "order-123", order);
Kubernetes'te Dapr Sidecar Injection:
Dapr, Kubernetes'te dapr-sidecar-injector servisi aracılığıyla pod'lara otomatik olarak daprd konteynerini enjekte eder. dapr.io/enabled: "true" annotation'ı yeterlidir .
yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: order-service
spec:
template:
metadata:
annotations:
dapr.io/enabled: "true"
dapr.io/app-id: "order-service"
dapr.io/app-port: "5000"
Kubernetes Native Sidecar Desteği:
Kubernetes, native sidecar konteynerlerini destekler. Bu, sidecar'ın ana uygulamadan önce başlamasını ve sonra sonlanmasını garanti eder; böylece shutdown sırasında sidecar'ın erken kapanması önlenir .
6. Ne Zaman Sidecar Kullanmalı?
Kullanın:
-
Uygulamanız farklı dillerde yazılmış servislerden oluşuyorsa .
-
Yatay kesen endişeleri (gözlemlenebilirlik, güvenlik, dayanıklılık) merkezi olarak yönetmek istiyorsanız .
-
Servisler arası iletişimi şeffaf bir şekilde güvence altına almak istiyorsanız (mTLS) .
-
Aynı host'ta çalışan ancak bağımsız güncellenebilir bir bileşen istiyorsanız .
Kullanmayın:
-
Uygulamanız küçük ve basitse (kaynak maliyeti faydayı aşabilir) .
-
Çok düşük gecikme gerektiren, sık iletişimli bileşenler varsa (sidecar ek yük getirir) .
-
Fonksiyonellik bir kütüphane olarak daha verimli uygulanabiliyorsa .
7. En İyi Pratikler
-
Dil-Agnostik İletişim: Sidecar ile uygulama arasında HTTP/gRPC gibi standart protokoller kullanın .
-
Kaynak Limitleri Belirleyin: Her sidecar için CPU ve bellek limitleri tanımlayın.
-
Yaşam Döngüsünü Yönetin: Kubernetes native sidecar desteğini kullanarak başlatma/sonlandırma sırasını garanti edin .
-
Platform Ekibini Ayırın: Dapr gibi çözümlerde, arka uç teknolojilerini platform ekibi yönetir; geliştirici sadece API'yi çağırır .
-
Hibrit Yaklaşım: Altyapı tabanlı dayanıklılık (Linkerd) ile kod tabanlı dayanıklılığı (Polly) birlikte kullanın: Linkerd cluster seviyesinde, Polly ise iş mantığı seviyesinde koruma sağlar .
Sonuç
Sidecar Pattern, mikroservis mimarisinde yatay kesen endişeleri ana uygulamadan ayırarak hem geliştirici verimliliğini artırır hem de operasyonel tutarlılık sağlar. Envoy, Service Mesh'lerin veri düzleminde yüksek performanslı bir proxy olarak görev yaparken; Dapr, uygulama geliştiricilere basit building block API'leri sunar. Service Mesh, sidecar'ları control plane aracılığıyla orkestre ederek mTLS, trafik yönetimi ve gözlemlenebilirlik gibi yetenekleri kod değişikliği olmadan sunar. .NET geliştiricileri, Dapr SDK'sı ve Kubernetes native sidecar desteği ile bu desenden etkin bir şekilde yararlanabilir. Unutmayın: Sidecar, bir araçtır; doğru kullanıldığında güçlüdür, gereksiz yere kullanıldığında ise kaynak israfına yol açar.