微服务架构基础之Service Mesh
ServiceMesh(服務(wù)網(wǎng)格) 概念在社區(qū)里頭非常火，有人提出 2018 年是 ServiceMesh 年，還有人提出 ServiceMesh 是下一代的微服務(wù)架構(gòu)基礎(chǔ)。
那么到底什么是 ServiceMesh？它的誕生是為了解決什么問題？企業(yè)是否適合引入 ServiceMesh？
?
微服務(wù)架構(gòu)的核心技術(shù)問題
?
在業(yè)務(wù)規(guī)模化和研發(fā)效能提升等因素的驅(qū)動(dòng)下，從單塊應(yīng)用向微服務(wù)架構(gòu)的轉(zhuǎn)型 (如下圖所示)，已經(jīng)成為很多企業(yè) (尤其是互聯(lián)網(wǎng)企業(yè)) 數(shù)字化轉(zhuǎn)型的趨勢。
在微服務(wù)模式下，企業(yè)內(nèi)部服務(wù)少則幾個(gè)到幾十個(gè)，多則上百個(gè)，每個(gè)服務(wù)一般都以集群方式部署，這時(shí)自然產(chǎn)生兩個(gè)問題 (如下圖所示)：
?
一、服務(wù)發(fā)現(xiàn)：?服務(wù)的消費(fèi)方 (Consumer) 如何發(fā)現(xiàn)服務(wù)的提供方 (Provider)？
二、負(fù)載均衡：?服務(wù)的消費(fèi)方如何以某種負(fù)載均衡策略訪問集群中的服務(wù)提供方實(shí)例？
作為架構(gòu)師，如果你理解了這兩個(gè)問題，也就理解了微服務(wù)架構(gòu)在技術(shù)上最核心問題。
?
三種服務(wù)發(fā)現(xiàn)模式
?
服務(wù)發(fā)現(xiàn)和負(fù)載均衡并不是新問題，業(yè)界其實(shí)已經(jīng)探索和總結(jié)出一些常用的模式，這些模式的核心其實(shí)是代理 (Proxy，如下圖所以)，以及代理在架構(gòu)中所處的位置。
?
在服務(wù)消費(fèi)方和服務(wù)提供方之間增加一層代理，由代理負(fù)責(zé)服務(wù)發(fā)現(xiàn)和負(fù)載均衡功能，消費(fèi)方通過代理間接訪問目標(biāo)服務(wù)。根據(jù)代理在架構(gòu)上所處的位置不同，當(dāng)前業(yè)界主要有三種不同的服務(wù)發(fā)現(xiàn)模式：
模式一：傳統(tǒng)集中式代理
?
?
這是最簡單和傳統(tǒng)做法，在服務(wù)消費(fèi)者和生產(chǎn)者之間，代理作為獨(dú)立一層集中部署，由獨(dú)立團(tuán)隊(duì) (一般是運(yùn)維或框架) 負(fù)責(zé)治理和運(yùn)維。常用的集中式代理有硬件負(fù)載均衡器 (如 F5)，或者軟件負(fù)載均衡器 (如 Nginx)，F5(4 層負(fù)載)+Nginx(7 層負(fù)載) 這種軟硬結(jié)合兩層代理也是業(yè)內(nèi)常見做法，兼顧配置的靈活性 (Nginx 比 F5 易于配置)。
這種方式通常在 DNS 域名服務(wù)器的配合下實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)，服務(wù)注冊(cè) (建立服務(wù)域名和 IP 地址之間的映射關(guān)系) 一般由運(yùn)維人員在代理上手工配置，服務(wù)消費(fèi)方僅依賴服務(wù)域名，這個(gè)域名指向代理，由代理解析目標(biāo)地址并做負(fù)載均衡和調(diào)用。
國外知名電商網(wǎng)站 eBay，雖然體量巨大，但其內(nèi)部的服務(wù)發(fā)現(xiàn)機(jī)制仍然是基于這種傳統(tǒng)的集中代理模式，國內(nèi)公司如攜程，也是采用這種模式。
模式二：客戶端嵌入式代理
?
這是很多互聯(lián)網(wǎng)公司比較流行的一種做法，代理 (包括服務(wù)發(fā)現(xiàn)和負(fù)載均衡邏輯) 以客戶庫的形式嵌入在應(yīng)用程序中。這種模式一般需要獨(dú)立的服務(wù)注冊(cè)中心組件配合，服務(wù)啟動(dòng)時(shí)自動(dòng)注冊(cè)到注冊(cè)中心并定期報(bào)心跳，客戶端代理則發(fā)現(xiàn)服務(wù)并做負(fù)載均衡。
Netflix 開源的 Eureka(注冊(cè)中心)[附錄 1] 和 Ribbon(客戶端代理)[附錄 2] 是這種模式的典型案例，國內(nèi)阿里開源的 Dubbo 也是采用這種模式。
模式三：主機(jī)獨(dú)立進(jìn)程代理
這種做法是上面兩種模式的一個(gè)折中，代理既不是獨(dú)立集中部署，也不嵌入在客戶應(yīng)用程序中，而是作為獨(dú)立進(jìn)程部署在每一個(gè)主機(jī)上，一個(gè)主機(jī)上的多個(gè)消費(fèi)者應(yīng)用可以共用這個(gè)代理，實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)和負(fù)載均衡，如下圖所示。這個(gè)模式一般也需要獨(dú)立的服務(wù)注冊(cè)中心組件配合，作用同模式二。
阿里、微博、摩拜、唯品會(huì)等公司都在積極探索Service Mesh的架構(gòu)模式，只是在實(shí)踐中一般具備一定開發(fā)能力的公司都會(huì)選擇基于Istio進(jìn)行二次開發(fā)，如目前阿里開源的SOFAMesh/SOFAMosn兩個(gè)項(xiàng)目。
?
?Service Mesh（服務(wù)網(wǎng)格）
?
?Service Mesh又稱為服務(wù)網(wǎng)格，本質(zhì)上就是我們前面介紹過的模式三。之所為稱之為服務(wù)網(wǎng)格是因?yàn)榘凑漳Ｊ饺慕Y(jié)構(gòu)，每個(gè)主機(jī)上同時(shí)運(yùn)行了業(yè)務(wù)邏輯代碼和代理，此時(shí)這個(gè)代理被形象地稱之為SideCar（業(yè)務(wù)代碼進(jìn)程相當(dāng)于主駕駛，共享一個(gè)代理相當(dāng)于邊車），服務(wù)之間通過SideCar發(fā)現(xiàn)和調(diào)用目標(biāo)服務(wù)，從而形成服務(wù)之間的一種網(wǎng)絡(luò)狀依賴關(guān)系，然后通過獨(dú)立部署的一種稱之為控制平面（ControlPlane）的獨(dú)立組件來集中配置這種依賴調(diào)用關(guān)系以及進(jìn)行路由流量調(diào)撥等操作，如果此時(shí)我們把主機(jī)和業(yè)務(wù)邏輯從視覺圖上剝離，就會(huì)出現(xiàn)一種網(wǎng)絡(luò)狀的架構(gòu)，服務(wù)網(wǎng)格由此得名。
在新一代的Service Mesh架構(gòu)中服務(wù)消費(fèi)方和提供方的主機(jī)（或容器）兩邊都會(huì)部署代理SideCar，此時(shí)SideCar與服務(wù)所在的主機(jī)又稱之為數(shù)據(jù)平面（DataPlane），與我們前面說到的用于依賴關(guān)系配置和流量調(diào)撥操作的控制平面相對(duì)應(yīng)。
?
Istio
?
通過上述的內(nèi)容，我們從概念上應(yīng)該是大概理解了什么是Service Mesh。而具體要落地Service Mesh只有概念是遠(yuǎn)遠(yuǎn)不夠的，相反，如果沒有一種可落地執(zhí)行的開源框架，這個(gè)概念也不會(huì)這么快被大家所接受。
?Istio就是目前受Google/IBM 等大廠支持和推進(jìn)的一個(gè) ServiceMesh開源框架組合。它解決了開發(fā)人員和運(yùn)維人員在整體應(yīng)用程序向分布式微服務(wù)體系結(jié)構(gòu)過渡時(shí)所面臨的挑戰(zhàn)。我們知道無論是基于SpringCloud的微服務(wù)架構(gòu)體系還是目前我們說到的Service Mesh，隨著微服務(wù)規(guī)模的增長會(huì)帶來很多的復(fù)雜性，如服務(wù)發(fā)現(xiàn)、負(fù)載均衡、故障恢復(fù)、監(jiān)控,甚至A/B測試、訪問控制等。而要對(duì)涉及這些問題的微服務(wù)架構(gòu)體系進(jìn)行管理，如果沒有成熟的組件的話，就會(huì)需要耗費(fèi)很多的精力去開發(fā)一些運(yùn)維工具，而這個(gè)成本是非常高的。
?
而Istio則提供了一個(gè)完整的解決方案來滿足微服務(wù)應(yīng)用程序的各種需求。下圖是Istio官網(wǎng)（https://istio.io）所展示的關(guān)于Istio的一張架構(gòu)圖：
?
在這張架構(gòu)圖中Istio服務(wù)網(wǎng)格在邏輯上還是分為數(shù)據(jù)平面和控制平面。數(shù)據(jù)平面中的SideCar代理是由一款叫做Envoy的組件來承擔(dān)的，它是一款用C++開發(fā)的高性能代理，用于協(xié)調(diào)服務(wù)網(wǎng)格中所有服務(wù)的入站和出站流量。
?
Envoy提供了很多內(nèi)在的特性如：
動(dòng)態(tài)服務(wù)發(fā)現(xiàn)
負(fù)載均衡
TLS終止
HTTP/2和gRPC代理
熔斷器
健康檢查
基于百分比的流量分割
故障注入
豐富的指標(biāo)
?
從上面的特性上看實(shí)際上Envoy已經(jīng)提供了很完備的SideCar的功能，只是由于其采用的是C++開發(fā)的，目前在國內(nèi)的落地實(shí)踐中會(huì)有不同的取舍和選擇，如螞蟻金服內(nèi)部在實(shí)踐的過程中就沒有使用Istio默認(rèn)集成的Envoy，而是用 Golang 開發(fā)了新的 Sidecar，已經(jīng)開源的SOFAMosn，來替代 Envoy。
?
在Istio控制平面中的各個(gè)組件的作用如下：
Mixer：負(fù)責(zé)收集代理上采集的度量數(shù)據(jù)，進(jìn)行集中監(jiān)控；
Pilot：主要為SideCar提供服務(wù)發(fā)現(xiàn)、智能路由（如A/B測試）、彈性（超時(shí)、重試、斷路器）的流量管理功能；
Citadel：負(fù)責(zé)安全控制數(shù)據(jù)的管理和下發(fā)；
?
以上就是關(guān)于Istio及其組件的一些介紹，具體如何使用Istio進(jìn)行服務(wù)開發(fā)及安裝操作，大家可以看看Istio的官網(wǎng)，另外需要強(qiáng)調(diào)的是kubernetes是目前 Isito 主力支持的容器云環(huán)境。
?
Service Mesh的優(yōu)勢
?
事實(shí)上Service Mesh這種架構(gòu)模式并不新鮮，很早就有公司進(jìn)行過嘗試，之所以最近又火起來的原因，主要還是因?yàn)槟Ｊ揭弧⒛Ｊ蕉拇_有一些固有的缺陷，模式一相對(duì)比較重，有單點(diǎn)問題和性能問題。
?
而模式二則有客戶端復(fù)雜，支持多語言困難，路由、熔斷、限流等服務(wù)操作無法集中治理的問題。而Service Mesh則正好彌補(bǔ)了二者的不足，它是純分布式的，沒有單點(diǎn)的問題，性能也比較優(yōu)秀并且與開發(fā)語言無關(guān)，還可以集中進(jìn)行治理。
?
此外，隨著微服務(wù)化、多語言和容器化的發(fā)展趨勢，很多公司也迫切需要一種輕量級(jí)的服務(wù)發(fā)現(xiàn)機(jī)制，加上一些大廠如Google/IBM的助推（如kubernetes與Docker的容器之爭），正好Service Mesh迎合了這種趨勢，所以才有今天火熱的局面。
原文地址：https://www.cnblogs.com/tianyamoon/p/10106587.html
.NET社區(qū)新聞，深度好文，歡迎訪問公眾號(hào)文章匯總 http://www.csharpkit.com
總結(jié)
以上是生活随笔為你收集整理的微服务架构基础之Service Mesh的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： eShopOnContainers 看微
- 下一篇： dotnet core调试docker下