1.1　Service Mesh基本概念

2019年，在眾多熱門技術(shù)的趨勢中，云原生的關(guān)注度居高不下，很多開發(fā)者都對(duì)由此興起的一眾技術(shù)十分追捧，眾多企業(yè)又開始探索云原生架構(gòu)的轉(zhuǎn)型與落地。這一年，中國的開發(fā)者們經(jīng)歷了從關(guān)注“云原生概念”到關(guān)注“云原生落地實(shí)踐”的轉(zhuǎn)變。而Service Mesh技術(shù)也因此越來越火熱，受到越來越多的開發(fā)者的關(guān)注，并擁有了大批擁護(hù)者。那么，Service Mesh是什么呢？它為什么會(huì)受到開發(fā)者的關(guān)注？它和傳統(tǒng)微服務(wù)框架有什么區(qū)別？

Service Mesh一詞最早由開發(fā)Linkerd的Buoyant公司提出，并于2016年9月29日第一次公開使用。William Morgan、Buoyant CEO對(duì)Service Mesh這一概念定義如下：

Service Mesh是一個(gè)專門處理服務(wù)通信的基礎(chǔ)設(shè)施層。它的職責(zé)是在由云原生應(yīng)用組成服務(wù)的復(fù)雜拓?fù)浣Y(jié)構(gòu)下進(jìn)行可靠的請(qǐng)求傳送。在實(shí)踐中，它是一組和應(yīng)用服務(wù)部署在一起的輕量級(jí)的網(wǎng)絡(luò)代理，且對(duì)應(yīng)用服務(wù)透明。

以上這段話有4個(gè)關(guān)鍵點(diǎn)。

?本質(zhì)：基礎(chǔ)設(shè)施層。

?功能：請(qǐng)求分發(fā)。

?部署形式：網(wǎng)絡(luò)代理。

?特點(diǎn)：透明。

2017年，隨著Linkerd的傳入，Service Mesh進(jìn)入國內(nèi)社區(qū)的視野，并且由國內(nèi)的“技術(shù)布道師”翻譯成“服務(wù)網(wǎng)格”。

服務(wù)網(wǎng)格從總體架構(gòu)上來講比較簡單，由一堆緊挨著各項(xiàng)服務(wù)的用戶代理，外加一組任務(wù)管理流程組成。在服務(wù)網(wǎng)格中，代理被稱為數(shù)據(jù)層或數(shù)據(jù)平面（Data Plane），管理流程被稱為控制層或控制平面（Control Plane）。數(shù)據(jù)層截獲不同服務(wù)之間的調(diào)用并對(duì)其進(jìn)行處理；控制層不僅可以協(xié)調(diào)代理的行為，而且可以通過為運(yùn)維人員提供API，操控和測量整個(gè)網(wǎng)絡(luò)。

更進(jìn)一步地說，服務(wù)網(wǎng)格是一個(gè)專用的基礎(chǔ)設(shè)施層，旨在“在微服務(wù)架構(gòu)中實(shí)現(xiàn)可靠、快速和安全的服務(wù)間調(diào)用”。它不是一個(gè)“服務(wù)”的網(wǎng)格，而是一個(gè)“代理”的網(wǎng)格，服務(wù)可以插入這個(gè)“代理”的網(wǎng)格中，從而使網(wǎng)絡(luò)抽象化。在典型的服務(wù)網(wǎng)格中，這些代理作為一個(gè)Sidecar（邊車）被注入每個(gè)服務(wù)部署中。服務(wù)不直接通過網(wǎng)絡(luò)調(diào)用服務(wù)，而是調(diào)用它們本地的Sidecar代理，而Sidecar代理又代表了服務(wù)管理請(qǐng)求，從而封裝了服務(wù)間通信的復(fù)雜性。相互連接的Sidecar代理實(shí)現(xiàn)了所謂的數(shù)據(jù)平面，這與用于配置代理和收集指標(biāo)的服務(wù)網(wǎng)格組件（控制平面）形成對(duì)比。

總而言之，Service Mesh的基礎(chǔ)設(shè)施層主要分為兩部分：控制平面與數(shù)據(jù)平面。當(dāng)前流行的兩款開源服務(wù)網(wǎng)格Istio和Linkerd實(shí)際上都是這種構(gòu)造。

