I02 · Gateway / Service Mesh 詳細 ROADMAP
計畫文件，不會被 Quartz 渲染。
回主 roadmap → infra/ROADMAP.md
章節目標
Request 過了 Edge 層（DNS/CDN/LB/TLS 終止）後，第一個碰到的應用層設施。Gateway 負責：認證 / 路由 / rate limit / 版本管理 / protocol translation。Service Mesh 負責服務間通訊（east-west traffic）。
跟 I01 的分工：I01 處理 north-south traffic 的網路面（DNS / TLS / LB）；I02 處理 gateway 層的應用路由。
🌱 基本介紹
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 01 | Gateway 跟 Service Mesh 的差異 | 01-gateway-vs-mesh | 🌱 | Gateway 對外（north-south），Mesh 對內（east-west）；功能 overlap 與分工 |
❓ 為什麼需要
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 02 | 為什麼每個 service 自己做 auth/rate-limit 會出問題 | 02-why-centralize-at-gateway | 🌱 | 一致性 / 漏洞修補 / policy 下放複雜度；把橫切面集中到 Gateway |
| 03 | 為什麼微服務之間需要 Service Mesh | 03-why-need-mesh | 🌱 | mTLS / observability / retry / circuit breaker 的通用需求；app 層硬 code 這些很痛 |
| 04 | 為什麼 Kong / Istio 複雜度高還被採用 | 04-why-complex-still-adopted | 🌱 | 可觀察性、跨 team 治理、debug 時間的權衡 |
🕰️ 演進
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 05 | API Gateway 演進 | ⛔️ infra/gateway-mesh/21-api-gateway | 🌿 | 跨系列（原始篇） |
| 06 | Service Mesh 演進 | 06-mesh-evolution | 🌱 | Netflix OSS library → Istio sidecar → eBPF mesh（Cilium）；每代解什麼 |
| 07 | Gateway / Mesh 演進驅動力 | 07-gateway-mesh-evolution-drivers | 🌱 | 單體 nginx 撞微服務複雜度 → API Gateway；Gateway 單點 scaling 撞牆 → Mesh 解耦 east-west；Sidecar proxy overhead 撞牆 → eBPF mesh；每代解前代的複雜度或效能極限 |
🧠 知識型
F02-A API Gateway
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 08 | Gateway 全景選型 | 08-gateway-landscape | 🌱 | Kong / APISIX / Envoy Gateway / AWS API Gateway / Tyk；特性矩陣 |
| 09 | Kong 深入（plugin 架構） | 09-kong-deep | 🌱 | plugin 生命週期、Lua / Go plugin 開發、DB vs DB-less 模式；跟 infra/gateway-mesh/kong/ 案例連動 |
| 10 | 路由策略設計 | 10-routing-strategies | 🌱 | Host / Path / Header / Method；versioning（/v1）；blue-green / canary at gateway |
| 11 | Multi-layer Rate Limit 策略 | 11-multi-layer-rate-limit | 🌱 | 三層 rate limit 分工：CDN（粗粒度 DDoS 級）/ Gateway（per-API-key / per-user）/ Application（business rule-based）；Token bucket vs Sliding window；distributed rate limit（Redis / Kong’s counter-strategy）；跟 I01 #25 DDoS 層呼應 |
| 12 | Gateway Auth（JWT / API Key / mTLS） | 12-gateway-auth | 🌱 | 驗證策略、plugin 化；跟 backend/auth/ B10 分工 |
| 13 | Request / Response Transformation | 13-gateway-transform | 🌱 | header injection / rewrite / body mapping；legacy API 包裝 |
| 14 | gRPC Routing at Gateway | 14-grpc-routing-gateway | 🌱 | Envoy gRPC route、gRPC-Web translation（browser → gRPC backend）、gRPC stream routing；跟 I01 #29 edge gRPC 挑戰分工（I01 是 LB / TLS，這裡是 routing / auth / rate limit） |
| 15 | WebSocket Routing at Gateway | 15-websocket-routing-gateway | 🌱 | Path-based routing、WebSocket Upgrade 處理、auth for WS（query string vs sub-protocol token）、heartbeat / timeout；跟 I01 #30 edge WebSocket 分工 |
| 16 | Protocol Translation（REST ↔ gRPC ↔ GraphQL） | 16-protocol-translation | 🌱 | gRPC ↔ REST（grpc-gateway, Envoy HTTP/JSON transcoder）、REST ↔ GraphQL bridge、跨協議 error/auth mapping；多協議 service 橋接策略 |
F02-B Kubernetes Ingress
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 17 | Ingress Controller 選型 | 17-ingress-controller | 🌱 | Nginx Ingress / Traefik / Istio Gateway / AWS ALB Controller 比較 |
| 18 | Gateway API（新世代） | 18-gateway-api | 🌱 | K8s Gateway API vs Ingress；多 team 共享 cluster 的授權模型 |
| 19 | Ingress 跟 K8s 整合 | 19-ingress-k8s-integration | 🌱 | Service / Endpoint / 健康檢查；跟 infra/k8s/02-k8s-networking 連動 |
F02-C Service Mesh
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 20 | Istio 深入 | 20-istio-deep | 🌱 | Control plane（istiod）、sidecar（envoy）、VirtualService / DestinationRule |
| 21 | Linkerd 深入 | 21-linkerd-deep | 🌱 | 輕量化選擇；Rust 改寫的效能；跟 Istio 的 trade-off |
| 22 | eBPF Mesh（Cilium） | 22-cilium-ebpf-mesh | 🌱 | sidecar-less mesh；效能差異；network policy 整合 |
| 23 | mTLS 自動化 | 23-mesh-mtls | 🌱 | 只講 mesh 自動化機制：sidecar 自動包 mTLS / cert rotation workflow；憑證本身管理見 infra/security-governance/ I06 #17 內部 PKI；Edge ingress TLS 見 infra/network-edge/ I01 #24 |
| 24 | Retry / Circuit Breaker / Timeout at mesh | 24-mesh-resilience | 🌱 | Mesh 層 retry 避免 app 硬 code；跟 backend/api-design/ B09 22-23 分工 |
F02-D Service Mesh vs Service Discovery
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 25 | Service Mesh vs Service Discovery 差異與互補 | 25-mesh-vs-service-discovery | 🌱 | 概念分工釐清：Service Discovery = 「X 服務在哪」（DNS / Consul / etcd）；Service Mesh = 「X 服務怎麼通訊」（mTLS / retry / observability）；兩者互補而非取代；跟 infra/compute/ I03 #26 Service Discovery 連動 |
F02-E API Governance（企業層 API 治理）
Gateway 處理 routing / auth / rate limit；API Governance 處理跨 team / 跨產品的 API 生命週期——誰擁有、怎麼版本化、內外 API 分治、deprecation 流程。大企業 infra 這是獨立 discipline（Apigee / Kong Enterprise / MuleSoft）。
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 26 | API 目錄與治理 | 26-api-catalog-governance | 🌱 | API catalog tools（Backstage / SwaggerHub / Stoplight / Apigee）；ownership 映射；discoverability；跟 infra/platform-engineering/ I10 Service Catalog 連動 |
| 27 | API 版本化與 Deprecation 策略 | 27-api-versioning-deprecation | 🌱 | URL versioning vs header / accept header；sunset policy；deprecation timeline；backward-compat 責任劃分；跟 backend/api-design/ B09 分工 |
| 28 | 內部 API vs 外部 API 治理差異 | 28-internal-vs-external-api | 🌱 | 內外 API 的 SLA / rate limit / auth / docs 要求差異；BFF 的定位；跟 B2B partner API |
F02-F 實戰應用
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 29 | Gateway + Mesh 組合架構 | 29-gateway-mesh-combined | 🌱 | 外部 Kong + 內部 Istio；責任切割；重複功能的取捨 |
| 30 | BFF（Backend for Frontend）Pattern | 30-bff-pattern | 🌱 | BFF 的位置選擇：獨立 service vs Gateway plugin vs GraphQL schema；每 client（web / mobile / IoT）一個 BFF 的 trade-off；跟 backend/api-design/ B09 BFF 分工 |
| 31 | GraphQL Federation at Gateway | 31-graphql-federation | 🌱 | Apollo Router / Hasura / Wundergraph；多 GraphQL sub-schema 合併；N+1 問題；跟 REST gateway 組合架構 |
| 32 | API Gateway 資安（吸收 micro-service/51） | ⛔️ backend/micro-service/51-api-gateway-security | 🌿 | 跨系列 |
| 33 | 微服務資安（吸收 micro-service/50） | ⛔️ backend/micro-service/50-microservice-security | 🌿 | 跨系列 |
🔧 小實作注意事項
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 34 | 本機起 Kong stack | 34-local-kong-stack | 🌱 | Docker Compose + Postgres + Kong + sample upstream；完整走一次 plugin 配置 |
| 35 | K8s 裡起 Istio + sample app | 35-istio-k8s-demo | 🌱 | istioctl install + Bookinfo demo；VirtualService 設計 |
| 36 | Kong 踩坑案例（吸收 ops-notes） | ⛔️ infra/gateway-mesh/kong/ | 🌿 | 跨系列（8 個實戰案例） |
💣 Anti-pattern
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 37 | Gateway / Mesh Anti-patterns | 37-gateway-mesh-antipatterns | 🌱 | 把商業邏輯塞 Gateway（plugin 一團亂）；Mesh 用了但沒做 mTLS（白花 overhead）；Gateway 單點沒 HA；DB-backed Kong 沒 tune；sidecar resource 沒設 limit；盲目上 Istio 5 人小團隊撐不住；多協議 service 沒用 protocol translator 直接讓 client 自己轉；BFF 做成第二個 monolith |
🧰 對應檢查工具
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 38 | Gateway / Mesh 工具 | 38-gateway-mesh-tooling | 🌱 | Kong Manager / Konga、Istioctl / Kiali（mesh 視覺化）、Envoy admin、istioctl proxy-status、grpcurl / Postman（protocol test）、Apollo Studio（GraphQL Federation） |
📎 補充
| # | 主題 | Slug | Stage | 大綱 |
|---|
| S01 | Gateway 做 AI Agent 的 routing？ | s01-gateway-for-ai-agents | 🌱 | LLM provider proxy（OpenAI / Anthropic / local model）；token counting 集中化；跟 Portkey / LiteLLM 對照 |
章節進度統計
- 知識主題：34 + 1 補充 = 35 項（2026-04 新增 Multi-layer Rate Limit、gRPC Routing、WebSocket Routing、Protocol Translation、BFF Pattern、GraphQL Federation 6 題；BFF/GraphQL 從補充升主知識）
- 🌿 growing：1（既有 infra/）+ 3（跨系列）= 4
- 🌱 seed：31
跨系列連結
- →
infra/gateway-mesh/21-api-gateway（原始篇）
- →
infra/gateway-mesh/kong/ 8 案例（實戰踩坑）
- →
backend/auth/ B10（Gateway auth 分工）
- →
backend/api-design/ B09 21-23（rate limit / retry / circuit breaker 分工）
- →
backend/micro-service/50-microservice-security、51-api-gateway-security
- →
infra/k8s/02-k8s-networking（K8s Ingress）
- → I01 Edge（request 從 I01 到 I02）
- → I03 Compute（request 從 I02 到 I03 workload）