Service Mesh 發展趨勢：雲原生中流砥柱

1、前言

本文內容整理自 5月25日 在 Kubernetes & Cloud Native Meetup 上海站發表的主題演講，主要介紹了 Service Mesh 最新的產品動態，分析其發展趨勢和將來走向；結合螞蟻金服的上雲實踐，闡述在雲原生背景下 Service Mesh 的核心價值，以及對雲原生落地的關鍵做用。
內容主要有三個部分：

1. Service Mesh 產品動態：介紹最近半年 Service Mesh 的產品動態，包括開源項目和雲廠商推出的雲上服務；
2. Service Mesh 發展趨勢：根據最近的產品動態，總結 Service Mesh 的發展趨勢，推斷將來的走向；
3. Service Mesh 與雲原生：結合雲原生，更好的理解 Service Mesh 的價值和做用。

2、Service Mesh 產品動態

（一）Istio 1.1 發佈
Istio 是目前 Service Mesh 社區最引人注目的開源項目，在今年的 3月份 發佈了期待已久的 Istio 1.1 版本，咱們來看看 Istio 最近幾個版本的發佈狀況：
· 2018年6月1日，Istio 發佈了 0.8 版本，這是 Istio 歷史上第一個 LTS 版本，也是 Istio 歷史上變更最大的一個版本；
· 2018年7月31日，Istio 發佈了 1.0 版本，號稱 "Product Ready"；
· 而後就是漫長的等待，Istio 1.0 系列以每月一個小版本的方式一路發佈了 1.0.1 到 1.0.6，而後纔開始 1.1.0 snapshot 1 到 6，再 1.1.0-rc 1 到 6，終於在 2019年3月20日 發佈了 1.1 版本，號稱 "Enterprise Ready"。

從 Istio 1.0 到 Istio 1.1，中間的時間跨度高達 9個月！咱們來看看通過這漫長的開發時間才發佈的 Istio 1.1 版本帶來了哪些新的東西：

圖中標紅的部分，涉及到 Istio 的架構調整，下面將詳細介紹 Istio 1.1 版本中帶來的架構變化。

（二）Istio 1.1 架構變化
下圖是 Istio 1.0 和 Istio 1.1 的架構圖對比：

Istio 1.1 的第一個架構變化來自 Galley：在 Istio 1.1 的架構圖中增長了 Galley 組件。可是實際上在 Istio 1.0 版本中 Gallay 組件就已經存在，只是當時 Galley 的功能很是簡單，只是作配置更新以後的驗證（Validation），在 Istio 1.0 的架構圖中都沒有出現。而在 Istio 1.1 版本以後，Galley 的定位發生了巨大的變化：Galley開始分擔 Pilot/Mixer 的職責。

在 Istio 1.1 版本以前的設計中，Istio 的三大組件 Pilot/Mixer/Citadel 都須要訪問 Kubernetes 的 API Server，以獲取服務註冊信息和配置信息，包括 Kubernetes 原生資源如 service/deployment/pod 等，還有 Istio 的自定義資源（數量多達50多個的 CRD） 。這個設計致使 Istio 的各個組件都不得不和 Kubernetes 的 API Server產生強綁定，不只僅代碼大量冗餘，並且在測試中也由於須要和 Kubernetes 的 API Server 交互致使 Pilot/Mixer 模塊測試困難。

爲了解決這個問題，在 Istio 1.1 以後，訪問 Kubernetes 的 API Server 的工做將逐漸交給 Galley 組件，而其餘組件如 Pilot/Mixer 就會和 Kubernetes 解耦。

這個工做還在進行中，目前 Istio 的 CRD 已經修改成由 Galley 讀取，而 K8s 的原生資源（Service / Deployment / Pod等），暫時仍是由 Pilot 讀取。爲了方便在各個組件中同步數據，Istio 引入了MCP（Mesh Configuration Protocol）協議。在 Istio 1.1 版本中，Pilot 經過 MCP 協議從 Galley 同步數據。MCP 是受 xDS v2 協議（準確說是 aDS）的啓發而制定的新協議，用於在Istio 各模塊之間同步數據。

