云計算技術(shù)及應(yīng)用-第8章-云原生

第8章云原生8.1云原生概述8.2微服務(wù)和服務(wù)網(wǎng)格8.3服務(wù)網(wǎng)格 8.4云原生系統(tǒng)的安全性8.5本章小節(jié)8.6習(xí)題8.1云原生概述

8.1.1云原生起源及發(fā)展 8.1.2云平臺與傳統(tǒng)平臺的區(qū)別 8.1.3云原生架構(gòu) 8.1.4云原生的12要素

8.1.1云原生起源及發(fā)展2010年，PaulFremantle首次提出了CloudNative的概念，即云原生。2015年，MattStine在自己的書中定義了符合云原生架構(gòu)的一些特征。2015年，CloudNativeComputingFoundation（縮寫為CNCF，中文譯為“云原生計算基金會”）成立。2019年，VMwareTanzu官網(wǎng)給出了云原生的最新定義：

云原生是一種利用云計算交付模型的優(yōu)勢來構(gòu)建和運行應(yīng)用程序的方法論。當(dāng)企業(yè)使用云原生架構(gòu)開發(fā)和運維應(yīng)用程序時，它們能更快速地響應(yīng)客戶需求，將新想法推向市場。云原生開發(fā)融合了DevOps、連續(xù)交付、微服務(wù)和容器。圖8-1CNCF生態(tài)圖8.1.1云原生起源及發(fā)展8.1.2云平臺與傳統(tǒng)平臺的區(qū)別云計算不僅僅是一種使用IT資源的方式，它已經(jīng)演變成一個生態(tài)系統(tǒng)。云計算和軟件架構(gòu)設(shè)計的結(jié)合還將提高整個產(chǎn)品的在線性程度和上線速度。云計算消除了開發(fā)人員關(guān)注硬件資源的需要，從而加快了交付速度。傳統(tǒng)的開發(fā)人員產(chǎn)品的開發(fā)上線非常繁瑣，容易出錯。測試人員的操作環(huán)境與開發(fā)人員的環(huán)境不完全一致。在云壞境中創(chuàng)建虛擬機、啟動業(yè)務(wù)耗時以小時計算?；谠频拈_發(fā)過程只需要確定服務(wù)需求、軟件編碼、部署應(yīng)用程序等步驟。通過容器等工具，確保了開發(fā)、測試、部署等軟件環(huán)境的一致性，降低了系統(tǒng)依賴的風(fēng)險。8.1.2云平臺與傳統(tǒng)平臺的區(qū)別8.1.3云原生架構(gòu)云原生是為“云”設(shè)計的應(yīng)用程序。云原生包含很多內(nèi)容，包括微服務(wù)、持續(xù)交付、敏捷架構(gòu)、DevOps和12要素。它不僅包括方法論和原則，還涉及具體的操作工具。使用基于云原生的技術(shù)和管理方法，業(yè)務(wù)可以更好地在云中誕生，或者遷移到云平臺，以享受云計算高效、持續(xù)的服務(wù)功能。云服務(wù)提供的很多能力如靈活的資源需求、高可用性、高可靠性和其他功能，使得開發(fā)人員可以簡單地選擇相應(yīng)的服務(wù)，而不需要考慮自建機房引發(fā)的一系列問題。而且，如果架構(gòu)本身被設(shè)計為支持多云架構(gòu)，可用性將得到進(jìn)一步改善。微服務(wù)隨著大量開源技術(shù)的成熟和云計算的發(fā)展，不同的架構(gòu)設(shè)計風(fēng)格出現(xiàn)在面向服務(wù)的應(yīng)用中，即從單一架構(gòu)轉(zhuǎn)移到微型服務(wù)化。微服務(wù)是一種能夠獨立發(fā)布應(yīng)用服務(wù)的基本服務(wù)，從而可以作為一個獨立的組件升級重用等，對整個大服務(wù)的應(yīng)用也沒有什么影響。每個服務(wù)都可以由專門的開發(fā)人員單獨完成。微服務(wù)架構(gòu)也存在技術(shù)挑戰(zhàn)，如性能延遲、分布式事務(wù)處理、集成測試、故障診斷等。8.1.3云原生架構(gòu)敏捷基礎(chǔ)設(shè)施使用軟件工程的原則、實踐和工具來提供基礎(chǔ)設(shè)施資源的生命周期管理意味著工人可以更經(jīng)常地構(gòu)建更受控制或更穩(wěn)定的基礎(chǔ)設(shè)施，而開發(fā)人員可以在任何時候拉動基礎(chǔ)設(shè)施來服務(wù)于開發(fā)、測試、調(diào)優(yōu)等工作。同時業(yè)務(wù)開發(fā)需要有良好的體系結(jié)構(gòu)設(shè)計，不需要依賴本地數(shù)據(jù)進(jìn)行持久化。所有資源都可以在任何時間、任何時間發(fā)布，同時以API的方式提供彈性、隨需應(yīng)變的計算、存儲能力。技術(shù)人員通過代碼來自動化的完成部署服務(wù)器、管理服務(wù)器模板、更新服務(wù)器和定義基礎(chǔ)設(shè)施模型等工作?；A(chǔ)設(shè)施通過代碼進(jìn)行改變和測試，確保穩(wěn)定的基礎(chǔ)設(shè)施服務(wù)在自動化過程中得到維護，并在每次改變之后執(zhí)行測試。8.1.3云原生架構(gòu)持續(xù)交付持續(xù)交付又分為持續(xù)集成、持續(xù)部署和持續(xù)發(fā)布階段，以確保代碼能夠快速、安全地部署到生產(chǎn)環(huán)境中。持續(xù)集成意味著每次開發(fā)人員提交更改時，它會立即構(gòu)建并自動化測試。持續(xù)交付是一組軟件發(fā)布的能力，在完成了連續(xù)集成之后，提供給預(yù)發(fā)布系統(tǒng)。8.1.3云原生架構(gòu)DevOpsdev(開發(fā)人員)+ops(操作)DevOps內(nèi)容包括組織文化、自動化、精益、反饋和分享等不同范疇。組織結(jié)構(gòu)、企業(yè)文化和理念等需要自上而下地設(shè)計，以促進(jìn)開發(fā)部門、運行和維護部門和質(zhì)量保證部門之間的溝通、合作和整合，組成一個分層的系統(tǒng)。DevOps意識到開發(fā)和運營必須緊密合作，強調(diào)高效組織中的團隊如何與自動化工具進(jìn)行協(xié)作和溝通，以完成軟件生命周期管理，并更快更頻繁地交付更穩(wěn)定的軟件。8.1.3云原生架構(gòu)8.1.4云原生的12要素在云計算的發(fā)展過程中，人們認(rèn)識到云計算中應(yīng)用開發(fā)與傳統(tǒng)的的應(yīng)用開發(fā)之間的區(qū)別，于是考慮使用新的方法來開發(fā)更適合云計算的應(yīng)用程序。這種應(yīng)用程序方法論的十二個元素是由heroku的工程師根據(jù)云應(yīng)用程序開發(fā)的最佳實踐開發(fā)的，可以被認(rèn)為是云原生應(yīng)用程序的基礎(chǔ)。一個應(yīng)用程序只有一個基準(zhǔn)代碼副本，但是這個代碼可以部署到多個環(huán)境中，比如開發(fā)、測試和生產(chǎn)環(huán)境。在云原生架構(gòu)中，這個原則可以解釋為服務(wù)或功能的單一基準(zhǔn)代碼，每個基準(zhǔn)代碼都有自己的持續(xù)集成和持續(xù)部署工作流。8.1.4云原生的12要素依賴關(guān)系的聲明和隔離在開發(fā)云原生應(yīng)用程序中很重要。許多問題是由于缺少依賴關(guān)系或依賴關(guān)系的不同版本造成的，根源在于內(nèi)部部署環(huán)境和云環(huán)境之間的差異。目前容器技術(shù)的使用已經(jīng)大大減少了依賴性引起的問題，因為依賴關(guān)系在Dockerfiles中聲明并且已經(jīng)打包到容器中。8.1.4云原生的12要素依賴關(guān)系環(huán)境變量配置應(yīng)該放在環(huán)境變量里。配置和代碼應(yīng)該嚴(yán)格分開，這樣就可以很容易地配置不同的環(huán)境。例如，測試環(huán)境中，有測試配置文件，應(yīng)用程序部署到生產(chǎn)環(huán)境中，替換為生產(chǎn)環(huán)境中的配置文件即可。運營團隊可以使用Kubernetes組態(tài)管理或者在云環(huán)境中使用托管配置服務(wù)。8.1.4云原生的12要素后端服務(wù)將后端服務(wù)作為附加資源使用。后端服務(wù)是指程序需要通過網(wǎng)絡(luò)調(diào)用來運行的各種服務(wù)。比如云原生中的緩存服務(wù)和數(shù)據(jù)庫即服務(wù)是后端服務(wù)。在訪問這些后端服務(wù)時，建議通過外部配置系統(tǒng)獲取這些服務(wù)的配置信息來減少耦合。8.1.4云原生的12要素8.1.4云原生的12要素嚴(yán)格分離構(gòu)建和運行階段。運營團隊使用持續(xù)集成和持續(xù)部署來完全自動構(gòu)建和發(fā)布應(yīng)用程序。構(gòu)建、發(fā)布和運行8.1.4云原生的12要素使用一個或多個無狀態(tài)處理器運行應(yīng)用程序云中的應(yīng)用程序應(yīng)該是無狀態(tài)的，需要持久化的任何數(shù)據(jù)都應(yīng)該存儲在外部。這樣才能實現(xiàn)云計算的彈性。8.1.4云原生的12要素數(shù)據(jù)隔離每個服務(wù)管理自己的數(shù)據(jù)。這是云原生應(yīng)用程序的一個通用模式。每個服務(wù)管理自己的數(shù)據(jù)，這些數(shù)據(jù)只能通過服務(wù)API獲得。這意味著一個服務(wù)不能直接訪問其他服務(wù)中的數(shù)據(jù)，即使它屬于同一個應(yīng)用程序。8.1.4云原生的12要素并發(fā)通過流程模型進(jìn)行擴展。云原生應(yīng)用程序的兩個主要優(yōu)點是可伸縮性和更有效的資源利用。運營團隊通過獨立調(diào)整個別服務(wù)或功能來獲得更高的資源利用率。8.1.4云原生的12要素云原生應(yīng)用架構(gòu)設(shè)計要允許系統(tǒng)快速彈性擴展、改變部署及故障恢復(fù)。在云環(huán)境中，由于不可控的硬件因素、業(yè)務(wù)的高低峰值等，經(jīng)常需要應(yīng)對故障下的發(fā)布及擴展過程。健壯8.1.4云原生的12要素使開發(fā)、預(yù)發(fā)布和生產(chǎn)環(huán)境盡可能保持一致。利用容器技術(shù)將服務(wù)所需的依賴性打包，從而減少不一致環(huán)境的問題開發(fā)環(huán)境等于在線環(huán)境8.1.4云原生的12要素日志在分布式系統(tǒng)中很重要。分布式系統(tǒng)中同時運行這么多的服務(wù)，并且還是在不同的節(jié)點上運行的。如果應(yīng)用程序出錯時沒有好的日志記錄方法，運營團隊就沒法解決問題。將日志看作是事件流8.1.4云原生的12要素將管理任務(wù)作為一個短期過程來處理。函數(shù)和容器是執(zhí)行這些任務(wù)的好工具。將后臺管理任務(wù)作為一次性處理來管理。8.2微服務(wù)和服務(wù)網(wǎng)格

