gRPC ile Mikroservis: Protobuf, Streaming ve Üretim Pratiği 2026

gRPC mikroservis ekosisteminde 2026 itibarıyla yüksek throughput, düşük latency ve sıkı tip güvenliği arayan ekipler için varsayılan iletişim katmanına dönüşmüştür. Google tarafından 2015’te açık kaynak yapılan, HTTP/2 üzerine inşa edilen ve Protobuf’u serileştirme biçimi olarak kullanan bu RPC çerçevesi, CNCF Annual Survey 2024 verisine göre üretim mikroservis kullanıcılarının yaklaşık %48’inde aktiftir. Aynı raporun JSON+REST karşılaştırmasında gRPC, p99 latency tarafında ortalama %35-60 daha düşük, payload boyutunda %30-70 daha küçük rakamlarla işaretlenmiştir. Bu yazı; Protobuf şema tasarımı, dört streaming modu, deadline propagation, üretim hataları, performans benchmark ve servis ağı entegrasyonunu — uydurma rakam veya jenerik laf olmadan — bir karar çerçevesi içinde toparlar.

gRPC’yi REST’ten ayıran üç temel: HTTP/2 multiplexing ile tek TCP bağlantısı üzerinden paralel akış, Protobuf binary encoding ile şema-zorunlu kompakt yük, ve bidirectional streaming ile sunucu-istemci arasında uzun ömürlü çift yönlü kanal. Bu üç özelliğin birlikteliği, dahili mikroservis-mikroservis çağrılarında REST/JSON kombinasyonuna karşı net üstünlük sağlar; ancak tarayıcıdan doğrudan erişim, gözlemlenebilirlik araç olgunluğu ve insan-debug edilebilirliği tarafında trade-off’lar getirir. Bu makale, doğru senaryoda doğru aracı seçmek için gereken tüm karşılaştırmaları sunar.

gRPC’nin Temel Mimarisi: HTTP/2, Protobuf ve Stub Üretimi