Istio 1.1 的第二個架構變化來自於 Mixer，在 Istio 1.1 版本中，推薦使用 Out-of-Process Adapter，即進程外適配器。Istio 預計下一個版本將棄用 In-Proxy Adapter，目前全部的 Adapter 都將改成 Out-of-Process adapter。

什麼是 In-Proxy Adapter？下圖是 Mixer 的架構圖，在 Istio 的設計中，Mixer 是一個獨立進程，Proxy 經過遠程調用來和 Mixer 交互。而 Mixer 的實現了 Adapter 模式，定義了 Adapter API，而後內建了數量很是多的各類Adapter。這些 Adatper 的代碼存放在 Mixer 代碼中，運行時也在 Mixer 的進程內，所以稱爲 In-Process Adapter。

In-Process Adapter 的問題在於全部的 Adapter 的實現都和 Mixer 直接綁定，包括代碼和運行時。所以當 Adapter 須要更新時就須要更新整個 Mixer，任意一個 Adapter 的實現出現問題也會影響整個 Mixer，並且數量衆多的 Adapter 也帶來了數量衆多的CRD。爲此，Istio 1.1 版本中經過引入 Out-of-Process Adapter 來解決這個問題。

Out-of-Process Adapter 以獨立進程的方式運行在 Mixer 進程以外，所以 Out-of-Process Adapter 的開發/部署和配置均可以獨立於 Mixer，從而將 Mixer 從 Adaper 的實現細節中解脫出來。

可是，Out-of-Process Adapter 的引入，會致使新的性能問題：原來 Mixer 和 In-Process Adapter 之間是方法調用，如今改爲 Out-of-Process Adapter 以後就變成遠程調用了。而 Mixer 一直以來都是 Istio 架構設計中最大的爭議，以前 Proxy 和 Mixer 之間的遠程調用，已經形成很是大的性能瓶頸，而引入 Out-of-Process Adapter 以後遠程調用會從一次會變成屢次（每一個配置生效的 Out-of-Process Adapter 就意味着一次遠程調用），這會讓性能雪上加霜。

總結 Out-of-Process Adapter 的引入：架構更加的優雅，性能更加的糟糕。

在 Istio 1.1 爲了架構而不顧性能的同時，Istio 內部也有其餘的聲音傳出，如正在規劃中的 Mixer v2。這個規劃最重要的決策就是放棄 Mixer 獨立進程的想法，改成將 Mixer 的功能合併到 Envoy 中，從而避免 Envoy 和 Mixer 之間遠程調用的開銷。關於 Mixer 的性能問題和 Mixer 合併的思路，螞蟻金服在去年六月份開始 SOFAMesh 項目時就有清晰的認識和計劃，時隔一年，終於欣喜的看到 Istio 開始正視 Mixer 的架構設計問題並回到正確的方向上。

對此有興趣的朋友能夠經過閱讀下面的文章獲取更詳細的信息（發表於一年前，可是依然有效）：
· 大規模微服務架構下的Service Mesh探索之路 [1]：第二節架構設計中的"合併部分Mixer功能"
· Service Mesh架構反思：數據平面和控制平面的界線該如何劃定？ [2]
· Mixer Cache: Istio的阿克琉斯之踵? [3]：系列文章，有兩篇
· Istio Mixer Cache工做原理與源碼分析 [4]: 系列文章，有四篇

目前 Mixer v2 的規劃還處於 Review 狀態，實現方式還沒有有明確決定。若是要合併 Mixer，考慮到目前 Mixer 是基於 Golang 編寫，而 Envoy 是基於 C++，這意味着須要用 C++ 重寫全部的 Adapter，工做量巨大，恐怕不是短時間以內可以完成的。固然也有另一個新穎（或者說腦洞大開）的思路：引入 Web Assembly（WASM）。目前 Envoy 在進行支持 Web Assembly 的嘗試，若是成功，則經過 Web Assembly 的方式來支持 Mixer Adapter 不失爲一個好選擇。

