1. 前言
今年，ServiceMesh(服務網格)概念在社群裡頭非常火，有人提出2018年是ServiceMesh年，還有人提出ServiceMesh是下一代的微服務架構基礎。作為架構師，如果你現在還不了解ServiceMesh的話，是否感覺有點落伍了？
那麼到底什麼是ServiceMesh？它誕生的背景是什麼？它解決什麼問題？企業是否适合引入ServiceMesh？根據近年在一線網際網路企業的實踐和思考，從個人視角出發，我為大家一一解答這些問題。
2. 微服務架構的核心技術問題
在業務規模化和研發效能提升等因素的驅動下，從單塊應用向微服務架構的轉型(如下圖所示)，已經成為很多企業(尤其是網際網路企業)數字化轉型的趨勢。
在微服務模式下，企業内部服務少則幾個到幾十個，多則上百個，每個服務一般都以叢集方式部署，這時自然産生兩個問題(如下圖所示)：
一、服務發現：服務的消費方(Consumer)如何發現服務的提供方(Provider)？
二、負載均衡：服務的消費方如何以某種負載均衡政策通路叢集中的服務提供方執行個體？
作為架構師，如果你了解了這兩個問題，可以說就了解了微服務架構在技術上的最核心問題。
3. 三種服務發現模式
服務發現和負載均衡并不是新問題，業界其實已經探索和總結出一些常用的模式，這些模式的核心其實是代理(Proxy，如下圖是以)，以及代理在架構中所處的位置，
在服務消費方和服務提供方之間增加一層代理，由代理負責服務發現和負載均衡功能，消費方通過代理間接通路目标服務。根據代理在架構上所處的位置不同，目前業界主要有三種不同的服務發現模式：
3.1 模式一：傳統集中式代理
這是最簡單和傳統做法，在服務消費者和生産者之間，代理作為獨立一層集中部署，由獨立團隊(一般是運維或架構)負責治理和運維。常用的集中式代理有硬體負載均衡器(如F5)，或者軟體負載均衡器(如Nginx)，F5(4層負載)+Nginx(7層負載)這種軟硬結合兩層代理也是業内常見做法，兼顧配置的靈活性(Nginx比F5易于配置)。
這種方式通常在DNS域名伺服器的配合下實作服務發現，服務注冊(建立服務域名和IP位址之間的映射關系)一般由運維人員在代理上手工配置，服務消費方僅依賴服務域名，這個域名指向代理，由代了解析目标位址并做負載均衡和調用。
國外知名電商網站eBay，雖然體量巨大，但其内部的服務發現機制仍然是基于這種傳統的集中代理模式，國内公司如攜程，也是采用這種模式。
3.2 模式二：用戶端嵌入式代理
這是很多網際網路公司比較流行的一種做法，代理(包括服務發現和負載均衡邏輯)以客戶庫的形式嵌入在應用程式中。這種模式一般需要獨立的服務注冊中心元件配合，服務啟動時自動注冊到注冊中心并定期報心跳，用戶端代理則發現服務并做負載均衡。
Netflix開源的Eureka(注冊中心)[附錄1]和Ribbon(用戶端代理)[附錄2]是這種模式的典型案例，國内阿裡開源的Dubbo也是采用這種模式。
3.3 模式三：主機獨立程序代理
這種做法是上面兩種模式的一個折中，代理既不是獨立集中部署，也不嵌入在客戶應用程式中，而是作為獨立程序部署在每一個主機上，一個主機上的多個消費者應用可以共用這個代理，實作服務發現和負載均衡，如下圖所示。這個模式一般也需要獨立的服務注冊中心元件配合，作用同模式二。
Airbnb的SmartStack[附錄3]是這種模式早期實踐産品，國内公司唯品會對這種模式也有探索和實踐。
4. 三種服務發現模式的比較
上面介紹的三種服務發現模式各有優劣，沒有絕對的好壞，可以認為是三種不同的架構風格，在不同的公司都有成功實踐。下表總結三種服務發現模式的優劣比較，業界案例和适用場景建議，供架構師選型參考：
5. 服務網格ServiceMesh
所謂的ServiceMesh，其實本質上就是上面提到的模式三~主機獨立程序模式，這個模式其實并不新鮮，業界(國外的Airbnb和國内的唯品會等)早有實踐，那麼為什麼現在這個概念又流行起來了呢？我認為主要原因如下：
- 上述模式一和二有一些固有缺陷，模式一相對比較重，有單點問題和性能問題；模式二則有用戶端複雜，支援多語言困難，無法集中治理的問題。模式三是模式一和二的折中，彌補了兩者的不足，它是純分布式的，沒有單點問題，性能也OK，應用語言棧無關，可以集中治理。
- 微服務化、多語言和容器化發展的趨勢，企業迫切需要一種輕量級的服務發現機制，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主力支援的容器雲環境。
6. 我的建議
目前我本人并不特别看好ServiceMesh，也不是特别建議企業在生産上試水ServiceMesh，主要原因如下：
- ServiceMesh其實并不是什麼新東西，本質就是上面提到的服務發現模式三~主機獨立程序模式，這個模式很早就有公司在探索和實踐，但是一直沒有普遍流行起來，說明這個模式也是存在落地挑戰的。從表面上看，模式三是模式一和模式二的折中，同時解決了模式一和模式二存在的問題，但是在每個主機上獨立部署一個代理程序，是有很大運維管理開銷的，一方面是規模化部署的問題(考慮服務很多，機器也很多的場景)；另一方面是如何監控治理的問題，代理挂了怎麼辦？你的團隊是否具備自動化運維和監控的能力？另外開發人員在服務調試的時候，會依賴于這個獨立的代理，調試排錯比較麻煩，這個問題怎麼解決？
- Istio的确做了一些标準化工作，但是沒有什麼特别的創新，可是說換湯不換藥，就是把模式三規範化和包裝了一下。透過現象看本質，Google/IBM等行業大廠在背後推Isito/ServiceMesh，背後有一些市場利益訴求考慮，例如Google要推進它的kubernates和公有雲生态。
- 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]，同時和容器雲排程平台配合，實作了研發全自助式釋出上線。
7. 結論
1. 服務注冊發現和負載均衡是微服務架構在技術上的根本問題，解決的辦法是采用代理Proxy。根據代理在架構上的位置不同，服務發現代理一般有三種模式：
- 模式一：集中式代理
- 模式二：用戶端嵌入式代理
- 模式三：主機獨立程序代理
這三種模式沒有絕對的好還之分，隻是三種不同的架構風格，各有優劣和适用場景，在不同企業都有成功落地案例。
2. ServiceMesh本質上就是模式三~主機獨立程序代理，它結合了模式一和模式二的優勢，但是分布式部署運維管理開銷大。Istio對ServiceMesh的架構、功能和API進行了标準化。
3. ServiceMesh還在演進中，生産落地仍有挑戰，一般企業不建議生産級使用。集中式代理最成熟，對于一般中小企業，建議從集中式代理開始，等達到一定規模和具備一定的研發運維能力，再根據需要考慮其它服務發現模式。
4. 架構師不要盲目追新，在了解微服務架構原理的基礎上，可以學習和試點新技術，但是對于生産級應用，應該以成熟穩定，有大規模落地案例作為選型第一準則。
5. 波波和極客時間合作，2018年推出了視訊課程《微服務架構和實踐160講》，目前已經更新到第六期，馬上上線第七期《微服務監控告警Prometheus架構和實踐》，對度量驅動開發(MDD)理念和Prometheus監控工具進行深度剖析，歡迎大家關注。
8. 附錄
- Netflix Eureka https://github.com/netflix/eureka
- Netflix Ribbon https://github.com/netflix/ribbon
- Airbnb SmartStack https://medium.com/airbnb-engineering/smartstack-service-discovery-in-the-cloud-4b8a080de619
- Istio https://istio.io/
- Envoy https://www.envoyproxy.io/
- Traefik https://github.com/containous/traefik
- Kong https://github.com/kong/kong
- Radar https://github.com/ppdai-incubator/radar