由CNCF與全球開源志愿者共同發(fā)起的“Cloud Native + Open Source Virtual Summit China 2020中國線上峰會”(KubeCon 2020)，將于2020年7月30日-8月1日正式上線。大會注冊將于7月27日截止，尚未報(bào)名的小伙伴要抓緊了。峰會官網(wǎng)「cncf.lfasiallc.cn」已經(jīng)上線，會議注冊免費(fèi)，誠邀全球廣大的開源組織、企業(yè)、技術(shù)大咖和開發(fā)者報(bào)名參會，提前鎖定這場開源界最負(fù)盛名的旗艦峰會，開啟云原生下一個十年。

　　在過去幾年中，微服務(wù)成為了業(yè)界技術(shù)熱點(diǎn)，大量的互聯(lián)網(wǎng)公司都在使用微服務(wù)架構(gòu)，也有很多傳統(tǒng)企業(yè)開始實(shí)踐互聯(lián)網(wǎng)技術(shù)轉(zhuǎn)型，基本上也是以微服務(wù)和容器為核心。本文將主要介紹微服務(wù)架構(gòu)的概述以及云原生環(huán)境下的 Service Mesh 和傳統(tǒng)微服務(wù)應(yīng)用的區(qū)別。

　　微服務(wù)架構(gòu)概述

　　微服務(wù)架構(gòu)可謂是當(dāng)前軟件開發(fā)領(lǐng)域的技術(shù)熱點(diǎn)，在各種博客、社交媒體和會議演講上的出鏡率非常之高，無論是做基礎(chǔ)架構(gòu)還是做業(yè)務(wù)系統(tǒng)的工程師，對微服務(wù)都相當(dāng)關(guān)注，而這個現(xiàn)象與熱度到目前為止，已經(jīng)持續(xù)了近 5 年之久。

　　尤其是近些年來，微服務(wù)架構(gòu)逐漸發(fā)展成熟，從最初的星星之火到現(xiàn)在的大規(guī)模落地與實(shí)踐，幾乎已經(jīng)成為分布式環(huán)境下的首選架構(gòu)。微服務(wù)成為時下技術(shù)熱點(diǎn)，大量互聯(lián)網(wǎng)公司都在做微服務(wù)架構(gòu)的落地和推廣。同時，也有很多傳統(tǒng)企業(yè)基于微服務(wù)和容器，在做互聯(lián)網(wǎng)技術(shù)轉(zhuǎn)型。

　　而在這個技術(shù)轉(zhuǎn)型中，國內(nèi)有一個趨勢，以 Spring Cloud 與 Dubbo 為代表的微服務(wù)開發(fā)框架非常普及和受歡迎。然而軟件開發(fā)沒有銀彈，基于這些傳統(tǒng)微服務(wù)框架構(gòu)建的應(yīng)用系統(tǒng)在享受其優(yōu)勢的同時，痛點(diǎn)也越加明顯。這些痛點(diǎn)包括但不限于以下幾點(diǎn)：

　　侵入性強(qiáng)。想要集成 SDK 的能力，除了需要添加相關(guān)依賴，往往還需要在業(yè)務(wù)代碼中增加一部分的代碼、或注解、或配置;業(yè)務(wù)代碼與治理層代碼界限不清晰。

　　升級成本高。每次升級都需要業(yè)務(wù)應(yīng)用修改 SDK 版本，重新進(jìn)行功能回歸測試，并且對每一臺機(jī)器進(jìn)行部署上線，而這對于業(yè)務(wù)方來說，與業(yè)務(wù)的快速迭代開發(fā)是有沖突的，大多不愿意停下來做這些與業(yè)務(wù)目標(biāo)不太相關(guān)的事情。

　　版本碎片化嚴(yán)重。由于升級成本高，而中間件卻不會停止向前發(fā)展的步伐，久而久之，就會導(dǎo)致線上不同服務(wù)引用的 SDK 版本不統(tǒng)一、能力參差不齊，造成很難統(tǒng)一治理。

　　中間件演變困難。由于版本碎片化嚴(yán)重，導(dǎo)致中間件向前演進(jìn)的過程中就需要在代碼中兼容各種各樣的老版本邏輯，帶著 “枷鎖” 前行，無法實(shí)現(xiàn)快速迭代。

　　內(nèi)容多、門檻高。Spring Cloud 被稱為微服務(wù)治理的全家桶，包含大大小小幾十個組件，內(nèi)容相當(dāng)之多，往往需要幾年時間去熟悉其中的關(guān)鍵組件。而要想使用 Spring Cloud 作為完整的治理框架，則需要深入了解其中原理與實(shí)現(xiàn)，否則遇到問題還是很難定位。

