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

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

　　微服務架構概述

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

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

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

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

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

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

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

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

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

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

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

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

　　Service Mesh 定義

　　Service Mesh 一詞最早由開發(fā) Linkerd 的 Buoyant 公司提出，并于 2016 年 9 月29 日第一次公開使用了這一術語。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ǎng)絡代理，并且對應用服務透明。

　　以上這段話有四個關鍵點：

　　本質：基礎設施層;

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

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

　　特點：透明;

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

　　服務網(wǎng)格概述

　　服務網(wǎng)格從總體架構上來講比較簡單，不過是一堆緊挨著各項服務的用戶代理，外加一組任務管理流程組成。代理在服務網(wǎng)格中被稱為數(shù)據(jù)層或數(shù)據(jù)平面(data plane)，管理流程被稱為控制層或控制平面(control plane)。數(shù)據(jù)層截獲不同服務之間的調用并對其進行“處理”;控制層協(xié)調代理的行為，并為運維人員提供 API，用來操控和測量整個網(wǎng)絡。

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

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

　　控制平面的特點：

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

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

　　負責網(wǎng)絡行為的可視化;

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

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

　　通常是按照無狀態(tài)目標設計的，但實際上為了提高流量轉發(fā)性能，需要緩存一些數(shù)據(jù)，因此無狀態(tài)也是有爭議的;

　　直接處理入站和出站數(shù)據(jù)包，轉發(fā)、路由、健康檢查、負載均衡、認證、鑒權、產(chǎn)生監(jiān)控數(shù)據(jù)等;

　　對應用來說透明，即可以做到無感知部署;

　　服務網(wǎng)格帶來的變革

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

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

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

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

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

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

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

　　安全。在某種程度上，單體架構應用受其單地址空間的保護。然而，一旦單體架構應用被分解為多個微服務，網(wǎng)絡就會成為一個重要的攻擊面。更多的服務意味著更多的網(wǎng)絡流量，這對黑客來說意味著更多的機會來攻擊信息流。而服務網(wǎng)格恰恰提供了保護網(wǎng)絡調用的能力和基礎設施。服務網(wǎng)格的安全相關的好處主要體現(xiàn)在以下三個核心領域：服務的認證、服務間通訊的加密、安全相關策略的強制執(zhí)行。

　　服務網(wǎng)格帶來了巨大變革并且擁有其強大的技術優(yōu)勢，被稱為第二代“微服務架構”。然而就像之前說的軟件開發(fā)沒有銀彈，傳統(tǒng)微服務架構有許多痛點，而服務網(wǎng)格也不例外，也有它的局限性。

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

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

　　延遲。從鏈路層面來講，服務網(wǎng)格是一種侵入性的、復雜的技術，可以為系統(tǒng)調用增加顯著的延遲。這個延遲是毫秒級別的，但是在特殊業(yè)務場景下，這個延遲可能也是難以容忍的。

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

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

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

　　這些技術方案不外乎三種：

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

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

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

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

　　總結

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

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

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

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