Mikroservis Mimarisi & Servis Keşfi 5 dk okuma 3 okunma

Service Discovery: Consul, Eureka ve Kubernetes DNS

Service Discovery (Servis Keşfi), mikroservis mimarilerinde dinamik olarak ölçeklenen servislerin birbirini otomatik olarak bulmasını sağlayan mekanizmadır. Bu yazıda, en yaygın üç çözüm (HashiCorp Consul, Netflix Eureka ve Kubernetes DNS) karşılaştırılır; her birinin çalışma prensipleri, avantajları, dezavantajları, .NET entegrasyonu ve hangi senaryoda hangisinin tercih edilmesi gerektiği ele alınır.

Service Discovery: Consul, Eureka ve Kubernetes DNS

Service Discovery: Consul, Eureka ve Kubernetes DNS

Mikroservis mimarisinde, servis instance'ları dinamik olarak oluşturulur, ölçeklenir ve yok edilir. IP adresleri ve portlar sürekli değişir. Geleneksel yaklaşımdaki sabit IP veya hostname kullanımı bu ortamda işe yaramaz. İşte Service Discovery (Servis Keşfi), bu sorunu çözer: Servisler bir servis kataloğuna (service catalog) kaydolur ve diğer servisler bu katalogdan güncel adres bilgilerini sorgular .


1. Service Discovery Nedir ve Neden Gereklidir?

Servis keşfi, bir ağdaki servisleri keşfetme, izleme ve sağlık durumlarını kontrol etme sürecidir. Servisler, kendilerini bir servis kataloğuna kaydeder ve bu katalog, servisler arası iletişim için tek doğruluk kaynağı (single source of truth) olarak işlev görür .

Servis Keşfinin Sağladığı Faydalar:

  • Dinamik IP ve Port Keşfi: Servis instance'larının IP adresleri ve portları değişse bile iletişim kesintisiz devam eder.

  • Yatay Ölçekleme Kolaylığı: Yeni instance'lar otomatik olarak kataloğa eklenir.

  • Sağlık Kontrolleri: Sağlıksız instance'lar otomatik olarak katalogdan çıkarılır.

  • Yük Dengeleme: İstekler sağlıklı instance'lar arasında dağıtılır .


2. İki Temel Servis Keşfi Modeli

Servis keşfi iki ana yaklaşımla uygulanır:

Model Açıklama Temsilci
Client-Side Discovery İstemci, servis kataloğunu sorgular ve hangi instance'a istek göndereceğine kendisi karar verir. Netflix Eureka
Server-Side Discovery İstemci, bir aracıya (load balancer/proxy) istek gönderir; aracı, katalogdan uygun instance'ı seçer. Kubernetes Service, Consul

Client-side discovery, istemciye daha fazla kontrol ve esneklik sunar; ancak her istemcinin keşif mantığını bilmesi gerekir. Server-side discovery ise istemciyi basitleştirir, ancak bir aracı katmanı gerektirir .


3. Consul (HashiCorp)

Genel Bakış:
Consul, HashiCorp tarafından geliştirilen, platformdan bağımsız bir servis ağı (service networking) çözümüdür. Servis keşfi, sağlık kontrolü, KV (Key-Value) depolama ve servis mesh özelliklerini bir arada sunar .

Çalışma Prensibi:

  • Her düğümde (node) bir Consul Agent çalışır.

  • Servisler, Agent üzerinden kendilerini kaydeder ve sağlık kontrollerini tanımlar.

  • Consul Server'ları, Raft konsensüs algoritması ile yüksek erişilebilirlik sağlar.

  • Servisler, DNS veya HTTP API üzerinden katalogdan sorgulanabilir .

Sağlık Kontrol Türleri:
Consul, HTTP, TCP, UDP, gRPC, Docker, Script ve TTL gibi çok çeşitli sağlık kontrolü türlerini destekler .