8.2.1微服務(wù)概述 8.2.2微服務(wù)框架 8.2.3微服務(wù)劃分及架構(gòu) 8.2.4SpringBoot 8.2.5SpringCloud 8.2.6微服務(wù)實踐

8.2.1微服務(wù)概述將一個大型應(yīng)用程序分解為許多獨立的小型應(yīng)用程序，每個應(yīng)用程序處理一項任務(wù)。而且新功能的增加，只需要通過新增小型應(yīng)用程序的方式就可以實現(xiàn)。這就是微服務(wù)。微服務(wù)架構(gòu)樣式是一種將單個應(yīng)用程序開發(fā)為一組小服務(wù)的方法，每個小服務(wù)都在自己的進(jìn)程中運行并與輕量級機制（通常是HTTP資源API）進(jìn)行通信。這些服務(wù)圍繞業(yè)務(wù)功能構(gòu)建，并且可以由全自動部署機制獨立部署。這些服務(wù)幾乎沒有集中管理，可以用不同的編程語言編寫并使用不同的數(shù)據(jù)存儲技術(shù)。8.2.1微服務(wù)概述微服務(wù)基本結(jié)構(gòu)圖微服務(wù)的優(yōu)勢獨立開發(fā)：開發(fā)團隊基于微服務(wù)所獨有的功能來工作，更獨立、更快速。輕松部署：基于它們所提供的服務(wù)，它們可以被獨立地部署到應(yīng)用中。微服務(wù)支持持續(xù)集成和持續(xù)交付。彈性的錯誤隔離：即便其中某個服務(wù)發(fā)生了故障，整個系統(tǒng)還可以繼續(xù)工作。應(yīng)用程序在處理總體服務(wù)故障時可以通過降低功能來完成，而不是讓整個應(yīng)用程序崩潰?；旌霞夹g(shù)：可以使用不同的語言和技術(shù)來為同一個應(yīng)用構(gòu)建不同的服務(wù)。按粒度擴展：可以獨立擴展各項服務(wù)以滿足其支持的應(yīng)用程序功能的需求，不需要將所有組件全部擴展。代碼重用：微服務(wù)中代碼重用更加充分。8.2.1微服務(wù)概述8.2.2微服務(wù)框架微服務(wù)成為很多企業(yè)架構(gòu)重構(gòu)的方向，同時也對架構(gòu)師提出更高的挑戰(zhàn)。目前有很多常用于微服務(wù)構(gòu)建的框架，對于構(gòu)建微服務(wù)架構(gòu)能夠帶來一些幫助。8.2.2微服務(wù)框架Java語言相關(guān)微服務(wù)框架SpringBootSpringCloudDubboDropwizardAkka8.2.2微服務(wù)框架Net相關(guān)微服務(wù)框架.NETCoreServiceFabricSurgingMicrodotFramework8.2.2微服務(wù)框架Node.js相關(guān)微服務(wù)框架SenecaHapiRestifyLoopBack8.2.3微服務(wù)劃分及架構(gòu)微服務(wù)體系結(jié)構(gòu)更適合未來具有一定擴展復(fù)雜性、用戶期望增加較大的應(yīng)用。在決定使用微服務(wù)體系結(jié)構(gòu)之后，面臨的另一個問題是如何將系統(tǒng)劃分為微服務(wù)。模塊拆分拆是分布式微服務(wù)實現(xiàn)中的難點之一。它將直接影響系統(tǒng)的復(fù)雜性、團隊協(xié)作、代碼維護難度、硬件資源分配等。模塊分割分拆得越細(xì)，硬件資源的分配就越靈活，團隊協(xié)調(diào)就越方便，但這也會增加系統(tǒng)的復(fù)雜性和代碼維護的難度。8.2.3微服務(wù)劃分及架構(gòu)微服務(wù)系統(tǒng)由多個服務(wù)單元組成，每個服務(wù)單元都有多個實例。由于系統(tǒng)的服務(wù)粒度小，服務(wù)數(shù)量多，服務(wù)之間的相互依賴關(guān)系是網(wǎng)絡(luò)化的，所以因此系統(tǒng)需要服務(wù)注冊中心統(tǒng)一管理微服務(wù)實例，檢查每個微服務(wù)實例的健康狀態(tài)。服務(wù)注冊中心可以通知服務(wù)使用者它想要使用的服務(wù)的實例信息(如服務(wù)名稱、地址等)。服務(wù)使用者通常使用HTTP協(xié)議或使用消息組件作為通信機制。服務(wù)注冊中心將提供服務(wù)的健康檢查，查看注冊的服務(wù)是否可用。8.2.4

