摘要：在將您的單體應(yīng)用微服務(wù)化時(shí)，也可以采用這種方式，即新的功能使用微服務(wù)架構(gòu)來(lái)開(kāi)發(fā)，通過(guò)對(duì)原有的單體應(yīng)用暴露和端口號(hào)的方式供其進(jìn)行調(diào)用和使用。如果這時(shí)其他服務(wù)再來(lái)訪問(wèn)這個(gè)和端口號(hào)，那一定會(huì)出現(xiàn)找不到服務(wù)等各種故障。

作者注：
聯(lián)系方式 leontian1024@gmail.com || github.com/XinyaoTian
新人入行，非常期待能與各位大牛們討論，感謝各位的閱讀，希望對(duì)您有所幫助。

相信每一位老道的開(kāi)發(fā)者和軟件工程師們都會(huì)有過(guò)，曾經(jīng)( 也許現(xiàn)在仍然 )被龐大且復(fù)雜的軟件系統(tǒng)所支配的恐懼。隨著軟件版本的迭代和開(kāi)發(fā)團(tuán)隊(duì)人員規(guī)模的擴(kuò)大，曾經(jīng)那個(gè)小巧別致、設(shè)計(jì)精良的軟件或應(yīng)用一去不返，如今已經(jīng)變得遍地狼藉，慘不忍睹——混亂的接口、不規(guī)范的調(diào)用、像貼狗皮膏藥一般貼上去的新功能組件……曾經(jīng)那個(gè)賞心悅目的應(yīng)用，如今看了就反胃。這一切都預(yù)示著一個(gè)問(wèn)題：開(kāi)發(fā)軟件的方式需要改變。

縱使有那么多種軟件開(kāi)發(fā)模式，但如果不能從底層技術(shù)上實(shí)現(xiàn)對(duì)設(shè)計(jì)的約束，問(wèn)題將會(huì)隨著時(shí)間的推移，最終暴露出來(lái)。譬如“高內(nèi)聚，低耦合”的設(shè)計(jì)理念，如果不能從底層就實(shí)現(xiàn)模塊間的隔離，而依靠開(kāi)發(fā)時(shí)的技巧和經(jīng)驗(yàn)，那么最終這個(gè)軟件依舊會(huì)變得一團(tuán)糟( 因?yàn)閳F(tuán)隊(duì)會(huì)有新人的加入、即使經(jīng)驗(yàn)老道的開(kāi)發(fā)者也會(huì)有頭腦發(fā)昏的時(shí)候…… )。因此，“不這么寫(xiě)就無(wú)法運(yùn)行”這樣的硬性要求就很有必要了。

云計(jì)算和容器技術(shù)的出現(xiàn)，非常及時(shí)地幫助我們解決了這一難題。云計(jì)算的高彈性和按需分配、容器技術(shù)的快速啟停和隔離，都很好的幫助了我們減少運(yùn)維開(kāi)銷(xiāo)，且對(duì)于不同模塊實(shí)現(xiàn)操作系統(tǒng)級(jí)別的隔離。在這兩種關(guān)鍵技術(shù)出現(xiàn)前后，軟件架構(gòu)的差別如下圖所示：

( 上圖: 單體應(yīng)用 與 微服務(wù)應(yīng)用 )

以 Web 應(yīng)用為例，按照之前的開(kāi)發(fā)方式，我們往往會(huì)選用一個(gè)功能齊全但相當(dāng)復(fù)雜的開(kāi)發(fā)框架( 比如JAVA開(kāi)發(fā)常用的 SpringBoot )，然后在這個(gè)框架的基礎(chǔ)上，根據(jù)開(kāi)發(fā)經(jīng)驗(yàn)和框架的功能將整個(gè)應(yīng)用分層( 比如最常用的表示層、業(yè)務(wù)邏輯層和數(shù)據(jù)資源層的分層方法 )，之后根據(jù)需求分析得出的各個(gè)功能，通過(guò)不同目錄、文件和函數(shù)的方式分別開(kāi)發(fā)，最終一個(gè)完整的 Web 應(yīng)用被開(kāi)發(fā)出來(lái)。其過(guò)程如下圖所示。

