從單體到微服務：使用服務網格遷移 Snap 的架構

經過兩年的架構演進，Snap 從單體遷移到了雲託管的微服務，這使得計算成本降低了 65%，同時減少了冗餘並提升了客戶的可靠性，所有的這些遷移都滿足了安全性和隱私合規性的需求。

面向服務架構爲工程師提供了可擴展性和所有權。開源的邊緣（edge）代理 Envoy 是核心的構建塊，能夠爲服務間通信創建一致的層。內部的 Web 應用 Switchboard 構成了 Snap 服務網格的控制平面，它爲服務的所有者提供了一個地方來管理他們的服務依賴。

在過去的兩年間，雲基礎設施不斷演化，Snap 已經從 Google App Engine 中的單體應用轉變成了 Kubernetes 中的微服務，其中 Kubernetes 可以跨 Amazon Web Services 和 Google Cloud。

從零開始實現基於微服務的系統時，會面臨一些挑戰，包括對現有底層基礎設施的考慮，如網絡拓撲、認證、雲資源供應、部署、日誌和監控、流量路由、限速以及 staging 與生產環境。

正如 Snap 的工程博客中所描述的，爲了找到一個可行的方案，他們也考慮了 Snapchatters 當前的經驗。文中也指出，他們沒有一個專門的團隊，因此沒有時間實現這項計劃。

Snap 沒有從頭開始，而是決定使用開源的邊緣代理服務 Envoy，實現其服務網格設計模式。

Envoy 提供了很多特性，比如支持 gRPC 和 HTTP/2、客戶端負載均衡、可插拔的過濾器、藉助一組動態管理 API（如 xDS）所實現的數據平面和控制平面的清晰分離。隨着 AWS 和 Google Cloud 都提供了可用的 Envoy，於是 Envoy 就成爲了 Snap 中服務與服務間的通信層。在 Snap，每個 Envoy 代理都連接一個自定義的控制平面，通過 xDS API 接收服務發現和詳細的流量管理配置。

在使用服務網格的過程中，很重要的一點就是解決 Envoy 中關於移動客戶端通信的問題。除此之外，當在 AWS 和 Google Cloud 上同時運行時，工程師要站在安全的角度管理他們的 Envoy 配置。

由此，形成了 Snap 服務網格。Snap 有一個名爲 Switchboard 的內部 Web 應用，它擔任 Snap 服務唯一的控制平面，這樣服務的所有者就可以管理他們的服務依賴了。

Switchboard 配置的核心是它的服務。每個服務都有一個協議和基本的元數據，如所有者、email 列表和描述。這些服務所組成的集羣可以位於任意的雲供應商、可用區或環境中。Switchboard 服務有它們的依賴和消費者，也就是其他的 Switchboard 服務。如果 Snap 當時把整個系統的 API 接口全部暴露給工程團隊的話，那麼將會有大量配置，從而導致管理上的困難。

Switchboard 的配置變更是存儲在 DynamoDB 中的。服務網格上的 Envoy 代理通過一個雙向的 gRPC 流連接至 xDS 控制平面。當某個服務的 Envoy 配置生成時，控制平面會發送更新後的配置給一小部分 Envoy 代理，並且在測定它們的健康狀況之後，纔將變更提交至整個網格。

與此同時，服務的所有者可以直接通過 Switchboard 供應和管理 Kubernetes 集羣，還可以通過金絲雀發佈、健康檢查端點和分區滾動更新生成 spinnaker 管道。

爲了將暴露給互聯網的服務數量降至最低，Snap 爲其微服務設計了一個共享的、內部的、分區的網絡。將會有一個 API 網關暴露到互聯網上，這樣的話，沒有外部流量可以直接與內部網絡進行通信。

這個 API 網關上運行的 Envoy 鏡像和微服務上運行的 Envoy 鏡像是一樣的，連接到相同的控制面板。除此之外，還有自定義的 Envoy 過濾器，用來處理 Snapchat 的認證模式以及限速和負載 shedding 功能。

統一的 Snap 服務網格架構圖如下所示：