　　治理功能不全。不同于 RPC 框架，Spring Cloud 作為治理全家桶的典型，也不是萬能的，諸如協(xié)議轉(zhuǎn)換支持、多重授權(quán)機(jī)制、動態(tài)請求路由、故障注入、灰度發(fā)布等高級功能并沒有覆蓋到。而這些功能往往是企業(yè)大規(guī)模落地不可獲缺的功能，因此公司往往還需要投入其它人力進(jìn)行相關(guān)功能的自研或者調(diào)研其它組件作為補(bǔ)充。

　　以上列出了傳統(tǒng)微服務(wù)框架的局限性，但這并不意味著它們一無是處。在中小企業(yè)，采用 Spring Cloud 這樣的傳統(tǒng)微服務(wù)框架已經(jīng)可以滿足絕大部分服務(wù)治理的需求，并且借此快速推進(jìn)微服務(wù)化改造。這些痛點(diǎn)往往是技術(shù)發(fā)展到一定的程度必然要經(jīng)歷的階段，這些痛點(diǎn)促使技術(shù)不斷發(fā)展、不斷前進(jìn)。

　　在眾多熱門技術(shù)趨勢中，云原生的關(guān)注度居高不下，很多開發(fā)者都對由此興起的一眾技術(shù)十分追捧，眾多企業(yè)又開始探索云原生架構(gòu)的轉(zhuǎn)型與落地。這一年，中國的開發(fā)者們經(jīng)歷了從關(guān)注“云原生概念”到關(guān)注“云原生落地實(shí)踐”的轉(zhuǎn)變。

　　而 Service Mesh 技術(shù)也因此越來越火熱，受到越來越多開發(fā)者的關(guān)注，并擁有了大批擁躉。那么 Service Mesh 是什么呢?它為什么會受到開發(fā)者的關(guān)注?它和傳統(tǒng)微服務(wù)應(yīng)用有什么區(qū)別?

　　Service Mesh 定義

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

　　A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application.

　　In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.

　　翻譯成中文如下：

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

　　以上這段話有四個關(guān)鍵點(diǎn)：

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

　　功能：請求分發(fā);

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

　　特點(diǎn)：透明;

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

　　服務(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)用并對其進(jìn)行“處理”;控制層協(xié)調(diào)代理的行為，并為運(yùn)維人員提供 API，用來操控和測量整個網(wǎng)絡(luò)。

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

　　總而言之，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)、產(chǎn)生監(jiān)控?cái)?shù)據(jù)等;

　　對應(yīng)用來說透明，即可以做到無感知部署;

　　服務(wù)網(wǎ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ù)本身。

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

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

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

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

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

　　安全。在某種程度上，單體架構(gòu)應(yīng)用受其單地址空間的保護(hù)。然而，一旦單體架構(gòu)應(yīng)用被分解為多個微服務(wù)，網(wǎng)絡(luò)就會成為一個重要的攻擊面。更多的服務(wù)意味著更多的網(wǎng)絡(luò)流量，這對黑客來說意味著更多的機(jī)會來攻擊信息流。而服務(wù)網(wǎng)格恰恰提供了保護(hù)網(wǎng)絡(luò)調(diào)用的能力和基礎(chǔ)設(shè)施。服務(wù)網(wǎng)格的安全相關(guān)的好處主要體現(xiàn)在以下三個核心領(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)境中，會極大地增加整體鏈路和操作運(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)用增加顯著的延遲。這個延遲是毫秒級別的，但是在特殊業(yè)務(wù)場景下，這個延遲可能也是難以容忍的。

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

　　服務(wù)網(wǎng)格的百花齊放

　　ServiceMesher 社區(qū)從成立以來，舉辦過九場線下 Meetup 以及一場線上 Virtual Meetup，來自螞蟻集團(tuán)、網(wǎng)易、阿里集團(tuán)、新浪、美團(tuán)、百度等一線互聯(lián)網(wǎng)公司分別都分享了各自公司關(guān)于服務(wù)網(wǎng)格的設(shè)計(jì)、實(shí)踐與落地挑戰(zhàn)，業(yè)界知名技術(shù)大會，也經(jīng)常能看到大廠的專家與架構(gòu)師分享服務(wù)網(wǎng)格落地相關(guān)的主題。可謂是百花齊放，百家爭鳴!

　　這些技術(shù)方案不外乎三種：

　　其一，借鑒服務(wù)網(wǎng)格通信代理的思想，基于公司內(nèi)部服務(wù)框架改革而來，強(qiáng)依賴內(nèi)部 RPC 框架與協(xié)議，僅適用于本公司的服務(wù)網(wǎng)格技術(shù)方案;