( 上圖: 基于框架的軟件開(kāi)發(fā)架構(gòu)網(wǎng)格 )

通過(guò)使用框架，我們把軟件在層次上分為三層，而之后的每個(gè)功能，就相當(dāng)于縱向地添加一個(gè)新列。如果以這種方式看待一個(gè)應(yīng)用，那么我們就可以將任何基于這種開(kāi)發(fā)方法的應(yīng)用看作一個(gè)3行n列的表格或矩陣了。

雖然這種開(kāi)發(fā)方式已經(jīng)非常普及，非常成熟，但其仍有許多有待改進(jìn)的地方。比如：

依賴(lài)和庫(kù)過(guò)于龐雜。理想情況下，我們希望針對(duì)每一個(gè)模塊，多帶帶管理其相應(yīng)的依賴(lài)和庫(kù)，而不是以整個(gè)應(yīng)用作為單位來(lái)管理。

無(wú)法改變層次結(jié)構(gòu)。某種層次結(jié)構(gòu)對(duì)于某些業(yè)務(wù)需求來(lái)說(shuō)很棒，但對(duì)于另外一些也許就顯得不那么合適了。使用這種方式開(kāi)發(fā)，幾乎所有功能都要遵從這種既定的層次開(kāi)發(fā)( 比如寫(xiě) UI、寫(xiě)業(yè)務(wù)邏輯、寫(xiě)數(shù)據(jù)庫(kù)層 )。而對(duì)于目前日漸快速的迭代和敏捷的開(kāi)發(fā)思想，我們需要一種更加靈活輕便的方式進(jìn)行開(kāi)發(fā)。

無(wú)法實(shí)現(xiàn)跨語(yǔ)言開(kāi)發(fā)。我們知道，幾乎每種編程語(yǔ)言都有自己最擅長(zhǎng)的領(lǐng)域。也許某些功能選用其他編程語(yǔ)言的開(kāi)發(fā)效率更高，運(yùn)行效果更好。然而，使用這種方式我們往往只能使用選定的框架所支持的語(yǔ)言。

模塊的獨(dú)立性不足。單純通過(guò)函數(shù)和文件來(lái)進(jìn)行隔離，隔離性仍然不夠。一個(gè)疏忽或是加急上線就會(huì)讓之前良好的高內(nèi)聚低耦合的良好軟件結(jié)構(gòu)灰飛煙滅。因此，我們需要更加底層的機(jī)制來(lái)硬性約束我們實(shí)現(xiàn)“高內(nèi)聚低耦合”，把“應(yīng)該這么做”變?yōu)椤氨仨氝@么做”。

而伴隨著云計(jì)算和容器技術(shù)的發(fā)展，微服務(wù)的出現(xiàn)，恰巧將這些問(wèn)題迎刃而解。

( 上圖: 容器技術(shù)的基本層次結(jié)構(gòu) )

Docker 可以看作是輕量級(jí)的虛擬機(jī)——它可以通過(guò)“容器鏡像”快速啟動(dòng)和停止預(yù)先配置好的相應(yīng)運(yùn)行環(huán)境。每一個(gè)容器都可以被看作一個(gè)獨(dú)立的操作系統(tǒng)，相互隔離，互不干擾。因此，借助docker 我們就可以針對(duì)一個(gè)應(yīng)用中不同的功能，為其獨(dú)立定制運(yùn)行環(huán)境，獨(dú)立裝載依賴(lài)和工具庫(kù)，獨(dú)立運(yùn)行獨(dú)立停止，獨(dú)立升級(jí)，每個(gè)功能可以使用其最適合的編程語(yǔ)言進(jìn)行開(kāi)發(fā)，也將整個(gè)應(yīng)用拘泥于一種框架了。利用 docker 將每個(gè)模塊在操作系統(tǒng)層面進(jìn)行隔離，對(duì)于每個(gè)模塊都可以獨(dú)立管理其生命周期了，這就是“微服務(wù)”中“微”字的具體含義。

