service mesh - 微服務通訊進化之路

1、什麼是 service mesh

service mesh 致力於作微服務時代的 TCP,  它解決的是微服務架構時代的通訊問題。管理和控制網絡間通訊問題，解放業務團隊，提高總體研發效率。

1. 微服務時代的 TCP

TCP 是互聯網的基石，首先來回顧下 TCP 對網絡的做用，再來看看微服務時代下通訊面臨的問題以及 service mesh 該解決的問題，以及如何像 TCP 同樣通用化的解決這些問題。從而成爲做爲微服務時代的 TCP。

（1）端到端時代的 TCP

互聯網能發展至今，TCP 協議功不可沒。它讓計算機真正的可以互連互通。TCP 是提供了可靠的端到端的鏈接、數據傳輸方式。TCP  經過提供了握手協議、ACK 機制、超時重傳、滑動窗口、擁塞控制算法、數據分片、數據校驗等等，實現面向鏈接、可靠的端到端網絡通訊。
TCP 不只解決了這些問題，它還成爲全部應用程序互聯的通用標準。互聯網的應用幾乎都使用 TCP 協議進行通訊，能夠說，沒有 TCP 就沒有今天的互聯網。
TCP 協議由操做系統處理，絕大多數網絡業務進程無需處理端到端通訊，對網絡協議的優化也無需更新各個應用程序的版本，只須要優化操做系統的協議便可，作到了標準化和解耦。極大的釋放了應用程序的業務迭代能力，豐富的應用程序也進一步的促進了計算機操做系統進入千家萬戶。

（2）分佈式微服務時代的 TCP ——  service mesh

在互聯網迅速融入社會後，業務也愈來愈複雜。服務端須要處理的業務愈來愈多，幾個大型服務器徹底沒法知足業務運營的須要, 業務開發團隊也是動輒幾百、上千人。後臺的分佈式架構、微服務架構開始流行，以適應複雜的業務，並圍繞獨立的業務構建團隊。
隨着業務的不斷髮展，微服務的數量愈來愈多，微服務間的通訊網絡也變得十分複雜，微服務間的通訊拓撲能夠構成一個複雜的網絡。


在微服務架構中，一次請求每每經歷了許多服務節點。在這個角度看，服務間通訊已經不在是端到端的調用了，而是"多個節點訪問多個節點"的關係了。在處理分佈式微服務架構中"多個節點"的互相通訊上，須要解決這些通用的問題:

• 服務註冊、服務發現；

• 負載均衡；

• 彈性能力(熔斷、限流、降級、超時、重試等)；

• 安全(認證受權)；

• 可觀測性(控制面板、拓撲圖、鏈路追蹤等)。

service mesh 要作微服務時代的 TCP，也就是在解決上述問題的基礎上，還要作到通用化、標準化，解耦合業務進程與 mesh。讓通訊過程在微服務間變得簡單、可靠。下圖是 TCP 須要處理的問題以及 service mesh 須要處理的問題:


將這些能力與業務進程剝離，是 service mesh 和成爲新一代 TCP 的理念。這樣有利於通訊過程的標準化、通用化，讓業務開發無需關心通訊過程，從而進一步解放業務的迭代效率。

2. 分佈式微服務的通訊發展史

service mesh 這個詞彙在 2016 年出現。可是服務間通訊的相關技術早在網格計算機系統時代就開始發展了。從計算機設備端到端通訊的發展開始，經歷過如下階段:

