1. GİRİŞ

Dağıtık sistemler ve mikroservis mimarileri büyüdükçe uygulama bileşenlerinin birbirlerini bulması ve güvenilir biçimde iletişim kurması karmaşıklaşır. "Service discovery" (hizmet keşfi), bu karmaşıklığın merkezindeki problemdir: bir servis diğer servislerin adreslerini, durumlarını ve erişim bilgilerini nasıl öğrenir? Statik yapılandırma küçük sistemlerde işe yararken, modern bulut‑native uygulamalarda instance'ların kısa ömürlü olması (ephemeral), auto‑scaling ve dinamik ağ topolojileri nedeniyle otomatik keşif gerekli hale gelmiştir.

Bu konu neden bugün önemli?

• Bulut, konteyner orkestrasyonları ve serverless modeller service instance'larını dinamik hale getirdi.
• Global dağıtık uygulamalar, düşük gecikme için lokasyon bazlı routing ve traffic steering gerektirir.
• Observability, otomatik failover ve canary release gibi operasyonel yaklaşımlar güvenilir keşif olmadan zor uygulanır.

Kimler için önemli?

• Yazılım mimarları ve backend mühendisleri
• Platform mühendisleri, SRE ve DevOps ekipleri
• Kubernetes ve container altyapı yöneticileri

Hangi problemleri çözüyor?

• Dinamik IP/port değişimleriyle başa çıkmak
• Sağlıklı instance'lara yönlendirme ve load balancing sağlamak
• Coğrafi dağıtım, canary ve blue/green deploy süreçlerinde trafik yönlendirmek

2. KAVRAMSAL TEMELLER

2.1 Service Discovery nedir?

Service discovery, bir tüketici servisinin (client) bir sağlayıcı servisin (server) konumu ve erişim metadatasını (IP, port, proto, tags, health) dinamik olarak öğrenmesini sağlayan mekanizmadır. Keşif mekanizması; registry, health checks, watchers ve client library'leri veya altyapı bileşenleri üzerinden çalışır.

2.2 Temel bileşenler

• Service Registry: Kayıtlı hizmetlerin merkezi veya dağıtık deposu (Consul, etcd, Zookeeper, Eureka).
• Health Checks: Hizmetin canlılık ve hazır olma durumunu belirleyen periyotlu kontroller.
• Discovery Mechanism: Client‑side polling, server‑side proxy, DNS lookup ya da event‑driven watchers.
• Metadata & Tags: Bölge, sürüm, instance tipi, canary etiketi gibi routing kararlarında kullanılan bilgiler.

2.3 Neden farklı discovery modelleri var?

Farklı uygulama gereksinimleri ve altyapı kısıtları client‑side discovery, server‑side discovery, DNS tabanlı veya mesh‑tabanlı yaklaşımları gerektirir. Her model performans, operasyonsellik, güvenilirlik ve dağıtım kolaylığı arasında trade‑off taşır.

3. NASIL ÇALIŞIR? — MODELLER VE TEKNİK DETAYLAR

3.1 Client‑side discovery

Client‑side discovery'de client (istemci uygulama) doğrudan service registry'ye (örn. Consul, Eureka) sorgu yapar, sağlıklı instance'ların listesini alır ve kendi içinde load balancing uygular. Bu model, basitlik ve düşük gecikme avantajı sağlar çünkü client doğrudan ve yerel karar verir. Dezavantajı, her client'ın discovery logic'ini içermesi nedeniyle kod tekrarları ve registry'ye yüksek sorgu yoğunluğu yaratmasıdır.

Avantajlar

• Düşük latency: doğrudan backend instance'a bağlanılır.
• Esneklik: client özel load balancing stratejileri uygulayabilir.

Dezavantajlar

• Registry yükü ve thundering‑herd riskleri.
• Client tarafı complexity ve library yönetimi.

3.2 Server‑side discovery (API Gateway / Load Balancer)

Server‑side discovery modelinde client, merkezi bir load balancer veya API gateway'e (ör. Envoy, NGINX, AWS ALB) istek gönderir; gateway/service proxy ise registry'yi sorgulayarak istekleri uygun backend instance'larına yönlendirir. Bu model client'ları basitleştirir ve merkezi politika uygulamayı kolaylaştırır. Dezavantajı, gateway'in SPOF veya darboğaz olma riskidir; bu yüzden yüksek erişilebilirlik ve yanıt hızı önemlidir.

Avantajlar

• Client'lar sade kalır; discovery logic merkezi yönetilir.
• Güvenlik ve observability politikaları merkezi olarak uygulanabilir.

Dezavantajlar

• Gateway latency ekleyebilir; doğru ölçeklenme gerektirir.
• Merkezi bileşenlerin yüksek erişilebilir olması şarttır.

3.3 DNS‑based discovery

DNS tabanlı keşif, servis adlarını DNS kayıtlarına çevirir. Kubernetes'in Service kaynakları örneğin cluster DNS (CoreDNS) aracılığıyla her servisi host adı ile çözümleyebilir. DNS discovery, altyapı tarafından native olarak desteklenir ve client tarafında ek kütüphane gerektirmez. Ancak DNS TTL ve cache davranışı nedeniyle sağlık durumundaki hızlı değişikliklere tepki gecikebilir.

