前言
讀著讀著內心有越來越多的疑問，因此後面許多 Ambassador 與
大使模式常見架構
an ambassador container brokers (中介器)
看他的名字就知道源於 message broker
[ Service A ] (Producer)
|
| sends
v
+------------------+
| Message Broker |
+------------------+
|
| delivers
v
[ Service B ] (Consumer)
Broker: 在你的 App 所在機器(single node)負責對外溝通的橋樑
App Container <--> Ambassador Container <--> 外部 Service 或 Broker (the rest of the world)
+-------------------------+
| Application Container |
| (你的服務邏輯) |
+-----------+-------------+
|
| localhost:8080
v
+-----------+-------------+
| Ambassador Container |
| (代理到外部 Kafka) |
+-----------+-------------+
|
| kafka://broker-1:9092
v
Kafka Broker / External Service
Ex 你有個靜態網站，想要有登入功能
[ 使用者 ]
|
v
+------------+ <--- HTTPS 請求
| Ambassador |
| Container | <--- 負責：登入驗證、JWT 驗證、轉發
+------------+
|
| 認證通過才轉發
v
+-------------+
| Static Site | (nginx or Hugo 靜態文件 server)
+-------------+
Ex: k8s Service Mesh (like Istio)
🔍 回顧一下：什麼是 Ambassador Pattern？
一個幫助應用程式處理和外部服務溝通的中介代理（sidecar/proxy），
讓應用程式不直接對外連線，而是透過這個「Ambassador」做轉發、處理、觀測、重試、加密等功能。 這樣應用本身就可以更簡潔、專注於業務邏輯。
典型用途
- 幫 App 呼叫外部 API
- 跟資料庫或分片系統溝通（sharded services）
- 處理 TLS、安全驗證
- 設定 timeout / retry / fallback
- 插入 tracing / metrics 等可觀測性的遙測數據
- 負責 routing 到外部系統或特定 shard
Ambassador 的位置可以在：
- Client-side（應用程式旁）
- Server-side（統一入口）
Using an Ambassador to Shard a Service
常見的 sharded service 模式
single-node 連接到 sharded service 的方式
我們有一群負責儲存資料的 sharded service，要怎麼把它跟 frontend or middleware 結合？
分成多個 shard（分片儲存），我們就需要一些「邏輯」來把每個 request route 到正確的 shard。但這樣的邏輯不容易加入到原本只連接單一資料庫的程式碼裡。
而且，sharding 會讓開發環境（通常只有一個 shard）和正式環境（有很多 shard）之間的設定差異變得很大，難以共用設定檔。
兩種 Ambassador 解法：
✅ 1. Server-side Ambassador（透過 Load Balancer）
- 放在 server 端前面（例如一個負責分流的 load balancer）
- client 只連一個統一的 endpoint
- Load balancer 會根據請求內容，把請求送到對應的 shard
🔄 好處： client 不用改程式
⚠️ 壞處： sharded service 需要自己部署這個智慧的 Load Balancer，架構變複雜
✅ 2. Client-side Ambassador（由 client 自己分流）
- client 內部有分流邏輯（例如根據 user_id 計算 shard）
- client 自己決定要連到哪一個 shard
🔄 好處： sharded service 很簡單，只負責處理請求
⚠️ 壞處： 每個 client 都要知道 shard 資訊、實作 routing 邏輯，client 開發變難
🧪 舉例說明：會員資料查詢
假設你有一個「查詢會員資料」的 API，資料分成 3 個 shard（A, B, C）儲存：
Server-side Ambassador 做法：
Client 發出 request 到：
https://user-service.com/user/12345
後面的 load balancer 會依照 userId 自動轉發到正確的 shard（例如 Shard B）
Client-side Ambassador 做法：
# client 自己決定連哪個 shard
shard = hash(user_id) % 3
url = f"http://user-shard-{shard}/user/{user_id}"
a sharded ambassador proxy
從 App 端接收所有 request，route requset 到適當的 分片儲存空間，單純指向一個後端的感覺一樣．
Ambassador vs API Gateway
API Gateway 可以被視為 Ambassador Pattern 的一種實作。
但兩者在用途與範疇上略有不同，API Gateway 是 Ambassador 的具體形式之一，但不是唯一的形式。
API Gateway 是什麼？
API Gateway 是一個專門作為「整個系統入口」的元件，常見功能：
| 功能 | 說明 |
|---|---|
| 路由 | 根據路徑將請求分發給不同微服務 |
| 認證/授權 | 檢查 API token、OAuth、JWT 等 |
| Rate limiting | 限流、熔斷、防止濫用 |
| 跨服務聚合 | 一個 API 呼叫對應多個微服務合併回應 |
| 加密/解密 | 處理 TLS、Header 重寫 |
| 日誌與監控 | 為 observability 收集資料 |
常見 API Gateway 工具有：
- Kong
- NGINX
- Amazon API Gateway
- Apigee
- Envoy Gateway
- Ambassador（是個產品名稱，也是這個 pattern）
[ Client App ]
|
+-----------------------------+
| API Gateway (入口層) | <- 這裡是一種 server-side Ambassador
+-----------------------------+
| |
[ Service A ] [ Service B ]
這裡是 client-side Ambassador
[ Client App ]
|
+-------------+
| Ambassador | <- 例如 sidecar、local proxy
+-------------+
|
[ Service X ]
Ambassador vs AWS ALB
AWS ALB（Application Load Balancer）不是完整意義下的 Ambassador，但在某些場景下可以扮演「Ambassador pattern 的 server-side 實作」角色。
它本身更像是 具備 routing 能力的 Layer 7 Load Balancer，
在 Sharding、微服務、API Gateway 架構中，可以應用為一種 Ambassador 實作工具。
AWS ALB 雖然不是為 Ambassador Pattern 設計的，但在「以路由為核心的 server-side 分流場景」下，它可以實作 Ambassador 的角色
不過它缺乏完整 proxy 層所需要的 observability、安全性、retry 控制等功能，無法完全取代像 Envoy 或 Istio 這類 full-featured Ambassador 實作。
Istio / Envoy
Istio 和 Envoy 可以看作是 Ambassador Pattern 的一種實作，特別是用在微服務之間的流量控制與觀測。
🧱 一、什麼是 Envoy？
Envoy 是由 Lyft 開發的高效能、現代化的 Layer 7 proxy（應用層代理伺服器）：
| 特性 | 說明 |
|---|---|
| 高性能 | C++ 編寫，支援大規模服務流量 |
| 支援 gRPC/HTTP | 可用於微服務 HTTP / gRPC 溝通 |
| 熔斷 / Retry / 超時 | 內建、可配置 |
| Tracing / Metrics | 支援 Zipkin, Jaeger, Prometheus 等 |
| mTLS / JWT 驗證 | 支援零信任架構 |
你可以把 Envoy 想成是一個超強的「流量管家」
👉 負責幫應用決定「去哪裡、怎麼去、去的時候加什麼資訊」。
🧱二、什麼是 Istio？
Istio 是一個基於 Envoy 的 Service Mesh 控制平面（Control Plane），由 Google、IBM、Lyft 合作開發。
| 組成元件 | 功能 |
|---|---|
| Envoy | Data Plane，Sidecar Proxy，攔截流量 |
| Istiod | Control Plane，發憑證、下設定、註冊服務等 |
| Kiali / Jaeger | 觀測工具整合（dashboard, tracing） |
在 Kubernetes 上，每個 Pod 都會被自動注入一個 Envoy Sidecar，
所有的服務之間流量都會經過這個 Envoy。
🧱三、Istio + Envoy = Ambassador Pattern
✅ 它們實作了 Ambassador Pattern，甚至更進一步：
| 特性 | Ambassador Pattern | Istio + Envoy |
|---|---|---|
| 代理外部連線 | ✅ | ✅（sidecar） |
| timeout / retry 設定 | ✅ | ✅ 可 declarative 設定 |
| TLS / 認證 | ✅ | ✅ 自動 mTLS |
| tracing / observability | ✅ | ✅ Jaeger, Prometheus |
| 可與 shard 或其他系統溝通 | ✅ | ✅（具 routing 能力） |
| 較通用的應用場景 | ✅ | ✅ 更適合微服務架構 |
可以說 Envoy 是 Ambassador 的實體，Istio 是它的管控大腦。
🧪 實例：應用與用法
你有一個前端 service 要呼叫 user-service：
- 請求先進入 Envoy sidecar（前端 pod 中）
- Envoy 根據路由規則，決定送到哪個 user-service pod
- Envoy 記錄 log、metrics、trace
- 請求抵達 user-service 的 Envoy sidecar，再轉給內部服務
- 所有流量都在 envoy <–> envoy 之間 mTLS 加密
📌 小結
Istio + Envoy 是 Ambassador Pattern 的典型實作，特別是用在微服務環境中。
Envoy 負責實際攔截與代理流量，Istio 則負責告訴 Envoy 要怎麼處理流量。
這樣讓應用程式可以完全專注在商業邏輯，不用管 TLS、重試、分流、觀測等基礎功能。
Hands On: Implementing a Sharded Redis
Client Redis Driver
↓ (GET user:12345)
[ Twemproxy (proxy)]
↓
[Consistent Hash → redis-1]
↓
[Redis Pod redis-1]
↓ (GET user:12345)
Using an Ambassador for Service Brokering
使用 Ambassador pattern 來實作 Service Brokering，幫 client 找到對應的 service instance
目標：讓應用程序具備可移植性 portable，能在多個環境中正常運作（如公共雲、物理數據中心、私有雲）。 挑戰：在不同環境中，服務發現（Service Discovery）與配置方式可能不同。 舉例：公共雲環境下的 MySQL 可能是 SaaS（軟體即服務）。私有雲可能需要動態啟動新的 VM 或容器來運行 MySQL。
服務發現與代理
服務發現（Service Discovery）： 應用程序需要能夠根據所處環境自動發現並連接到適當的服務（例如 MySQL）。 這需要一個系統去 introspect（檢測）環境並建立正確的服務連結。 服務代理（Service Brokering）： 用於管理服務發現的系統通常被稱為 Service Broker。 它負責發現正確的服務（如 MySQL）並建立連結。
Ambassador Pattern 的作用 Ambassador Pattern 協助分離應用程序邏輯與服務代理邏輯： 應用容器： 總是通過 localhost 連接到服務（如 MySQL），無需關心環境差異。 服務代理 Ambassador： 負責檢測運行環境，並動態代理到正確的服務（如 MySQL SaaS 或 VM 中的 MySQL）。 簡化應用的服務交互，提升應用的可移植性。
Ambassador Pattern 的價值 解耦：分離應用程序邏輯與環境配置/服務代理邏輯。 簡化：應用僅需連接 localhost，其他細節由 Ambassador 管理。 可移植性：讓應用程序在不同環境（如雲、數據中心）中平滑運行。
關鍵流程 應用程序： 始終連接 localhost（例如 localhost:3306）。 無需感知實際服務配置。 Ambassador： 負責檢測環境（例如在公共雲檢測 SaaS，或在私有雲啟動 VM 容器）。 配置與代理服務，確保應用程序正確連接到 MySQL。
步驟 1：應用容器 應用容器：應用程序運行在容器內，直接使用本地連接（localhost:3306）來訪問 MySQL。 簡化配置：應用程序不需要知道 MySQL 服務的實際位置或環境差異，它只需始終連接到 localhost:3306。
步驟 2：服務代理 Ambassador Ambassador： Ambassador 是服務代理，負責處理應用程序與 MySQL 服務之間的中介工作。它接收到應用程序的請求後，開始進行以下操作： 檢測環境：透過與 服務代理（Service Broker）交互，檢測應用程序運行所在的環境（例如公有雲、私有雲或本地數據中心）。 發現服務：動態查找正確的 MySQL 實例，根據運行環境調整連接策略。
步驟 3：MySQL 實例 建立連接： Ambassador 確定正確的 MySQL 實例（例如公有雲中的 SaaS MySQL，或私有雲中運行在 VM 或容器內的 MySQL）後，建立與該實例的連接，並代理應用程序的所有請求到 MySQL 實例。
應用程序不需要關注底層的 MySQL 部署細節或環境配置，只需要通過 Ambassador 簡單地連接到 localhost:3306。
Using an Ambassador to Do Experimentation or Request Splitting
目的: 無痛觀察新版系統
使用 Request Splitting（請求分流） 技術，把每一筆請求同時送到正式系統（Production）與實驗系統（Experimental），這種作法稱為 tee。
「tee」是一種把資料複製一份、同時送往兩個不同目的地的技術，類似 Unix 指令 tee 的行為。
cat data.txt | tee output.txt
Request Splitting 是實作 tee 的方法之一。 通常透過 Proxy、Ambassador、Service Mesh（如 Envoy）來達成「同時送兩份請求」的行為。
Client → Ambassador
↙ ↘
| Production System | | Experimental System |
Ambassador 接到一筆請求，會：
→ 主路徑：將請求正常處理並送往正式服務
→ tee 路徑：複製這筆請求，送往一個實驗版本，但不讓它回應給使用者，只觀察輸出（Log, Metrics）
這在 Envoy 或 Istio 中，可以透過 Mirroring / Shadow Traffic 設定來實現。
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: my-app
spec:
hosts:
- my-app.default.svc.cluster.local
http:
- route:
- destination:
host: my-app-v1.default.svc.cluster.local
weight: 100 # 所有 request 正常進入 production v1
mirror:
host: my-app-v2.default.svc.cluster.local
mirrorPercentage:
value: 100.0 # 將 100% request 複製一份給 v2（實驗系統）
Hands On: Implementing 10% Experiments
nginx as the ambassador