SpringBoot目前微服務(wù)框架使用SpringCloud較為常見。它基于SpringBoot這個Web框架。SpringBoot是Spring團隊提供的框架，可以簡化Spring應(yīng)用程序的初始構(gòu)建過程和開發(fā)過程。SpringCloud通過提供一系列開發(fā)組件和框架來快速完成微服務(wù)系統(tǒng)的搭建。8.2.4

SpringBootSpringBoot只有一個pertiesprofile，沒有其他的XMLprofile，不需要XML配置，也更適合全新的Spring項目。8.2.4

SpringBootIDEA使用SpringBoot開發(fā)項目的基本操作創(chuàng)建之后，可以看到如左圖所示的項目總結(jié)構(gòu)。POM是項目對象模型（ProjectObjectModel）的簡稱，它是Maven項目中的文件，使用XML表示，名稱叫做pom.xml。該文件用于管理：源代碼、配置文件、開發(fā)者的信息和角色、問題追蹤系統(tǒng)、組織信息、項目授權(quán)、項目的url、項目的依賴關(guān)系等等。8.2.4

SpringBoot添加基礎(chǔ)代碼8.2.4

SpringBoot8.2.4

SpringBoot啟動項目8.2.4

SpringBoot項目啟動后輸出可以通過在瀏覽器中輸入http://localhost:8080/hello/say來查看，查看結(jié)果如下圖8.2.5SpringCloudSpringCloud給開發(fā)者留出了一套簡單易懂、容易部署的分布式系統(tǒng)開發(fā)工具包。SpringCloud中包括分布式/版本化配置、服務(wù)注冊和發(fā)現(xiàn)、路由、服務(wù)到服務(wù)呼叫、負(fù)載平衡、斷路器、全局鎖、領(lǐng)導(dǎo)層選舉和集群狀態(tài)、分布式消息傳遞等內(nèi)容。SpringCloud通過SpringBoot風(fēng)格的封裝，屏蔽掉了復(fù)雜的配置和實現(xiàn)原理。SpringCloud就是這些可以獨立部署、水平擴展、獨立訪問（或者有獨立的數(shù)據(jù)庫）的微服務(wù)大管家。SpringCloud包含很多子項目，以SpringCloudAlibaba為例介紹。8.2.5SpringCloudSpringCloudAlibaba為分布式應(yīng)用開發(fā)提供一站式解決方案。有了它，開發(fā)人員只需要添加一些注釋和少量配置，就能將SpringCloud應(yīng)用連接到阿里巴巴的分布式解決方案，用阿里巴巴的中間件構(gòu)建分布式應(yīng)用系統(tǒng)。SpringCloudAlibaba中使用AlibabaSentinel來進(jìn)行流量控制、斷路和系統(tǒng)自適應(yīng)保護，使用AlibabaNacos來完成實例的注冊?？蛻舳丝梢允褂肧pring管理的Bean發(fā)現(xiàn)實例，通過SpringCloudNetflix的客戶端負(fù)載均衡器來支持功能區(qū)，分布式配置中使用AlibabaNacos作為數(shù)據(jù)存儲。Seata來保證具有高性能和易用性，并通過DubboRPC擴展了ApacheDubboRPC調(diào)用的SpringCloud中服務(wù)到服務(wù)的通信協(xié)議。SpringCloudAlibaba

