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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

( 上圖: 自己整理的“目前微服務(wù)架構(gòu)的技術(shù)?！保Ｍ魑蛔x者有所幫助 )

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