基于這種開(kāi)發(fā)方式，每個(gè)功能模塊可以被獨(dú)立開(kāi)發(fā)，獨(dú)立部署，獨(dú)立運(yùn)行，獨(dú)立進(jìn)行版本控制，等等。而對(duì)于規(guī)模比較龐大的系統(tǒng)來(lái)說(shuō)，這種利用微服務(wù)架構(gòu)所開(kāi)發(fā)的應(yīng)用，其天然的優(yōu)勢(shì)就更能體現(xiàn)出來(lái)了——即每個(gè)模塊可以獨(dú)立的團(tuán)隊(duì)由多帶帶負(fù)責(zé)。因此，微服務(wù)開(kāi)發(fā)中的第一個(gè)重點(diǎn)，就是要有非常明確的需求，以及一個(gè)經(jīng)驗(yàn)豐富的架構(gòu)師，在設(shè)計(jì)之初就對(duì)各個(gè)功能模塊進(jìn)行合理的規(guī)劃和拆分。

在整個(gè)應(yīng)用設(shè)計(jì)之初由總設(shè)計(jì)師或架構(gòu)師設(shè)計(jì)好各個(gè)功能模塊后，第二個(gè)重點(diǎn)就來(lái)了：設(shè)計(jì)微服務(wù)中各個(gè)模塊間的調(diào)用接口——通常由 Rest API 或者 gRPC 組成——來(lái)負(fù)責(zé)模塊之間的交互，這就是微服務(wù)的第二個(gè)重點(diǎn)。良好的接口設(shè)計(jì)將會(huì)使你的應(yīng)用結(jié)構(gòu)清晰，開(kāi)發(fā)起來(lái)事半功倍。而且每個(gè)獨(dú)立團(tuán)隊(duì)在開(kāi)發(fā)時(shí)都能感受到明顯的模塊邊界，且可以放心利用模擬數(shù)據(jù)和測(cè)試數(shù)據(jù)進(jìn)行開(kāi)發(fā)( 只要符合接口規(guī)則的數(shù)據(jù)就能用，不用操心其他模塊是如何實(shí)現(xiàn)的 )，從而真正實(shí)現(xiàn)每個(gè)團(tuán)隊(duì)富有效率的并行開(kāi)發(fā)。

利用微服務(wù)架構(gòu)開(kāi)發(fā)除了上述好處之外，在運(yùn)維方面的優(yōu)勢(shì)也非常直觀——我們可以清晰地觀測(cè)到整個(gè)系統(tǒng)的資源瓶頸在何處( 哪個(gè)容器的資源開(kāi)銷(xiāo)最大 )，從而實(shí)現(xiàn)有針對(duì)性的“定向擴(kuò)縮容”。利用微服務(wù)架構(gòu)前后的擴(kuò)縮容機(jī)制如下圖所示意。

( 上圖: 單體應(yīng)用和微服務(wù)應(yīng)用最直觀的差別：定向擴(kuò)縮容 示意圖 )

在看完上面的介紹后，相信飽受單體應(yīng)用折磨的各位讀者已經(jīng)對(duì)微服務(wù)開(kāi)發(fā)已經(jīng)躍躍欲試了。但是，對(duì)于一個(gè)正在運(yùn)行并使用的應(yīng)用來(lái)說(shuō)，完完全全從零開(kāi)始開(kāi)發(fā)并不現(xiàn)實(shí)。對(duì)于一個(gè)已經(jīng)成熟并正在使用的單體應(yīng)用系統(tǒng)來(lái)說(shuō)，我們可以通過(guò)自己的努力，將一個(gè)單體應(yīng)用在幾次迭代過(guò)程中，逐漸改變?yōu)槲⒎?wù)應(yīng)用。如何辦到呢？下面放一張圖片來(lái)幫助您激發(fā)靈感：

