Service Connect 概述
AWS ECS Service Connect 是 Amazon ECS 於 2022 年推出的原生服務網格解決方案,旨在簡化微服務之間的通訊。它提供了一種無需額外基礎設施即可實現服務發現、負載平衡和可觀測性的方式。
Service Connect 的核心特點
- 簡化的服務發現:自動處理服務註冊和 DNS 解析,無需手動配置
- 內建負載平衡:提供客戶端負載平衡,無需額外的 Load Balancer
- 統一的可觀測性:自動收集連線指標並整合至 CloudWatch
- 零程式碼變更:應用程式無需修改即可使用服務網格功能
- 與 ECS 深度整合:原生支援 ECS 服務,配置簡單直觀
運作原理
Service Connect 在每個 ECS 任務中注入一個 Envoy Proxy sidecar 容器,負責處理所有進出流量:
| |
與 App Mesh 比較
在 Service Connect 推出之前,AWS App Mesh 是 AWS 上實現服務網格的主要方案。以下是兩者的詳細比較:
功能對比表
| 功能 | Service Connect | App Mesh |
|---|---|---|
| 設定複雜度 | 低(ECS 原生整合) | 高(需額外資源配置) |
| 服務發現 | AWS Cloud Map | AWS Cloud Map |
| Proxy | Envoy(自動管理) | Envoy(手動配置) |
| 流量路由 | 基本負載平衡 | 進階路由規則 |
| 重試策略 | 內建預設值 | 完全可自定義 |
| 斷路器 | 內建 | 完全可自定義 |
| mTLS | 不支援(截至目前) | 支援 |
| 跨帳號/跨叢集 | 不支援 | 支援 |
| 可觀測性 | CloudWatch 整合 | X-Ray、CloudWatch |
選擇建議
選擇 Service Connect 的情境:
- 希望快速實現服務網格功能
- 主要需求是服務發現和基本負載平衡
- 所有服務都在同一個 ECS 叢集中
- 團隊對服務網格經驗較少
選擇 App Mesh 的情境:
- 需要進階流量管理(金絲雀部署、流量分割)
- 需要 mTLS 進行服務間加密
- 跨叢集或跨帳號的服務通訊
- 需要與 EKS 或 EC2 上的服務整合
遷移考量
| |
從 App Mesh 遷移至 Service Connect 時,需要注意:
- Service Connect 目前不支援 mTLS,若有加密需求需另行處理
- 進階路由規則需要在應用層實現
- 遷移過程中可能需要維護兩套配置
Namespace 設定
Cloud Map Namespace 是 Service Connect 的核心元件,所有服務都會註冊到 Namespace 中進行發現。
建立 Cloud Map Namespace
| |
Namespace 類型比較
| 類型 | 用途 | Service Connect 支援 |
|---|---|---|
| HTTP Namespace | 純粹的服務發現 | 完全支援 |
| DNS Private Namespace | VPC 內 DNS 解析 | 部分支援 |
| DNS Public Namespace | 公開 DNS 解析 | 不支援 |
在 ECS Cluster 啟用 Service Connect
| |
使用 AWS Console 建立 Namespace
- 前往 AWS Cloud Map 控制台
- 點選「Create namespace」
- 選擇「API calls」作為實例發現方式
- 輸入 Namespace 名稱(例如:
production) - 完成建立後,在 ECS Cluster 設定中啟用
服務端與客戶端設定
Service Connect 區分兩種角色:服務端(提供服務)和客戶端(呼叫服務)。一個服務可以同時扮演兩種角色。
服務端配置(Server/Producer)
服務端需要定義 portMappings 並設定 Service Connect 配置:
| |
建立服務端 ECS Service:
| |
客戶端配置(Client/Consumer)
客戶端只需啟用 Service Connect,即可透過服務名稱存取其他服務:
| |
服務間通訊
啟用 Service Connect 後,客戶端可以直接使用服務名稱進行通訊:
| |
| |
服務同時作為客戶端和服務端
許多微服務需要同時提供服務並呼叫其他服務:
| |
流量管理與負載平衡
Service Connect 提供內建的客戶端負載平衡功能,透過 Envoy Proxy 實現智慧流量分配。
負載平衡策略
Service Connect 預設使用 Round Robin 負載平衡策略,將請求平均分配到所有健康的後端實例:
| |
健康檢查與自動故障轉移
Service Connect 會自動將流量從不健康的實例轉移:
| |
逾時設定
透過 Task Definition 中的 Service Connect 配置設定連線逾時:
| |
重試機制
Service Connect 提供內建的重試機制,處理暫時性故障:
| |
連線池管理
Envoy Proxy 自動管理連線池,優化服務間通訊效能:
- HTTP/1.1:維持持久連線,減少連線建立開銷
- HTTP/2:支援多工,單一連線處理多個請求
- 自動重連:連線中斷時自動重新建立
監控與可觀測性
Service Connect 自動收集豐富的指標數據,並整合至 Amazon CloudWatch。
自動收集的指標
Service Connect 會自動產生以下 CloudWatch 指標:
| 指標名稱 | 說明 | 維度 |
|---|---|---|
RequestCount | 請求總數 | ServiceName, TargetService |
RequestCountPerTarget | 每個目標的請求數 | ServiceName, TargetService, TargetIP |
ActiveConnectionCount | 活躍連線數 | ServiceName |
NewConnectionCount | 新建連線數 | ServiceName |
ProcessedBytes | 處理的位元組數 | ServiceName |
TargetResponseTime | 目標回應時間 | ServiceName, TargetService |
HTTPCode_Target_2XX_Count | 2XX 回應數量 | ServiceName |
HTTPCode_Target_4XX_Count | 4XX 回應數量 | ServiceName |
HTTPCode_Target_5XX_Count | 5XX 回應數量 | ServiceName |
建立 CloudWatch Dashboard
| |
設定 CloudWatch 告警
| |
整合 AWS X-Ray
雖然 Service Connect 不直接支援 X-Ray,但可以在應用程式中加入 X-Ray SDK 實現分散式追蹤:
| |
日誌分析
| |
Terraform 部署範例
以下是使用 Terraform 完整部署 Service Connect 架構的範例。
專案結構
| |
基礎設施配置(main.tf)
| |
VPC 和網路配置(vpc.tf)
| |
Cloud Map Namespace 和 ECS Cluster(ecs.tf)
| |
Backend API Service(services/backend-api.tf)
| |
Frontend Web Service(services/frontend-web.tf)
| |
輸出配置(outputs.tf)
| |
部署指令
| |
故障排除與最佳實務
常見問題與解決方案
1. 服務無法相互連線
症狀:客戶端服務無法透過服務名稱存取其他服務
診斷步驟:
| |
解決方案:
- 確認兩個服務都在同一個 Namespace 中
- 驗證 portMappings 的 name 屬性與 Service Connect 配置中的 portName 一致
- 檢查安全群組是否允許服務間通訊
2. Envoy Proxy Sidecar 啟動失敗
症狀:任務啟動但快速失敗,容器日誌顯示 Envoy 相關錯誤
診斷步驟:
| |
解決方案:
- 確認 Task Definition 中的 portMappings 使用正確的 appProtocol(http 或 grpc)
- 檢查 ECS Task 執行角色是否有足夠權限
- 確認 Container 的健康檢查端點可正常存取
3. 延遲過高
症狀:服務間通訊延遲明顯高於預期
診斷步驟:
| |
解決方案:
- 檢查目標服務的資源使用情況(CPU、記憶體)
- 考慮增加目標服務的任務數量
- 檢查應用程式本身的效能問題
- 調整逾時設定以符合實際需求
4. 服務發現更新延遲
症狀:新部署的任務需要較長時間才能接收流量
解決方案:
| |
- 縮短健康檢查間隔
- 減少 startPeriod 以加快健康狀態確認
- 確保健康檢查端點快速回應
最佳實務
1. 命名規範
| |
2. 資源配置建議
| |
3. 安全性配置
| |
4. 可觀測性配置
| |
5. 部署策略
| |
效能調優建議
連線池優化:Service Connect 的 Envoy Proxy 會自動管理連線池,但應確保應用程式也正確配置 HTTP 連線重用
健康檢查間隔:根據服務特性調整健康檢查頻率,避免過於頻繁造成資源浪費
逾時設定:根據實際服務回應時間設定合理的逾時值
資源監控:定期檢視 CloudWatch 指標,識別效能瓶頸