（三）其餘社區產品動態
最近，CNCF 在籌建 Universal Data Plane API （UDPA/通用數據平面 API）工做組，以制定數據平面的標準 API，爲 L4/L7 數據平面配置提供事實上的標準。Universal Data Plane API 的創意來自 Envoy，實現爲 xDS API。而目前 xDS v2 API 已是數據平面API的事實標準，此次的 UDPA 會以 xDS v2 API 爲基礎。工做組的初始成員來自包括 Envoy 和 gRPC 項目的表明，螞蟻金服也在積極參與 UDPA 工做組，目前還處於很是早期的籌備階段。

Linkerd2 在 2019年4月17日 發佈了最新的穩定版本 Linkerd 2.3 版本。Linkerd2 是目前開源產品中惟一正面對抗 Istio 的存在，不過在國內知名度不高，使用者也不多。比較有意思的是，開發 Linkerd2 的初創公司 Buoyant 最近的 B 輪融資來自 Google 的投資部門。
（四）雲廠商的產品動態
隨着 Service Mesh 技術的發展，和各方對 Service Mesh 前景的看好，各大主流雲提供商都開始在 Service Mesh 技術上發力。
首先看 AWS，在2019年4月，AWS 宣佈 App Mesh GA。App Mesh 是 AWS 推出的 AWS 原生服務網格，與 AWS 徹底集成，包括：
· 網絡（AWS cloud map）
· 計算（Amazon EC2 和 AWS Fargate）
· 編排工具（AWS EKS，Amazon ECS 和 EC2 上客戶管理的 k8s）

App Mesh 的數據平面採用 Envoy，產品很是有創意的同時支持 VM 和容器，支持多種產品形態，如上圖所示。（AWS App Mesh 的更多詳細內容，請瀏覽文章用AWS App Mesh從新定義應用通信 [5]）

Google 的打法則是圍繞 Istio 。首先是在2018年末推出了 Istio on GKE，即"一鍵集成Istio"，並提供遙測、日誌、負載均衡、路由和 mTLS 安全能力。接着 Google 又推出 Google Cloud Service Mesh，這是 Istio 的徹底託管版本，不只僅提供 Istio 開源版本的完整特性，還集成了 Google Cloud 上的重要產品 Stackdriver 。

近期，Google 推出 Traffic Director 的 beta 測試版本，Traffic Director 是徹底託管的服務網格流量控制平面，支持全局負載均衡，適用於虛擬機和容器，提供混合雲和多雲支持、集中式健康檢查和流量控制，還有一個很是特別的特性：支持基於流量的自動伸縮。

（Google Traffic Director 的詳細介紹，請查看文章 Google Traffic Director詳細介紹 [6]）

微軟則推出了Service Fabric Mesh。Azure Service Fabric 是 Microsoft 的微服務框架，設計用於公共雲，內部部署以及混合和多雲架構。而 Service Fabric Mesh 是 Azure 徹底託管的產品，在 2018年8月 推出預覽版。

上週（5月21號）最新消息，微軟在 KubeConf 上推出 Service Mesh Interface。SMI 是在 Kubernetes 上運行服務網格的規範，定義了由各類供應商實現的通用標準，使得最終用戶的標準化和服務網格供應商的創新能夠一箭雙鵰，SMI 預期將爲 Service Mesh 帶來了靈活性和互通性。

SMI 是一個開放項目，由微軟、Linkerd、HashiCorp、Solo、Kinvolk 和 Weaveworks 聯合啓動；並獲得了 Aspen Mesh、Canonical、Docker、Pivotal、Rancher、Red Hat 和 VMware 的支持。

3、Service Mesh 發展趨勢

在分享完最近半年 Service Mesh 產品的動態以後，咱們來分析探討 Service Mesh 的發展趨勢。

（一）趨勢1：上雲+託管
在微服務/容器這些年的發展歷程中，咱們會發現一個頗有意思（甚至有些啼笑皆非）的現象：

