下一代的微服務架構基礎是ServiceMesh？

今年，ServiceMesh(服務網格) 概念在社區裏頭很是火，有人提出 2018 年是 ServiceMesh 年，還有人提出 ServiceMesh 是下一代的微服務架構基礎。做爲架構師，若是你如今還不瞭解 ServiceMesh 的話，是否感受有點落伍了？

那麼到底什麼是 ServiceMesh？它的誕生是爲了解決什麼問題？企業是否適合引入 ServiceMesh？經過這篇文章，將爲你一一解答這些問題。

微服務架構的核心技術問題

在業務規模化和研發效能提高等因素的驅動下，從單塊應用向微服務架構的轉型 (以下圖所示)，已經成爲不少企業 (尤爲是互聯網企業) 數字化轉型的趨勢。

在微服務模式下，企業內部服務少則幾個到幾十個，多則上百個，每一個服務通常都以集羣方式部署，這時天然產生兩個問題 (以下圖所示)：

1、服務發現： 服務的消費方 (Consumer) 如何發現服務的提供方 (Provider)？

2、負載均衡： 服務的消費方如何以某種負載均衡策略訪問集羣中的服務提供方實例？

做爲架構師，若是你理解了這兩個問題，也就理解了微服務架構在技術上最核心問題。

三種服務發現模式

服務發現和負載均衡並非新問題，業界其實已經探索和總結出一些經常使用的模式，這些模式的核心實際上是代理 (Proxy，以下圖因此)，以及代理在架構中所處的位置。

在服務消費方和服務提供方之間增長一層代理，由代理負責服務發現和負載均衡功能，消費方經過代理間接訪問目標服務。根據代理在架構上所處的位置不一樣，當前業界主要有三種不一樣的服務發現模式：

模式一：傳統集中式代理

這是最簡單和傳統作法，在服務消費者和生產者之間，代理做爲獨立一層集中部署，由獨立團隊 (通常是運維或框架) 負責治理和運維。經常使用的集中式代理有硬件負載均衡器 (如 F5)，或者軟件負載均衡器 (如 Nginx)，F5(4 層負載)+Nginx(7 層負載) 這種軟硬結合兩層代理也是業內常見作法，兼顧配置的靈活性 (Nginx 比 F5 易於配置)。

這種方式一般在 DNS 域名服務器的配合下實現服務發現，服務註冊 (創建服務域名和 IP 地址之間的映射關係) 通常由運維人員在代理上手工配置，服務消費方僅依賴服務域名，這個域名指向代理，由代理解析目標地址並作負載均衡和調用。

國外知名電商網站 eBay，雖然體量巨大，但其內部的服務發現機制仍然是基於這種傳統的集中代理模式，國內公司如攜程，也是採用這種模式。

模式二：客戶端嵌入式代理

這是不少互聯網公司比較流行的一種作法，代理 (包括服務發現和負載均衡邏輯) 以客戶庫的形式嵌入在應用程序中。這種模式通常須要獨立的服務註冊中心組件配合，服務啓動時自動註冊到註冊中心並按期報心跳，客戶端代理則發現服務並作負載均衡。

Netflix 開源的 Eureka(註冊中心)[附錄 1] 和 Ribbon(客戶端代理)[附錄 2] 是這種模式的典型案例，國內阿里開源的 Dubbo 也是採用這種模式。

模式三：主機獨立進程代理

這種作法是上面兩種模式的一個折中，代理既不是獨立集中部署，也不嵌入在客戶應用程序中，而是做爲獨立進程部署在每個主機上，一個主機上的多個消費者應用能夠共用這個代理，實現服務發現和負載均衡，以下圖所示。這個模式通常也須要獨立的服務註冊中心組件配合，做用同模式二。

Airbnb 的 SmartStack[附錄 3] 是這種模式早期實踐產品，國內公司惟品會對這種模式也有探索和實踐。

三種服務發現模式的比較

上面介紹的三種服務發現模式各有優劣，沒有絕對的好壞，能夠認爲是三種不一樣的架構風格，在不一樣的公司都有成功實踐。下表總結三種服務發現模式的優劣比較，業界案例和適用場景建議，供架構師選型參考：

服務網格 ServiceMesh