• 第一代網格計算機系統，應用程序的開發中須要處理網絡通信細節問題，如數據包順序、流量控制等。這些處理網絡的邏輯和業務邏輯混在一塊兒。
• 隨之發展出了 TCP/IP 協議，處理網絡的代碼從應用程序中抽象出來，通用的協議成爲操做系統的網絡層的一部分，解放了應用程序的開發。
• 微服務時代，隨着應用程序功能的不斷增長，新的微服務架構開始流行。第一代微服務架構中應用程序開發須要處理微服務面臨的一些問題，包括負載均衡、熔斷、重試等，對於微服務架構的應用開發人員有額外的要求。
• 隨着微服務架構的發展，Spring Cloud 、Dubbo 等微服務框架開始出現，框架層面處理了負載均衡、熔斷、重試等，進一步的解放了應用程序的開發，以加快上層業務的迭代效率。Spring Cloud 等做爲以類庫方式存在的侵入式微服務框架，只是幫助業務程序減小了直接編寫的冗餘代碼，可是依然須要框架與應用程序一塊兒編譯打包，功能與業務進程一同運行。Spring Cloud 等框架仍是有以下缺點：門檻高：因爲框架組件多，對於業務開發人員，就須要掌握較多非業務的知識，增長了業務開發人員的挑戰。功能不全：框架所能提供的微服務治理功能是有限的，好比路由規則定義能力(Version Base Routing、Content Base Routing) 。跨語言：跨語言是微服務的優點之一，它可讓不一樣語言編寫的服務經過暴露接口服務調用的方式開放能力。而使用類庫的微服務，將被類庫支持的語言限制。

  升級困難：框架也是須要不斷的改進升級的，因爲應用程序的編寫使用的是框架，當框架升級更新時，就必須從新編譯打包應用程序，按照發版流程升級全部使用框架的微服務。這樣的流程將是十分複雜和耗時的。

• Spring Cloud 等做爲以類庫方式存在的侵入式微服務框架，只是幫助業務程序減小了直接編寫的冗餘代碼，可是依然須要框架與應用程序一塊兒編譯打包，功能與業務進程一同運行。Spring Cloud 等框架仍是有以下缺點:
• Proxy 模式。在微服務以前，爲了不客戶端、服務端的耦合問題曾經過中間代理層如 Nginx、HAProxy、Apache 等反向代理完成轉發功能，並由中間代理層實現負載均衡，從而解耦合服務端與客戶端。Proxy 模式具有一些基礎的微服務治理功能，同時它能夠獨立於應用服務，減小微服務治理與業務服務的耦合。
• Sidecar 模式。Proxy 模式的功能較爲簡單，並不能徹底代替侵入式的框架。sidecar 模式則在 Proxy 模式上進一步改進，它的實現每每是在 Proxy 的請求轉發的基礎上，利用框架類庫進一步實現微服務框架具備的各類功能，如服務註冊、熔斷、重試等。sidecar 模式因爲其解決的問題思路，通常是針對特定的基礎架構設計的，它的通用性具備一些侷限性。
• 第一代 service mesh。2016 年 1 月，離開 twitter 的工程師William Morgan和 Oliver Gould 發佈了 Linkerd ，成爲第一個 Service Mesh 項目。2017 年 1 月來自 Lyft Envoy 誕生，它是業界第二個 service mesh 項目。service mesh 在 sidecar 的基礎上，解決了通用性問題，不受限於原有的基礎環境。在 Service Mesh 中，全部的請求都經過 Service Mesh 轉發，不提供直連方式，它掌控全部的流量。

• 第二代 service mesh。2017 年 5 月, Google、IBM、Lyft 聯手發佈了 Istio，它與第一代 Service Mesh 相比，增長了控制平面，它具有遠超第一代的控制能力。經過集中式控制面板，加上全部流量均會經過 Service Mesh 轉發，經過 Service Mesh 的控制面板，就能夠控制全部整個系統。

（1）框架、庫

以 Spring Cloud 、Dubbo 爲表明的框架，與語言強相關相關，必須框架支持的語言，或提供各語言庫函數，才能夠進行微服務通訊。它們須要和業務代碼一塊兒編譯進入業務進程，在進行框架、庫的更新時，將會十分痛苦，須要更新全部的相關業務服務。

（2）proxy 模式