控制平面的特點(diǎn)：

?不直接解析數(shù)據(jù)包。

?與控制平面中的代理通信、下發(fā)策略和配置。

?負(fù)責(zé)網(wǎng)絡(luò)行為的可視化。

?通常提供API或命令行工具，可用于配置版本化管理，便于持續(xù)集成和部署。

數(shù)據(jù)平面的特點(diǎn)：

?通常是按照無狀態(tài)目標(biāo)設(shè)計(jì)的，但實(shí)際上為了提高流量轉(zhuǎn)發(fā)效率，需要緩存一些數(shù)據(jù)，因此無狀態(tài)也是有爭議的。

?直接處理入站和出站數(shù)據(jù)包，如轉(zhuǎn)發(fā)、路由、健康檢查、負(fù)載均衡、認(rèn)證、鑒權(quán)、監(jiān)控?cái)?shù)據(jù)等。

?對(duì)應(yīng)用來說透明，可以做到無感知部署。

那么，服務(wù)網(wǎng)格的出現(xiàn)帶來了哪些變革呢？

第一，微服務(wù)治理與業(yè)務(wù)邏輯的解耦。服務(wù)網(wǎng)格把SDK中的大部分功能從應(yīng)用中剝離出來，拆解為獨(dú)立進(jìn)程，以Sidecar的模式進(jìn)行部署。服務(wù)網(wǎng)格通過將服務(wù)通信及相關(guān)管控功能從業(yè)務(wù)程序中分離并下沉到基礎(chǔ)設(shè)施層，使其和業(yè)務(wù)系統(tǒng)完全解耦，使開發(fā)人員更加專注于業(yè)務(wù)本身。

注意，這里提到了一個(gè)詞“大部分”，在SDK中往往需要保留協(xié)議編解碼的邏輯，甚至在某些場景下還需要一個(gè)輕量級(jí)的SDK來實(shí)現(xiàn)細(xì)粒度的治理與監(jiān)控策略。例如，要想實(shí)現(xiàn)方法級(jí)別的調(diào)用鏈路追蹤，服務(wù)網(wǎng)格就需要業(yè)務(wù)應(yīng)用實(shí)現(xiàn)Trace ID的傳遞，而這部分實(shí)現(xiàn)邏輯也可以通過輕量級(jí)的SDK實(shí)現(xiàn)。因此，從代碼層面來講，服務(wù)網(wǎng)格并非零侵入的。

第二，異構(gòu)系統(tǒng)的統(tǒng)一治理。隨著新技術(shù)的發(fā)展和人員的更替，即使在同一家公司也會(huì)出現(xiàn)不同語言、不同框架的應(yīng)用和服務(wù)。為了統(tǒng)一管控這些服務(wù)，以往的做法是為每種語言、每種框架都開發(fā)一套完整的SDK，不僅維護(hù)成本非常高，而且會(huì)給公司的中間件團(tuán)隊(duì)帶來很大的挑戰(zhàn)。有了服務(wù)網(wǎng)格之后，可以將主體的服務(wù)治理功能下沉到基礎(chǔ)設(shè)施，多語言的支持就會(huì)輕松很多。只需提供一個(gè)非常輕量級(jí)的SDK，甚至在很多情況下都不需要一個(gè)單獨(dú)的SDK，就可以輕松實(shí)現(xiàn)多語言、多協(xié)議的統(tǒng)一流量管控、監(jiān)控等需求。

此外，相對(duì)于傳統(tǒng)微服務(wù)框架，服務(wù)網(wǎng)格還擁有三大技術(shù)優(yōu)勢。

