前言
本文內容整理自5月25日在 Kubernetes & Cloud Native Meetup 上海站發表的主題演講，主要介紹了ServiceMesh最新的產品動態，分析其發展趨勢和未來走向；結合螞蟻的上雲實踐，闡述在雲原生背景下Service Mesh的核心價值，以及對雲原生落地的關鍵作用。
內容主要有三個部分：
- Service Mesh產品動態：介紹最近半年 Service Mesh 的產品動態，包括開源項目和雲廠商推出的雲上服務
- Service Mesh發展趨勢：根據最近的產品動態，總結 Service Mesh 的發展趨勢，推斷未來的走向
3 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中引入Servicemesh：典型如 knative 項目和 knative 的 Google Cloud 託管版本 Google Cloud Run，通過引入對容器的支持和使用 Istio，knative 將 Serverless 的支持擴展到 Function 之外，在極大的擴展 Serverless 適用範圍的前提下，也將服務間通訊的能力引入到 Serverless。
- 在Servicemesh中引入 Serverless：典型如 Google Traffic Director 產品，在提供 Service Mesh 各種能力的同時，支持按照流量自動伸縮服務的實例數量，從而融入了部分 serverless 的特性。
對於 Serverless 和 Servicemesh 的結合，我們來展望未來形態：未來應該會出現一種新型服務模式，Serverless 和 Servicemesh 合二爲一。只要將服務部署上來，就自動可以得到 Servicemesh 的服務間通訊能力和 Serverless的無服務器運維。在螞蟻金服，我們將這理解成爲是未來雲原生應用的終態之一，正在積極的探索其落地的實際方式。
趨勢5：Mesh模式延伸
回顧一下 Service Mesh 模式的核心，其基本原理在於將客戶端SDK剝離，以 Proxy 獨立進程運行；目標是將原來存在於SDK中的各種能力下沉，爲應用減負，以幫助應用雲原生化。
遵循這個思路，將 Service Mesh 的應用場景泛化，不侷限於服務間的同步通信，就可以推廣到更多的場景：特徵是有網絡訪問，而是通過客戶端SDK來實現。
在螞蟻金服的實踐中，我們發現Mesh模式不僅僅適用於服務間同步通訊，也可以延伸到以下場景：
- Database Mesh: 數據庫訪問
- Message Mesh：消息機制
- Cache Mesh：緩存
以上模式的產品螞蟻金服都在探索中，相關的產品正在開發和嘗試落地。社區也有一些相關的產品，比如 Database Mesh 方面張亮同學在力推的 Apache Shardingsphere 項目。
通過更多的 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 雲原生工作坊，我們將在這次活動中，推出螞蟻金服金融雲完全託管版本的SOFAMesh的體驗版本，歡迎報名參加。我將在上海 kubeconf 的 workshop 現場恭候大駕。
原文鏈接：