وقتی از مونولیت به microservice می‌روید، دو درد تقریباً همیشه ظاهر می‌شود:

Networking  →  discovery، retry، timeout، mTLS، LB
Observability →  کدام hop کند است؟ کجا ۵xx می‌آید؟

Envoy برای همین ساخته شد — ابتدا در Lyft، امروز موتور تقریباً هر service mesh و بسیاری از API gatewayهای مدرن:

An open source edge and service proxy, designed for cloud-native and AI-native applications

نسخه پایدار اعلام‌شده روی سایت: 1.39.1. فلسفه رسمی:

The network should be transparent to applications. When problems do occur it should be easy to determine the source.

CNCF Graduated — ۲۸ نوامبر ۲۰۱۸ (ورود Incubating سپتامبر ۲۰۱۷). Airbnb، Netflix، Google، Microsoft، Uber، Stripe، Datadog و ده‌ها شرکت بزرگ روی آن سوارند.

مشکل: شبکه در معماری توزیع‌شده

Library در هر زبان:
  upgrade دردناک، polyglot سخت، behavior ناهمسان

Hardware / cloud LB alone:
  L4 عالی — L7 app semantics محدود

Envoy (out-of-process):
  یک binary کنار هر سرویس یا در edge
  یک data plane برای Java/Go/Python/…
  stats + tracing یکسان

Envoy از درس‌های NGINX، HAProxy و load balancerهای سخت‌افزاری/ابری آمده — اما برای SOA بزرگ و الان AI traffic طراحی شده است.

Envoy چیست؟

طبق What is Envoy:

• L7 proxy و communication bus برای معماری سرویس‌گرا
• Out-of-process — کنار اپ، نه داخل library
• L3/L4 + HTTP L7 filter chains — pluggable
• مناسب front/edge proxy و service-to-service mesh
• Dynamic configuration از طریق xDS APIs
• Best-in-class observability — stats، access log، distributed tracing

Site: envoyproxy.io
Docs: docs
Repo: github.com/envoyproxy/envoy

زبان: C++ با عملکرد بالا و footprint نسبتاً کوچک
License: Apache 2.0

شعار مدرن سایت: one engine برای cloud-native و AI-native — streaming LLM، agent-to-tool، agent-to-agent، کنار ترافیک کلاسیک.

تاریخچه

معماری مفهومی

Downstream client
       │
       ▼
   Listener(s)  ── filter chain (TCP/HTTP)
       │
       ▼
   HTTP Connection Manager (HCM)
       │  HTTP filters: auth, ratelimit, …
       ▼
   Router filter ──► Route → Cluster
       │
       ▼
   Load balancer → Endpoint (upstream)
       │
       ▼
   Upstream service / LLM provider / …

مفاهیم کلیدی

جزئیات مسیر درخواست: Life of a Request.

Life of a request (خلاصه)

1. اتصال downstream به Listener
2. codec (HTTP/1.1، HTTP/2، HTTP/3) stream می‌سازد
3. HTTP filter chain اجرا می‌شود (custom filters → … → router)
4. Route از RouteConfiguration انتخاب می‌شود (قابل invalidate توسط filter)
5. Cluster انتخاب؛ load balancer یک endpoint می‌چیند
6. connection pool upstream؛ درخواست forward می‌شود
7. پاسخ از مسیر filterها برمی‌گردد؛ stats و tracing ثبت می‌شود

Health: ترکیب service discovery (eventually consistent) + active health check + outlier detection (passive).

xDS: config بدون restart

Envoy می‌تواند static YAML بخورد؛ در مقیاس، control plane از طریق xDS config می‌فرستد:

نتیجه: تغییر routing، cluster، policy on the fly — بدون restart و ideally بدون drop connection. این همان «runtime programmable» در سایت رسمی است.

Control planeهای معروف روی Envoy: Istio، Envoy Gateway، Contour، و بسیاری platformهای داخلی.

قابلیت‌های شبکه و پروتکل

• HTTP/1.1 ↔ HTTP/2 شفاف در هر دو جهت
• HTTP/3 (upstream/downstream؛ ترجمه بین نسخه‌ها)
• gRPC first-class روی multiplexed HTTP/2+
• TCP/UDP proxy در لایه L3/L4
• فیلترهای خاص برای Redis، MongoDB، Postgres، DynamoDB sniffing و غیره

Load balancing پیشرفته

• weighted round-robin، Maglev، least-request، random، …
• automatic retries
• circuit breaking
• global rate limiting (سرویس خارجی)
• request shadowing (mirror)
• zone-aware load balancing
• outlier detection

امنیت

• TLS termination و origination
• mTLS و SNI
• فیلترهای JWT، RBAC، ext_authz (external authorization)
• SDS برای چرخش certificate بدون restart

با cert-manager می‌توان certهای edge را صادر کرد؛ در mesh، معمولاً control plane (مثلاً Istio) identity و mTLS را مدیریت می‌کند.

Observability

هدف اصلی: شفاف کردن شبکه.

• Stats غنی برای همه subsystemها (statsd-compatible و sinks دیگر)
• Access logs ساخت‌یافته
• Distributed tracing (Zipkin، Jaeger، OpenTelemetry providers)
• Admin port برای introspection

وقتی همه ترافیک از Envoy می‌گذرد، bottleneck و error budget قابل‌دیدن می‌شود — همان چیزی که در microservice بدون proxy یکسان سخت است.

Extensibility

بدون fork کردن Envoy:

Envoy AI Gateway از ExtProc برای منطق مدل، rate limit توکنی، و transform بین providerها استفاده می‌کند.

نقش‌های استقرار

۱. Edge / Front proxy

