作者 | 馬若飛
近幾年，微服務架構逐漸發展成熟，從最初的星星之火到現在大規模的落地和實踐，幾乎已經成為分散式環境下的首選架構。然而軟體開發沒有銀彈，基於微服務構建的應用系統在享受其優勢的同時，痛點也越加明顯。Service Mesh 技術也因此而生，受到越來越多的開發者關注，並擁有了大批擁躉。本文會從概念介紹開始，讓大家理解 Service Mesh 技術出現的原因以及願景；接著會對目前最主流的兩個產品 Istio 和 AWS App Mesh 進行詳細的比較；最後簡要介紹一下我們目前在該領域的一些探索與實踐。
1
Service Mesh - 服務通訊的濟世良方
Service Mesh 是什麼？
Service Mesh（中文譯做服務網格）這一概念由 Buoyant 公司的 CEO，William Morg」n 首先提出。2017 年 4 月該公司釋出了第一個 Service Mesh 產品 Linkerd，這篇同一時間發表的文章 What’s a service mesh？And why do I need one？ 也被業界公認是 Service Mesh 的權威定義。
“A service mesh is a dedicated infrastructure layer for handling service-to-service communication。 It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern， cloud native application。 In practice， the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code， without the application needing to be aware。”
其定義翻譯為：Service Mesh 是一個處理服務通訊的專門的基礎設施層。它的職責是在由雲原生應用組成服務的複雜拓撲結構下進行可靠的請求傳送。在實踐中，它是一組和應用服務部署在一起的輕量級的網路代理，對應用服務透明。這段話有點晦澀難懂，但只要抓住下面 4 個關鍵點就能輕鬆理解：
本質：基礎設施層
功能：請求分發
部署形式：網路代理
特點：透明
如果用一句話來總結，我個人對它的定義是：Service Mesh 是一組用來處理服務間通訊的網路代理。
為什麼需要 Service Mesh？
上面晦澀抽象的定義很難讓你真正理解 Service Mesh 存在的意義。你可能會想，服務間通訊（service-to-service communication）無非就是透過 RPC、HTTP 這些方式進行，有什麼可處理的？沒錯，服務間只需要遵循這些標準協議進行互動就可以了，但是在微服務這樣的分散式環境下，分散的服務勢必帶來互動的複雜性，而規模越大的系統其通訊越加錯綜複雜。分散式計算下的 8 個謬論很好的歸納了分散式環境下存在的網路問題。而為了解決這些問題，提高系統的容錯能力和可用性，出現了服務註冊與發現、負載均衡、熔斷、降級、限流等等和通訊相關的功能，而這些才是 Service Mesh 要真正處理的問題。
Pattern：Service Mesh 這篇文章詳細的講述了微服務架構下通訊處理的演進，由此引出 Service Mesh 出現的意義和核心價值。下圖為服務通訊演變的過程：
最初，流量管理和控制能力（比如圖例中的熔斷、服務發現）是和業務邏輯耦合在一起，即便以引用包的方式被呼叫，依然解決不了異構系統無法重用的問題。
流控功能和業務耦合相當不美好，於是出現了提供這些功能的公共庫和框架。但這些庫通常比較複雜，無論是學習使用，與業務系統整合、維護都會帶來很大的成本。
為避免花費太多時間開發和維護這些通用庫，人們希望流量控制能力可以下沉到網路通訊棧的層面，但幾乎無法實現。
於是另一種思路出現，就是將這些功能獨立成一個代理，由它先接管業務服務的流量，處理完成後再轉發給業務服務本身，這就是 Sidecar 模式。
為統一管理 Sidecar，該模式進一步進化，形成網路拓撲，增加了控制平面，演變成 Service Mesh（最後的網格圖中，綠色代表業務服務，藍色代表 sidecar 服務）。
可以說，Service Mesh 就是 Sidecar 的網路拓撲形態，Mesh 這個詞也由此而來。（關於 Sidecar 模式這裡不做討論，你可以自行 Google）。
業務系統的核心價值應該是業務本身，而不是服務，微服務只是一種實現手段，實現業務才是目標。現有的微服務架構下，為解決可能出現的網路通訊問題，提升系統的彈性，開發人員不得不花費大量時間和精力去實現流量控制相關的非業務需求，不能聚焦在業務本身。而 Service Mesh 的出現解決了這一問題，帶來了下面 2 個變革：
解決了微服務框架中的服務流量管理的痛點，使開發人員專注於業務本身；
將服務通訊及相關管控功能從業務程式中分離並下層到基礎設施層，使其和業務系統完全解耦。
在雲原生應用中，面對數百個服務或數千個例項，單個業務鏈路的請求經由服務的拓撲路徑可能會非常複雜，單獨處理非常必要。這就是 Service Mesh 的意義所在。
Service Mesh 的主要功能
那麼 Service Mesh 到底能帶來哪些實用的功能呢？可以把它們歸納為下面 4 個部分：
流量控制：流控是最主要也是最重要的功能，透過 Service Mesh，我們可以為應用提供智慧路由（藍綠部署、金絲雀釋出、A/B test）、超時重試、熔斷、故障注入、流量映象等各種控制能力；
安全：在安全層面上，授權和身份認證也可以託管給 Service Mesh；
策略：可以為流量設定配額、黑白名單等策略；
可觀察性：服務的可觀察性一般是透過指標資料、日誌、追蹤三個方式展現的，目前的 Service Mesh 產品可以很容易和和主流的後端設施整合，提供給應用系統完整的監控能力。
透過上面的講述，我相信 Service Mesh 的概念大家都已經有所瞭解。接下來我們來介紹兩個重要的網格產品，讓大家進一步瞭解 Service Mesh 的產品形態是什麼樣的。
2
Istio vs AWS App Mesh - 開源與閉環之爭
目前市面上比較成熟的開源服務網格主要有下面幾個：Linkerd，這是第一個出現在公眾視野的服務網格產品，由 Twitter 的 finagle 庫衍生而來，目前由 Buoyant 公司負責開發和維護；Envoy，Lyft 開發並且是第一個從 CNCF 孵化的服務網格產品，定位於通用的資料平面或者單獨作為 Sidecar 代理使用；Istio，由 Google、IBM、Lyft 聯合開發的所謂第二代服務網格產品，控制平面的加入使得服務網格產品的形態更加完整。
從今年的風向看，作為構建雲原生應用的重要一環，Service Mesh 已經被各大雲廠商認可，並看好它的發展前景。在 Istio 紅透半邊天的情況下，作為和 Google 在雲服務市場競爭的 Amazon 來說，自然不願錯失這塊巨大的蛋糕。他們在今年 4 月份釋出了自己的服務網格產品：AWS App Mesh。這一部分內容我們會聚焦於 Istio 和 App Mesh 這兩個產品，透過橫向的對比分析讓大家對 Service Mesh 的產品形態和兩大雲廠商的策略有一個更深入的認識。
產品定位
從官方的介紹來看，Istio 和 App Mesh 都明確的表示自己是一種服務網格產品。Istio 強調了自己在連線、安全、控制和視覺化 4 個方面的能力；而 App Mesh 主要強調了一致的可見性和流量控制這兩方面能力，當然也少不了強調作為雲平臺下的產品的好處：託管服務，無需自己維護。
從某種程度上講，Istio 是一個相對重一點的解決方案，提供了不限於流量管理的各個方面的能力；而 App Mesh 是更加純粹的服務於執行在 AWS 之上的應用並提供流控功能。筆者認為這和它目前的產品形態還不完善有關（後面會具體提到）。從與 AWS 技術支援團隊的溝通中可以感覺到，App Mesh 應該是一盤很大的棋，目前只是初期階段。
核心術語
和 AWS 裡很多產品一樣，App Mesh 也不是獨創，而是基於 Envoy 開發的。AWS 這樣的閉環生態必然要對其進行改進和整合。同時，也為了把它封裝成一個對外的服務，提供適當的 API 介面，在 App Mesh 這個產品中提出了下面幾個重要的技術術語，我們來一一介紹一下。
服務網格（Service mesh）：服務間網路流量的邏輯邊界。這個概念比較好理解，就是為使用 App mesh 的服務圈一個虛擬的邊界。
虛擬服務（Virtual services）：是真實服務的抽象。真實服務可以是部署於抽象節點的服務，也可以是間接的透過路由指向的服務。
虛擬節點（Virtual nodes）：虛擬節點是指向特殊工作組（task group）的邏輯指標。例如 AWS 的 ECS 服務，或者 Kubernetes 的 Deployment。可以簡單的把它理解為是物理節點或邏輯節點的抽象。
Envoy：AWS 改造後的 Envoy（未來會合併到 Envoy 的官方版本），作為 App Mesh 裡的資料平面，Sidecar 代理。
虛擬路由器（Virtual routers）：用來處理來自虛擬服務的流量。可以理解為它是一組路由規則的封裝。
路由（Routes）：就是路由規則，用來根據這個規則分發請求。
上面的圖展示了這幾個概念的關係：當用戶請求一個虛擬服務時，服務配置的路由器根據路由策略將請求指向對應的虛擬節點，這些節點最終會與叢集中某個對外提供服務的 DNS 或者服務名一一對應。
那麼這些 App Mesh 自創的術語是否能在 Istio 中找到相似甚至相同的物件呢？我歸納了下面的表格來做一個對比：
從上面的對比看出，App Mesh 目前基本上實現了最主要的流量控制（路由）的功能，但像超時重試、熔斷、流量複製等高階一些的功能還沒有提供，有待進一步完善。
架構
AWS App Mesh 是一個商業產品，目前還沒有找到架構上的技術細節，不過我們依然可以從現有的、公開的文件或介紹中發現一些有用的資訊。
從這張官網的結構圖中可以看出，每個服務的橙色部分就是 Sidecar 代理：Envoy。而中間的 AWS App Mesh 其實就是控制平面，用來控制服務間的互動。那麼這個控制平面具體的功能是什麼呢？我們可以從今年的 AWS Summit 的一篇 PPT 中看到這樣的字樣：
控制平面用來把邏輯意圖轉換成代理配置，並進行分發。
熟悉 Istio 架構的朋友有沒有覺得似曾相識？沒錯，這個控制平面的職責和 Pilot 基本一致。由此可見，不管什麼產品的控制平面，也必須具備這些核心的功能。
那麼在平臺的支援方面呢？下面這張圖展示了 App Mesh 可以被執行在如下的基礎設施中，包括 EKS、ECS、EC2 等等。當然，這些都必須存在於 AWS 這個閉環生態中。
而 Istio 這方面就相對弱一些。儘管 Istio 宣稱是支援多平臺的，但目前來看和 Kubernetes 還是強依賴。不過它並不受限於單一的雲平臺，這一點有較大的優勢。
Istio 的架構大家都比較熟悉，資料平面由 Envoy sidecar 代理組成，控制平面包括了 Pilot、Mixer、Citadel、Galley 等控制元件。它們的具體功能這裡就不再贅述了，感興趣的同學可以直接去官網檢視詳細資訊。
功能與實現方式
部署
無論是 Istio 還是 App Mesh 都使用了控制平面 + 資料平面的模式，且 Sidecar 都使用了 Envoy 代理。Istio 的控制平面元件較多，功能也更復雜，1。0。x 版本完整安裝後的 CRD 有 50 個左右。架構修改後 Mixer 的一些 adapter 被獨立出去，crd 有所降低。下面是最新的 1。4 版本，安裝後仍然有 24 個 crd。
而 App Mesh 就簡單得多，只針對核心概念添加了如下 3 個 crd，用一個 controller 進行管理。
儘管 Istio 更多的 crd 在一定程度上代表了更加豐富的功能，但同時也為維護和 troubleshooting 增加了困難。
流量控制
儘管兩者的資料平面都基於 Envoy，但它們提供的流量控制能力目前還是有比較大的差距的。在路由的設定方面，App Mesh 提供了相對比較豐富的匹配策略，基本能滿足大部分使用場景。下面是 App Mesh 控制檯裡的路由配置截圖，可以看出，除了基本的 URI 字首、HTTP Method 和 Scheme 外，也支援請求頭的匹配。
Istio 的匹配策略更加完善，除了上面提到的，還包括 HTTP Authority，埠匹配，請求引數匹配等，具體資訊可以從官方文件的虛擬服務設定檢視。下面兩段 yaml 分別展示了兩個產品在虛擬服務配置上的差異。
App Mesh 配置：
Istio 配置：
另外一個比較大的不同是，App Mesh 需要你對不同版本的服務分開定義（即定義成不同的虛擬服務），而 Istio 是透過目標規則 DestinationRule 裡的子集 subsets 和路由配置做的關聯。本質上它們沒有太大區別。
除了路由功能外，App Mesh 就顯得捉襟見肘了。就在筆者撰寫本文時，AWS 剛剛添加了重試功能。而 Istio 藉助於強大的 Envoy，提供了全面的流量控制能力，如超時重試、故障注入、熔斷、流量映象等。
安全
在安全方面，兩者的實現方式具有較大區別。預設情況下，一個使用者不能直接訪問 App Mesh 的資源，需要透過 AWS 的 IAM 策略給使用者授權。比如下面的配置是容許使用者用任意行為去操作網格內的任意資源：
因此，App Mesh 的授權和認證都是基於 AWS 自身的 IAM 策略。
Istio 提供了兩種認證方式，基於 mTLS 的傳輸認證，和 基於 JWT 的身份認證。而 Istio 的授權是透過 RBAC 實現的，可以提供基於名稱空間、服務和 HTTP 方法級別的訪問控制。這裡就不具體展示了，大家可以透過官網文件來檢視。
可觀察性
一般來說，可以透過三種方式來觀察你的應用：指標資料、分散式追蹤、日誌。Istio 在這三個方面都有比較完整的支援。指標方面，可以透過 Envoy 獲取請求相關的資料，同時還提供了服務級別的指標，以及控制平面的指標來檢測各個元件的執行情況。透過內建的 Prometheus 來收集指標，並使用 Grafana 展示出來。分散式追蹤也支援各種主流的 OpenTracing 工具，如 Jaeger、Zipkin 等。訪問日誌一般都透過 ELK 去完成收集、分析和展示。另外，Istio 還擁有 Kiali 這樣的視覺化工具，給你提供整個網格以及微服務應用的拓撲檢視。總體來說，Istio 在可觀察方面的能力是非常強大的，這主要是因為 Mixer 元件的外掛特性帶來了巨大的靈活性。
App Mesh 在這方面做的也不錯。從最新發布的官方 repo 中，App Mesh 已經提供了整合主流監控工具的 helm chart，包括 Prometheus、Grafana、Jaeger 等。同時，AWS 又一次發揮了自己閉環生態的優勢，提供了與自家的監控工具 CloudWatch、X-Ray 的整合。總的來說，App Mesh 在對服務的可觀察性上也不落下風。
Amazon 與 Google 的棋局
AWS App Mesh 作為一個 2019 年 4 月份才釋出的產品（GA），在功能的完整性上和 Istio 有差距也是情有可原的。從 App Mesh 的 Roadmap 可以看出，很多重要的功能，比如熔斷已經在開發計劃中。從筆者與 AWS 的支援團隊瞭解的資訊來看，他們相當重視這個產品，優先順序很高，進度也比較快，之前還在預覽階段的重試功能在上個月也正式釋出了。另外，App Mesh 是可以免費使用的，使用者只需要對其中的例項資源付費即可，沒有額外費用。對 AWS 來說，該產品的開發重點是和現有產品的整合，比如 Roadmap 列出的使用 AWS Gateway 作為 App Mesh 的 Ingress。藉助著自己的生態優勢，這種整合即方便快捷的完善了 App Mesh，同時又讓生態內的產品結合的更緊密，使得閉環更加的牢固，不得不說是一步好棋。
和 App Mesh 目前只強調流控能力不同，Istio 更多的是把自己打造成一個更加完善的、全面的服務網格系統。架構優雅，功能強大，但效能上受到質疑。在產品的更迭上貌似也做的不盡如人意（不過近期接連發布了 1。3 到 1。4 版本，讓我們對它的未來發展又有了期待）。Istio 的優勢在於 3 大頂級技術公司加持的強大資源，加上開源社群的反哺，利用好的話容易形成可持續發展的局面，併成為下一個明星級產品。然而 Google 目前對 Istio 的態度有一些若即若離，一方面很早就在自家的雲服務 gcloud 裡提供了 Istio 的預設安裝選項，但同時又釋出了和 Istio 有競爭關係的 Traffic director 這個託管的控制平面。筆者的猜測是 Google 也意識到 Istio 的成熟不可能一蹴而就，鑑於網格技術託管需求的越發強烈，先提供一個輕量化的產品以佔領市場。
目前各大廠商都意識到了網格技術的重要性並陸續推出了自己的產品（包括 AWS App Mesh，Kong 的 Kuma，國內的螞蟻金服、騰訊雲等），競爭也會逐漸激烈。未來是三分天下還是一統山河，讓我們拭目以待。
3
我們的實踐 - 從 Service Mesh 邁向雲原生
最後這部分給大家簡要介紹一下我們（FreeWheel）在 Service Mesh 領域的實踐。希望透過一些前瞻性的探索，總結出最佳實踐，為我們將來的微服務應用全面擁抱雲原生提供一定的經驗和指導。目前我們已經開發完成的 Data service 專案就整合了 AWS App Mesh，即將上線，並使用網格的能力進行智慧路由和釋出。
Data service 專案只包含兩個服務：Forecast service 和 Query service，前者作為業務服務透過 Query service 查詢來自持久層（ClickHouse）的資料；後者作為資料訪問代理，從持久層獲取資料並進行物件化的封裝。這個 mini 的微服務系統非常適合作為一個先行者為我們探索網格的功能、效能、易用性等方面的能力，且範圍足夠小，不會影響到其他業務系統。
選擇 AWS App Mesh 作為該專案的網格產品主要原因如下：
FreeWheel 是一個重度使用 AWS 各項服務的公司，未來所有的服務也都會全部託管的 AWS 上。作為一個閉環生態，App Mesh 可以和現有服務無縫整合，提高易用性；
相比 Istio 這樣還不太成熟的開源產品，我們可以得到 AWS 技術團隊的全力支援；
資料平面基於成熟高效的 Envoy，控制平面不存在 Istio 中的效能問題；
完全免費。
下圖是該專案的部署檢視。前端請求從我們的業務系統 UIF 傳送到 Forecast service，它作為 App Mesh 的一個虛擬節點，呼叫 Data service 進行資料查詢。Data service 作為資料平面，會注入 App Mesh 的 sidecar 代理。這兩個服務組成了一個 Mesh 網格，並無縫整合在 AWS 的 EKS 中。
下圖是網格內部的邏輯檢視，展示瞭如何利用 App Mesh 進行智慧路由。Forecast service 作為呼叫者被定義為虛擬節點，Data service 作為虛擬服務，掛載著虛擬路由，內部根據需要可以設定若干路由規則。用 App Mesh 實現一個金絲雀釋出的過程非常簡單：假設在 Data service 的新版本（V2）釋出前，流量都被指向 V1 版本；此時我們在 App Mesh 裡配置好一個新的路由規則，將 10% 的流量指向新的 V2 版本；只需要將新的規則透過 kubectl apply -f new-rule。yaml 應用到叢集中，金絲雀釋出就可以完成，且無縫切換，對使用者透明。
在後續的工作中，我們會先驗證 App Mesh 的效能和可靠性，然後逐漸的將更多的流量控制（如超時重試、熔斷等）功能新增進來，並總結出一整套可行的實施方案，供大家參考。也歡迎對 Service Mesh 感興趣的同學加入到我們的團隊中，一起學習，共同進步。
4
總結
解耦是軟體開發中永恆的主題，開發人員對消除重複的偏執是推動軟體、以及架構模式演進的主要動力。而 Service Mesh 的核心價值就是將服務通訊功能從業務邏輯中解耦，並下沉為基礎設施，由控制平面統一管理。有人將 Service Mesh、Kubernetes 和 Serverless 技術稱為雲原生應用開發的三駕馬車。Kubernetes 是雲應用實際意義上的作業系統；Service Mesh 將服務通訊功能剝離，實現了與業務的解耦；Serverless 讓你不用關心應用的伺服器。這三項技術讓我們有能力實現應用開發的終極目標，那就是：只關注業務本身。而它們，也會引領我們通向未來雲原生應用的詩和遠方。
點個在看少個 bug