· 爲了解決單體的複雜度問題，咱們引入微服務架構；
· 爲了解決微服務架構下大量應用部署的問題，咱們引入容器；
· 爲了解決容器的管理和調度問題，咱們引入 Kubernetes；
· 爲了解決微服務框架的侵入性問題，咱們引入 Service Mesh；
· 爲了讓 Service Mesh 有更好的底層支撐，咱們又將 Service Mesh 運行在 k8s 上。

在這個過程當中，從單個應用（或者微服務）的角度看，的確自身的複雜度下降，在有底層系統支撐的狀況下部署/維護/管理/控制/監控等也都大爲簡化。可是站在整個系統的角度，總體複雜度並無消失，只是從單體分解到微服務，從應用下沉到 Service Mesh，複雜度從總量上不但沒有減小，反而大爲增長。

解決這個問題最好的方式就是 上雲，使用 託管 版本的 k8s 和 Service Mesh，從而將底層系統的複雜度交給雲廠商，而客戶只須要在雲的基礎上享受 Service Mesh 技術帶來的使用便利和強大功能。

前面咱們分享產品動態時，能夠看到目前 Google / AWS / 微軟 這三巨頭都已經推出了各自的 Service Mesh 託管產品，而在國內，阿里雲/華爲雲等也有相似的產品推出，咱們螞蟻金服也將在稍後在金融雲上推出 SOFAMesh 的雲上託管版本。在這裏，我總結爲一句話：
幾乎全部的主要公有云提供商都在提供（或者準備提供）Service Mesh 託管方案。
（二）趨勢2：VM 和容器混用
第二個趨勢就是VM和容器混用，即 Service Mesh 對服務的運行環境的支持，不只支持容器（尤爲指 k8s），也支持虛擬機，並且支持運行在這兩個環境下的服務相互訪問，甚至直接在產品層面上屏蔽二者的差別。
好比 Google 的 Traffic Director 產品：

AWS 的 App Mesh 產品：

都是在產品層面直接提供 VM 和容器混用的支持，無論應用是運行在 VM 上仍是容器內均可以支持，並且能夠方便的遷移。

（三）趨勢3：混合雲和多雲支持
混合雲和多雲支持最近正成爲一個新的技術熱點和商業模式，甚至 Google Cloud 都喊出口號，要 "All in Hybrid Cloud"！Google Traffic Director 旗幟鮮明的表達了 Google Cloud 對混合雲的重視：

下圖是 Google Traffic Director 給出的一個應用改造示例：從單體結構轉爲微服務架構，從私有云轉爲公有云加私有云的混合雲模式。

Service Mesh 毫無疑問是實現上述轉型並提供混合雲和多雲支持的一個很是理想的解決方案。

（四）趨勢4：和 Serverless 的結合
Service Mesh 技術和 Serverless 技術是工做在不一樣緯度的兩個技術：
· Service Mesh 技術的關注點在於服務間通信，其目標是剝離客戶端 SDK，爲應用減負，提供的能力主要包括安全性、路由、策略執行、流量管理等。
· Serverless 技術的關注點在於服務運維，目標是客戶無需關注服務運維，提供服務實例的自動伸縮，以及按照實際使用付費。

理論上 Service Mesh 技術和 Serverless 技術並無衝突的地方，能夠結合使用。事實上目前業界也開始出現這個趨勢，而融合的方式有兩種：

1. 在 Serverless 中引入 Service Mesh：典型如 Knative 項目和 Knative 的 Google Cloud 託管版本 Google Cloud Run，經過引入對容器的支持和使用 Istio，Knative 將 Serverless 的支持擴展到 Function 以外，在極大的擴展 Serverless 適用範圍的前提下，也將服務間通信的能力引入到 Serverless。
2. 在 Service Mesh 中引入 Serverless：典型如 Google Traffic Director 產品，在提供 Service Mesh 各類能力的同時，支持按照流量自動伸縮服務的實例數量，從而融入了部分 Serverless 的特性。

