Service Mesh Nedir? Mikro Servis Ağ Yönetimi

Mikro servisleriniz arasındaki iletişim karmaşıklaşıyor mu? Her servise retry, timeout, circuit breaker mu ekliyorsunuz? Service Mesh ile bu altyapıyı servislerden ayırın, merkezi bir ağ katmanında yönetin.

Tanım

Service Mesh, mikro servisler arasındaki ağ iletişimini yöneten bir altyapı katmanıdır. Her servisin yanına bir proxy (sidecar) ekleyerek, servisin iş mantığına dokunmadan trafik yönetimi, güvenlik ve gözlemlenebilirlik sağlar.

Service Mesh Olmadan:
Service A ──(retry, timeout, TLS kodu)──→ Service B

Service Mesh İle:
Service A → [Sidecar Proxy] ──→ [Sidecar Proxy] → Service B
              Envoy                  Envoy
              (retry, timeout, mTLS otomatik)

Neden Service Mesh?

| Sorun | Service Mesh Çözümü | |-------|-------------------| | Her servise retry/timeout kodu | Proxy'de otomatik | | Servisler arası şifreleme | mTLS otomatik | | Hangi servis kime istek atıyor? | Dağıtık tracing | | Canary deployment | Traffic splitting | | A/B testing | Header-based routing |

Temel Bileşenler

Data Plane

Her servisin yanında çalışan sidecar proxy (genellikle Envoy). Tüm gelen ve giden ağ trafiğini yakalar.

Control Plane

Proxy'leri yapılandıran ve yöneten merkezi katman (Istiod, Linkerd control plane).

                    ┌──────────────┐
                    │ Control Plane│
                    │   (Istiod)   │
                    └──────┬───────┘
                           │ config
              ┌────────────┼────────────┐
              ▼            ▼            ▼
         [Envoy]      [Envoy]      [Envoy]
         Service A    Service B    Service C

Istio ile Traffic Management

Canary Deployment

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-app
spec:
  hosts:
    - my-app
  http:
    - route:
        - destination:
            host: my-app
            subset: v1
          weight: 90
        - destination:
            host: my-app
            subset: v2
          weight: 10

Retry ve Timeout

http:
  - route:
      - destination:
          host: payment-service
    retries:
      attempts: 3
      perTryTimeout: 2s
    timeout: 10s

Circuit Breaker

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: payment-service
spec:
  host: payment-service
  trafficPolicy:
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 60s

mTLS (Mutual TLS)

Service Mesh, servisler arası trafiği otomatik olarak şifreler:

Service A → [TLS şifreleme] → Ağ → [TLS çözme] → Service B
             Sidecar                  Sidecar

Sertifika oluşturma, dağıtma ve yenileme otomatiktir.

Service Mesh Araçları

| Araç | Proxy | Öne Çıkan | |------|-------|-----------| | Istio | Envoy | En popüler, zengin özellikler | | Linkerd | Rust proxy | Hafif, basit, hızlı | | Consul Connect | Envoy | Multi-platform, HashiCorp | | AWS App Mesh | Envoy | AWS entegrasyonu |

Ne Zaman Service Mesh?

✅ Kullanın:

• 10+ mikro servisiniz varsa
• Servisler arası güvenlik (mTLS) gerekiyorsa
• Canary/blue-green deployment yapıyorsanız
• Dağıtık tracing ve observability istiyorsanız

❌ Kullanmayın:

• Az sayıda servis varsa (<5)
• Monolitik mimaride
• Ekipte Kubernetes deneyimi yoksa
• Kaynak (CPU/RAM) kısıtlıysa

Best Practices

1. Yavaş yavaş benimseyin — Önce gözlemlenebilirlik, sonra trafik yönetimi
2. Sidecar kaynak limitlerini ayarlayın — Her proxy CPU/RAM tüketir
3. mTLS'i zorunlu kılın — STRICT mode kullanın
4. Tracing entegrasyonu — Jaeger/Zipkin ile dağıtık izleme
5. Upgrade planı — Service mesh sürümlerini düzenli güncelleyin

Sonuç

Service Mesh, mikro servis mimarisinin ağ karmaşıklığını soyutlayan güçlü bir araçtır. Güvenlik, trafik yönetimi ve gözlemlenebilirliği merkezi bir katmanda toplar. Ancak karmaşıklık ve kaynak maliyeti getirir — gerçekten ihtiyacınız olduğundan emin olun.

Service mesh ve mikro servis mimarisini LabLudus platformunda öğrenin.