( 上圖: 熱帶雨林中的參天大樹(shù)與附著在其上的藤蔓 )

沒(méi)錯(cuò)，就像您所想到的那樣：在這幅圖中，龐大的樹(shù)木代表著我們?cè)械膯误w項(xiàng)目，而樹(shù)外所覆蓋著的藤蔓就象征著微服務(wù)組件。在將您的單體應(yīng)用微服務(wù)化時(shí)，也可以采用這種方式，即：新的功能使用微服務(wù)架構(gòu)來(lái)開(kāi)發(fā)，通過(guò)對(duì)原有的單體應(yīng)用暴露 IP 和端口號(hào)的方式供其進(jìn)行調(diào)用和使用。

利用這種方式，您之后新開(kāi)發(fā)的功能所對(duì)應(yīng)的軟件實(shí)體就都是基于微服務(wù)架構(gòu)的了。這樣隨著時(shí)間的推移和版本的逐漸迭代，采用微服務(wù)架構(gòu)所開(kāi)發(fā)的部分所占比例越來(lái)越大，最后原來(lái)的單體應(yīng)用也逐漸變?yōu)榱苏麄€(gè)應(yīng)用中的一個(gè)獨(dú)立服務(wù)，您的軟件架構(gòu)就徹底地完成了微服務(wù)化。

這種改造方式來(lái)源于 Chris Richardson 的系列博文中的一篇，如果您對(duì)這方面內(nèi)容感興趣的話，歡迎您移步其博客一探究竟( 博客的中文翻譯鏈接: https://www.jianshu.com/p/29f... )。由于內(nèi)容過(guò)多，在此不再展開(kāi)討論一一贅述。

顯然不是，技術(shù)的發(fā)展從來(lái)沒(méi)有止境，也不存在止鏡。微服務(wù)的出現(xiàn)，雖然解決了傳統(tǒng)軟件開(kāi)發(fā)結(jié)構(gòu)龐大、模塊復(fù)雜等諸多難點(diǎn)，但是解決了原有的問(wèn)題后，新的問(wèn)題又浮出了水面：微服務(wù)應(yīng)用的每個(gè)基本單元之間調(diào)用關(guān)系復(fù)雜、網(wǎng)絡(luò)位置處于動(dòng)態(tài)變化、且每個(gè)組件的生命周期都各自獨(dú)立，因此難以實(shí)現(xiàn)統(tǒng)一的管理。

這里說(shuō)的可能有些抽象，那么就為大家舉一個(gè)小例子：請(qǐng)大家設(shè)想一個(gè)簡(jiǎn)單的場(chǎng)景：每一個(gè)微服務(wù)組件都有一個(gè)自己獨(dú)有的網(wǎng)絡(luò)位置( 在因特網(wǎng)中就是我們最常用的 IP 和端口號(hào) )，以此來(lái)唯一確定一個(gè)服務(wù)；其他服務(wù)若想調(diào)用本服務(wù)，就需要知道該服務(wù)的 IP 和端口號(hào)，以此對(duì)其發(fā)送網(wǎng)絡(luò)請(qǐng)求。

細(xì)心的朋友可能已經(jīng)察覺(jué)到問(wèn)題了：對(duì)于一個(gè)微服務(wù)架構(gòu)的應(yīng)用場(chǎng)景，微服務(wù)的每一個(gè)組件都是不斷處于動(dòng)態(tài)擴(kuò)縮容的狀態(tài)中的，可能上一秒這個(gè) IP 和端口號(hào)還對(duì)應(yīng)著相應(yīng)的組件，下一秒這個(gè)組件就由于當(dāng)前訪問(wèn)量的下降而被節(jié)約成本，自動(dòng)地縮容釋放掉了。如果這時(shí)其他服務(wù)再來(lái)訪問(wèn)這個(gè) IP 和端口號(hào)，那一定會(huì)出現(xiàn)找不到服務(wù)等各種故障。

( 上圖: 多變的網(wǎng)絡(luò)位置是微服務(wù)管理中的一大難題 )

架構(gòu)改變所帶來(lái)的諸如此類(lèi)的問(wèn)題還有許多，在此就不一一列舉了。準(zhǔn)備將自己的軟件架構(gòu)進(jìn)行微服務(wù)化的朋友們需要三思：改變一種軟件架構(gòu)可能會(huì)解決許多曾經(jīng)的架構(gòu)所存在的問(wèn)題，但同時(shí)也會(huì)帶來(lái)很多原有架構(gòu)不會(huì)出現(xiàn)的新問(wèn)題。

不過(guò)幸好微服務(wù)架構(gòu)已經(jīng)有不少?lài)?guó)內(nèi)外的大公司和優(yōu)秀團(tuán)隊(duì)作為先驅(qū)，率先摸著石頭過(guò)了一次河，并且告訴了我們?cè)S多過(guò)河的寶貴經(jīng)驗(yàn)，甚至已經(jīng)有許多工具和開(kāi)源項(xiàng)目被開(kāi)發(fā)出來(lái)，幫助我們解決剛才分析到的種種問(wèn)題了。

