Service Mesh 發展趨勢：雲原生中流砥柱
Service Mesh 發展趨勢：雲原生中流砥柱
前言
本文內容整理自5月25日在 Kubernetes & Cloud Native Meetup 上海站發表的主題演講，主要介紹了 ServiceMesh 最新的產品動態，分析其發展趨勢和未來走向；結合螞蟻金服的上雲實踐，闡述在雲原生背景下 Service Mesh 的核心價值，以及對雲原生落地的關鍵作用。
內容主要有三個部分：
- Service Mesh 產品動態：介紹最近半年 Service Mesh 的產品動態，包括開源專案和雲廠商推出的雲上服務
- Service Mesh 發展趨勢：根據最近的產品動態，總結 Service Mesh 的發展趨勢，推斷未來的走向
- Service Mesh 與雲原生：結合雲原生，更好的理解 Service Mesh 的價值和作用
Service Mesh 產品動態
Istio1.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探索之路 ： 第二節架構設計中的"合併部分Mixer功能"
- Service Mesh架構反思：資料平面和控制平面的界線該如何劃定？
- Mixer Cache: Istio的阿克琉斯之踵? ： 系列文章，有兩篇
- Istio Mixer Cache工作原理與原始碼分析： 系列文章，有四篇
目前 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重新定義應用通訊 。
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詳細介紹。
微軟則推出了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 的支援。
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 技術並沒有衝突的地方，可以結合使用。事實上目前業界也開始出現這個趨勢，而融合的方式有兩種：
- 在 Serverless 中引入 Service Mesh：典型如 Knative 專案和 Knative 的 Google Cloud 託管版本 Google Cloud Run，通過引入對容器的支援和使用 Istio，Knative 將 Serverless 的支援擴充套件到 Function 之外，在極大的擴充套件 Serverless 適用範圍的前提下，也將服務間通訊的能力引入到 Serverless。
- 在 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 社群出現了兩個推動標準化的大事件：
- CNCF 籌建 Universal Data Plane API （通用資料平面 API）工作組，計劃以 xDS v2 API 為基礎制定資料平面的標準 API，工作組的初始成員來自包括 Envoy 和 gRPC 專案的代表（可以理解為 Google 為首）；
- 微軟在 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 需要在這個體系中獲得各種支撐和配合，才能最大限度的發揮自身的優勢。
Service Mesh 與雲原生
在最後一段，我們來談談 Service Mesh 技術和雲原生的關係，也就是本次分享的標題所說的：雲原生中流砥柱。
憑什麼？
什麼是雲原生？
在解釋之前，首先問一個問題：什麼是雲原生？相信這個問題很多同學都問過，或者被問過，每個人心裡可能都有自己的理解和表述。在今年年初，我也特意就這個問題問了自己，然後嘗試著給出了一個我的答案：
雲原生指 "原生為雲設計"，具體說就是：應用原生被設計為在雲上以最佳方式執行，充分發揮雲的優勢。
關於雲原生的理解，以及對這句話的詳細闡述，這裡不詳細展開，有興趣的同學可以瀏覽我之前的演講內容，講的比較深入，厚顏自薦一下：
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 而不是簡單的被灌輸（包括被我灌輸），那麼請嘗試獨立的做如下思考：
- 拋開左邊的這兩點，不要將思維侷限在這個範圍內；
- 考慮雲原生的大背景，結合您自身對雲原生的理解，和對雲的期望；
- 針對右邊的 Service Mesh 的六個趨勢，忘記我前面講述的內容，只考慮其背後的實際場景和客戶需求，以及這個場景帶來的業務價值，然後認真對比使用 Service Mesh 和不使用 Service Mesh 兩種情況下的解決方案；
- 請在上述思考的過程中，更多的從業務應用的角度來看待問題，假設你是那個雲上的應用（還記得前面圖上的小 baby 嗎？），你會希望被如何對待？
希望這樣的思考能讓您有所收穫。
尾聲：歡迎報名 SOFAStack 雲原生工作坊
最後做個廣告，歡迎大家參加 SOFAStack 雲原生工作坊，我們將在這次活動中，推出螞蟻金服金融雲完全託管版本的 SOFAMesh 的體驗版本，歡迎報名參加。我將在上海 KubeConf 的 workshop 現場恭候大駕。
提示：請使用釘釘掃描上面的二維碼。或者直接訪問 KubeConf 的活動頁面 檢視這次 worksh