在分佈式服務器上，nginx 、HAProxy 等代理早就提供了終端訪問服務器的負載均衡，它們一樣也能夠用於微服務間的通訊，實現服務發現、負載均衡等相關功能。且 proxy 模式下，只須要接受網絡報文便可，而後會將其轉發到對應的服務上，與調用方、服務進程的編程語言無關，無需提供特定 API、SDK ，透明性更好。但傳統的代理 nginx、HAProxy 等功能較簡單，對於常常伸縮的微服務節點，使用也十分受到限制。

（3）sidecar

Proxy 模式的功能較爲簡單，並不能徹底代替侵入式的框架。sidecar 模式則在 Proxy 模式上進一步改進，它的實現每每是在 Proxy 的請求轉發的基礎上，利用框架類庫進一步實現微服務框架具備的各類功能，如服務註冊、熔斷、重試等。sidecar 模式因爲其解決的問題思路，通常是針對特定的基礎架構設計的，它的通用性具備一些侷限性。但相比於傳統的框架如 Spring Cloud，它是將對應的 SDK 運行於 sidecar 進程上，當對相關庫進行更新時，只須要更新 sidecar 進程便可，不會影響到業務進程。

（4）service mesh

sidecar 模式的存在更多的是爲了兼容已有的分佈式系統，從而慢慢轉向 service mesh 理念，將流量交給"微服務時代的 TCP"。service mesh 的通訊流程大體以下:


能夠看到，service mesh 相比於傳統的 l5 以及當前的 polaris，業務服務調用流程上少了一步，只須要將請求轉發給 service mesh 便可，它將直接轉發到對應的業務服務。

在 service mesh 處理了這些請求、響應的轉發以後，因爲流量都通過 service mesh ，這就能夠很方便的對這些流量進行統一管理，從而進一步提供限流、熔斷、監控、全鏈路拓撲圖生成等, 以及能夠進一步針對 service mesh 層的流量進行分析處理，這些都將不需對應業務人員參與。就像 TCP 協議同樣，統一處理了超時重傳、可靠傳輸、流量控制、擁塞控制等，並能夠不斷的更新優化協議機制，而業務進程不須要再處理這些，不須要業務進程發版更新。業務進程只需構造 TCP 報文交給操做系統便可，端到端的優化則能夠經過優化 TCP 處理。而 service mesh 也同樣，對於分佈式微服務之間的服務調用流量的進一步分析、管理功能的迭代，不須要更新業務服務、發版處理，解放業務開發人員，也解放微服務治理基礎能力開發人員。
但目前 service mesh 也存在必定的問題，大規模的實踐並不太多，騰訊內部的業務實踐上也並很少。全部流量有 mesh 層統一處理，也帶了了性能上的質疑, 不過這將被技術解決，它的優勢和趨勢是十分明顯的。

（5）微服務通訊治理

在微服務這樣的分佈式系統環境下，須要經過各類方式完成以下功能:

• 服務註冊: 節點啓動後，對外註冊提供服務，使得其它業務方能夠調用節點的接口。

• 服務發現: 當業務節點須要訪問分佈式的服務方時，能夠經過服務發現功能獲取目標節點的 IP，完成網絡訪問。

• 負載均衡: 經過不一樣的負載均衡策略，能夠將訪問分發到分佈式的各個節點上，加強服務方集羣的容量。

• 限流:  單體的節點的負載能力有限，限流能夠保護服務方不至於流量過大，對節和集羣加一層保護措施。

• 熔斷: 若服務方的響應時間過長或不可用調用過多，及時熔斷的熔斷能夠提高總體的可用性。

• 降級: 熔斷後，業務方能夠選擇進行降級處理，進行不處理或簡單處理，保證總體可用性。

• 自動擴容: 根據訪問量的增長，自動調整服務方集羣節點數量，提升服務端的容量。

• 自動故障隔離: 當系統內部組件出現故障後，故障隔離措施能夠將故障範圍控制在局部，防止故障範圍擴大，增長對上層系統可用性帶來的影響。

• 自動業務恢復: 熔斷、降級等處理後，能夠及時根據系統狀況恢復正常。

• 監控: 對微服務、容器、機器、業務進行監控，瞭解系統的情況以便於進行相應調整。