3.4 Event‑driven ve watch tabanlı discovery

Modern registry'ler (Consul, etcd) değişiklikleri watch/stream ile client'lara bildirebilir. Bu event driven yaklaşım, client'ların altyapı değişikliklerine anlık tepki vermesini sağlar ve polling yükünü azaltır. Örneğin Kubernetes, API server aracılığıyla resource değişikliklerini watch etmeye imkan verir.

3.5 Service Mesh yaklaşımları

Service mesh (Istio, Linkerd) ile discovery ve routing genelde sidecar proxy'ler (Envoy) aracılığıyla gerçekleştirilir. Mesh control plane, registry ve health metadata'yı toplayıp sidecar'lara dağıtır; böylece uygulama kodu discovery logic'inden tamamen ayrışır. Mesh ayrıca mTLS, traffic shifting, fault injection ve telemetry gibi gelişmiş özellikleri kolaylaştırır.

3.6 Health checks ve liveness/readiness

Sağlık kontrolleri service discovery'nin merkezidir. Kubernetes'te readiness probe bir pod'u servise dahil etmeden önce hazır olup olmadığını kontrol ederken, liveness probe düğümü yeniden başlatılmasını tetikleyebilir. Consul gibi registry'lerde ise active/passive health check'ler ve script tabanlı doğrulamalar kullanılabilir.

3.7 Metadata ve routing kararları

Discovery metadata (tags, version, region, az, canary) routing kararlarının temelini oluşturur. Örneğin bir client sadece aynı bölgedeki instance'lara yönlendirme isteyebilir veya yalnızca belirli sürüme sahip instance'ları hedefleyebilir. Bu filtreleme hem client‑side hem de server‑side mekanizmalarla uygulanabilir.

4. GERÇEK DÜNYA ÖRNEKLERİ VE ARAÇLAR

4.1 Kubernetes

Kubernetes, service discovery için API server + CoreDNS + kube‑proxy kombinasyonunu sunar. Her Service için DNS adı oluşur; DNS çözümlemesi ve kube‑proxy/iptables routing ile trafiğin uygun pod'lara yönlendirilmesi sağlanır. Ayrıca Endpoints ve EndpointSlices ile ölçeklenebilir discovery verisi tutulur.

4.2 Consul

HashiCorp Consul, service registry, health checking, key/value store ve DNS/HTTP API ile zengin bir discovery çözümüdür. Etiketleme, intent policy ve mesh entegrasyonu ile özellikle multi‑datacenter ve hybrid cloud senaryolarında tercih edilir.

4.3 etcd

etcd, yüksek performanslı bir distributed key‑value store'dur. Kubernetes'in altında yer alan store olarak da bilinir. etcd doğrudan discovery için tasarlanmamış olsa da registry verisi saklamak ve watch mekanizması sağlamak için kullanılabilir.

4.4 Eureka (Netflix)

Netflix OSS ekosisteminin bir parçası olan Eureka, Java/Spring dünyasında popüler bir service registry'dir. Client‑side discovery için tasarlanmış ve Spring Cloud ile sık kullanılmaktadır.

4.5 Zookeeper

Apache Zookeeper, dağıtık coordination ve discovery için kullanılır. Hem metadata depolama hem de ephemeral node mekanizması sayesinde geleneksel discovery işlemlerinde tercih edilmiştir; fakat modern alternatifler (etcd, Consul) daha hafif ve kolay yönetilebilirdir.

4.6 Service Mesh (Istio, Linkerd) ve Envoy

Service mesh, discovery'yi control plane aracılığıyla merkezi bir şekilde yönetir; Envoy gibi yüksek performanslı proxy'ler sidecar olarak çalışır ve dinamik olarak control plane'den aldığı konfigürasyonla discovery ve routing yapar. Mesh ayrıca observability (tracing, metrics), security (mTLS) ve trafik yönetimi (traffic shifting, fault injection) özellikleri sunar.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Dinamik ortamlarla (konteyner, cloud) uyumlu: instance'lar ephemeral olsa da discovery sayesinde erişim korunur.
• Otomatik health‑aware routing ile hata süreleri azalır ve SRE operasyonları kolaylaşır.
• Metadata tabanlı routing (version, region) ile canary ve blue/green deployment’lar mümkün olur.

Sınırlamalar

• Registry bileşeni bir SPOF olabilir; yüksek erişilebilirlik tasarımı şarttır.
• DNS TTL, cache davranışı ve eventual consistency discovery hızını etkileyebilir.
• Client‑side discovery çok sayıda client olduğunda registry'ye yüksek yük bindirebilir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Registry bileşenlerini HA modunda çalıştırın (cluster, multi‑AZ, replication).
• Health checks'i gerçekçi ve etkili olacak şekilde tasarlayın: readiness/liveness probe'ları ayırın.
• DNS TTL'lerini uygulama gereksinimine göre dikkatle ayarlayın; kısa TTL yoğun DNS trafiği oluşturabilir.

Performans optimizasyonu