對於 Serverless 和 Service Mesh 的結合，咱們展望將來形態：將來應該會出現一種新型服務模式，Serverless 和 Service Mesh 合二爲一。只要將服務部署上來，就自動能夠獲得 Service Mesh 的服務間通信能力和 Serverless 的無服務器運維。在螞蟻金服，咱們將這理解成爲是將來雲原生應用的終態之一，正在積極探索其落地的實際方式。

（五）趨勢5：Mesh 模式延伸
回顧一下 Service Mesh 模式的核心，其基本原理在於將客戶端 SDK 剝離，以 Proxy 獨立進程運行；目標是將原來存在於 SDK 中的各類能力下沉，爲應用減負，以幫助應用雲原生化。

遵循這個思路，將 Service Mesh 的應用場景泛化，不侷限於服務間的同步通訊，就能夠推廣到更多的場景：特徵是有網絡訪問，而是經過客戶端 SDK 來實現。

在螞蟻金服的實踐中，咱們發現 Mesh 模式不只僅適用於服務間同步通信，也能夠延伸到如下場景：
· Database Mesh：數據庫訪問
· Message Mesh：消息機制
· Cache Mesh：緩存

以上模式的產品螞蟻金服都在探索中，相關的產品正在開發和嘗試落地。社區也有一些相關的產品，好比 Database Mesh 方面張亮同窗在力推的 Apache Shardingsphere [7] 項目。經過更多的 Mesh 模式，咱們能夠覆蓋更多的場景，從而實現讓應用在各個方面都作到減負，而不只僅是 Service Mesh 對應的服務間通信，從而爲後續的應用雲原生化奠基基礎。

（六）趨勢6：標準化，不鎖定
雲原生的一個重要主張，就是但願在雲上爲用戶提供一致的用戶體驗，提倡標準化，避免供應商綁定（Not Lock-In）。

從前面分享的 Service Mesh 產品動態能夠看出，目前 Service Mesh 市場上出現了衆多的供應商和產品：開源的、閉源的、大公司出的、小公司出的。市場繁榮的同時也帶來了市場碎片化的問題——全部圍繞業務應用的外圍工做，好比經過 Service Mesh 對流量進行控制，配置各類安全/監控/策略等行爲，以及在這些需求上創建起來的工具和生態系統，卻不得不緊緊的綁死在某個具體的 Service Mesh 實現上，所謂」供應商鎖定」。其根本問題在於各家實現不一樣，又沒有統一標準。所以，要想解決上述問題，就必須釜底抽薪：解決 Service Mesh 的標準化問題。

就在最近這一個月，Service Mesh 社區出現了兩個推進標準化的大事件：

1. CNCF 籌建 Universal Data Plane API （通用數據平面 API）工做組，計劃以 xDS v2 API 爲基礎制定數據平面的標準 API，工做組的初始成員來自包括 Envoy 和 gRPC 項目的表明（能夠理解爲 Google 爲首）；
2. 微軟在 KubeConf 上推出 Service Mesh Interface，準備定義在 Kubernetes 上運行服務網格的規範，爲 Service Mesh 帶來了靈活性和互通性。SMI 由微軟牽頭，聯合 Linkerd，HashiCorp，Solo，Kinvolk 和 Weaveworks。

爲了方便理解這兩個標準，我爲你們準備了一張圖：

其中，Universal Data Plane API 是數據平面的標準，控制平面經過這個API來控制數據平面的行爲。而 Service Mesh Interface 是控制平面的標準，上層的應用/工具/生態體系經過 Service Mesh Interface 來實現跨不一樣的 Service Mesh 實現爲最終用戶提供一致性的體驗。

固然這兩個標準化 API 都剛剛起步，並且，標準化的工做一般不只僅是技術問題，涉及到複雜的利益關係，具體將來走向如今難於推斷，只能密切關注。
（七）發展趨勢分析

咱們總結一下上面列出的 Service Mesh 最近的 6 個發展趨勢：

這些趨勢都和雲有關，核心在於讓雲來提供能力，包括：
· 讓雲承擔更多職責
· 提供更高抽象
· 適用更多場景
· 減小應用負擔：實現應用輕量化

最終實現讓業務應用專一業務的戰略目標。