• 日誌: 收集日誌用於覆盤分析。

• 流量鏡像等: 將線上的流量複製一份到特定的環境中，用於對訪問內容進行分析。
  service mesh 則在對流量透明轉發的基礎上，提供這些通用的能力。

3. 爲何須要 service mesh

kubernetes 技術將微服務的架構推向主流，讓全部語言均可以以容器形式部署，提供微服務功能。而跨語言的微服務間通訊將比 Spring Cloud 等語言相關的框架更加複雜，kubernetes 雖然提供了 service 代理層通訊，提供了服務發現、服務註冊、負載均衡的基礎功能。可是認證受權、可觀測性、鏈路追蹤、熔斷、降級、限流等業務發展不斷龐大後都須要的微服務通訊治理功能卻依然不足。
若解決這些功能的代碼開發工做放在業務工程內，編譯進業務代碼，那就不可避免的須要進行編譯、發版甚至測試流程，對於通用能力的進一步迭代更新，好比流量分析，則須要更新發版全部業務進程。並且對於跨語言的微服務，通用的框架能力還須要提供多語言版本。而對於熔斷、限流等的規則配置，則分散於不一樣的業務配置中，不利於統一管理。
這些通用的且業務相關性不大的微服務能力，能不能更加通用的進行維護、中臺化？將全部的流量都交給 service mesh 這一透明代理層，對流量的管控不在須要業務進程處理，相應的微服務間訪問的通用能力也交由 service mesh 層處理便可，包括認證受權、熔斷、降級、限流、監控追蹤等。對於流量的進一步分析、控制，也只要更新 service mesh 層，無需業務開發人員過多關注，交由相應的開發人員便可。好比利用 service mesh 層完成流量的灰度、管控特性分支、生成拓撲圖、統計異常訪問等，都可以作到業務進程無關。這樣能夠極大的解放業務開發人員。

2、騰訊服務間通訊發展

1. L5 名字系統

L5 名字系統誕生較早，主要是在分佈式架構下提供統一的服務發現、服務註冊以及負載均衡功能，它誕生時，尚未 kubernetes，微服務尚未現在這樣流行。它主要是在虛擬機時代經過 L5 Agent 進程協助業務進程進行服務註冊與發現，從而讓分佈式系統可以向用戶提供更好的服務端能力。L5 提供的名字系統能力主要流程以下圖所示: 


L5 在流程上, 給業務進程提供的主要是服務發現、服務註冊功能，讓分佈式的業務服務器可以找到指定服務的 IP，並經過 IP 的分發控制提供負載均衡功能。最終服務的調用是經過兩個業務服務的 IP 進行訪問的, 業務服務調用的網絡報文不會通過 L5 Agent 及 L5 Server 。

這樣，流量將直接由分佈式的業務服務 A 與業務服務 B 直接創建鏈接。須要業務進程自行處理通訊過程，涉及認證、請求、響應等。即便交給框架處理，跨語言的微服務間調用也須要跨語言的框架支持，而通用能力的更新，則須要更新業務進程發版處理，維護成本極高。而且，因爲全部的流量是微服務間創建通訊的，它們的調用鏈路也是不易於全局化的。

2. polaris 新一代名字系統

polaris 做爲誕生在 kubernetes 分佈式微服務架構普遍應用以後的雲原生時代，在架構上首先兼容了老的 L5 名字服務，以兼容騰訊內部的老業務服務，同時提供了統一的微服務功能包括限流、熔斷等能力。在將來規劃上，也考慮了 sidecar、mesh 能力。在將公司內的全部老 L5 業務系統的能力兼容遷移到 polaris 上以後，相信後續的 mesh 能力的接入也能夠更加平滑。
當前 polaris 的調用流程仍是與 L5 相似，polaris server 將業務服務的 ip 返回，業務進程間創建鏈接。可是 polaris 提供了跨語言的統一 sdk，接入 polaris 的團隊在後續的更新上，能夠更加統一，若 polaris 支持 mesh 能力，老服務的遷移改造對業務的影響可能會更小。

