本章節涵蓋現代分散式系統的架構模式，包括邊車模式、服務網格、API Gateway 以及部署升級策略。

邊車模式 (Sidecar Pattern)#

邊車模式的靈感來自邊三輪摩托車，通過給主服務加上一個「邊車」來擴展功能，實現控制面與資料面的分離。

核心概念#

flowchart TB
    subgraph Node["計算節點"]
        direction LR
        App["應用服務<br/>(業務邏輯)"] <--> SC["Sidecar<br/>(控制邏輯)"]
    end
    SC <--> Ext["對外的進出通訊"]

    style Node fill:#e3f2fd
    style SC fill:#fff9c4

Sidecar 負責的控制面功能：

  • 監控、日誌記錄
  • 限流、熔斷
  • 服務註冊與發現
  • 協定適配轉換
  • 鏈路追蹤

Sidecar 和應用程式必須同生共死——一起創建、一起停用。這是邊車模式的基本要求。

兩種實現方式的比較#

方式優點缺點
SDK/Library效能好、資源利用率高侵入性強、語言限制、升級需重新發布
Sidecar無侵入、語言無關、獨立升級增加延遲、部署複雜度高

Sidecar 的應用場景#

  1. 老系統改造：無需修改原有程式碼即可加入分散式能力
  2. 多語言系統：統一管理不同語言編寫的服務
  3. 控制邏輯標準化：將控制面功能統一管理

設計要點#

Sidecar 設計的關鍵考量

  1. 程序間通訊

    • 使用網路遠程呼叫（127.0.0.1 上通訊，開銷不明顯）
    • 避免使用信號或共享記憶體等侵入式方式

  2. 協定設計

    • 內部協定：靠近和兼容本地服務的協定
    • 外部協定：使用開放標準的協定
    • 避免使用與語言相關的協定

  3. 功能邊界

    • Sidecar 只負責控制面的東西
    • 不要把業務邏輯設計到 Sidecar 中

  4. 上下文傳遞

    • 允許應用服務和 Sidecar 交換上下文資訊
    • 例如：重試次數、限流狀態、遠程服務可用性

使用 Docker 容器技術可以大幅簡化 Sidecar 的打包、部署和管理。

服務網格 (Service Mesh)#

當 Sidecar 在架構中越來越多時，需要對其進行統一管理。Service Mesh 就是 Sidecar 的集群化管理。

演進路徑#

直接通訊 → 網路層分離 → 應用層流控 → TCP/IP 標準化
    → 彈力設計（限流、熔斷） → SDK/Framework → Sidecar → Service Mesh

Service Mesh 的特點#

  • 是一個基礎設施層
  • 是一個輕量級的服務通訊網路代理
  • 對應用服務透明無侵入
  • 用於解耦控制面和資料面

Service Mesh 在分散式系統中的地位，類似於 TCP 在 OSI 七層模型中的地位——它把底層的流量控制（丟包重傳、擁塞控制）都管了，讓應用層只需關心業務邏輯。

Service Mesh 架構#

flowchart TB
    subgraph CP["控制面 (Control Plane)"]
        Pilot["Pilot<br/>(規則下發)"]
        Mixer["Mixer<br/>(資料收集)"]
        Auth["Auth<br/>(身份認證)"]
    end

    subgraph DP["資料面 (Data Plane)"]
        subgraph P1[" "]
            SC1["Sidecar<br/>(Envoy)"]
            S1["服務 A"]
        end
        subgraph P2[" "]
            SC2["Sidecar<br/>(Envoy)"]
            S2["服務 B"]
        end
        subgraph P3[" "]
            SC3["Sidecar<br/>(Envoy)"]
            S3["服務 C"]
        end
    end

    CP --> SC1
    CP --> SC2
    CP --> SC3
    SC1 --- S1
    SC2 --- S2
    SC3 --- S3

    style CP fill:#e3f2fd
    style DP fill:#fff3e0

設計重點#

Service Mesh 的 Sidecar 如果出問題，會導致整個架構出現致命問題。因此必須保證高可用：

  • 本機 Sidecar 之外，部署集中式的 Sidecar 作為備援
  • 結合 Gateway 模式，Sidecar 粒度可粗可細

API Gateway 模式#

Gateway 是進入系統的唯一入口，類似於設計模式中的 Facade 模式。

多層 Gateway 架構#

flowchart TD
    GW["總 Gateway<br/>(接入層)"]
    GW --> GA["Gateway A<br/>(用戶系統)"]
    GW --> GB["Gateway B<br/>(訂單系統)"]
    GW --> GC["Gateway C<br/>(商品系統)"]
    GA --> SA["服務群組"]
    GB --> SB["服務群組"]
    GC --> SC["服務群組"]

    style GW fill:#ffccbc
    style GA fill:#fff9c4
    style GB fill:#fff9c4
    style GC fill:#fff9c4

Gateway 核心功能#

功能說明
請求路由根據請求資訊路由到正確的後端服務
服務註冊後端服務註冊 API 介面（URI、方法、標頭）
負載均衡Round Robin、加權、Session 粘連
彈力設計限流、熔斷、重試、監控
安全防護SSL 管理、身份驗證、惡意攻擊防範