　　其二，基于服務(wù)網(wǎng)格開源框架 Istio 與 知名數(shù)據(jù)面開源項(xiàng)目 Envoy 進(jìn)行改版，以適配公司內(nèi)部通信與安全協(xié)議，兼容內(nèi)部注冊中心與配置中心，具有一定普適性的企業(yè)級服務(wù)網(wǎng)格解決方案;

　　其三，自研數(shù)據(jù)面(如螞蟻集團(tuán)的 MOSN)，或者完全自研數(shù)據(jù)面與控制面，去除外部依賴，支持快速迭代與自由擴(kuò)展，追求實(shí)際業(yè)務(wù)收益最大化。

　　然而，各大廠對服務(wù)網(wǎng)格的探索有一段時間了，實(shí)際的大規(guī)模落地案例卻不多。我們不禁反思，火了2年的服務(wù)網(wǎng)格究竟給微服務(wù)帶來了什么？我們很難在此刻去判定上述三個方案的優(yōu)劣，但是有一點(diǎn)，服務(wù)網(wǎng)格作為第二代微服務(wù)框架的地位是一貫且明確的。此外，不管直接采用開源方案還是完全自研，知名開源項(xiàng)目體現(xiàn)出來的架構(gòu)思想與理念值得所有云原生技術(shù)人員學(xué)習(xí)和參考。當(dāng)然開源項(xiàng)目也需要大家共建，希望更多大廠內(nèi)部的優(yōu)秀實(shí)踐能不斷反饋到社區(qū)里面來，共同促進(jìn)服務(wù)網(wǎng)格的發(fā)展與繁榮。

　　總結(jié)

　　本文介紹了微服務(wù)架構(gòu)的發(fā)展，以及服務(wù)網(wǎng)格的概念、服務(wù)網(wǎng)格相對于傳統(tǒng)微服務(wù)架構(gòu)的優(yōu)缺點(diǎn)，對于后者，需要讀者們辯證地去看待。從架構(gòu)演進(jìn)路徑來看，從最早期的巨石單體(Monolithic)到分布式(Distributed)，再到微服務(wù)(Microservices)、容器化(Containerization)、容器編排(Container Orchestration)，最后到服務(wù)網(wǎng)格(Service Mesh)、無服務(wù)器(Serverless)。而服務(wù)網(wǎng)格正是這一演進(jìn)路徑中，至關(guān)重要的一環(huán)。

　　展望未來，Kubernetes 正在爆炸式發(fā)展，它已經(jīng)成為企業(yè)綠地應(yīng)用的容器編排的首選。如果說 Kubernetes 已經(jīng)徹底贏得了市場，并且基于 Kubernetes 的應(yīng)用程序的規(guī)模和復(fù)雜性持續(xù)增加，那么就會有一個臨界點(diǎn)，而服務(wù)網(wǎng)格則將是有效管理這些應(yīng)用程序所必需的?？v使前路漫漫，但是隨著服務(wù)網(wǎng)格技術(shù)的持續(xù)發(fā)展，其實(shí)現(xiàn)產(chǎn)品(如 Istio)的架構(gòu)與功能的不斷優(yōu)化，服務(wù)網(wǎng)格將完全取代傳統(tǒng)微服務(wù)架構(gòu)，成為大小企業(yè)微服務(wù)化和上云改造的首選架構(gòu)。

　　歡迎關(guān)注服務(wù)網(wǎng)格和云原生相關(guān)技術(shù)的小伙伴兒報(bào)名參加KubeCon 2020云原生大會，更有來自華為、騰訊、DaoCloud以及Buoyant的開源技術(shù)專家，將帶來有關(guān)服務(wù)網(wǎng)絡(luò)的最新動態(tài)和案例應(yīng)用。大會報(bào)名通道現(xiàn)免費(fèi)開通中，歡迎大家登陸官網(wǎng)「cncf.lfasiallc.cn」，共話云原生新十年。

特別提醒：本網(wǎng)內(nèi)容轉(zhuǎn)載自其他媒體，目的在于傳遞更多信息，并不代表本網(wǎng)贊同其觀點(diǎn)。其原創(chuàng)性以及文中陳述文字和內(nèi)容未經(jīng)本站證實(shí)，對本文以及其中全部或者部分內(nèi)容、文字的真實(shí)性、完整性、及時性本站不作任何保證或承諾，并請自行核實(shí)相關(guān)內(nèi)容。本站不承擔(dān)此類作品侵權(quán)行為的直接責(zé)任及連帶責(zé)任。如若本網(wǎng)有任何內(nèi)容侵犯您的權(quán)益，請及時聯(lián)系我們，本站將會在24小時內(nèi)處理完畢。