商業(yè)化組件AlibabaCloudACM：在分布式架構(gòu)環(huán)境中對應(yīng)用配置進(jìn)行集中管理和推送的應(yīng)用配置中心產(chǎn)品。AlibabaCloudOSS：阿里云對象存儲服務(wù)。AlibabaCloudSchedulerX：阿里中間件團隊開發(fā)的一款分布式任務(wù)調(diào)度產(chǎn)品。AlibabaCloudSMS：覆蓋全球的短信服務(wù)。8.2.5SpringCloudSpringCloudAlibaba

開源組件Nacos：阿里巴巴開源產(chǎn)品，一個更易于構(gòu)建云原生應(yīng)用的動態(tài)服務(wù)發(fā)現(xiàn)、配置管理和服務(wù)管理平臺。01RocketMQ：一款開源的分布式消息系統(tǒng)，基于高可用分布式集群技術(shù)。03Seata：阿里巴巴開源產(chǎn)品，一個易于使用的高性能微服務(wù)分布式事務(wù)解決方案。05Sentinel：面向分布式服務(wù)架構(gòu)的輕量級流量控制產(chǎn)品。02Dubbo：ApacheDubbo?是一款高性能JavaRPC框架，用于實現(xiàn)服務(wù)通信。04068.2.5SpringCloud8.2.6微服務(wù)實踐例如Service甲是訂單服務(wù)，Service乙是商品服務(wù)?？蛻粼趧?chuàng)建訂單的時候，需要調(diào)用商品信息。從服務(wù)間協(xié)作的角度看，訂單服務(wù)會調(diào)用商品服務(wù)。其中被調(diào)用的是服務(wù)提供方，調(diào)用方為消費方。但是由于多種原因，如微服務(wù)部署在云環(huán)境中的，對應(yīng)一個服務(wù)會有多個實例來做負(fù)載均衡，應(yīng)對臨時訪問壓力增加新的服務(wù)節(jié)點等等，服務(wù)實例的網(wǎng)絡(luò)位置地址會動態(tài)改變。8.2.6微服務(wù)實踐解決方案如下：1）在每個服務(wù)實例內(nèi)部包含一個服務(wù)發(fā)現(xiàn)的客戶端。2）在每個服務(wù)啟動時會向服務(wù)發(fā)現(xiàn)中心上報自己的網(wǎng)絡(luò)位置。服務(wù)發(fā)現(xiàn)中心內(nèi)部維護一個服務(wù)注冊表，服務(wù)注冊表是服務(wù)發(fā)現(xiàn)的核心部分，是包含所有服務(wù)實例的網(wǎng)絡(luò)地址的數(shù)據(jù)庫。3）服務(wù)發(fā)現(xiàn)客戶端會定期從服務(wù)發(fā)現(xiàn)中心同步服務(wù)注冊表，并緩存在客戶端。4）當(dāng)需要對某服務(wù)進(jìn)行請求時，服務(wù)實例通過該注冊表，定位目標(biāo)服務(wù)網(wǎng)絡(luò)地址。若目標(biāo)服務(wù)存在多個網(wǎng)絡(luò)地址，則使用負(fù)載均衡算法從多個服務(wù)實例中選擇出一個，然后發(fā)出請求。8.2.6微服務(wù)實踐實踐工具--NacosNacos是一個幫助開發(fā)運維人員發(fā)現(xiàn)、配置和管理微服務(wù)的工具。Nacos提供了一組簡單易用的特性集合，幫助開發(fā)運維人員快速實現(xiàn)動態(tài)服務(wù)發(fā)現(xiàn)、服務(wù)配置、服務(wù)元數(shù)據(jù)及流量管理。Nacos幫助開發(fā)運維人員更敏捷和容易地構(gòu)建、交付和管理微服務(wù)平臺。Nacos支持幾乎所有主流類型的“服務(wù)”的發(fā)現(xiàn)、配置和管理。。8.3服務(wù)網(wǎng)格服務(wù)網(wǎng)格是用于控制和監(jiān)視監(jiān)控微服務(wù)應(yīng)用程序中的內(nèi)部的服務(wù)到服務(wù)流量的軟件基礎(chǔ)結(jié)構(gòu)層。它通常采用與應(yīng)用程序代碼一起部署的網(wǎng)絡(luò)代理的“數(shù)據(jù)平面”的形式，以及用于與這些代理交互的“控制平面”。Docker和Kubernetes解決了應(yīng)用部署、調(diào)度和更新的問題。但是微服務(wù)應(yīng)用作為一種分布式系統(tǒng)，運行時的很多問題，比如服務(wù)的發(fā)現(xiàn)、故障熔斷和負(fù)載均衡等都需要應(yīng)用去處理。為了解決這些問題，業(yè)界逐漸發(fā)展出了微服務(wù)治理框架。初期的微服務(wù)治理都是基于開發(fā)框架的，如SpringCloud和Dubbo。這些開發(fā)框架很好的解決了微服務(wù)運行時的問題，但是存在開發(fā)語言鎖定，對應(yīng)用存在侵入性、開發(fā)運維職責(zé)不清等弊端。服務(wù)網(wǎng)格（ServiceMesh）就是在這種環(huán)境下出現(xiàn)的。ServiceMesh服務(wù)網(wǎng)格的概念已經(jīng)被大部分的大型云上企業(yè)接受，ServiceMesh服務(wù)網(wǎng)格被詬病的性能問題也在被逐步解決中。Serverless目前發(fā)展得還比較初期，包括了全托管的服務(wù)和FaaS（函數(shù)即服務(wù)）。全托管服務(wù)在公有云上已經(jīng)逐步成熟，隨著混合云的普及，全托管服務(wù)會逐步發(fā)展。FaaS由于涉及開發(fā)模式的轉(zhuǎn)變，目前要取代現(xiàn)有的開發(fā)模式還需要假以時日時日，不過有些在合適合的應(yīng)用場景中應(yīng)該會有越來越多的應(yīng)用。目前，servicemesh服務(wù)網(wǎng)格起作用的位置包括：每個微服務(wù)導(dǎo)入的Library，在特定節(jié)點提供服務(wù)給所有容器節(jié)點的Agent，與應(yīng)用程序容器一起運行的Sidecar容器。8.3服務(wù)網(wǎng)格基于Sidecar的servicemesh服務(wù)網(wǎng)格模式的基本架構(gòu)圖8.3服務(wù)網(wǎng)格ServcieMesh服務(wù)網(wǎng)格開源軟件Linkerd是一個用于云原生應(yīng)用的開源、可擴展的ServcieMesh（服務(wù)網(wǎng)格）。同時，Linkerd也是CNCF（云原生計算基金會）中的組件之一。Linkerd的出現(xiàn)是為了解決像twitter、google這類超大規(guī)模生產(chǎn)系統(tǒng)的復(fù)雜性問題。Linkerd不是通過控制服務(wù)之間的通信機制來解決這個問題，而是通過在服務(wù)實例之上添加一個抽象層來解決的。Linkerd負(fù)責(zé)跨服務(wù)通信中最困難、易出錯的部分，包括延遲感知、負(fù)載均衡、連接池、TLS、儀表盤、請求路由等等?！@些都會影響應(yīng)用程序伸縮性、性能和彈性。Linkerd作為獨立代理運行，無需特定的語言和庫支持。應(yīng)用程序通常會在已知位置運行Linkerd實例，然后通過這些實例代理服務(wù)進(jìn)行調(diào)用?！床皇侵苯舆B接到