今年逻澳，ServiceMesh(服務網格)概念在社區(qū)里頭非趁允兀火，有人提出2018年是ServiceMesh年檩禾，還有人提出ServiceMesh是下一代的微服務架構基礎挂签。作為架構師，如果你現(xiàn)在還不了解ServiceMesh的話盼产，是否感覺有點落伍了饵婆？那么到底什么是ServiceMesh？它誕生的背景是什么辆飘？它解決什么問題啦辐？企業(yè)是否適合引入ServiceMesh谓传？根據近年在一線互聯(lián)網企業(yè)的實踐和思考，從個人視角出發(fā)芹关，我為大家一一解答這些問題续挟。
微服務架構的核心技術問題
在業(yè)務規(guī)模化和研發(fā)效能提升等因素的驅動下侥衬，從單塊應用向微服務架構的轉型(如下圖所示)诗祸，已經成為很多企業(yè)(尤其是互聯(lián)網企業(yè))數字化轉型的趨勢。
在微服務模式下轴总，企業(yè)內部服務少則幾個到幾十個直颅，多則上百個，每個服務一般都以集群方式部署怀樟，這時自然產生兩個問題(如下圖所示)：
一功偿、服務發(fā)現(xiàn)：服務的消費方(Consumer)如何發(fā)現(xiàn)服務的提供方(Provider)？
二往堡、負載均衡：服務的消費方如何以某種負載均衡策略訪問集群中的服務提供方實例械荷？
作為架構師，如果你理解了這兩個問題虑灰，可以說就理解了微服務架構在技術上的最核心問題吨瞎。
三種服務發(fā)現(xiàn)模式
服務發(fā)現(xiàn)和負載均衡并不是新問題，業(yè)界其實已經探索和總結出一些常用的模式穆咐，這些模式的核心其實是代理(Proxy颤诀，如下圖所以)，以及代理在架構中所處的位置对湃，
在服務消費方和服務提供方之間增加一層代理崖叫，由代理負責服務發(fā)現(xiàn)和負載均衡功能，消費方通過代理間接訪問目標服務熟尉。根據代理在架構上所處的位置不同归露，當前業(yè)界主要有三種不同的服務發(fā)現(xiàn)模式：
模式一：傳統(tǒng)集中式代理
這是最簡單和傳統(tǒng)做法，在服務消費者和生產者之間斤儿，代理作為獨立一層集中部署剧包，由獨立團隊(一般是運維或框架)負責治理和運維。常用的集中式代理有硬件負載均衡器(如F5)往果，或者軟件負載均衡器(如Nginx)疆液，F(xiàn)5(4層負載)+Nginx(7層負載)這種軟硬結合兩層代理也是業(yè)內常見做法，兼顧配置的靈活性(Nginx比F5易于配置)陕贮。
這種方式通常在DNS域名服務器的配合下實現(xiàn)服務發(fā)現(xiàn)堕油，服務注冊(建立服務域名和IP地址之間的映射關系)一般由運維人員在代理上手工配置，服務消費方僅依賴服務域名，這個域名指向代理掉缺，由代理解析目標地址并做負載均衡和調用卜录。
國外知名電商網站eBay，雖然體量巨大眶明，但其內部的服務發(fā)現(xiàn)機制仍然是基于這種傳統(tǒng)的集中代理模式艰毒，國內公司如攜程，也是采用這種模式搜囱。
模式二：客戶端嵌入式代理
這是很多互聯(lián)網公司比較流行的一種做法丑瞧，代理(包括服務發(fā)現(xiàn)和負載均衡邏輯)以客戶庫的形式嵌入在應用程序中。這種模式一般需要獨立的服務注冊中心組件配合蜀肘，服務啟動時自動注冊到注冊中心并定期報心跳绊汹，客戶端代理則發(fā)現(xiàn)服務并做負載均衡。
Netflix開源的Eureka(注冊中心)[附錄1]和Ribbon(客戶端代理)[附錄2]是這種模式的典型案例扮宠，國內阿里開源的Dubbo也是采用這種模式西乖。
模式三：主機獨立進程代理
這種做法是上面兩種模式的一個折中，代理既不是獨立集中部署涵卵，也不嵌入在客戶應用程序中浴栽，而是作為獨立進程部署在每一個主機上煤痕，一個主機上的多個消費者應用可以共用這個代理最冰，實現(xiàn)服務發(fā)現(xiàn)和負載均衡拌屏，如下圖所示。這個模式一般也需要獨立的服務注冊中心組件配合坏晦，作用同模式二。
Airbnb的SmartStack[附錄3]是這種模式早期實踐產品嫁乘，國內公司唯品會對這種模式也有探索和實踐昆婿。
三種服務發(fā)現(xiàn)模式的比較
上面介紹的三種服務發(fā)現(xiàn)模式各有優(yōu)劣，沒有絕對的好壞蜓斧，可以認為是三種不同的架構風格仓蛆，在不同的公司都有成功實踐。下表總結三種服務發(fā)現(xiàn)模式的優(yōu)劣比較挎春，業(yè)界案例和適用場景建議看疙，供架構師選型參考：
服務網格ServiceMesh
所謂的ServiceMesh，其實本質上就是上面提到的模式三~主機獨立進程模式直奋，這個模式其實并不新鮮能庆，業(yè)界(國外的Airbnb和國內的唯品會等)早有實踐，那么為什么現(xiàn)在這個概念又流行起來了呢脚线？我認為主要原因如下：
上述模式一和二有一些固有缺陷搁胆，模式一相對比較重，有單點問題和性能問題；模式二則有客戶端復雜渠旁，支持多語言困難攀例，無法集中治理的問題。模式三是模式一和二的折中顾腊，彌補了兩者的不足肛度，它是純分布式的，沒有單點問題投慈，性能也OK承耿，應用語言棧無關，可以集中治理伪煤。
微服務化加袋、多語言和容器化發(fā)展的趨勢，企業(yè)迫切需要一種輕量級的服務發(fā)現(xiàn)機制抱既，ServiceMesh正是迎合這種趨勢誕生职烧，當然這還和一些大廠(如Google/IBM等)的背后推動有關。
模式三(ServiceMesh)也被形象稱為邊車(Sidecar)模式防泵，如下圖蚀之，早期有一些摩托車，除了主駕駛位捷泞，還帶一個邊車位足删，可以額外坐一個人。在模式三中锁右，業(yè)務代碼進程(相當于主駕駛)共享一個代理(相當于邊車)失受，代理除了負責服務發(fā)現(xiàn)和負載均衡，還負責動態(tài)路由咏瑟、容錯限流拂到、監(jiān)控度量和安全日志等功能，這些功能是具體業(yè)務無關的码泞，屬于跨橫切面關注點(Cross-Cutting Concerns)范疇兄旬。
在新一代的ServiceMesh架構中(下圖上方)，服務的消費方和提供方主機(或者容器)兩邊都會部署代理SideCar余寥。ServiceMesh比較正式的術語也叫數據面板(DataPlane)领铐，與數據面板對應的還有一個獨立部署的控制面板(ControlPlane)，用來集中配置和管理數據面板劈狐，也可以對接各種服務發(fā)現(xiàn)機制(如K8S服務發(fā)現(xiàn))罐孝。術語數據面板和控制面板，估計是偏網絡SDN背景的人提出來的肥缔。
上圖左下角莲兢，每個主機上同時居住了業(yè)務邏輯代碼(綠色表示)和代理(藍色表示)，服務之間通過代理發(fā)現(xiàn)和調用目標服務，形成服務之間的一種網絡狀依賴關系改艇，控制面板則可以配置這種依賴調用關系收班，也可以調撥路由流量。如果我們把主機和業(yè)務邏輯剝離谒兄，就出現(xiàn)一種網格狀架構(上圖右下角)摔桦，服務網格由此得名。
Istio[附錄4]是Google/IBM等大廠支持和推進的一個ServiceMesh標準化工作組承疲，上圖是Istio給出的ServiceMesh參考架構邻耕。Istio專注在控制面板的架構、功能燕鸽、以及控制面板和數據面板之間API的標準化兄世，它的控制面板功能主要包括：
Istio-Manager：負責服務發(fā)現(xiàn)，路由分流啊研，熔斷限流等配置數據的管理和下發(fā)
Mixer：負責收集代理上采集的度量數據御滩，進行集中監(jiān)控
Istio-Auth：負責安全控制數據的管理和下發(fā)
Envoy[附錄5]是目前Istio主力支持的數據面板代理，其它主流代理如nginx/kong等也正在陸續(xù)加入這個陣營党远。kubernetes是目前Isito主力支持的容器云環(huán)境削解。
我的建議
目前我本人并不特別看好ServiceMesh，也不是特別建議企業(yè)在生產上試水ServiceMesh沟娱，主要原因如下：
ServiceMesh其實并不是什么新東西氛驮，本質就是上面提到的服務發(fā)現(xiàn)模式三~主機獨立進程模式，這個模式很早就有公司在探索和實踐花沉，但是一直沒有普遍流行起來柳爽，說明這個模式也是存在落地挑戰(zhàn)的。從表面上看碱屁，模式三是模式一和模式二的折中，同時解決了模式一和模式二存在的問題蛾找，但是在每個主機上獨立部署一個代理進程娩脾，是有很大運維管理開銷的，一方面是規(guī)拇蛎化部署的問題(考慮服務很多柿赊，機器也很多的場景)；另一方面是如何監(jiān)控治理的問題幻枉，代理掛了怎么辦碰声？你的團隊是否具備自動化運維和監(jiān)控的能力？另外開發(fā)人員在服務調試的時候熬甫，會依賴于這個獨立的代理胰挑，調試排錯比較麻煩，這個問題怎么解決？
Istio的確做了一些標準化工作瞻颂，但是沒有什么特別的創(chuàng)新豺谈，可是說換湯不換藥，就是把模式三規(guī)范化和包裝了一下贡这。透過現(xiàn)象看本質茬末，Google/IBM等行業(yè)大廠在背后推Isito/ServiceMesh，背后有一些市場利益訴求考慮盖矫，例如Google要推進它的kubernates和公有云生態(tài)丽惭。
ServiceMesh在年初聲音比較大，最近漸漸安靜下來辈双，我聽到國內只有一些大廠(華為责掏，新浪微博，螞蟻金服等)在試水辐马，實際生產級落地的案例聊聊無幾拷橘。大多數企業(yè)對ServiceMesh只是觀望，很多架構師對ServiceMesh實際落地都存在疑慮喜爷。
所以我的個人建議冗疮，對于大部分企業(yè)(一般運維和研發(fā)能力不是特別強)，采用模式一~集中代理模式就足夠了檩帐。這個模式比較傳統(tǒng)不新鮮术幔，但是在很多一線企業(yè)已經切實落地，我甚至認為湃密，除了一些大廠诅挑，大部分中小企業(yè)的服務發(fā)現(xiàn)架構采用的就是集中代理。我本人經歷過三家互聯(lián)網公司泛源，大的有eBay拔妥，中等有攜程，小的有拍拍貸达箍，都是采用集中式代理模式没龙，而且玩得都很好。我的架構理念很簡單缎玫，對于生產級應用硬纤，不追新，老實采用大部分企業(yè)落地過的方案赃磨。
模式一的最大好處是集中治理筝家，應用不侵入，語言棧無關邻辉，另外因為模式一是集中部署的溪王，不像模式三是分布式部署腮鞍，所以模式一的運維開銷也遠小于模式三。對于模式一在扰，大家最大的顧慮是性能和單點問題缕减，其實性能還是OK的，如果架構和容量規(guī)劃合理的話芒珠，實際生產中經過集中代理的性能開銷一般可以控制在小于10個ms桥狡，eBay和攜程等大流量企業(yè)的成功實踐已經驗證了這點。單點問題一般建議采用兩層負載結構皱卓，例如硬件F5+軟件nginx兩層負載裹芝，F(xiàn)5以主從HA部署，nginx則以集群多實例部署娜汁，這種架構兼顧了高可用和配置的靈活性嫂易。
另外，模式一還可以和服務注冊中心結合掐禁，從而降低手工配置的復雜性怜械，實現(xiàn)DevOps研發(fā)自助部署，一種方案如下圖所示：
服務啟動時自動注冊到服務注冊中心并定期報心跳傅事，Proxy則定期到服務注冊中心同步實例缕允。這種方式下，不需要為每個服務申請一個域名蹭越，只需一個泛域名即可障本，消費者訪問服務時采用服務名+泛域名即可，整個服務上線流程可以做到DevOps研發(fā)自助响鹃。目前社區(qū)流行的一些開源代理如traefik[附錄7]和kong[附錄8]等都支持和多種服務注冊中心(Consul/Eureka/Etcd/Zookeeper等)進行集成驾霜。目前這種方案在拍拍貸有初步成功實踐，采用kong[附錄7]和自研服務注冊中心Radar[附錄8]买置，同時和容器云調度平臺配合粪糙，實現(xiàn)了研發(fā)全自助式發(fā)布上線。
結論
1. 服務注冊發(fā)現(xiàn)和負載均衡是微服務架構在技術上的根本問題忿项，解決的辦法是采用代理Proxy猜旬。根據代理在架構上的位置不同，服務發(fā)現(xiàn)代理一般有三種模式：
模式一：集中式代理
模式二：客戶端嵌入式代理
模式三：主機獨立進程代理 這三種模式沒有絕對的好還之分倦卖，只是三種不同的架構風格，各有優(yōu)劣和適用場景椿争，在不同企業(yè)都有成功落地案例怕膛。
2. ServiceMesh本質上就是模式三~主機獨立進程代理，它結合了模式一和模式二的優(yōu)勢秦踪，但是分布式部署運維管理開銷大褐捻。Istio對ServiceMesh的架構掸茅、功能和API進行了標準化。
3. ServiceMesh還在演進中柠逞，生產落地仍有挑戰(zhàn)昧狮，一般企業(yè)不建議生產級使用。集中式代理最成熟板壮，對于一般中小企業(yè)逗鸣，建議從集中式代理開始，等達到一定規(guī)模和具備一定的研發(fā)運維能力绰精，再根據需要考慮其它服務發(fā)現(xiàn)模式撒璧。
4. 架構師不要盲目追新，在理解微服務架構原理的基礎上笨使，可以學習和試點新技術卿樱，但是對于生產級應用，應該以成熟穩(wěn)定硫椰，有大規(guī)模落地案例作為選型第一準則繁调。
From
https://mp.weixin.qq.com/s/KM6oEGxPLydSHtaidqGS9w