Avantajları:

  • Platformdan bağımsız (VM, container, serverless).

  • Çoklu veri merkezi (multi-datacenter) desteği.

  • Servis mesh entegrasyonu ile sıfır güven mimarisi.

  • Zengin sağlık kontrolü seçenekleri.

Dezavantajları:

  • Kurulum ve operasyonel karmaşıklık.

  • Öğrenme eğrisi.

Ne Zaman Kullanılır?

  • Çoklu bulut (multi-cloud) veya hibrit ortamlar.

  • Kubernetes ve VM'lerin birlikte kullanıldığı sistemler.

  • Servis mesh ihtiyacı olan projeler .


4. Netflix Eureka

Genel Bakış:
Eureka, Netflix tarafından geliştirilen, özellikle Spring Cloud ekosisteminde yaygın kullanılan bir servis keşfi çözümüdür. Java ekosistemi için tasarlanmıştır ancak Steeltoe aracılığıyla .NET'te de kullanılabilir .

Çalışma Prensibi:

  • Servisler, Eureka Server'a kaydolur.

  • Her servis, periyodik olarak heartbeat (kalp atışı) göndererek canlı olduğunu bildirir (varsayılan 30 saniye).

  • İstemciler, Eureka Server'dan servis listesini çeker ve kendi yük dengelemelerini yapar (client-side discovery).

  • Sağlık kontrolleri varsayılan olarak heartbeat ile yapılır; ancak Spring Boot Actuator entegrasyonu ile daha detaylı sağlık bilgisi yayınlanabilir .

Avantajları:

  • Java/Spring ekosistemi için olgun ve yaygın.

  • Client-side load balancing ile esneklik.

  • Zone-aware routing (aynı bölgedeki servisleri tercih etme).

Dezavantajları:

  • Java ekosistemine sıkı bağımlılık.

  • Sağlık kontrolü mekanizması (heartbeat) sınırlı.

  • 2026 itibarıyla yeni projelerde Kubernetes DNS'e kıyasla daha az tercih edilmektedir .

Ne Zaman Kullanılır?

  • Spring Cloud tabanlı Java mikroservis projeleri.

  • Kubernetes ve VM tabanlı uygulamaların birlikte çalıştığı durumlar.

  • Client-side load balancing ihtiyacı olan sistemler .


**5. Kubernetes DNS

Genel Bakış:
Kubernetes, container orchestration platformu olarak yerleşik servis keşfi sunar. Kubernetes Service ve DNS mekanizması, platform üzerinde çalışan uygulamalar için otomatik servis keşfi sağlar .

Çalışma Prensibi:

  • Her Service kaynağı, bir ClusterIP (sanal IP) alır.

  • Kubernetes, kube-dns (CoreDNS) aracılığıyla her Service için bir DNS kaydı oluşturur.

  • DNS kaydı formatı: my-svc.my-namespace.svc.cluster-domain.example

  • Aynı namespace'teki uygulamalar, sadece servis adını kullanarak erişebilir: http://my-service

  • Farklı namespace'ler için: my-service.other-namespace .

  • Headless Service kullanıldığında, DNS kaydı tüm Pod IP'lerini döner ve istemci kendi load balancing'ini yapabilir .

Avantajları:

  • Sıfır konfigürasyon: Kubernetes, DNS yönetimini otomatik yapar.

  • Dil bağımsız: Her programlama dili standart DNS kullanır.

  • RBAC uyumlu: Kubernetes güvenlik politikalarıyla entegre.

  • Az bağımlılık: Ek bir servis keşfi aracı gerekmez .

Dezavantajları:

  • Kubernetes'e bağımlılık: Sadece Kubernetes ortamında çalışır.

  • Çoklu cluster desteği yok: Farklı cluster'lar arasında servis keşfi yapılamaz.

  • Client-side load balancing sınırlı: ClusterIP, kube-proxy üzerinden server-side load balancing yapar.

Ne Zaman Kullanılır?

  • Tüm uygulamalar Kubernetes üzerinde çalışıyorsa.

  • Ek bir servis keşfi altyapısı kurmak istenmiyorsa.

  • Standart DNS tabanlı keşif yeterliyse .