在目前種種微服務(wù)場(chǎng)景的解決方案中，有兩種是使用最為普遍、同時(shí)也廣受好評(píng)的。它們分別是較早出現(xiàn)的 Spring Cloud 框架，以及近幾年微服務(wù)領(lǐng)域最為流行的 Service Mesh 微服務(wù)管理框架。由于 Service Mesh 所帶來(lái)的“業(yè)務(wù)代碼零侵入”、“直接與容器管理框架(如 K8s )集成”等諸多優(yōu)點(diǎn)，因此基于 Service Mesh 的微服務(wù)開(kāi)發(fā)和蔚云方式正在逐漸成為主流，特別是 Google 宣布了其 Istio 項(xiàng)目可以與 K8s 完美集成后，國(guó)內(nèi)外社區(qū)的開(kāi)發(fā)者對(duì) Service Mesh 的發(fā)展更是翹首以盼。下面就對(duì) Service Mesh 進(jìn)行一下簡(jiǎn)單的介紹。

“A service mesh is a dedicated infrastructure layer for handling service-to-service communication. “ —— William Morgan( Founder of Service Mesh )

Service Mesh 是一個(gè)專(zhuān)注于處理服務(wù)間通信的基礎(chǔ)設(shè)施層。
云原生應(yīng)用有著復(fù)雜的服務(wù)拓?fù)洌?Service Mesh 保證請(qǐng)求可以在這些拓?fù)渲锌煽康卮┧蟆Ｔ趯?shí)際應(yīng)用當(dāng)中，Service Mesh 通常是由一系列輕量級(jí)的網(wǎng)絡(luò)代理組成的，它們與應(yīng)用程序部署在一起，但應(yīng)用程序不需要知道它們的存在。

( 上圖: Service Mesh 示意圖——幫助您管理錯(cuò)誤復(fù)雜的微服務(wù)應(yīng)用 )

Service Mesh 的概念最早由前 twitter 的基礎(chǔ)設(shè)施工程師 William Morgan 于 2017 年 4 月 25 日提出。雖然在此之前，微服務(wù)領(lǐng)域也有類(lèi)似的概念被提出或用于開(kāi)發(fā)項(xiàng)目，但在業(yè)界始終沒(méi)有一個(gè)統(tǒng)一的名稱(chēng)。 William Morgan 在自己的博文 "What’s a service mesh? And why do I need one?" 中正式給 Service Mesh 做出了權(quán)威的定義。至此，"Service Mesh" 這個(gè)名詞正式出現(xiàn)在各大公司以及技術(shù)社區(qū)的視野中。