所謂的 ServiceMesh，其實本質上就是上面提到的模式三：主機獨立進程模式，這個模式其實並不新鮮，業界 (國外的 Airbnb 和國內的惟品會等) 早有實踐，那麼爲何如今這個概念又流行起來了呢？我認爲主要緣由以下：

1. 上述模式一和二有一些固有缺陷，模式一相對比較重，有單點問題和性能問題；模式二則有客戶端複雜，支持多語言困難，沒法集中治理的問題。模式三是模式一和二的折中，彌補了二者的不足，它是純分佈式的，沒有單點問題，性能也不錯，應用語言棧無關，能夠集中治理。

2. 微服務化、多語言和容器化發展的趨勢，企業迫切須要一種輕量級的服務發現機制，ServiceMesh 正是迎合這種趨勢誕生，固然這還和一些大廠 (如 Google/IBM 等) 的背後推進有關。

模式三 (ServiceMesh) 也被形象稱爲邊車 (Sidecar) 模式，以下圖，早期有一些摩托車，除了主駕駛位，還帶一個邊車位，能夠額外坐一我的。在模式三中，業務代碼進程 (至關於主駕駛) 共享一個代理 (至關於邊車)，代理除了負責服務發現和負載均衡，還負責動態路由、容錯限流、監控度量和安全日誌等功能，這些功能是具體業務無關的，屬於跨橫切面關注點 (Cross-Cutting Concerns) 範疇。

在新一代的 ServiceMesh 架構中 (下圖上方)，服務的消費方和提供方主機 (或者容器) 兩邊都會部署代理 SideCar。ServiceMesh 比較正式的術語也叫數據平面 (DataPlane)，與數據平面對應的還有一個獨立部署的控制平面 (ControlPlane)，用來集中配置和管理數據平面，也能夠對接各類服務發現機制 (如 K8S 服務發現)。術語數據平面和控制平面，估計是偏網絡 SDN 背景的人提出來的。

上圖左下角，每一個主機上同時居住了業務邏輯代碼 (綠色表示) 和代理 (藍色表示)，服務之間經過代理髮現和調用目標服務，造成服務之間的一種網絡狀依賴關係，控制平面則能夠配置這種依賴調用關係，也能夠調撥路由流量。若是咱們把主機和業務邏輯剝離，就出現一種網格狀架構 (上圖右下角)，服務網格由此得名。

Istio[附錄 4] 是 Google/IBM 等大廠支持和推動的一個 ServiceMesh 標準化工做組，上圖是 Istio 給出的 ServiceMesh 參考架構 (注意這個是老版架構，新版有一些調整，可是大框架沒變)。Istio 專一在控制平面的架構、功能、以及控制平面和數據平面之間 API 的標準化，它的控制平面功能主要包括：

• Istio-Manager：負責服務發現，路由分流，熔斷限流等配置數據的管理和下發

• Mixer：負責收集代理上採集的度量數據，進行集中監控

• Istio-Auth：負責安全控制數據的管理和下發

Envoy[附錄 5] 是目前 Istio 主力支持的數據平面代理，其它主流代理如 nginx/kong 等也正在陸續加入這個陣營。kubernetes 是目前 Isito 主力支持的容器雲環境。

個人建議

目前我本人並不特別看好 ServiceMesh，也不是特別建議企業在生產上試水 ServiceMesh，主要緣由以下：

1. 本質上，ServiceMesh 其實並非新東西，它只是模式三主機獨立進程模式，這個模式早就有公司在探索和實踐了，可是並未流行起來，可見這個模式也是存在落地挑戰的。

   表面上看，模式三既是模式一和模式二的折中，也解決了模式一和模式二存在的問題。

   可是在每一個主機上獨立部署一個代理進程，是有很大運維管理開銷的，一方面是規模化部署的問題 (考慮服務不少，機器也不少的場景)；另外一方面是如何監控治理的問題，代理掛了怎麼辦？你的團隊是否具有自動化運維和監控的能力？另外開發人員在服務調試的時候，會依賴於這個獨立的代理，調試排錯比較麻煩，這個問題怎麼解決？

2. Istio 的確作了一些標準化工做，可是沒有什麼特別的創新，但是說換湯不換藥，就是把模式三規範化和包裝了一下。透過現象看本質，Google/IBM 等行業大廠在背後推 Isito/ServiceMesh，背後有一些市場利益訴求考慮，例如 Google 要推動它的 kubernates 和公有云生態。