對於 Service Mesh 技術將來的走向，個人見解是：Service Mesh 技術必然不是孤立的自行發展，而是在雲原生的大環境下，與雲原生的其餘技術、理念、最佳實踐一塊兒相互影響、相互促進、相互支撐、共同發展。雲原生是一個龐大的技術體系，Service Mesh 須要在這個體系中得到各類支撐和配合，才能最大限度的發揮自身的優點。

4、Service Mesh 與雲原生

在最後一段，咱們來談談 Service Mesh 技術和雲原生的關係，也就是本次分享的標題所說的：雲原生中流砥柱。憑什麼？

（一）什麼是雲原生？
在解釋以前，首先問一個問題：什麼是雲原生？相信這個問題不少同窗都問過，或者被問過，每一個人內心可能都有本身的理解和表述。在今年年初，我也特地就這個問題問了本身，而後嘗試着給出了一個個人答案：

雲原生指 "原生爲雲設計"，具體說就是：應用原生被設計爲在雲上以最佳方式運行，充分發揮雲的優點。

關於雲原生的理解，以及對這句話的詳細闡述，這裏不詳細展開，有興趣的同窗能夠瀏覽我以前的演講內容，講的比較深刻，厚顏自薦一下：
· 暢談雲原生（上）[8]: 如何理解雲原生？雲原生應用應該是什麼樣子？雲原生下的中間件該如何發展？
· 暢談雲原生（下）[9]: 雲和應用該如何銜接？如何讓產品更符合雲原生？

（二）Service Mesh 的核心價值
關於 Service Mesh 的核心價值，我我的的理解，不在於 Service Mesh 提供的玲琅滿目的各類功能和特性，而是：實現業務邏輯和非業務邏輯的分離，將非業務邏輯的功能實現，從客戶端SDK中剝離出來，放到獨立的 Proxy 進程中，這是 Service Mesh 在技術實現上走出的第一步，也是相當重要的第一步：由於這一步，實現了業務邏輯和非業務邏輯的分離，並且是最完全的物理分離，哪怕須要爲此付出一次遠程調用的代價。

而這一步邁出以後，前面就是海闊天空：
· 業務邏輯和非業務邏輯分離以後，咱們就能夠將這些非業務邏輯繼續下沉
· 下沉到基礎設施，基礎設施能夠是基於VM的，能夠是基於容器和k8s的；也能夠是VM和容器混合
· 基礎設施也能夠以雲的形式提供，能夠是公有云、私有云，也能夠是混合雲、多雲；
· 能夠選擇雲上託管，徹底託管也好，部分託管也好，產品形態能夠很靈活
總結說，業務邏輯和非業務邏輯的分離：
· 爲下沉到基礎設施提供可能
· 爲上雲提供可能
· 爲應用輕量化提供可能
注：這裏說的上雲，指的是上雲原生(Cloud Native)的雲，而不是上雲就緒(Cloud Ready)的雲。

（三）Mesh化是雲原生落地的關鍵步驟
在過去一年中，螞蟻金服一直在努力探索雲原生落地的方式，在這個過程當中，咱們有一些感悟，其中很是重要的一條就是：Mesh 化是雲原生落地的關鍵步驟。

如上圖所示：

· 最下方是雲，基於k8s和容器打造，提供各類基礎能力，這些能力有一部分來自傳統中間件的下沉
· 在雲上是 Mesh 層，包含 Service Mesh 以及咱們前面提到的各類擴展的 Mesh 模式，實現通訊的標準化
· 在經過 Mesh 剝離非業務功能並下沉以後，應用實現了輕量化，傳統的 App 和新興的微服務均可以受益於此
· 更進一步，輕量化以後的業務應用，其工做負載在瘦身減負以後變得至關的乾淨，基本只剩業務邏輯，包括傳統的 App，以 Container 形式運行的服務和新穎的 Function，這些負載在往 Serverless 形態轉換時相對要輕鬆不少