隨著云計(jì)算的普及，越來(lái)越多的開(kāi)發(fā)者和企業(yè)開(kāi)始使用“微服務(wù)”的開(kāi)發(fā)模式。這種開(kāi)發(fā)模式擁有諸如耦合度低、跨語(yǔ)言開(kāi)發(fā)、更小粒度擴(kuò)容等許多優(yōu)勢(shì)，但同樣也面臨著許多挑戰(zhàn)，就如我們上文所分析的那樣。

Service Mesh 從出現(xiàn)至今總共經(jīng)歷了三個(gè)階段：微服務(wù)初期、Sidecar 時(shí)期和 Service Mesh 時(shí)期。

在微服務(wù)初期( 2015年前 )開(kāi)發(fā)微服務(wù)應(yīng)用的過(guò)程中，我們需要重復(fù)性地處理一系列基礎(chǔ)工作，比如：服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)、得到服務(wù)實(shí)例后的負(fù)載均衡、熔斷機(jī)制等。這些工作在 Service Mesh 出現(xiàn)之前統(tǒng)統(tǒng)都要開(kāi)發(fā)人員在項(xiàng)目中用代碼解決并實(shí)現(xiàn)，導(dǎo)致應(yīng)用程序中加入了大量的非功能性代碼。即使使用類(lèi)似 Netflix OSS 的庫(kù)和 Spring Cloud 的框架，開(kāi)發(fā)人員依然面臨著需掌握內(nèi)容多、技術(shù)門(mén)檻高等諸多困難。

( 上圖: Sidecar ，中文意思為摩托車(chē)的跨斗，不由贊嘆命名的非常生動(dòng) )

"Sidecar" 這個(gè)詞，本人使用 Google 搜索引擎同時(shí)檢索 sidecar 和 microservices 這兩個(gè)關(guān)鍵字并按時(shí)間順序排序，最早出現(xiàn)的檢索結(jié)果是在 2014 年 5 月 14 日的這篇演講中。根據(jù)本人查閱的資料顯示，"Sidecar" 這個(gè)名詞最早由 Netflix 提出并被用于 Eureka 項(xiàng)目。由于這個(gè)項(xiàng)目的廣泛應(yīng)用，故在此之后，凡是微服務(wù)中“用于端對(duì)端通信的、被多帶帶分離出來(lái)的“組件，就都被稱(chēng)為 "Sidecar" 了。

仔細(xì)分析上述一系列的重復(fù)性工作，我們可以發(fā)現(xiàn)，這些工作幾乎全部集中在處理各個(gè)服務(wù)間的通信問(wèn)題。那么，為何我們不把這些工作從業(yè)務(wù)邏輯中抽離出來(lái)，使其專(zhuān)注于服務(wù)間通信，并形成多帶帶的組件呢？
Sidecar 模式，即在微服務(wù)中將關(guān)于服務(wù)通訊的功能抽離出來(lái)，并作為一個(gè)多帶帶的組件運(yùn)行在微服務(wù)中。這種在微服務(wù)中獨(dú)立負(fù)責(zé)端對(duì)端通信的組件，我們稱(chēng)之為 Sidecar 。這種在微服務(wù)中將業(yè)務(wù)邏輯與服務(wù)通信解藕，并分離為兩個(gè)獨(dú)立運(yùn)行組件的做法，正是 Service Mesh 概念的雛形。
但在這個(gè)階段，每個(gè)微服務(wù)中的 Sidecar 還無(wú)法通用，即這個(gè)微服務(wù)的 Sidecar 沒(méi)有辦法拆出來(lái)給另一個(gè)微服務(wù)使用。