3. ServiceMesh 在年初聲音比較大，最近漸漸安靜下來，我聽到國內只有一些大廠 (華爲，新浪微博，螞蟻金服等) 在試水，實際生產級落地的案例聊聊無幾。大多數企業對 ServiceMesh 只是觀望，不少架構師對 ServiceMesh 實際落地都存在疑慮。

因此個人我的建議，對於大部分企業 (通常運維和研發能力不是特別強)，採用模式一集中代理模式就足夠了。這個模式比較傳統不新鮮，可是在不少一線企業已經切實落地，我甚至認爲，除了一些大廠，大部分中小企業的服務發現架構採用的就是集中代理。我本人經歷過三家互聯網公司，大的有 eBay，中等有攜程，小的有拍拍貸，都是採用集中式代理模式，並且玩得都很好。個人架構理念很簡單，對於生產級應用，不追新，老實採用大部分企業落地過的方案。

模式一的最大好處是集中治理，應用不侵入，語言棧無關，另外由於模式一是集中部署的，不像模式三是分佈式部署，因此模式一的運維開銷也遠小於模式三。對於模式一，你們最大的顧慮是性能和單點問題，其實性能仍是 OK 的，若是架構和容量規劃合理的話，實際生產中通過集中代理的性能開銷通常能夠控制在小於 10 個 ms，eBay 和攜程等大流量企業的成功實踐已經驗證了這點。單點問題通常建議採用兩層負載結構，例如硬件 F5+ 軟件 nginx 兩層負載，F5 以主從 HA 部署，nginx 則以集羣多實例部署，這種架構兼顧了高可用和配置的靈活性。

另外，模式一還能夠和服務註冊中心結合，從而下降手工配置的複雜性，實現 DevOps 研發自助部署，一種方案以下圖所示：

服務啓動時自動註冊到服務註冊中心並按期報心跳，Proxy 則按期到服務註冊中心同步實例。這種方式下，不須要爲每一個服務申請一個域名，只需一個泛域名便可，消費者訪問服務時採用服務名 + 泛域名便可，整個服務上線流程能夠作到 DevOps 研發自助。目前社區流行的一些開源代理如 traefik[附錄 7] 和 kong[附錄 8] 等都支持和多種服務註冊中心 (Consul/Eureka/Etcd/Zookeeper 等) 進行集成。目前這種方案在拍拍貸有初步成功實踐，採用 kong[附錄 7] 和自研服務註冊中心 Radar[附錄 8]，同時和容器雲調度平臺配合，實現了研發全自助式發佈上線。

結 論

一、服務註冊發現和負載均衡是微服務架構在技術上的根本問題，解決的辦法是採用代理 Proxy。根據代理在架構上的位置不一樣，服務發現代理通常有三種模式：

• 模式一：集中式代理

• 模式二：客戶端嵌入式代理

• 模式三：主機獨立進程代理

這三種模式沒有絕對的好壞之分，只是三種不一樣的架構風格，各有優劣和適用場景，在不一樣企業都有成功落地案例。

二、ServiceMesh 本質上就是模式三中主機獨立進程代理，它結合了模式一和模式二的優點，可是分佈式部署運維管理開銷大。Istio 對 ServiceMesh 的架構、功能和 API 進行了標準化。

三、ServiceMesh 還在演進中，生產落地仍有挑戰，通常企業不建議生產級使用。集中式代理最成熟，對於通常中小企業，建議從集中式代理開始，等達到必定規模和具有必定的研發運維能力，再根據須要考慮其它服務發現模式。

四、架構師不要盲目追新，在理解微服務架構原理的基礎上，能夠學習和試點新技術，可是對於生產級應用，應該以成熟穩定，有大規模落地案例做爲選型第一準則。

歡迎工做一到五年的Java工程師朋友們加入Java程序員開發： 854393687 羣內提供免費的Java架構學習資料（裏面有高可用、高併發、高性能及分佈式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用本身每一分每一秒的時間來學習提高本身，不要再用"沒有時間「來掩飾本身思想上的懶惰！趁年輕，使勁拼，給將來的本身一個交代！