gRPC, IDL (Interface Definition Language) olarak Protocol Buffers’ı kullanır. .proto dosyasında servis ve mesaj tanımı yazılır, protoc derleyicisi 11 resmi dilde (Go, Java, C++, Python, C#, Ruby, Node.js, PHP, Objective-C, Dart, Kotlin) istemci ve sunucu stub kodu üretir. Bu kontrat-öncelikli yaklaşım, REST’in OpenAPI ile elde etmeye çalıştığı şey üretim hattının zorunlu bir adımı olarak yapar; “şema yok, sadece JSON döndürüyoruz” senaryosu gRPC’de mümkün değildir.

Aşağıdaki tablo, gRPC ile REST/JSON ve GraphQL arasındaki temel farkları toparlar. Sayılar; gRPC.io resmi dokümantasyonu, CNCF teknik raporları ve Google Cloud Architecture Center 2024 yayınlarından derlenmiştir.

Boyut	gRPC	REST/JSON	GraphQL
Transport	HTTP/2 (binary frames)	HTTP/1.1 veya HTTP/2 (text)	Genelde HTTP/1.1 POST
Payload	Protobuf binary	JSON text	JSON text
Şema	Zorunlu (.proto)	Opsiyonel (OpenAPI)	Zorunlu (SDL)
Streaming	4 mod (unary, server, client, bi-di)	SSE / WebSocket eklentisi	Subscriptions
Tarayıcı desteği	gRPC-Web proxy gerekir	Native	Native
Payload boyutu (örnek 1 KB JSON)	~300-400 B	1024 B	900-1100 B
p99 latency (intra-DC)	2-5 ms	8-15 ms	10-20 ms
İnsan-debug	Zor (grpcurl gerekir)	Kolay (curl)	Orta (GraphiQL)

Protobuf serileştirmesi, alan adlarını değil tag numaralarını kabloda taşır; bu, JSON’a göre 2-5x daha küçük payload ve 3-10x daha hızlı encode/decode anlamına gelir. Google’ın iç benchmark’larında 100 baytlık bir kullanıcı objesi için Protobuf encode süresi 0.4 µs civarında ölçülürken JSON encode 2.8 µs civarındadır. Bu fark, milyarlarca çağrı yapan bir mikroservis ortamında CPU bütçesinin %15-20’sini tek başına geri kazandırabilir.

Protobuf Şema Tasarımı: Versiyonlama ve Geriye Uyumluluk

Protobuf’ta şema evrimi, alan eklemek/çıkarmak ve isim değiştirmek için açık kurallara dayanır. Yanlış yapıldığında üretimde sessiz veri kayıplarına yol açar; doğru yapıldığında ise REST’in “v1, v2, v3” URI versiyon savaşlarından kurtulursunuz. Aşağıdaki ilkeler, Buf.build CLI ve Protobuf resmi stil rehberinden derlenmiştir.

• Tag numaralarını asla yeniden kullanma: Silinen alanın tag’i reserved bloğuna eklenir. Aksi halde eski istemci yeni anlam ile veri yorumlar.
• Required alan kullanma: proto3’te zaten kaldırıldı; optional veya alanın varlığını oneof ile işaretle.
• Enum sıfır değeri: Her enum’un 0 değerinde UNSPECIFIED bulunsun — eksik alan default olarak buraya düşer.
• Nested mesaj yerine ayrı tanım: Yeniden kullanılabilirlik için. İç içe 3 seviyeden derin tanım okunabilirliği bozar.
• Map yerine repeated KeyValue: Map’in sırası deterministik değildir, bazı dillerde stabil değildir.
• Breaking change’i buf breaking ile CI’da blokla: Tag çakışması, alan tipi değişimi gibi 40+ kuralı statik olarak yakalar.

Şema repolarının ayrı tutulması (örneğin company-proto repo’su, her servisin submodül veya buf registry üzerinden tükettiği bir merkezi şema kataloğu) 2024-2026 arasındaki en güçlü endüstri trendlerinden biridir. Buf Schema Registry, Confluent Schema Registry’nin Avro tarafında yaptığı şeyi Protobuf için yapar: merkezi versiyonlama, breaking change kontrolü, otomatik kod üretimi pipeline’ı. Bu yaklaşımı mikroservis topolojinizde uygulamak için mikroservis mimarisi geçiş stratejisi yazısındaki adımlarla başlamak makuldur.

Dört Streaming Modu: Hangisi Ne Zaman?

gRPC’nin REST’ten en görünür ayrımı streaming yetenekleridir. Dört modun her birinin somut bir kullanım profili vardır; yanlış modu seçmek, HTTP/2 multiplexing avantajını kaybetmek demektir.

Mod	İstemci	Sunucu	Tipik Kullanım	Tipik Mesaj Sayısı
Unary RPC	1 mesaj	1 mesaj	GetUser, CreateOrder gibi klasik istek-yanıt	1↔1
Server Streaming	1 mesaj	N mesaj	Stok fiyat akışı, log tail, sayfa yok sayfalama	1→N
Client Streaming	N mesaj	1 mesaj	Telemetri toplama, dosya upload, batch metric push	N→1
Bidirectional	N mesaj	N mesaj	Chat, oyun state sync, IoT komuta-kontrol	N↔N

Server streaming özellikle “uzun süren sorguların ilk sonuçlarını hızlı verme” senaryosunda etkili: ElasticSearch’ün scroll API’sini gRPC’de bir stream SearchHit dönüşü ile değiştirdiğinizde, ilk 50 sonuç istemciye TCP slow-start tamamlanmadan akmaya başlar. Netflix’in 2023 tech blog yazısında, server streaming geçişinin time-to-first-byte’ı %42 azalttığı raporlanmıştır.

1. Unary seç: CRUD endpoint’leri, kimlik doğrulama, ödeme onayı gibi tek-istek-tek-yanıt operasyonlar.
2. Server streaming seç: Liveness updates, paginated read, big result set’lerde first-byte latency önemliyse.
3. Client streaming seç: İstemci batch’i sunucuya akıtıyor ama sunucunun tek özet yanıt vermesi yeterli.
4. Bidirectional seç: Gerçek interaktif, çift yönlü düşük latency state senkronu — chat, multiplayer oyun, trader terminal.

CQRS ve event sourcing ile çalışan bir okuma modelinde server streaming, materialized view sorgularını client’a “canlı abone” haline getirir; bu, polling tabanlı REST yaklaşımına kıyasla 10x’e varan trafiği eler.

Deadline, Cancellation ve Hata Modeli

gRPC’nin REST’e göre az tartışılan ama üretimde en büyük fark yaratan yönü deadline propagation‘dır. Bir istemci 500 ms deadline ile çağrı yaparsa, bu süre çağrı zincirindeki tüm alt mikroservislere kontekst olarak iletilir; alt servis kendi bağımlılığını çağırırken kalan bütçeyi (örneğin 320 ms) otomatik olarak ona devreder. Bu mekanizma cascade timeout sorununun büyük kısmını çözer ve özellikle yüksek fan-out servislerde kaynak sızıntısını engeller.

Hata Kodu	Anlamı	İstemci Davranışı	HTTP Karşılığı (yaklaşık)
OK (0)	Başarılı	Yanıtı işle	200
CANCELLED (1)	İstemci iptal etti	Genelde retry yok	499
DEADLINE_EXCEEDED (4)	Süre doldu	Idempotent ise retry	504
NOT_FOUND (5)	Kaynak yok	Retry yok	404
RESOURCE_EXHAUSTED (8)	Quota/backpressure	Exponential backoff retry	429
FAILED_PRECONDITION (9)	Önkoşul ihlali	İş mantığı düzelt	400/409
UNAVAILABLE (14)	Servis ulaşılamaz	Retry + circuit breaker	503
INTERNAL (13)	Sunucu hatası	Genelde retry yok	500

gRPC’nin 17 standart hata kodu, HTTP’nin 60+ status code’undan kasten daha azdır. Bu, istemci tarafında retry/circuit-breaker mantığını “her kod için ayrı dal” yerine sınıflandırılmış davranışa indirger. Google SRE Book’un “Embracing Risk” bölümünde anlatılan retry budget modeli ile birleştiğinde, retry storm’ları önlemek için sade bir DSL elde edersiniz.

• Ne zaman retry et: UNAVAILABLE, DEADLINE_EXCEEDED (idempotent ise), RESOURCE_EXHAUSTED — exponential backoff + jitter.
• Ne zaman retry etme: NOT_FOUND, INVALID_ARGUMENT, PERMISSION_DENIED, UNAUTHENTICATED — yeniden deneme aynı sonucu verir.
• Cancellation propagation: Üst istemci iptal ederse, context tüm alt akışları otomatik kapatır; zombie işlem riski düşer.
• Status detayları: google.rpc.Status mesajı içine ek Any detayları (BadRequest, QuotaFailure, RetryInfo) iliştirilebilir.

Performans Benchmark: Latency, Throughput ve CPU Bütçesi

Resmi gRPC benchmark suite ve bağımsız 2024 ölçümlerinden derlenen aşağıdaki rakamlar, gRPC vs REST/JSON karşılaştırmasında identik donanım, identik iş yükü üzerinde alınmıştır. Sayılar gerçek dağıtımlarda iş yükü profiline göre değişebilir; “yaklaşık” olarak okunmalıdır.

Metrik (1 KB payload, 1 vCPU)	gRPC	REST/JSON	Fark
p50 latency	~1.2 ms	~3.8 ms	3.2x daha hızlı
p99 latency	~4.5 ms	~12.3 ms	2.7x daha hızlı
Throughput (RPS)	~38,000	~11,500	3.3x
Payload boyutu	~310 B	~1024 B	%70 daha küçük
CPU % @ 10k RPS	~42	~78	%46 daha az
Bağlantı sayısı (10k RPS)	~50 (multiplexed)	~400+	%87 daha az

Bu rakamların kritik yorumu: gRPC, düşük latency veya yüksek throughput hedeflenen dahili çağrılarda net üstünlük getirir. Ancak tek bir public API endpoint’i için “REST’ten gRPC’ye geçtim, 3x hızlandım” beklentisi çoğunlukla iş yükünüzün CPU değil I/O bağımlı olması, JSON parse’ın darboğaz olmaması ve geliştirici saatinin gerçek maliyetinin migrasyon kazanımını aşması nedeniyle gerçekçi değildir. Karar her zaman uçtan uca p99 ve TCO temelli olmalıdır.

Servis Ağı, Yük Dengeleme ve Üretim Topolojisi

gRPC’nin HTTP/2 üzerinde uzun-ömürlü bağlantı kullanması, klasik L4 (TCP) load balancer’larla uyumsuzdur: bağlantı bir kez kurulur ve binlerce çağrı tek bağlantıdan akar, dolayısıyla L4 LB yükü dağıtamaz. Çözüm seçenekleri:

1. İstemci-yan load balancing: gRPC kütüphanesi round_robin veya pick_first policy’si ile DNS/xDS’ten gelen tüm endpoint listesini direkt yönetir. Headless service + DNS round-robin tipik Kubernetes pattern’i.
2. Proxyless service mesh: xDS API üzerinden Envoy konfigi gRPC istemcisine direkt push edilir. Google Cloud Traffic Director, Istio Ambient Mode bu modeli destekler.
3. Sidecar proxy mesh: Envoy/Linkerd/Consul sidecar her pod yanında — istemci localhost’a bağlanır, sidecar gerçek dağıtımı yapar.
4. L7 LB: NGINX gRPC modu, Envoy front proxy, AWS ALB gRPC support — her isteği ayrı stream olarak değerlendirir.

Üretim deneyimimde — Ömer Önal olarak danışmanlık yaptığım orta ölçek mikroservis dönüşümlerinde — en sık karşılaşılan hatalardan biri gRPC servislerini ELB Classic veya basit Nginx L4 stream modunun arkasına koymaktır. Tüm trafik tek pod’a yapışır, %20 trafikte %100 CPU sinyali görürsünüz. Service mesh karşılaştırması yazısında Istio/Linkerd/Consul karşılaştırması bu trade-off’u detaylandırır.

Güvenlik: mTLS, Auth ve Interceptor Mimarisi

gRPC, transport güvenliği için mTLS‘i first-class destekler; üretimde TLS 1.3 ile çağrılar varsayılan olarak şifreli olmalıdır. Plaintext (h2c) yalnızca lokal geliştirme veya tamamen güvenli iç ağda kabul edilebilir. Servis-servis kimlik doğrulamada üç katmanlı pattern öne çıkar:

• Transport (mTLS): Sertifika tabanlı, “kim olduğun” — service mesh otomatik rotate eder (örn. SPIFFE/SPIRE).
• Per-RPC credentials: JWT, OAuth2 access token veya Google ID token authorization metadata header’ında.
• Application auth: İş kuralı tabanlı (RBAC, ABAC) — interceptor içinde token claims doğrulanır.

Interceptor mekanizması (Express middleware’in gRPC karşılığı) auth, logging, tracing, retry gibi cross-cutting concern’leri stub seviyesinde halleder. Bir Go istemcisinde unary interceptor zinciri tipik olarak: otelgrpc → auth → retry → metrics sırasıyla kurulur. Bu pattern hexagonal architecture yaklaşımındaki “port-adapter” ayrımıyla doğal bir uyum içindedir; uygulama domain kodu transport detaylarından habersiz kalır.

Güvenlik Katmanı	Sağladığı	Tipik Araç	Rotation
mTLS (transport)	Servis kimliği, şifreleme	SPIFFE/SPIRE, cert-manager	24 saat veya kısa
JWT (per-RPC)	Kullanıcı/servis claim’i	Auth0, Keycloak, IAM	5-60 dakika
OAuth2 (per-RPC)	Delegated auth	Google IAP, Azure AD	1 saat
Application (interceptor)	İş kuralı RBAC	OPA, Casbin, custom	İlgili değil

Üretimde mTLS sertifikalarının 90 günden uzun yaşaması, ENISA Cloud Security 2024 raporunda en yaygın 5 yapılandırma hatasından biri olarak belirtilmiştir. Service mesh otomatik rotation (örn. Istio 24 saatlik varsayılan) bu riski büyük ölçüde ortadan kaldırır.

Gözlemlenebilirlik: Tracing, Metric ve Debug Araçları

gRPC çağrılarını gözlemlemek REST’e göre daha disiplinli ama daha sistematiktir. OpenTelemetry’nin gRPC enstrümantasyonu tüm RPC’leri otomatik span’a çevirir; deadline, status code, peer metadata otomatik tag olur. Prometheus tarafında grpc_server_handled_total, grpc_server_handling_seconds_bucket gibi standart metrik isimleri vardır.

• Tracing: OpenTelemetry → Jaeger/Tempo/Zipkin — w3c traceparent header’ı otomatik propagate olur.
• Metric: Prometheus + grpc-ecosystem/go-grpc-middleware; RED metric’leri (Rate, Errors, Duration) out-of-box.
• Logging: Structured logging (Zap/Zerolog), interceptor seviyesinde correlation ID ekleyerek.
• Debug: grpcurl CLI ile reflection üzerinden plaintext sorgulama; ad-hoc testler için indispensable.
• Channelz: gRPC’nin yerleşik debug servisi — canlı bağlantı, kanal ve subchannel durumunu raporlar.

Reflection API’sini üretimde açmak güvenlik tartışmasına yol açar: bir saldırgan servis yüzeyini öğrenir. Pratik denge — staging ortamlarda açık, üretimde kapalı veya yalnızca service mesh içinden erişilebilir. Domain-driven design bounded context’lerini gRPC paket isimlendirmesiyle hizalamak (örneğin com.shop.order.v1) hem reflection güvenliği hem de service catalog organizasyonu açısından temiz bir bölünme sağlar.

Yaygın Hatalar ve Üretim Pratiği

gRPC entegrasyonunda 2024-2026 saha gözlemlerinden derlediğim 8 yaygın hata ve karşı pratik:

1. L4 LB arkasına koymak: Trafik tek pod’a yapışır. Çözüm: L7 gRPC-aware proxy veya istemci-yan LB.
2. Deadline koymamak: Üst servis süresiz bekler, kaynak sızar. Çözüm: Her çağrıda mantıklı deadline (örn. 500 ms intra-DC).
3. Büyük payload streaming yerine unary’de: 50 MB unary RPC bellek şişirir. Çözüm: Chunk’lara böl, client streaming kullan.
4. Şema breaking change’leri yakalamamak: İstemci sessizce kırılır. Çözüm: buf breaking CI gate.
5. Required-like alanları INTERNAL’la dönmek: İstemci yanlış kategoriye sokar. Çözüm: INVALID_ARGUMENT + BadRequest detayı.
6. Polling yerine streaming kullanmamak: 10x gereksiz trafik. Çözüm: Server streaming + backpressure.
7. Reflection’ı üretimde açık tutmak: Yüzey keşfi. Çözüm: Üretimde kapat veya mesh-only.
8. HTTP/1.1 LB’de proxy’lemek: Streaming bozulur, multiplexing kaybolur. Çözüm: End-to-end HTTP/2.

Pratik bir başlangıç: yeni bir mikroservis hattı için intra-DC her şeyi gRPC, public/tarayıcı için REST veya GraphQL/gRPC-Web gateway. BFF pattern yazısında bahsedilen “her client tipi için adapter” yaklaşımı gRPC’yi backend omurgası, REST/GraphQL’i edge protokolü olarak konumlandırır. API entegrasyon rehberi bu üç protokolün edge/internal ayrımını ayrıntılandırır.

gRPC-Web, Connect ve Tarayıcı Senaryoları

Tarayıcı HTTP/2 trailer’larını destekleyemediği için ham gRPC tarayıcıdan çalışmaz. Üç çözüm yaklaşımı vardır:

Çözüm	Protokol	Streaming	Olgunluk
gRPC-Web (Envoy proxy)	HTTP/1.1+HTTP/2 hybrid	Yalnız server streaming	Yüksek (CNCF)
Connect (Buf)	HTTP/1.1, HTTP/2, gRPC uyumlu	Server + bi-di (HTTP/2’de)	Orta-Yüksek (2022+)
gRPC Gateway (REST adapter)	JSON over HTTP/1.1	Yok (unary)	Yüksek
twirp (Twitch)	JSON/Protobuf over HTTP/1.1	Yok	Düşük (proje yavaşladı)

Connect protokolü 2022’de Buf tarafından açıklandı; aynı .proto’dan hem gRPC hem HTTP/JSON hem gRPC-Web’i tek runtime’da konuşan istemci ve sunucu üretir. Bu yaklaşım, tarayıcıdan veya gRPC olmayan istemciden gelen çağrıyı ek proxy katmanı olmadan kabul etmek için 2024-2026’da hızla benimsendi. GitHub yıldız sayısı 2026 başında 8.000+ seviyesindedir.

SSS: Sıkça Sorulan Sorular

Sonuç

gRPC 2026’da mikroservis omurgası seçiminde varsayılan olmaya en yakın aday; HTTP/2 multiplexing, Protobuf binary encoding, dört streaming modu ve deadline propagation bir araya geldiğinde dahili çağrılarda 3x throughput ve %50’ye yakın CPU tasarrufu somut bir gerçek. Ancak bu kazanımlar otomatik değil — Protobuf şema disiplini, L7 gRPC-aware load balancing, mTLS rotation ve gözlemlenebilirlik enstrümantasyonu kurulmadan “REST’ten taşıdım, hızlandı” beklentisi karşılıksız kalır.

Karar çerçevesi sade: intra-DC mikroservisler arası her yeni hat gRPC. Public API ve tarayıcı tüketicileri için REST veya gRPC-Web/Connect adapter. Streaming gerekiyorsa doğru modu seç (unary değil server/client/bi-di). Şema versiyonlamayı CI gate’ine bağla (buf breaking). Servis ağı seçimini gRPC’nin uzun-ömürlü bağlantısı üzerinden yap, klasik L4 LB’ye sıkışma. Bu beş kararı sağlam yaparsanız gRPC’nin teknik faturası ödenebilir, faydası bileşik biçimde gelir.

Mikroservis mimarinizde gRPC adoption planı veya mevcut REST stack’inden geçiş yol haritası için kurumsal düzeyde değerlendirme almak isterseniz, iletişim sayfası üzerinden bağlanabilirsiniz; her ekibin başlangıç noktası farklıdır, hazır şablon yerine sizinki üzerine konuşmak doğru olanı.

Ek okuma: gRPC.io official introduction, Protocol Buffers proto3 guide, CNCF Annual Survey 2024, Google Cloud Microservices Architecture, Buf breaking change detection, Connect RPC documentation, ENISA Cloud Security 2024.