Mikroservis Mimarisi İçin Proxy Üzerinden gRPC: HTTP/2 Tünelleme Ayarları İçin Kapsamlı Rehber

```html

gRPC, HTTP/2 üzerinde çalışan yüksek performanslı bir RPC çerçevesidir ve hizmetler arası etkileşim için de facto standart haline gelmektedir. Ancak gRPC trafiğini bir proxy üzerinden yönlendirmeye çalıştığınızda hemen sorunlar ortaya çıkar: çoğu klasik proxy sunucusu HTTP/2 ve uzun süreli akış bağlantıları ile çalışamaz. Bu yazıda, gRPC'yi proxy üzerinden doğru bir şekilde nasıl yapılandıracağınızı inceleyeceğiz - mimari seçiminizden Nginx, Envoy ve HAProxy için belirli yapılandırmalara kadar.

Neden gRPC, klasik proxy ile kötü çalışıyor

Sorunu anlamak için gRPC'nin nasıl çalıştığını anlamak gerekir. Protokol, taşıma katmanı olarak HTTP/2 kullanır ve bu, onu alışılmış REST'ten (HTTP/1.1 üzerinde) köklü bir şekilde ayırır. Çoğu kurumsal proxy, güvenlik duvarı ve yük dengeleyici, HTTP/1.1 döneminde tasarlandığı için HTTP/2 çoklu akışlarını işleyemez.

Klasik bir HTTP proxy üzerinden gRPC yönlendirmeye çalıştığınızda karşılaşacağınız belirli sorunlar şunlardır:

• HTTP/1.1'e düşürme. Birçok proxy otomatik olarak protokol sürümünü düşürür. gRPC, HTTP/2 gerektirir - bu olmadan bağlantı kurulamaz ve istemci UNAVAILABLE hatası alır.
• Uzun süreli bağlantıların kesilmesi. gRPC, sunucu ve iki yönlü akışı aktif bir şekilde kullanır. Agresif zaman aşımına sahip proxyler (özellikle AWS ELB Classic, bazı Squid sürümleri) 60 saniyeden uzun veri iletimi olmayan bağlantıları keser.
• Content-Type sorunları. gRPC, Content-Type: application/grpc başlığını kullanır. Bu türü bilmeyen bir proxy, isteği reddedebilir veya gövdeyi yanlış bir şekilde önbelleğe alabilir.
• Trailers (trailerlar). gRPC, çağrı sonlandırma durumunu iletmek için HTTP/2 trailerlarını kullanır. HTTP/1.1 proxyleri trailerları desteklemez - durum bilgisi kaybolur.
• Gövde önbellekleme. Bazı proxyler, yanıtın tüm gövdesini istemciye iletmeden önce önbelleğe alır. Akış gRPC çağrıları için bu, istemcinin akış tamamlanmadan hiçbir mesaj almayacağı anlamına gelir.

Anahtar çıkarım:

gRPC'nin proxy üzerinden çalışması için uçtan uca HTTP/2 desteğine sahip bir proxy veya özel bir tünelleme modu gereklidir. Klasik HTTP proxy, yapılandırma üzerinde değişiklik yapılmadan uygun değildir.

HTTP/2 tünelleme: nasıl çalışır

gRPC trafiğini proxy üzerinden yönlendirmek için iki temel yaklaşım vardır ve doğru çözümü seçmek için bu yaklaşımlar arasındaki farkı anlamak önemlidir.

Yöntem 1: HTTP/2 uçtan uca (önerilir)

Proxy, HTTP/2'yi anlar ve hem istemci hem de arka uç ile HTTP/2 bağlantısı kurar. Bireysel akışları analiz edebilir, istek düzeyinde yük dengelemesi uygulayabilir, başlıklar ekleyebilir ve TLS sonlandırması gerçekleştirebilir. Bu en işlevsel seçenektir - Envoy, Nginx (1.13.10 sürümünden itibaren) ve bulut sağlayıcılarındaki gRPC'yi bilen yük dengeleyiciler böyle çalışır.

Yöntem 2: TCP tünelleme (CONNECT)

Proxy, HTTP/2 trafiğini analiz etmez, sadece CONNECT yöntemi ile şeffaf bir TCP tüneli oluşturur. İstemci, tünel üzerinden doğrudan arka uç ile TLS bağlantısı kurar. Proxy yalnızca şifrelenmiş bir byte akışını görür. Bu yöntem, yapılandırması daha kolaydır, ancak gRPC istek düzeyinde yük dengeleme ve başlık ekleme yeteneklerinden mahrum bırakır.

Özellik	HTTP/2 uçtan uca	TCP CONNECT tüneli
İstek düzeyinde yük dengeleme	✅ Evet	❌ Hayır (sadece TCP)
Proxy'de TLS sonlandırma	✅ Evet	❌ Hayır
Başlık ekleme	✅ Evet	❌ Hayır
Yapılandırma zorluğu	Orta	Düşük
Akış desteği	✅ Tam	✅ Tam
Gözlemlenebilirlik (metrikler)	✅ Ayrıntılı	❌ Sadece TCP

Nginx'i gRPC proxy olarak yapılandırma

Nginx, 1.13.10 sürümünden itibaren gRPC proxy'lemeyi desteklemektedir (Şubat 2018). Çalışması için ngx_http_grpc_module modülüne ihtiyaç vardır ve bu, standart derlemeye dahildir. Önemli: Nginx, istemci tarafında (frontend) HTTP/2'yi destekler, ancak arka uçta gRPC için yalnızca HTTP/2 kullanır - normal HTTP upstream, HTTP/1.1 üzerinden çalışır.

Nginx'te gRPC proxy için temel yapılandırma

server {
    listen 443 ssl http2;
    server_name grpc.example.com;

    # TLS sertifikaları
    ssl_certificate     /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;

    # Modern TLS parametreleri
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location / {
        # proxy_pass yerine grpc_pass direktifi
        grpc_pass grpc://grpc_backend;

        # Uzun süreli akışlar için zaman aşımı
        grpc_read_timeout  3600s;
        grpc_send_timeout  3600s;
        grpc_connect_timeout 5s;

        # Gerçek istemci IP'sinin iletilmesi
        grpc_set_header X-Real-IP $remote_addr;
        grpc_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

upstream grpc_backend {
    server backend-1:50051;
    server backend-2:50051;
    server backend-3:50051;

    # HTTP/2 bağlantıları için keepalive
    keepalive 32;
}

Birkaç kritik detaya dikkat edin. İlk olarak, grpc_pass direktifi kullanılır, proxy_pass değil - bu farklı davranışa sahip farklı modüllerdir. İkincisi, grpc_read_timeout ve grpc_send_timeout zaman aşımı 3600 saniye (1 saat) olarak ayarlanmıştır - bu, veri iletimi olmadan uzun süre çalışan sunucu akışları için önemlidir. Üçüncüsü, keepalive 32 upstream'de, arka uçlarla HTTP/2 bağlantılarını yeniden kullanmayı sağlar.

Şifrelenmemiş gRPC için yapılandırma (grpc://)

server {
    listen 80 http2;
    server_name grpc-internal.example.com;

    location / {
        grpc_pass grpc://127.0.0.1:50051;

        # gRPC hatalarının işlenmesi
        error_page 502 = /error502grpc;
    }

    location = /error502grpc {
        internal;
        default_type application/grpc;
        add_header grpc-status 14;
        add_header content-length 0;
        return 204;
    }
}

error502grpc bloğu önemli bir detaydır: arka uç erişilemediğinde, gRPC istemcisinin doğru bir şekilde işleyemeyeceği HTTP 502 yerine doğru gRPC durumu UNAVAILABLE (14) döner.

Envoy Proxy: mikro hizmetlerde gRPC için en iyi seçim

Envoy, Lyft tarafından mikro hizmet mimarisi için özel olarak geliştirilmiştir ve gRPC desteği en derin düzeyde gerçekleştirilmiştir. Protocol Buffers'ı anlar, gRPC'yi REST'e dönüştürebilir, her RPC yöntemi için ayrıntılı metrikler toplar ve service mesh çözümleri için temel oluşturur - Istio, AWS App Mesh ve diğerleri. Ciddi bir mikro hizmet mimarisi inşa ediyorsanız, Envoy endüstri standardıdır.

gRPC için Envoy temel yapılandırması

static_resources:
  listeners:
  - name: grpc_listener
    address:
      socket_address:
        address: 0.0.0.0
        port_value: 8080
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: grpc_proxy
          codec_type: HTTP2
          route_config:
            name: grpc_routes
            virtual_hosts:
            - name: grpc_services
              domains: ["*"]
              routes:
              - match:
                  prefix: "/com.example.UserService"
                route:
                  cluster: user_service
                  timeout: 30s
                  retry_policy:
                    retry_on: "reset,connect-failure,retriable-status-codes"
                    num_retries: 3
                    retriable_status_codes: [14]
              - match:
                  prefix: "/com.example.OrderService"
                route:
                  cluster: order_service
                  timeout: 60s
          http_filters:
          - name: envoy.filters.http.grpc_stats
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.grpc_stats.v3.FilterConfig
              emit_filter_state: true
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

  clusters:
  - name: user_service
    connect_timeout: 5s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    http2_protocol_options: {}
    load_assignment:
      cluster_name: user_service
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: user-service
                port_value: 50051

Bu yapılandırmanın anahtar avantajları: gRPC hizmetlerine göre yönlendirme (yol ön eki, package.ServiceName formatında hizmetin tam adını karşılar), UNAVAILABLE durumunda otomatik yeniden denemeler ve grpc_stats filtresi aracılığıyla gRPC metriklerinin toplanması.

Envoy'da gRPC-Web dönüştürme

Envoy'un bir diğer önemli özelliği, yerleşik gRPC-Web dönüştürücüsüdür. Tarayıcılar doğrudan gRPC'yi desteklemez (HTTP/2 trailerları üzerindeki Fetch API kısıtlamaları nedeniyle), bu nedenle gRPC-Web protokolü kullanılır. Envoy, tarayıcıdan gelen gRPC-Web isteklerini arka uç için normal gRPC'ye otomatik olarak dönüştürebilir:

http_filters:
- name: envoy.filters.http.grpc_web
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.filters.http.grpc_web.v3.GrpcWeb
- name: envoy.filters.http.cors
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.filters.http.cors.v3.CorsPolicy
- name: envoy.filters.http.router
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

HAProxy ve gRPC: yük dengeleme ile yapılandırma

HAProxy, 1.9.2 sürümünden itibaren gRPC'yi desteklemektedir. TCP veya HTTP/2 düzeyinde çalışır, gRPC trafiğini dengeleyebilir ve sağlık kontrolleri gerçekleştirebilir. HAProxy, altyapınızda zaten kullanıyorsanız ve gRPC desteği eklemek istiyorsanız iyi bir seçimdir.

global
    maxconn 50000
    log stdout format raw local0

defaults
    log global
    timeout connect 5s
    timeout client  3600s
    timeout server  3600s

frontend grpc_frontend
    bind *:443 ssl crt /etc/haproxy/certs/server.pem alpn h2,http/1.1
    mode http
    option http-use-htx
    default_backend grpc_servers

backend grpc_servers
    mode http
    balance leastconn
    option http-use-htx

    # gRPC Sağlık Kontrol Protokolü üzerinden sağlık kontrolü
    option httpchk GET /grpc.health.v1.Health/Check
    http-check expect status 200

    server grpc1 10.0.0.1:50051 check ssl verify none
    server grpc2 10.0.0.2:50051 check ssl verify none
    server grpc3 10.0.0.3:50051 check ssl verify none

Birkaç önemli ayara dikkat edin. alpn h2,http/1.1 bind direktifinde, HAProxy'nin hem HTTP/2 hem de HTTP/1.1 bağlantılarını TLS ALPN müzakeresi üzerinden kabul ettiğini belirtir. timeout client 3600s ve timeout server 3600s - uzun süreli gRPC akışları için kritik öneme sahip parametrelerdir. leastconn algoritması, gRPC için roundrobin'dan daha uygundur, çünkü akış bağlantıları uzun süreli olabilir ve arka uçları dengesiz bir şekilde yükleyebilir.

TLS sonlandırma ve uçtan uca şifreleme için gRPC

gRPC varsayılan olarak TLS kullanımını gerektirir - bu, spesifikasyonun bir parçasıdır. Pratikte, mikro hizmet mimarisinde TLS sonlandırmasının nerede yapılacağı ve bileşenler arasındaki şifrelemenin nasıl düzenleneceği sorusu ortaya çıkar. Üç ana desen vardır.

Desen 1: Proxy'de TLS sonlandırma (Edge TLS)

Proxy, istemcilerden şifrelenmiş trafiği alır, şifre çözer ve arka uçlara şifresiz bir kanal üzerinden (veya ayrı bir TLS ile) iletir. Bu, kurumsal ağlarda en yaygın yaklaşımdır. Arka uçlar, yapılandırmayı basitleştirmek için grpc.Insecure() kullanabilir.

Desen 2: Uçtan uca şifreleme (mTLS)

Mutual TLS (mTLS), service mesh için standarttır. Her hizmetin kendi sertifikası vardır ve her bağlantıda her iki taraf da birbirinin sertifikalarını kontrol eder. Bu, hizmetlerin kimlik doğrulamasını ve küme içindeki trafiğin şifrelenmesini sağlar. İşte Istio'nun Envoy sidecar proxy ile böyle çalışır.

# Go: mTLS ile gRPC sunucusu
import (
    "crypto/tls"
    "crypto/x509"
    "google.golang.org/grpc"
    "google.golang.org/grpc/credentials"
)

func createMTLSCredentials() credentials.TransportCredentials {
    cert, _ := tls.LoadX509KeyPair("server.crt", "server.key")
    
    caCert, _ := os.ReadFile("ca.crt")
    caCertPool := x509.NewCertPool()
    caCertPool.AppendCertsFromPEM(caCert)
    
    tlsConfig := &tls.Config{
        Certificates: []tls.Certificate{cert},
        ClientAuth:   tls.RequireAndVerifyClientCert,
        ClientCAs:    caCertPool,
    }
    
    return credentials.NewTLS(tlsConfig)
}

// mTLS ile sunucu oluşturma
creds := createMTLSCredentials()
server := grpc.NewServer(grpc.Creds(creds))

Desen 3: TLS Passthrough

Proxy, TCP düzeyinde çalışır ve trafiği şifrelemez - yalnızca şifrelenmiş byte'ları arka uca yönlendirir. Bu, proxy açısından en basit seçenektir, ancak gRPC trafiğini analiz etme, başlık ekleme veya istek düzeyinde yük dengeleme yeteneğinden mahrum bırakır.

gRPC akışları için yük dengeleme: özellikler ve çözümler

gRPC için yük dengeleme, basit bir görev değildir ve bunun nedeni şudur. HTTP/1.1'de her istek ayrı bir TCP bağlantısıdır (veya bir havuzdan bağlantı), bu nedenle yük dengeleyici istekleri arka uçlara kolayca dağıtır. HTTP/2'de bir TCP bağlantısı birçok akışı çoklayabilir - eğer yük dengeleyici TCP düzeyinde çalışıyorsa, bir bağlantının tüm akışları tek bir arka uca yönlendirilir.

gRPC için bu, eğer istemci bir HTTP/2 bağlantısı kurmuşsa ve üzerinden 100 RPC isteği gönderiyorsa, TCP yük dengelemesi ile tüm 100 isteğin tek bir arka uç örneği tarafından işleneceği anlamına gelir. Diğer arka uçlar boşta kalacaktır. Çözüm, HTTP/2 akışları düzeyinde yük dengelemesidir (L7 yük dengelemesi).

gRPC için yük dengeleme algoritmaları

Algoritma	gRPC için uygun	Açıklama
Round Robin	✅ Evet	Benzer işleme sürelerine sahip tekil RPC'ler için iyidir
Least Connection	✅ En iyi seçim	Aktif akışları dikkate alır, yükü eşit şekilde dağıtır
Random	⚠️ Şartlı	Çok sayıda istek olduğunda çalışır, az sayıda istek olduğunda dengesizdir
IP Hash	❌ Kötü	İstemciyi tek bir arka uca bağlar, L7'de anlamı yoktur
Pick First (gRPC yerleşik)	❌ Üretim için değil	Tüm istekler ilk mevcut sunucuya gider

gRPC'de istemci yük dengelemesi

gRPC, istemci yük dengelemesini destekler - istemci, isteği hangi sunucuya göndereceğine kendisi karar verir. Bu, TCP çoklaması sorununu aşmayı sağlar. Hizmet keşfi için birden fazla A kaydı veya özel çözücüler (Consul, etcd) kullanılır. Go'da istemci yük dengelemesi için bir örnek:

import (
    "google.golang.org/grpc"
    "google.golang.org/grpc/balancer/roundrobin"
)

// DNS üzerinden round-robin yük dengelemesi ile istemci
conn, err := grpc.Dial(
    "dns:///grpc-service.internal:50051",
    grpc.WithDefaultServiceConfig(
        `{"loadBalancingConfig": [{"round_robin":{}}]}`
    ),
    grpc.WithTransportCredentials(creds),
)

// Least-connection ile istemci (gRPC >= 1.58'de mevcut)
conn, err := grpc.Dial(
    "dns:///grpc-service.internal:50051",
    grpc.WithDefaultServiceConfig(
        `{"loadBalancingConfig": [{"least_request":{}}]}`
    ),
    grpc.WithTransportCredentials(creds),
)

gRPC için dış proxy: ne zaman ve neden gereklidir

Nginx, Envoy, HAProxy gibi iç proxy bileşenlerinin yanı sıra, mikro hizmet mimarisinde bazen dış proxy sunucularını kullanma ihtiyacı doğar - örneğin, trafiği belirli bölgeler üzerinden yönlendirmek, ağ kısıtlamalarını aşmak veya çıkış bağlantılarını izole etmek için. Temel senaryoları inceleyelim.

Senaryo 1: Coğrafi dağıtılmış mikro hizmetler

Mikro hizmetleriniz farklı bölgelerde (örneğin, bir kısmı Avrupa'da, bir kısmı ABD'de) yer alıyorsa ve gRPC bağlantılarının hangi IP adresi üzerinden kurulduğunu kontrol etmeniz gerekiyorsa, dış proxy'ler öngörülebilir yönlendirme sağlamada yardımcı olabilir. Bu tür görevler için veri merkezi proxy'leri uygundur - bunlar, gRPC'nin gecikmelere duyarlılığı için kritik olan kararlı IP adresleri ve yüksek bağlantı hızı sağlar.

Senaryo 2: Çıkış trafiğinin izole edilmesi

Bazı kurumsal ortamlarda, tüm çıkış trafiği kurumsal bir proxy üzerinden geçmelidir. Dış gRPC hizmetlerine (örneğin, gRPC kullanan Google Cloud API'leri) erişmesi gereken gRPC istemcileri için bu zorluklar yaratır. Çözüm, kurumsal proxy üzerinden bir CONNECT tüneli yapılandırmaktır.

Go'da HTTP CONNECT proxy üzerinden çalışacak şekilde gRPC istemcisinin yapılandırılmasına bir örnek:

import (
    "net"
    "net/http"
    "golang.org/x/net/proxy"
    "google.golang.org/grpc"
)

// gRPC için SOCKS5 proxy kullanımı
proxyDialer, _ := proxy.SOCKS5(
    "tcp",
    "proxy.example.com:1080",
    &proxy.Auth{User: "user", Password: "pass"},
    proxy.Direct,
)

conn, err := grpc.Dial(
    "grpc-service.example.com:443",
    grpc.WithContextDialer(func(ctx context.Context, addr string) (net.Conn, error) {
        return proxyDialer.Dial("tcp", addr)
    }),
    grpc.WithTransportCredentials(creds),
)

Senaryo 3: Test etme ve geliştirme

Mikro hizmetlerin geliştirilmesinde, genellikle hizmetlerin farklı ağ ortamlarından nasıl davrandığını test etmeniz gerekir - yüksek gecikme ile hizmetin nasıl yanıt verdiğini kontrol etmek veya coğrafi bağımlı mantığı test etmek gibi. Bu tür görevler için konut proxy'leri kullanışlıdır; bunlar, gerçek ev kullanıcılarının IP'leri ile belirli bölgelerden gelen istekleri taklit etmeyi sağlar.

gRPC'yi proxy üzerinden yapılandırırken karşılaşılan tipik hatalar ve bunların giderilmesi

gRPC'yi proxy üzerinden yapılandırırken geliştiricilerin karşılaştığı en yaygın sorunları ve bunların çözüm yollarını inceleyelim.

Hata 1: "transport: beklenmedik content-type alındı"

Neden: Proxy, gRPC yanıtı yerine hata ile ilgili bir HTML sayfası (örneğin, 502 Bad Gateway) döndürür. gRPC istemcisi HTML'yi işleyemez ve bu hatayı verir.
Çözüm: Arka ucun erişilebilir olduğundan emin olun. Proxy düzeyinde gRPC hatalarının işlenmesini ekleyin (yukarıdaki Nginx örneğinde error502grpc bloğu ile gösterildiği gibi).

Hata 2: Bağlantı 60-120 saniye içinde kesiliyor

Neden: Proxy, idle bağlantıları zaman aşımına uğratır. Klasik değerler: AWS ELB - 60 saniye, Nginx varsayılan olarak - 60 saniye.
Çözüm 1: Proxy üzerindeki zaman aşımını artırın (yukarıdaki örneklerde gösterildiği gibi).
Çözüm 2: gRPC istemcisinin tarafında keepalive yapılandırması ayarlayın:

import "google.golang.org/grpc/keepalive"

kaParams := keepalive.ClientParameters{
    Time:                30 * time.Second, // Her 30 saniyede bir ping
    Timeout:             10 * time.Second, // 10 saniye yanıt bekle
    PermitWithoutStream: true,             // Aktif RPC olmadan bile ping at
}

conn, err := grpc.Dial(
    "grpc-service:50051",
    grpc.WithKeepaliveParams(kaParams),
    grpc.WithTransportCredentials(creds),
)

Hata 3: HTTP/2 uyumsuzluğu (ALPN hatası)

Neden: Proxy veya ara donanım ALPN (Application-Layer Protocol Negotiation) desteklemiyor veya h2, desteklenen protokoller listesine dahil edilmemiştir.
Çözüm: Proxy'nin TLS yapılandırmasında h2 protokolünün açıkça belirtildiğinden emin olun: alpn h2,http/1.1 (HAProxy) veya listen 443 ssl http2 (Nginx).

Hata 4: Akış donuyor - veriler gelmiyor

Neden: Proxy, yanıtı önbelleğe alır ve yalnızca tamamlandıktan sonra istemciye gönderir. Bu, proxy_buffering on ile yapılandırılan proxyler için tipik bir sorundur.
Nginx için çözüm:

location / {
    grpc_pass grpc://backend;
    
    # gRPC akışları için önbellekleme devre dışı bırakma
    grpc_buffer_size 0;
    
    # Veya normal proxy_pass için:
    proxy_buffering off;
    proxy_cache off;
}

gRPC üzerinden proxy tanılaması kontrol listesi

Sonuç

gRPC'yi proxy üzerinden yapılandırmak, HTTP/2'nin HTTP/1.1'den temel farklılıklarını anlamayı gerektirir: akışların çoklanması, uzun süreli bağlantılar, HTTP/2 trailerları ve ALPN müzakeresi. Klasik HTTP proxy'ler, gRPC ile özel bir yapılandırma olmadan çalışmaz - ya HTTP/2'yi destekleyen bir L7 proxy (Nginx 1.13.10+, Envoy, HAProxy 1.9.2+) ya da TCP CONNECT tünelleme gereklidir.

Üretim ortamı için Envoy önerilir - mikro hizmet mimarisi için özel olarak geliştirilmiştir, gRPC'yi yerel olarak destekler, her RPC yöntemi için ayrıntılı metrikler toplar ve çoğu service mesh çözümünün temelini oluşturur. Nginx, zaten bir API Gateway olarak kullanıyorsanız ve yeni bir bileşen eklemeden gRPC desteği eklemek istiyorsanız iyi bir seçimdir. HAProxy, performansın kritik olduğu durumlarda ve yapılandırmasına aşina iseniz uygundur.

Seçtiğiniz proxy ne olursa olsun, üç kural değişmez: uzun süreli akışlar için zaman aşım sürelerini artırın, yanıt önbelleklemesini devre dışı bırakın ve istemcide keepalive yapılandırmasını ayarlayın. Bu üç ayar, gRPC'yi proxy üzerinden kullanırken karşılaşılan sorunların %80'ini çözer.

Eğer mimarinizde gRPC hizmetlerinin dış ağlar üzerinden etkileşimde bulunması gerekiyorsa veya trafiği belirli bölgeler üzerinden yönlendirmek istiyorsanız, veri merkezi proxy'lerine dikkat edin - bunlar, gRPC'nin ikili protokolü ve gecikmelere duyarlılığı için kritik olan kararlı IP adresleri, düşük gecikme ve yüksek bant genişliği sağlar.