6. Karşılaştırma Tablosu

Kriter Consul Eureka Kubernetes DNS
Platform Platformdan bağımsız Java/Spring odaklı Kubernetes'e özel
Keşif Modeli Server-side (DNS/API) Client-side Server-side (ClusterIP)
Sağlık Kontrolü Çok zengin (HTTP, TCP, gRPC, Script) Heartbeat (temel) Readiness/Liveness Probe
Çoklu Veri Merkezi ✅ Evet Sınırlı ❌ Hayır
Servis Mesh ✅ Evet ❌ Hayır Istio/Linkerd ile
Dil Desteği Tüm diller Java (Steeltoe ile .NET) Tüm diller
Kurulum Karmaşıklığı Orta-Yüksek Düşük (Spring) Sıfır (yerleşik)
Kullanım Alanı Hibrit/çoklu bulut Spring Cloud Saf Kubernetes

7. .NET Ekosisteminde Service Discovery

.NET geliştiricileri için servis keşfi entegrasyonu sunan başlıca araçlar:

  • Steeltoe: .NET uygulamalarını Spring Cloud ve Cloud Foundry ekosistemiyle entegre eden açık kaynak kütüphane. Netflix Eureka ve HashiCorp Consul ile servis keşfini destekler .

  • .NET Aspire: Microsoft'un bulut-yerel uygulama geliştirme platformu. Servis keşfi soyutlaması sunar ve Kubernetes, Consul gibi sağlayıcılarla çalışır. Yerel geliştirmede ve Kubernetes'te aynı kodun kullanılmasını sağlar .

  • Microsoft.Extensions.ServiceDiscovery: Aspire ile gelen servis keşfi kütüphanesi. DNS ve DNS SRV tabanlı çözümleme yapabilir .

Örnek (Aspire ile):

csharp

// ServiceDefaults projesinde
builder.Services.AddServiceDiscovery();

// HttpClient yapılandırması
builder.Services.ConfigureHttpClientDefaults(http =>
{
    http.AddServiceDiscovery();
    http.AddStandardResilienceHandler();
});

// Kullanım
builder.Services.AddHttpClient<CatalogServiceClient>(client =>
{
    client.BaseAddress = new Uri("http://catalog-service");
});

8. En İyi Pratikler

  1. Platformunuza Uygun Seçim Yapın: Saf Kubernetes ortamındaysanız Kubernetes DNS en basit çözümdür. Hibrit ortamlar için Consul daha uygundur.

  2. Sağlık Kontrollerini İhmal Etmeyin: Servis keşfinin güvenilirliği, sağlık kontrollerinin doğruluğuna bağlıdır.

  3. DNS Cache Süresine Dikkat Edin: Kubernetes DNS'te IP adreslerini uzun süre cache'lemeyin; adresler stabil değildir .

  4. Client-Side Load Balancing Düşünün: Eureka gibi client-side çözümler, istemciye daha fazla kontrol verir.

  5. Observability Entegrasyonu: Servis keşfi katmanını izleyin; hangi servislerin kayıtlı olduğunu ve sağlık durumlarını takip edin.

Sonuç

Service Discovery, mikroservis mimarisinin olmazsa olmazıdır. Consul, platformdan bağımsız, zengin özellikli ve hibrit ortamlar için idealdir. Eureka, Spring Cloud ekosisteminde olgunlaşmış bir çözümdür ancak Kubernetes çağında yerini DNS tabanlı çözümlere bırakmaktadır. Kubernetes DNS ise saf Kubernetes ortamları için sıfır konfigürasyonlu, dil bağımsız ve RBAC uyumlu bir çözüm sunar. .NET geliştiricileri için Steeltoe (Eureka/Consul) ve .NET Aspire (soyutlanmış servis keşfi) güçlü seçeneklerdir. Doğru seçim, platformunuza ve operasyonel ihtiyaçlarınıza bağlıdır.

Tüm yazılar Soru ya da yorumun mu var? Yaz