Service Mesh 在 Sidecar 模式的基礎(chǔ)上更進(jìn)一步。Service Mesh 的定義——一個(gè)專(zhuān)注于處理服務(wù)間通信的基礎(chǔ)設(shè)施層——站在開(kāi)發(fā)者的角度來(lái)講，就是在每一個(gè)微服務(wù)中將用于通信的部分從業(yè)務(wù)中徹底解藕，應(yīng)用程序甚至不需要知道它們的存在。在 Service Mesh 中，每個(gè)微服務(wù)至少含有兩個(gè)組件：一個(gè)用于處理業(yè)務(wù)功能的“應(yīng)用程序”和一個(gè)專(zhuān)職處理服務(wù)間通信的“ Sidecar ”( 類(lèi)似網(wǎng)絡(luò)代理 )。

Service Mesh 的愿景是希望開(kāi)發(fā)者再也不需要將精力花費(fèi)在服務(wù)通信上。服務(wù)通信由每個(gè)微服務(wù)的 Sidecar 負(fù)責(zé)，而 Sidecar 由專(zhuān)門(mén)的項(xiàng)目來(lái)接管。目前，許多被熟知的項(xiàng)目都可以被我們當(dāng)作 Sidecar 來(lái)運(yùn)用，比如 Envoy 、 HAProxy 和 Nginx 。

使用了 Service Mesh 之后，開(kāi)發(fā)團(tuán)隊(duì)和運(yùn)維團(tuán)隊(duì)就可以更加明確的劃清自己的職責(zé)范圍——開(kāi)發(fā)團(tuán)隊(duì)專(zhuān)注于業(yè)務(wù)的開(kāi)發(fā)，而運(yùn)維團(tuán)隊(duì)只需關(guān)注微服務(wù)中的 Sidecar 就可以明確地了解到每個(gè)微服務(wù)的健康情況和各種指標(biāo)。

( 上圖: “Service Mesh”一詞成為技術(shù)術(shù)語(yǔ)，首次在公眾場(chǎng)合亮相  )

Service Mesh 的設(shè)計(jì)理念和作用

隨著云原生應(yīng)用的崛起，Service Mesh 逐漸成為一個(gè)獨(dú)立的基礎(chǔ)設(shè)施層。在云原生模型里，一個(gè)應(yīng)用可以由數(shù)百個(gè)服務(wù)組成，每個(gè)服務(wù)可能有數(shù)千個(gè)實(shí)例，而每個(gè)實(shí)例可能會(huì)持續(xù)地發(fā)生變化。服務(wù)間通信不僅異常復(fù)雜，而且也是運(yùn)行時(shí)行為的基礎(chǔ)。管理好服務(wù)間通信對(duì)于保證端到端的性能和可靠性來(lái)說(shuō)是非常重要的。

Service Mesh 實(shí)際上就是處于 TCP/IP 之上的一個(gè)抽象層，它假設(shè)底層的 L3/L4 網(wǎng)絡(luò)能夠點(diǎn)對(duì)點(diǎn)地傳輸字節(jié)（當(dāng)然，它也假設(shè)網(wǎng)絡(luò)環(huán)境是不可靠的，所以 Service Mesh 也必須具備處理網(wǎng)絡(luò)故障的能力）。

從某種程度上說(shuō)，Service Mesh 有點(diǎn)類(lèi)似 TCP/IP 。TCP 對(duì)網(wǎng)絡(luò)端點(diǎn)間傳輸字節(jié)的機(jī)制進(jìn)行了抽象，而Service Mesh則是對(duì)服務(wù)節(jié)點(diǎn)間請(qǐng)求的路由機(jī)制進(jìn)行了抽象。Service Mesh 不關(guān)心消息體是什么，也不關(guān)心它們是如何編碼的。應(yīng)用程序的目標(biāo)是“將某些東西從A傳送到B”，而 Service Mesh 所要做的就是實(shí)現(xiàn)這個(gè)目標(biāo)，并處理傳送過(guò)程中可能出現(xiàn)的任何故障。