TLS، L7 routing، rate limit، WAF-ish filters — جایگزین/مکمل nginx در سناریوهای dynamic و mesh-aligned.

۲. Sidecar / Service mesh data plane

کنار هر Pod؛ اپ فقط به localhost حرف می‌زند. Istio و مشابه روی همین engine سوارند. در کنار Cilium اغلب L3/L4 eBPF + L7 Envoy ترکیب می‌شود (بسته به طراحی mesh).

۳. Middle proxy / gateway

API gateway، ingress، north-south و east-west.

۴. AI-native gateway

ترافیک LLM: streaming، long-lived connections، backendهای گران inference، cost/token — first-class در روایت فعلی پروژه.

Envoy Gateway و Envoy AI Gateway

Envoy Gateway

پیاده‌سازی Kubernetes Gateway API با Envoy به‌عنوان data plane:

• GatewayClass / Gateway / HTTPRoute
• BackendTrafficPolicy، ClientTrafficPolicy
• مدیریت lifecycle پروکسی‌ها روی cluster

برای تیم‌هایی که به‌جای annotationهای Ingress قدیمی، API استاندارد Gateway می‌خواهند.

Envoy AI Gateway

روی همان foundation:

• AIGatewayRoute — مسیریابی یکپارچه به چند GenAI provider
• AIServiceBackend — OpenAI-compatible، Bedrock، self-hosted، …
• token-aware rate limiting، provider fallback
• headerهایی مثل x-ai-eg-model برای انتخاب مدل/backend
• ExtProc در دو فاز (router-level و upstream-level) برای transform و auth هنگام retry به provider دیگر

اسناد: aigateway.envoyproxy.io

نمونه config حداقلی (مفهومی)

Static listener + route به یک cluster:

static_resources:
  listeners:
  - name: listener_0
    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: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: backend
              domains: ["*"]
              routes:
              - match: { prefix: "/" }
                route:
                  cluster: service_cluster
          http_filters:
          - name: envoy.filters.http.router
  clusters:
  - name: service_cluster
    connect_timeout: 0.25s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: service_cluster
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address: { address: my-service, port_value: 80 }

در Kubernetes معمولاً این YAML را دستی نگه نمی‌دارید — Envoy Gateway / Istio / control plane آن را از CRDها می‌سازد.

اجرا و عملیات

# باینری / container رسمی
docker pull envoyproxy/envoy:v1.39.1

envoy -c /etc/envoy/envoy.yaml

# Admin (پیش‌فرض اغلب 9901 — در production محدود کنید)
curl localhost:9901/stats
curl localhost:9901/clusters
curl localhost:9901/config_dump

Best practices

1. Admin interface را به اینترنت expose نکنید
2. Resource limits و concurrency را با load test تنظیم کنید
3. Circuit breaker و timeout واقع‌بینانه — نه defaultهای گشاد
4. Access log + tracing را از روز اول روشن کنید
5. برای mesh، version Envoy را با control plane هم‌تراز کنید
6. SDS و چرخش cert را automate کنید
7. در AI gateway، fallback و token budget را صریح تعریف کنید
8. تغییرات route را از GitOps (Argo CD) اعمال کنید

مقایسه: کجا Envoy، کجا چیز دیگر؟

Envoy جایگزین CoreDNS یا etcd نیست — لایه proxy ترافیک است.

ارتباط با stack شما

Internet / Clients / AI agents
        │
        ▼
  Envoy (edge)  یا  Envoy Gateway / AI Gateway
        │
        ▼
  Services (± Envoy sidecars / Istio)
        │
        ├── [Cilium](/blog/cilium-ebpf-kubernetes-networking/)  L3/L4 + policy
        ├── [CoreDNS](/blog/coredns-kubernetes-dns-guide/)
        ├── [cert-manager](/blog/cert-manager-kubernetes-tls-certificates/)
        └── images از [Harbor](/blog/harbor-cloud-native-registry-guide/)
              ± [Dragonfly](/blog/dragonfly-p2p-image-distribution-guide/) P2P pull

Dapr می‌تواند کنار Envoy باشد: Dapr الگوهای application؛ Envoy (یا mesh) حمل‌ونقل و L7 policy شبکه.

Troubleshooting

curl localhost:9901/server_info
curl localhost:9901/stats/prometheus

چه زمانی Envoy؟

✅ استفاده کنید

• service mesh یا edge با نیاز L7 یکسان
• gRPC / HTTP/2 / HTTP/3 در مقیاس
• observability و policy متمرکز روی data plane
• Gateway API روی Kubernetes (Envoy Gateway)
• ترافیک LLM/agent با streaming و multi-provider

⚠️ شاید نه

• یک وب‌سایت استاتیک ساده → nginx کافی است
• فقط NetworkPolicy بدون L7 → Cilium/Calico
• تیم بدون ظرفیت ops برای proxy و xDS

جمع‌بندی

Envoy همان «universal data plane» است که networking و debugging میکروسرویس — و حالا ترافیک AI — را از داخل هر اپ بیرون می‌کشد و در یک engine قابل‌مشاهده و قابل‌سیاست‌گذاری جمع می‌کند.

قدم بعدی

1. Get Started + یک envoy.yaml static روی localhost
2. Admin /stats و یک route ساده به upstream
3. روی Kubernetes: Envoy Gateway + یک HTTPRoute
4. (اختیاری) Envoy AI Gateway با دو backend مدل و header x-ai-eg-model
5. مقایسه با nginx فعلی برای همان workload — latency و قابلیت مشاهده

منابع

• Envoy — envoyproxy.io
• What is Envoy
• Life of a Request
• CNCF Envoy
• GitHub — envoyproxy/envoy
• Envoy AI Gateway API

منتشر شده در P30Light — بخش زیرساخت و سرور.