L5/polaris/k8s service/service mesh 對比

L五、polaris、k8s service、service mesh 都提供了微服務之間的通訊功能。如下是一些對比：

相比較而言，在後續的發展中， service mesh 在通訊治理的功能上更易於擴展，能力將會更增強大，同時因爲其透明代理的特性，與業務的耦合極低。在業務 service mesh 化後，業務進程只需經過傳統的 tcp、http 進行通訊便可，對於進一步的微服務的流量管控，都交給 service mesh 處理，而升級也將隻影響 service mesh 代理層，業務進程能夠無感知。
 

3、新一代微服務通訊實戰

第二代 service mesh 誕生在 kubernetes 以後，它的表明是 istio。下面將在騰訊 tke 平臺上部署 istio 的 demo，讓多個跨語言的服務進行通訊。除了利用 kubernetes service 提供的服務發現、服務註冊、負載均衡以外, istio 進一步經過流量的管控，生成了可視化的訪問拓撲圖，展現訪問路徑、訪問的成功失敗數。同時經過對 http header 中的 cookie 的分析，實現對特性分支的訪問，以完成灰度功能。
目前騰訊內部的服務通訊依然依賴於  L5，istio 目前並無在騰訊大規模實戰。polaris 做爲新一代名字系統，雖然沒有作到 mesh，但兼容了 L5，讓 L5 業務無縫遷移到 polaris，並進一步實現了對微服務進行管控的功能，包括熔斷、限流、訪問統計等。同時，在 polaris 的規劃上，也有 sidecar、mesh 的信息。兼容老的業務系統形式，也是 service mesh 應用上的一大問題。

1. 新一代 service mesh 之 tke istio 體驗

（1）demo 部署

經過商城服務的 demo 演示，能夠體驗 istio 提供的流量管理功能。主要配置能夠參考文檔 Istio 服務 demo 演示【1】。【1】：demo 地址https://zhonghua.io/2019/06/26/tke-mesh-demo/?from=timeline&isappinstalled=0

demo 演示中提供的商城 demo 服務涉及數十個微服務，幷包括 nodejs、go、java、python、ruby 等各類編程語言，以下所示:


這樣的跨語言微服務之間的調用，如果基於框架完成微服務間的調用，則框架必須支持各個語言的版本，在更新框架時也必須更新各個語言版本，這給框架編寫維護帶來了極大的工做量。而框架的發展狀況也將限制業務在功能上的開發。

基於商城微服務的 istio 部署，能夠體驗 istio 的在通用透明性、流量轉發、流量控制、可觀測性方面帶來的優點功能。主要部署步驟以下:

1. 選擇支持 istio 功能的 tke 集羣；

2. 部署各個功能的 workload；

3. 爲每一個 workload 創建 service ；

4. 創建邊緣代理網關做爲流量入口，建立服務網關定義邊緣代理網關的流量行爲；

5. 爲 service 建立 destination rule 用於後續的分支版本控制；

6. 建立 virtual rule 匹配到不一樣版本的後臺服務，實現按條件進行的分支控制，將流量轉到不一樣的微服務分支；

7. 經過 virtual rule 基於流量控制實現權重路由和灰度發佈。

（2）透明代理

istio 基於 k8s service 的透明代理可讓訪問方對 service mesh 層是無感知的，客戶端無需關心 service mesh 層處理的服務發現、服務註冊、負載均衡等功能。只需將迭代工做放在業務上便可。demo 演示中，客戶端直接經過 k8s service 提供的域名進行 基於 http 協議的訪問，無需關係有多少服務方、服務方版本等問題。

（3）可觀測性 - 拓撲圖與訪問統計

在頁面上訪問商城主頁後，istio 經過流量的監控生成了網絡拓撲圖， 以下圖所示:


istio 經過流量的管理，能夠對訪問的時間、成功失敗率進行統計:


同時也能夠精確的看出每一個 pod 的具體訪問數據，能夠方便的看到用戶的全局訪問鏈路:

（4）流量級灰度控制

在開發測試過程當中，不一樣需求開發在測試、發佈階段每每須要將特殊 pod 與基準服務 pod 進行聯合調試，經過 virtual rule 和 destination rule 的配置規則，能夠精確的將特性流量轉到不一樣的微服務的指定特性 pod 上。經過 istio 能夠快速構建下圖所示的基準環境、分支特性環境的通訊過程，適應業務的須要。


istio 支持配置根據流量內容轉發，能夠經過自定義截取 http 協議中如 cookie 內容，對流量進行灰度轉發，控制分支特性。demo 示例部署了根據用戶進行分支轉發，將 user=jason 的用戶的 recommend 轉到 v2 分支上，其它基準環境不變，最終訪問的拓撲圖以下:


在正式環境中，能夠經過不一樣版本的轉發策略，實現流量級別的灰度升級，它的灰度粒度相比 tke 的 pod 級別的灰度，更加細緻，同時灰度策略也能夠更加靈活，能夠定義包括 cookie、header、url 等各類方式的灰度策略。

2. polaris 體驗

L5 做爲騰訊內部的名字系統服務，目前已經被 polaris 兼容替換。sidecar、service mesh 的支持也在 polaris 的架構規劃中。但目前業務仍是以兼容 L5 的訪問形式進行。對比 istio， polaris 誕生於騰訊內部， 內部業務將來經過 polaris 切換到 service mesh 比 istio  會更加容易。

（1）L5 兼容

L5 的服務端已經徹底被無感知的替換到了 polaris，利用 polaris 的別名兼容 L5 的 modid:cmdid 的訪問形式，使得業務側能夠沒有太多的感知。業務團隊也依然能夠按照原來的方式進行後臺的業務迭代。

（2）標準化 SDK

polaris 提供的標準化的 sdk ，支持了 go、cpp、java、python 等絕大多數語言。標準化的 sdk 維護相比各自團隊的獨立的框架、sdk，在微服務調用時，跨語言、跨平臺的維護成本更低。

（3）微服務治理功能

目前的 polaris 雖然在底層通訊方式上雖然依然和 L5 相似，除了支持基本的服務發現、服務註冊與負載均衡， polaris 也提供統一面板管理微服務通訊，支持了熔斷、限流、健康監控等微服務治理的功能。

（4）將來規劃

從 polaris 的規劃看，sidecar、service mesh 都在 polaris 的支持中。相信在 polaris 支持 mesh 的過程當中，對業務的改造工做量應該會更少、改形成本更低。

4、總結

互聯網業務依舊在快速發展，越加融入平常生活，業務也更加複雜，業務量也更多。對於團隊的迭代、架構也形成了影響。目前主流的服務端的微服務架構即是在業務複雜性、團隊複雜性的基礎上的新一代架構，適應團隊隨業務的快速拆分、迭代。微服務化也帶來了新的通訊問題。須要廣泛處理服務註冊、服務發現、負載均衡、熔斷、限流、降級、可觀測、認證受權、流量分析、監控統計等。而以 service mesh 通用化的形式處理微服務通帶來的能力，集合了世界各大企業的智慧理念，已經成爲了趨勢所在。 對於已經微服務化的服務架構團隊，可否向 TCP 同樣支持、處理微服務化帶來的通訊問題以及改造已有業務的成本是當前主要考慮因素。
polaris 目前更適應於騰訊內部業務，可以兼容業務的 L5 通訊方式，也提供了基礎的微服務治理功能,  在將來規劃上支持 sidecar、mesh 能力。對於業務團隊支持 mesh 上，預期遷移重構成本會更低。
istio 則是新一代開源 service mesh 產品的表明，它是目前 service mesh 的標杆產品，在功能支持上能夠快速接入各類社區產品，但適應和改造已有業務的成本會更高，同時 istio 在性能、生產實踐上也是待探索的。