配合 Serverless 技術領域最新的技術潮流和產品發展（如以 Knative 項目爲表明，Serverless 再也不僅僅是 Function 形式，也支持 BaaS 等偏傳統的工做負載），Mesh 化爲現有應用轉型爲 Serverless 模式提供助力。

在這裏咱們再分享一下螞蟻金服對將來中間件產品發展的感悟，咱們認爲中間件的將來在於 Mesh 化，並融入基礎設施，以下圖所示：

左邊是傳統的中間件形態，在雲原生時代，咱們但願將非業務功能從傳統中間件的富客戶端中剝離出來，而後將這些能力以及這些能力背後的中間件能力，下沉到基礎設施，下沉到雲。而中間件產品也會融入基礎設施，如圖中右邊所示。將來的中間件將做爲基礎設施和雲的一部分，而 Mesh 則成爲鏈接應用和基礎設施以及其餘中間件產品的橋樑。

更重要的是：業務應用所以而實現輕量化，在剝離各類非業務功能以後，業務應用就實現了只關注業務邏輯的戰略目標，從而實現從傳統應用到雲原生應用的轉型。

總結：經過 Service Mesh 技術，咱們實現了業務邏輯和非業務邏輯的分離，爲應用的輕量化和雲原生化提供可能；並經過將非業務邏輯的各類功能下沉到基礎設施和雲，極大的加強了基礎設施和雲的能力，爲雲原生的落地提供了極大助力。

所以，咱們認爲：Service Mesh 技術將在雲原生落地中扮演了很是重要的做用，不可或缺。

（四）Service Mesh 發展展望
最後再次展望一下 Service Mesh 的將來發展。
左邊是 Service Mesh 發展初期的最重要的兩個原始動力：多語言支持和類庫升級。關於這兩點，最近這兩年中介紹和推廣 Service Mesh 理念和產品的同窗基本都講過，可是今天我想指出的是：這只是 Service Mesh 的起點，而遠不是 Service Mesh 的終點。

Service Mesh 的將來，不會停留在僅僅知足多語言支持和類庫升級，而是跟隨雲原生的大潮，解決各類實際需求，同時又儘可能維持上層業務應用的簡單直白。

在此次分享的最後，我想給你們一個留一個課外做業，有心的同窗能夠嘗試一下：若是您想更深刻的理解 Service Mesh 的價值，想對 Service Mesh 將來的發展方向有更清晰的認識，尤爲是但願能經過自身的思考和感悟來理解 Service Mesh 而不是簡單的被灌輸（包括被我灌輸），那麼請嘗試獨立的作以下思考：

1. 拋開左邊的這兩點，不要將思惟侷限在這個範圍內；
2. 考慮雲原生的大背景，結合您自身對雲原生的理解，和對雲的指望；
3. 針對右邊的 Service Mesh 的六個趨勢，忘記我前面講述的內容，只考慮其背後的實際場景和客戶需求，以及這個場景帶來的業務價值，而後認真對比使用 Service Mesh 和不使用 Service Mesh 兩種狀況下的解決方案；
4. 請在上述思考的過程當中，更多的從業務應用的角度來看待問題，假設你是那個雲上的應用（還記得前面圖上的小 baby 嗎？），你會但願被如何對待。

但願這樣的思考能讓您有所收穫。

5、文中涉及的相關連接

[1] 大規模微服務架構下的Service Mesh探索之路：
https://skyao.io/talk/201806-...
[2] Service Mesh架構反思：數據平面和控制平面的界線該如何劃定？：
https://skyao.io/post/201804-...
[3] Mixer Cache: Istio的阿克琉斯之踵?：
https://skyao.io/post/201804-...
[4] Istio Mixer Cache工做原理與源碼分析：
https://skyao.io/post/201804-...
[5] 用AWS App Mesh從新定義應用通信：
https://skyao.io/post/201904-...
[6] Google Traffic Director詳細介紹：
https://skyao.io/post/201905-...
[7] Apache Shardingsphere：
https://shardingsphere.apache...
[8] 暢談雲原生（上）：
https://skyao.io/talk/201902-...
[9] 暢談雲原生（下）：
https://skyao.io/talk/201902-...