進階功能#

Gateway 的進階應用

灰度發布

  • 對相同服務的不同版本進行導流
  • 收集相關資料，用於軟體品質提升和產品試錯

API 聚合

  • 將多個後端請求聚合成一個請求
  • 減少用戶端與後端的通訊次數
  • 可並行請求多個後端服務

API 編排

  • 定義業務流程中的 API 呼叫順序
  • 使用 DSL 或類似 AWS Lambda 的方式串聯 API

Gateway vs Sidecar vs Service Mesh#

模式特點適用場景
Sidecar每個服務實體一個改造已有服務
Service MeshSidecar + 中央控制器完整的服務治理
Gateway集中式、粒度可調簡化運維、API 管理

Gateway 設計要點#

高效能

  • 使用高效能語言（Go、Java、C++）
  • 非同步非阻塞 I/O（epoll、Netty、goroutine）

高可用

  • 集群化部署
  • 服務化（執行時修改組態的 Admin API）
  • 優雅重啟（主程序分發請求，老程序處理完後退出）

架構原則

  • 業務松耦合、協定緊耦合
  • Gateway 只處理協定頭，不處理協定體
  • Gateway 應靠近後端服務，使用同一內網

部署升級策略#

在分散式系統中，一個服務有多個實體，部署和升級需要特別的策略。

停機部署 (Recreate)#

時間線：
  ├── 停止所有 V1 實體
  ├── 部署 V2
  └── 啟動所有 V2 實體

適用場景：新舊版本完全不兼容（如資料庫結構變更）

優點：不會有新舊版本同時在線的問題 缺點：需要停機，影響用戶

藍綠部署 (Blue/Green)#

flowchart TD
    LB["負載均衡"]
    LB -->|"100% 流量"| Blue["藍環境<br/>(V1)"]
    LB -.->|"切換流量"| Green["綠環境<br/>(V2)"]

    style Blue fill:#bbdefb
    style Green fill:#c8e6c9

優點：無停機、無新舊版本混用 缺點：需要雙倍資源（雲端時代問題不大）

滾動部署 (Rolling Update)#

時間線：
  ├── 部署 V2 實體 1，加入負載均衡
  ├── 移除 V1 實體 1
  ├── 部署 V2 實體 2，加入負載均衡
  ├── 移除 V1 實體 2
  └── ... 重複直到全部更新

優點：對有狀態服務友好，狀態可逐步重建 缺點：

  • 發布過程中新舊版本同時在線
  • 回滾困難
  • 需要處理新舊版本的兼容性

灰度部署 (Canary)#

flowchart TD
    LB["負載均衡"]
    LB -->|"90%"| V1["V1<br/>(穩定)"]
    LB -->|"10%"| V2["V2<br/>(金絲雀)"]

    style V1 fill:#c8e6c9
    style V2 fill:#fff9c4

「金絲雀」名稱來源：17 世紀英國礦工帶金絲雀下礦井檢測瓦斯，金絲雀對有毒氣體極為敏感。

流程：

  1. 部署新版本，導入小部分流量（如 10%）
  2. 監控是否有問題
  3. 逐步增加流量直到 100%

AB 測試#

比較項藍綠/灰度部署AB 測試
目的驗證新版本的品質驗證新版本的功能
關注點有沒有 bug用戶體驗是否更好
決策依據錯誤率、效能指標用戶行為資料

用戶分群方式：

  • 瀏覽器 Cookie
  • 查詢參數
  • 地理位置
  • 技術特徵（瀏覽器版本、螢幕尺寸、作業系統）
  • 用戶端語言

部署策略選擇#

開發/測試環境 → 停機或滾動部署（快速、乾淨）

生產環境：
├── 需要零停機 → 藍綠部署
├── 對新版本品質沒信心 → 灰度部署
├── 對新版本功能沒信心 → AB 測試
└── 新舊版本不兼容 → 停機部署

架構模式總結#

┌────────────────────────────────────────────────────┐
│                  分散式架構模式                      │
├────────────────────────────────────────────────────┤
│  流量管理                                          │
│    ├── Sidecar：每個服務實體的代理                  │
│    ├── Service Mesh：Sidecar 集群 + 控制面         │
│    └── API Gateway：集中式入口                     │
├────────────────────────────────────────────────────┤
│  部署策略                                          │
│    ├── 停機部署：簡單但有停機時間                    │
│    ├── 藍綠部署：無停機，需雙倍資源                  │
│    ├── 滾動部署：逐步替換，適合有狀態服務            │
│    ├── 灰度部署：漸進式發布，降低風險               │
│    └── AB 測試：功能驗證，資料驅動決策              │
└────────────────────────────────────────────────────┘

架構模式的選擇沒有標準答案，需要根據以下因素綜合考量：

  • 團隊規模和技術能力
  • 系統複雜度
  • 可用性要求
  • 運維成本預算
  • 現有基礎設施
Backward 效能設計 工程師文化 Forward