?可觀察性。因?yàn)榉?wù)網(wǎng)格是一個(gè)專用的基礎(chǔ)設(shè)施層，所有的服務(wù)間通信都需要通過它，所以它在技術(shù)堆棧中處于獨(dú)特的位置，以便在服務(wù)調(diào)用級(jí)別上提供統(tǒng)一的遙測指標(biāo)。這意味著，所有服務(wù)都被監(jiān)控為“黑盒”。服務(wù)網(wǎng)格捕獲諸如來源、目的地、協(xié)議、URL、狀態(tài)碼、延遲、持續(xù)時(shí)間等線路數(shù)據(jù)。這在本質(zhì)上等同于Web服務(wù)器日志可以提供的數(shù)據(jù)，但是服務(wù)網(wǎng)格可以為所有服務(wù)捕獲這些數(shù)據(jù)，而不僅僅是單個(gè)服務(wù)的Web層。需要指出的是，收集數(shù)據(jù)只是解決微服務(wù)應(yīng)用程序中可觀察性問題的一部分。存儲(chǔ)與分析這些數(shù)據(jù)則需要額外功能的機(jī)制補(bǔ)充，并作用于警報(bào)或?qū)嵗詣?dòng)伸縮等。

?流量控制。服務(wù)網(wǎng)格可以為服務(wù)提供智能路由（藍(lán)綠部署、金絲雀發(fā)布、A/B測試）、超時(shí)重試、熔斷、故障注入、流量鏡像等各種控制功能。以上這些是傳統(tǒng)微服務(wù)框架所不具備的功能，但對(duì)系統(tǒng)來說是至關(guān)重要的功能。這是因?yàn)榉?wù)網(wǎng)格承載了微服務(wù)之間的通信流量，所以可以在服務(wù)網(wǎng)格中通過規(guī)則進(jìn)行故障注入，模擬部分微服務(wù)出現(xiàn)故障的情況，對(duì)整個(gè)應(yīng)用的健壯性進(jìn)行測試。由于服務(wù)網(wǎng)格的設(shè)計(jì)目的是有效地將來源請(qǐng)求調(diào)用連接到其最優(yōu)目標(biāo)服務(wù)實(shí)例中，因此這些流量控制特性是面向目的地的。這正是服務(wù)網(wǎng)格流量控制功能的一大特點(diǎn)。

?安全。在某種程度上，單體架構(gòu)應(yīng)用受其單地址空間的保護(hù)。然而，一旦單體架構(gòu)應(yīng)用被分解為多個(gè)微服務(wù)，網(wǎng)絡(luò)就會(huì)成為一個(gè)重要的攻擊面。更多的服務(wù)意味著更多的網(wǎng)絡(luò)流量，這對(duì)黑客來說意味著擁有更多的機(jī)會(huì)來攻擊信息流。而服務(wù)網(wǎng)格恰恰提供了保護(hù)網(wǎng)絡(luò)調(diào)用的功能和基礎(chǔ)設(shè)施。服務(wù)網(wǎng)格安全的相關(guān)好處主要體現(xiàn)在以下3個(gè)核心領(lǐng)域：服務(wù)的認(rèn)證、服務(wù)間通信的加密，以及安全相關(guān)策略的強(qiáng)制執(zhí)行。

服務(wù)網(wǎng)格擁有極其強(qiáng)大的技術(shù)優(yōu)勢，帶來了巨大變革，被稱為“第二代微服務(wù)架構(gòu)”。然而就像之前說的軟件開發(fā)沒有“銀彈”，傳統(tǒng)微服務(wù)架構(gòu)有許多痛點(diǎn)一樣，服務(wù)網(wǎng)格也有它的局限性，具體如下。

?增加了復(fù)雜度。服務(wù)網(wǎng)格將Sidecar代理和其他組件引入已經(jīng)很復(fù)雜的分布式環(huán)境中，會(huì)極大地增加整體鏈路和操作運(yùn)維的復(fù)雜性。

?運(yùn)維人員需要更專業(yè)。在容器編排工具（如Kubernetes）上添加Istio之類的服務(wù)網(wǎng)格，需要運(yùn)維人員成為這兩種技術(shù)的專家，以便充分使用二者的功能，以及定位環(huán)境中遇到的問題。

?延遲。從鏈路層面來講，服務(wù)網(wǎng)格是一種侵入性的、復(fù)雜的技術(shù)，可以為系統(tǒng)調(diào)用增加明顯的延遲。雖然這個(gè)延遲是毫秒級(jí)別的，但是在特殊業(yè)務(wù)場景下，這個(gè)延遲可能是令人難以容忍的。

?平臺(tái)的適配。服務(wù)網(wǎng)格的侵入性迫使開發(fā)人員和運(yùn)維人員適應(yīng)平臺(tái)并遵守平臺(tái)的規(guī)則。