• Client tarafında lokal cache + watch kombinasyonu ile registry yükünü azaltın.
• Service mesh kullanıyorsanız sidecar performansını izleyin ve connection pooling ayarlarını optimize edin.

Güvenlik

• Service registry erişimini authentication ve authorization ile koruyun.
• mTLS ve network policy ile servisler arası iletişimi güvenli hale getirin.

Observability

• Discovery metriklerini (registration rate, deregistration, health failures) toplayın.
• Trace ve logs ile routing kararlarını ve failed requests'leri korelasyonlayın.

8. SIK YAPILAN HATALAR

• Registry'i tek bir node üzerinde çalıştırmak — HA ve replication olmadan production risklidir.
• Health check'leri aşırı basit tutmak — readiness ve liveness farkları iyi anlaşılmalı.
• DNS TTL'lerini çok uzun ayarlamak — hızlı değişim gereken durumlarda stale routing oluşur.
• Client'ları discovery logic ile aşırı donatmak — library yönetimi ve sürüm farklılıkları sorun yaratır.

9. GELECEK TRENDLER

1. Control plane federasyonu: Çoklu cluster ve multi‑cloud senaryolarında federated service registry ve global discovery artacak.
2. AI‑assisted routing: Telemetry'e göre akıllı trafik yönlendirme, latency ve maliyet optimizasyonu algoritmaları yaygınlaşacak.
3. Edge discovery: Edge compute ve IoT için lokal discovery ve eventual consistency modelleri gelişecek.
4. Service registry as a platform: Policy as code, declarative discovery politikaları ve schema registry entegrasyonları öne çıkacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Hangi discovery modeli benim için uygun?

   Küçük uygulamalar için DNS veya client‑side discovery yeterli olabilir. Büyük, multi‑region ve güvenlik odaklı sistemlerde service mesh ve centralized control plane daha uygundur. Ekip yetkinliği ve operasyonel hedefler seçimi belirler.

2. 2. Registry nasıl HA yapılır?

   Cluster kurulumu, multi‑AZ replikasyon, snapshot ve backup stratejileri ile registry yüksek erişilebilirlikli çalıştırılmalıdır. Ayrıca read‑replica ve write quorum stratejileri kullanılabilir.

3. 3. DNS TTL ne kadar olmalı?

   Use‑case'e göre değişir: yüksek dinamizm gerektiren kritik path'lerde kısa TTL (saniyeler seviyesinde), statik servislerde daha uzun TTL tercih edilebilir. Kısa TTL DNS load'u yaratır; denge gerekli.

4. 4. Service mesh neden gerekli?

   Service mesh, discovery'yi uygulama kodundan ayırır ve güvenlik, telemetry, traffic management gibi cross‑cutting ihtiyaçları merkezi olarak sağlar. Ancak ek altyapı ve operasyonel yük getirir.

5. 5. Health check nasıl tasarlanmalı?

   Readiness: servis isteklere cevap vermeye gerçekten hazır mı? Liveness: servis sağlıklı mı yoksa restart gerektiriyor mu? Karmaşık startup süreçleri veya dış bağımlılıklar için readiness'i kullanın.

6. 6. Client tarafında cache kullanmalı mıyım?

   Evet. Lokal cache + watch/event mekanizması ile registry sorgu yükü azaltılabilir. Ancak cache invalidation ve stale entry handling dikkatle tasarlanmalıdır.

7. 7. Service discovery güvenliği nasıl sağlanır?

   Registry API'lerini kimlik doğrulama ile koruyun, role‑based erişim kontrolleri ekleyin ve audit log tutun. mTLS ile hizmetler arası trafiği güvenli hale getirin.

8. 8. Çoklu cloud / hybrid ortamda discovery nasıl yapılır?

   Federated control plane, global registry ve bölgesel cache stratejileri kullanın. Trafik yönlendirme için latency‑aware ve cost‑aware policy'ler tasarlayın.

Anahtar Kavramlar

Service Registry

Hizmet kayıtlarının tutulduğu depo (Consul, etcd, Eureka).

Client‑side discovery

Client'ın doğrudan registry'den instance listesi alıp load balancing yaptığı model.

Server‑side discovery

Gateway veya proxy'nin registry'den karar alıp trafiği yönettiği model.

Service Mesh

Sidecar proxy'ler ve control plane ile discovery, security ve traffic yönetimini sağlayan katman.

Health Check

Servisin canlılık ve hazır olma durumunu kontrol eden mekanizma.

Öğrenme Yol Haritası

1. 0–1 ay: Temel networking, DNS, HTTP ve load balancing kavramlarını öğrenin.
2. 1–3 ay: Kubernetes servis discovery (CoreDNS, Endpoints), basic Consul/Eureka deneyimi kazanın.
3. 3–6 ay: Service mesh (Istio/Linkerd) ve Envoy/NGINX proxy konfigürasyonlarını uygulayın; health checks ve readiness/liveness pratiklerini öğrenin.
4. 6–12 ay: Multi‑cluster federation, global discovery, telemetry driven routing ve policy as code uygulamaları üzerinde deneyim kazanın.