與TCP不同的是，Service Mesh有著更高的目標(biāo)：為應(yīng)用運(yùn)行時(shí)提供統(tǒng)一的、應(yīng)用層面的可見(jiàn)性和可控性。通過(guò)每個(gè)微服務(wù)中的 Sidecar ，Service Mesh 得以將服務(wù)間通信從底層的基礎(chǔ)設(shè)施中分離出來(lái)，讓它成為整個(gè)生態(tài)系統(tǒng)的一等公民——它不再是單純的基礎(chǔ)設(shè)施，更可以被監(jiān)控、托管和控制。

盡管 Service Mesh 在云原生系統(tǒng)方面的應(yīng)用已經(jīng)有了快速的增長(zhǎng)，但仍然存在巨大的提升空間。服務(wù)發(fā)現(xiàn)和訪問(wèn)策略在云原生環(huán)境中仍顯初級(jí)，而 Service Mesh 毫無(wú)疑問(wèn)將成為這方面不可或缺的基礎(chǔ)。就像 TCP/IP 作為互聯(lián)網(wǎng)的基礎(chǔ)一樣，Service Mesh 將在微服務(wù)的底層基礎(chǔ)設(shè)施這條路上更進(jìn)一步。

本文主要介紹了兩個(gè)關(guān)鍵點(diǎn)：當(dāng)下最為流行的一種軟件開(kāi)發(fā)架構(gòu)——微服務(wù)架構(gòu)、以及解決微服務(wù)架構(gòu)帶來(lái)的種種問(wèn)題的微服務(wù)管理模型——Service Mesh(服務(wù)網(wǎng)格)模型。

在使用微服務(wù)架構(gòu)開(kāi)發(fā)應(yīng)用的初期，大家一定會(huì)沉醉于其清晰的模塊邊界和獨(dú)立運(yùn)行所帶來(lái)的種種便利。然而，這并不是說(shuō)微服務(wù)應(yīng)用就已經(jīng)十全十美了。隨著一個(gè)龐大的單體應(yīng)用被拆分為細(xì)碎的各個(gè)微小模塊，如果對(duì)它們進(jìn)行有效的管理就成為了新的挑戰(zhàn)。畢竟，一個(gè)中等體量的應(yīng)用被微服務(wù)化后，幾百個(gè)小模塊同時(shí)運(yùn)行是常有的事兒。那么，如何控制服務(wù)之間的調(diào)用？如何定位這些服務(wù)( 你知道，在這種場(chǎng)景下手動(dòng)修改配置文件指定其他服務(wù)的 IP 和 port 已經(jīng)不現(xiàn)實(shí)了 )？如何將出現(xiàn)錯(cuò)誤的應(yīng)用及時(shí)熔斷？這都是亟待我們解決的事情，也是目前微服務(wù)架構(gòu)所發(fā)展的主要方向。

在熟練運(yùn)用 Docker 后，我們可以繼續(xù)去學(xué)習(xí) Kubernetes，一款由 Google 和 IBM 共同開(kāi)發(fā)的開(kāi)源“容器集群管理框架”，類(lèi)似于控制容器的“操作系統(tǒng)”。

而微服務(wù)所面臨的上述種種問(wèn)題，目前我們可以借助同樣由 Google 開(kāi)發(fā)的 Istio(服務(wù)網(wǎng)格的一種) 來(lái)解決，諸如服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)、服務(wù)治理、流量管理和容錯(cuò)機(jī)制等等。其基本層次關(guān)系如下圖所示。

( 上圖: 自己整理的“目前微服務(wù)架構(gòu)的技術(shù)棧”，希望各位讀者有所幫助 )

希望本篇文章能夠成為您開(kāi)展微服務(wù)相關(guān)工作的參考，為您了解為服務(wù)理念、轉(zhuǎn)型微服務(wù)架構(gòu)提供幫助。文章中如果存在遺漏或錯(cuò)誤，也非常歡迎您指出，非常期待與您的交流與討論。