微服务 | 我为啥不看好 ServiceMesh
1. 前言
今年，ServiceMesh(服務網(wǎng)格)概念在社區(qū)里頭非?；?#xff0c;有人提出2018年是ServiceMesh年，還有人提出ServiceMesh是下一代的微服務架構(gòu)基礎(chǔ)。作為架構(gòu)師，如果你現(xiàn)在還不了解ServiceMesh的話，是否感覺有點落伍了？
那么到底什么是ServiceMesh？它誕生的背景是什么？它解決什么問題？企業(yè)是否適合引入ServiceMesh？根據(jù)近年在一線互聯(lián)網(wǎng)企業(yè)的實踐和思考，從個人視角出發(fā)，我為大家一一解答這些問題。
?
2. 微服務架構(gòu)的核心技術(shù)問題
在業(yè)務規(guī)?；脱邪l(fā)效能提升等因素的驅(qū)動下，從單塊應用向微服務架構(gòu)的轉(zhuǎn)型(如下圖所示)，已經(jīng)成為很多企業(yè)(尤其是互聯(lián)網(wǎng)企業(yè))數(shù)字化轉(zhuǎn)型的趨勢。
在微服務模式下，企業(yè)內(nèi)部服務少則幾個到幾十個，多則上百個，每個服務一般都以集群方式部署，這時自然產(chǎn)生兩個問題(如下圖所示)：
一、服務發(fā)現(xiàn)：服務的消費方(Consumer)如何發(fā)現(xiàn)服務的提供方(Provider)？
二、負載均衡：服務的消費方如何以某種負載均衡策略訪問集群中的服務提供方實例？
作為架構(gòu)師，如果你理解了這兩個問題，可以說就理解了微服務架構(gòu)在技術(shù)上的最核心問題。
?
3. 三種服務發(fā)現(xiàn)模式
服務發(fā)現(xiàn)和負載均衡并不是新問題，業(yè)界其實已經(jīng)探索和總結(jié)出一些常用的模式，這些模式的核心其實是代理(Proxy，如下圖所以)，以及代理在架構(gòu)中所處的位置，
在服務消費方和服務提供方之間增加一層代理，由代理負責服務發(fā)現(xiàn)和負載均衡功能，消費方通過代理間接訪問目標服務。根據(jù)代理在架構(gòu)上所處的位置不同，當前業(yè)界主要有三種不同的服務發(fā)現(xiàn)模式：
3.1 模式一：傳統(tǒng)集中式代理
?
這是最簡單和傳統(tǒng)做法，在服務消費者和生產(chǎn)者之間，代理作為獨立一層集中部署，由獨立團隊(一般是運維或框架)負責治理和運維。常用的集中式代理有硬件負載均衡器(如F5)，或者軟件負載均衡器(如Nginx)，F5(4層負載)+Nginx(7層負載)這種軟硬結(jié)合兩層代理也是業(yè)內(nèi)常見做法，兼顧配置的靈活性(Nginx比F5易于配置)。
這種方式通常在DNS域名服務器的配合下實現(xiàn)服務發(fā)現(xiàn)，服務注冊(建立服務域名和IP地址之間的映射關(guān)系)一般由運維人員在代理上手工配置，服務消費方僅依賴服務域名，這個域名指向代理，由代理解析目標地址并做負載均衡和調(diào)用。
國外知名電商網(wǎng)站eBay，雖然體量巨大，但其內(nèi)部的服務發(fā)現(xiàn)機制仍然是基于這種傳統(tǒng)的集中代理模式，國內(nèi)公司如攜程，也是采用這種模式。
3.2 模式二：客戶端嵌入式代理
這是很多互聯(lián)網(wǎng)公司比較流行的一種做法，代理(包括服務發(fā)現(xiàn)和負載均衡邏輯)以客戶庫的形式嵌入在應用程序中。這種模式一般需要獨立的服務注冊中心組件配合，服務啟動時自動注冊到注冊中心并定期報心跳，客戶端代理則發(fā)現(xiàn)服務并做負載均衡。
Netflix開源的Eureka(注冊中心)[附錄1]和Ribbon(客戶端代理)[附錄2]是這種模式的典型案例，國內(nèi)阿里開源的Dubbo也是采用這種模式。
3.3 模式三：主機獨立進程代理
這種做法是上面兩種模式的一個折中，代理既不是獨立集中部署，也不嵌入在客戶應用程序中，而是作為獨立進程部署在每一個主機上，一個主機上的多個消費者應用可以共用這個代理，實現(xiàn)服務發(fā)現(xiàn)和負載均衡，如下圖所示。這個模式一般也需要獨立的服務注冊中心組件配合，作用同模式二。
Airbnb的SmartStack[附錄3]是這種模式早期實踐產(chǎn)品，國內(nèi)公司唯品會對這種模式也有探索和實踐。
?
4. 三種服務發(fā)現(xiàn)模式的比較
上面介紹的三種服務發(fā)現(xiàn)模式各有優(yōu)劣，沒有絕對的好壞，可以認為是三種不同的架構(gòu)風格，在不同的公司都有成功實踐。下表總結(jié)三種服務發(fā)現(xiàn)模式的優(yōu)劣比較，業(yè)界案例和適用場景建議，供架構(gòu)師選型參考：
?
5. 服務網(wǎng)格ServiceMesh
所謂的ServiceMesh，其實本質(zhì)上就是上面提到的模式三~主機獨立進程模式，這個模式其實并不新鮮，業(yè)界(國外的Airbnb和國內(nèi)的唯品會等)早有實踐，那么為什么現(xiàn)在這個概念又流行起來了呢？我認為主要原因如下：
模式三(ServiceMesh)也被形象稱為邊車(Sidecar)模式，如下圖，早期有一些摩托車，除了主駕駛位，還帶一個邊車位，可以額外坐一個人。在模式三中，業(yè)務代碼進程(相當于主駕駛)共享一個代理(相當于邊車)，代理除了負責服務發(fā)現(xiàn)和負載均衡，還負責動態(tài)路由、容錯限流、監(jiān)控度量和安全日志等功能，這些功能是具體業(yè)務無關(guān)的，屬于跨橫切面關(guān)注點(Cross-Cutting Concerns)范疇。
在新一代的ServiceMesh架構(gòu)中(下圖上方)，服務的消費方和提供方主機(或者容器)兩邊都會部署代理SideCar。ServiceMesh比較正式的術(shù)語也叫數(shù)據(jù)面板(DataPlane)，與數(shù)據(jù)面板對應的還有一個獨立部署的控制面板(ControlPlane)，用來集中配置和管理數(shù)據(jù)面板，也可以對接各種服務發(fā)現(xiàn)機制(如K8S服務發(fā)現(xiàn))。術(shù)語數(shù)據(jù)面板和控制面板，估計是偏網(wǎng)絡(luò)SDN背景的人提出來的。
上圖左下角，每個主機上同時居住了業(yè)務邏輯代碼(綠色表示)和代理(藍色表示)，服務之間通過代理發(fā)現(xiàn)和調(diào)用目標服務，形成服務之間的一種網(wǎng)絡(luò)狀依賴關(guān)系，控制面板則可以配置這種依賴調(diào)用關(guān)系，也可以調(diào)撥路由流量。如果我們把主機和業(yè)務邏輯剝離，就出現(xiàn)一種網(wǎng)格狀架構(gòu)(上圖右下角)，服務網(wǎng)格由此得名。
Istio[附錄4]是Google/IBM等大廠支持和推進的一個ServiceMesh標準化工作組，上圖是Istio給出的ServiceMesh參考架構(gòu)。Istio專注在控制面板的架構(gòu)、功能、以及控制面板和數(shù)據(jù)面板之間API的標準化，它的控制面板功能主要包括：
- Istio-Manager：負責服務發(fā)現(xiàn)，路由分流，熔斷限流等配置數(shù)據(jù)的管理和下發(fā)
- Mixer：負責收集代理上采集的度量數(shù)據(jù)，進行集中監(jiān)控
- Istio-Auth：負責安全控制數(shù)據(jù)的管理和下發(fā)
Envoy[附錄5]是目前Istio主力支持的數(shù)據(jù)面板代理，其它主流代理如nginx/kong等也正在陸續(xù)加入這個陣營。kubernetes是目前Isito主力支持的容器云環(huán)境。
?
6. 我的建議
目前我本人并不特別看好ServiceMesh，也不是特別建議企業(yè)在生產(chǎn)上試水ServiceMesh，主要原因如下：
所以我的個人建議，對于大部分企業(yè)(一般運維和研發(fā)能力不是特別強)，采用模式一~集中代理模式就足夠了。這個模式比較傳統(tǒng)不新鮮，但是在很多一線企業(yè)已經(jīng)切實落地，我甚至認為，除了一些大廠，大部分中小企業(yè)的服務發(fā)現(xiàn)架構(gòu)采用的就是集中代理。我本人經(jīng)歷過三家互聯(lián)網(wǎng)公司，大的有eBay，中等有攜程，小的有拍拍貸，都是采用集中式代理模式，而且玩得都很好。我的架構(gòu)理念很簡單，對于生產(chǎn)級應用，不追新，老實采用大部分企業(yè)落地過的方案。
模式一的最大好處是集中治理，應用不侵入，語言棧無關(guān)，另外因為模式一是集中部署的，不像模式三是分布式部署，所以模式一的運維開銷也遠小于模式三。對于模式一，大家最大的顧慮是性能和單點問題，其實性能還是OK的，如果架構(gòu)和容量規(guī)劃合理的話，實際生產(chǎn)中經(jīng)過集中代理的性能開銷一般可以控制在小于10個ms，eBay和攜程等大流量企業(yè)的成功實踐已經(jīng)驗證了這點。單點問題一般建議采用兩層負載結(jié)構(gòu)，例如硬件F5+軟件nginx兩層負載，F5以主從HA部署，nginx則以集群多實例部署，這種架構(gòu)兼顧了高可用和配置的靈活性。
另外，模式一還可以和服務注冊中心結(jié)合，從而降低手工配置的復雜性，實現(xiàn)DevOps研發(fā)自助部署，一種方案如下圖所示：
服務啟動時自動注冊到服務注冊中心并定期報心跳，Proxy則定期到服務注冊中心同步實例。這種方式下，不需要為每個服務申請一個域名，只需一個泛域名即可，消費者訪問服務時采用服務名+泛域名即可，整個服務上線流程可以做到DevOps研發(fā)自助。目前社區(qū)流行的一些開源代理如traefik[附錄7]和kong[附錄8]等都支持和多種服務注冊中心(Consul/Eureka/Etcd/Zookeeper等)進行集成。目前這種方案在拍拍貸有初步成功實踐，采用kong[附錄7]和自研服務注冊中心Radar[附錄8]，同時和容器云調(diào)度平臺配合，實現(xiàn)了研發(fā)全自助式發(fā)布上線。
?
7. 結(jié)論
1.?服務注冊發(fā)現(xiàn)和負載均衡是微服務架構(gòu)在技術(shù)上的根本問題，解決的辦法是采用代理Proxy。根據(jù)代理在架構(gòu)上的位置不同，服務發(fā)現(xiàn)代理一般有三種模式：
- 模式一：集中式代理
- 模式二：客戶端嵌入式代理
- 模式三：主機獨立進程代理
這三種模式?jīng)]有絕對的好還之分，只是三種不同的架構(gòu)風格，各有優(yōu)劣和適用場景，在不同企業(yè)都有成功落地案例。
2.?ServiceMesh本質(zhì)上就是模式三~主機獨立進程代理，它結(jié)合了模式一和模式二的優(yōu)勢，但是分布式部署運維管理開銷大。Istio對ServiceMesh的架構(gòu)、功能和API進行了標準化。
3.?ServiceMesh還在演進中，生產(chǎn)落地仍有挑戰(zhàn)，一般企業(yè)不建議生產(chǎn)級使用。集中式代理最成熟，對于一般中小企業(yè)，建議從集中式代理開始，等達到一定規(guī)模和具備一定的研發(fā)運維能力，再根據(jù)需要考慮其它服務發(fā)現(xiàn)模式。
4.?架構(gòu)師不要盲目追新，在理解微服務架構(gòu)原理的基礎(chǔ)上，可以學習和試點新技術(shù)，但是對于生產(chǎn)級應用，應該以成熟穩(wěn)定，有大規(guī)模落地案例作為選型第一準則。
5.?波波和極客時間合作，2018年推出了視頻課程《微服務架構(gòu)和實踐160講》，目前已經(jīng)更新到第六期，馬上上線第七期《微服務監(jiān)控告警Prometheus架構(gòu)和實踐》，對度量驅(qū)動開發(fā)(MDD)理念和Prometheus監(jiān)控工具進行深度剖析，歡迎大家關(guān)注。
?
8. 附錄
總結(jié)
以上是生活随笔為你收集整理的微服务 | 我为啥不看好 ServiceMesh的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 自己动手写一个服务网关
- 下一篇： 买什么数据结构与算法，这里有：动态图解十