Service Mesh: Mikroservislerin gizli destekçisi

02 Tem 06:42

Service Mesh’in en iyi anlaşılabilir karşılaştırması hiç şüphesiz Linux sistemlerindeki "init" sürecinin rolüne benzetilebilir. Tıpkı sistem başlatılırken ilk proses olan `init` (ya da `systemd`) gibi, Service Mesh de mikroservis ekosistemindeki ilk temas noktasıdır — ancak modern, dağıtık bir versiyon. Örneğin, geleneksel monolitik bir uygulamanın tüm bileşenleri (veritabanı bağlantıları, I/O işlemleri, kimlik doğrulamaları) tek bir kod bloğu içinde yönetilirken, servis mesh bunu *yan uygulamalar (sidecar proxy’ler)* aracılığıyla "ayrıştırılmış bir scope"a taşıyor. Bu proxy’ler (örn. Istio’daki Envoy ya da Linkerd’daki Linkerd2-proxy), tıpkı servisin "gölge hesap makinesi" gibi davranıyor: tüm iletişimleri yakalayıp düzenliyor, yük dağıtımı yapıyor, hata enjeksiyonlarıyla sistemin dayanıklılığını test ediyor — ama asla doğrudan servisin iş mantığına müdahale etmiyor. Bu yaklaşıma biraz daha yakından bakınca, aslında *TCP/IP protokol katmanlarının* bir çeşit "mikroservis versiyonu" olduğunu görebilirsin. TCP’nin sağladığı güvenlik (TLS), akış kontrolü ve hata düzeltmesi ne kadar temel bir altyapıysa, Service Mesh de aynı role sahip — sadece burada katmanlar arasında değil, *servisler arası* iletişimde devreye giriyor. Örneğin, bir servis `GET /users` isteği gönderdiğinde, sidecar proxy bu isteği ele geçirip; JWT doğrulamasını yapıyor, trafiği canary deployment’e yönlendirebiliyor, ya da anormal trafik desenlerinde circuit breaker’ı tetikleyebiliyor. Bu, tıpkı bir network firewall’unun gelen paketleri filtrelemesi gibi — ama burada filtrelenen şey paket değil, hizmet çağrıları. Son olarak, service mesh’in en önemli faydalarından biri de *gözlemlenebilirlik*. Bunu veri merkezindeki bir "SNMP monitor" sistemine benzetebiliriz: sadece trafiği değil, servisler arasındaki *sürekli akışın* (latency, error rates, throughput) her detayını kaydedip, grafiklere döküyor. Bu sayede, örneğin bir servisin %5’lik bir yavaşlaması anında tespit edilip, hangi dependenc’lerin sorunlu olduğu anlaşılabiliyor. Farkıysa, SNMP’nin statik izlemesinin yerine, service mesh’in *dinamik* ve *programlanabilir* olması — gerektiğinde trafiği yeniden yönlendirebilen, kuralları anında değiştirebilen bir yapı sunması.

02 Tem 08:22

Önce "istekli proxy" laflarını duyunca ayaküstü dansa kalkıp göğüs göğüse çarpıştım. Sonra yan uygulama (sidecar) mimarisini görünce, bisiklete takoz takmak gibi mantık süpermiş sandım 😅 Hiçbir şeyi tam anlayamayıp, "Bu kadar da komplike olur mu?" diye şüphelendim ⚙️

02 Tem 09:02

Aynen, bizim de microservis mimarisine geçiş yaptığımız projede bu konuya iyice bulaştım. Service mesh'in aslında "istekli proxy"ler üzerinden çalışan bir ara katman olduğunu gördüm - her microservis'in yanına bir sidecar proxy (tipik olarak Envoy) bağlanıyor, ve tüm iletişim bu proxy'ler üzerinden gidiyor. Güvenlik kısmında otomatize TLS sertifika yönetimini ve trafiğin şifrelenmesini gördüm - Insomnia ile yaptığım API testlerinde dahi bu proxy'lerin arasında oluşan güvenli kanalı fark ettim. İzlenebilirlik tarafında da Jaeger ile yaptığım distributed tracing'de bütün request'ler arasındaki geçişleri tek bir yerden izleme şansı yakaladım, bu çok kullanışlı oldu. Özellikle production ortamında network debugging yaparken sidecar'ların verdiği detaylı metrikler sayesinde saatlerce sürebilecek sorunları dakikalar içinde çözebildik.

02 Tem 10:05

Hatırlıyorum, geçen sene bir projedeydik — müşteri arayüzünde sürekli connection resetler oluyordu, loglara bakıyorsun her şey düzgün görünüyor, ama servisler arasındaki istekler yarı yolda kayboluyordu. Sorunu çözmek için ilk aklıma gelen monitoring araçlarını kurdum, ama sonuçta gördüm ki sadece log’ları ve metrikleri toplamak yetmiyordu, trafiğin kendisini de kontrol etmek gerekiyordu. Sonra bir arkadaşım "Neden service mesh denen şeyi denemiyoruz?" dedi. İlk başta "Aa, başka bir proxy katmanı mı?" diye düşünmüştüm, ama karşılaştırmalı testler yapınca faydasını anladım. Örneğin, istemciden servise giden her istek artık otomatik olarak istatistik tutan, yeniden deneme yapan ve hatta güvenlik politikalını uygulayan bir sidecar proxy (Linkerd ya da Istio) üzerinden geçiyordu. Retry’ları ayarladım, circuit breaker’ları devreye soktum ve — zaten düzelme başladı. Üstüne üstlük, mTLS’yi de otomatik olarak etkinleştirdi, böylece servisler arası iletişim anında şifrelenmiş oldu. Eskiden aylarca sürecek güvenlik kontrollerini birkaç tıklama ile hallettik. Artık service mesh’in sadece "istekli proxy" değil, aynı zamanda bir güvenlik ve izleme omurgası olduğunu anladım — servis mimarisinin altında çalışıyor, ama hayatı kolaylaştırıyor.