有哪些微服務(wù)架構(gòu)設(shè)計(jì)的問(wèn)題

這篇文章主要講解了“有哪些微服務(wù)架構(gòu)設(shè)計(jì)的問(wèn)題”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來(lái)研究和學(xué)習(xí)“有哪些微服務(wù)架構(gòu)設(shè)計(jì)的問(wèn)題”吧！

數(shù)據(jù)庫(kù)拆分是否和微服務(wù)必須1對(duì)1

在最早談微服務(wù)架構(gòu)的時(shí)候我們就談到。要確保每個(gè)微服務(wù)都獨(dú)立自治和松耦合，那么微服務(wù)從數(shù)據(jù)庫(kù)到邏輯層到前臺(tái)全部都要進(jìn)行縱向拆分。

即數(shù)據(jù)庫(kù)的拆分是整個(gè)微服務(wù)架構(gòu)設(shè)計(jì)中的一個(gè)關(guān)鍵內(nèi)容。

而這里有一個(gè)關(guān)鍵思考就是，在微服務(wù)實(shí)踐中你會(huì)看到，實(shí)際上你上層的微服務(wù)組件的拆分相當(dāng)來(lái)說(shuō)會(huì)更加細(xì)，一個(gè)不算復(fù)雜的業(yè)務(wù)系統(tǒng)拆分到20到30個(gè)微服務(wù)組件都是正常情況。

而對(duì)于數(shù)據(jù)庫(kù)也拆分為20個(gè)獨(dú)立的DataBase顯然不合理。

這個(gè)一方面是增加了數(shù)據(jù)庫(kù)本身的管理復(fù)雜度，同時(shí)由于數(shù)據(jù)庫(kù)的太細(xì)拆分也引入了更多的分布式事務(wù)處理問(wèn)題，跨庫(kù)數(shù)據(jù)關(guān)聯(lián)查詢不方便等問(wèn)題。因此在這里，最好的建議是我們引入一個(gè)業(yè)務(wù)域的概念，即：

可以按業(yè)務(wù)域來(lái)進(jìn)行數(shù)據(jù)庫(kù)拆分，每一個(gè)業(yè)務(wù)域相當(dāng)獨(dú)立并對(duì)應(yīng)一個(gè)獨(dú)立數(shù)據(jù)庫(kù)，但是業(yè)務(wù)域里面本身可以有多個(gè)上層的微服務(wù)模塊組件。同一個(gè)業(yè)務(wù)域里面的微服務(wù)仍然通過(guò)注冊(cè)中心進(jìn)行訪問(wèn)和調(diào)用。

即同一個(gè)業(yè)務(wù)域里面的微服務(wù)在邏輯層本身還是解耦的，只能夠通過(guò)API接口訪問(wèn)調(diào)用，以方便分布式部署，但是數(shù)據(jù)庫(kù)層本身不拆分，共享同一個(gè)數(shù)據(jù)庫(kù)。

比如在我們的項(xiàng)目里面，我們會(huì)將4A和流程引擎兩個(gè)微服務(wù)共享一個(gè)數(shù)據(jù)庫(kù)，將費(fèi)用報(bào)賬，差旅報(bào)賬，借款報(bào)賬等獨(dú)立微服務(wù)共享一個(gè)報(bào)賬數(shù)據(jù)庫(kù)。

在這種方式下雖然沒(méi)有實(shí)現(xiàn)數(shù)據(jù)庫(kù)的徹底解耦，但是通過(guò)在邏輯層的微服務(wù)拆分和解耦，我們可以實(shí)現(xiàn)微服務(wù)部署包的更加細(xì)粒度管理。同時(shí)當(dāng)存在業(yè)務(wù)邏輯變更的時(shí)候，我們也僅僅需要變更相應(yīng)的微服務(wù)模塊，做到變更影響最小化目的。

是否使用SpringCloud全家桶

可以看到如果采用SpingCLoud微服務(wù)技術(shù)開(kāi)發(fā)框架，那么對(duì)應(yīng)服務(wù)注冊(cè)中心，限流熔斷，微服務(wù)網(wǎng)關(guān)，負(fù)載均衡，配置中心，安全，聲明式調(diào)用所有能力全部提供。

你需要做的就是采用SpringBoot框架來(lái)開(kāi)發(fā)一個(gè)個(gè)微服務(wù)組件即可。

當(dāng)然在我們實(shí)施的項(xiàng)目里面也存在另外一種方式，即只使用SpringBoot框架進(jìn)行單個(gè)微服務(wù)組件的開(kāi)發(fā)，其次再去組合和集成當(dāng)前業(yè)界主流的微服務(wù)開(kāi)源技術(shù)組件產(chǎn)品。

• 服務(wù)注冊(cè)中心：阿里的Nacos注冊(cè)中心

• 服務(wù)配置中心：攜程開(kāi)源的Apollo配置中心

• 限流熔斷：阿里的Sentinel

• 服務(wù)鏈監(jiān)控：直接對(duì)SkyWalking服務(wù)鏈監(jiān)控進(jìn)行集成

• API網(wǎng)關(guān)：采用Kong網(wǎng)關(guān)來(lái)實(shí)現(xiàn)API集成和管控治理

當(dāng)然你也可能完全不采用SpringBoot，而是走更加高效的支持RPC調(diào)用的Dubbo開(kāi)源框架進(jìn)行微服務(wù)組件的開(kāi)發(fā)和集成。

如果從微服務(wù)技術(shù)平臺(tái)的構(gòu)建和快速開(kāi)發(fā)上來(lái)說(shuō)，當(dāng)然是你直接選擇SpingCLoud整個(gè)開(kāi)源框架和組件來(lái)實(shí)現(xiàn)最簡(jiǎn)單，而且基本也完全能夠滿足需求。對(duì)于日常傳統(tǒng)企業(yè)應(yīng)用來(lái)說(shuō)，性能完全足夠，也不存在說(shuō)性能無(wú)法滿足的情況。畢竟不是所有項(xiàng)目都類(lèi)似互聯(lián)網(wǎng)存在海量數(shù)據(jù)訪問(wèn)和大并發(fā)下的高性能要求。

如果采用各種開(kāi)源組件，技術(shù)框架自己集成，那么肯定是存在前期的基礎(chǔ)技術(shù)平臺(tái)搭建，集成驗(yàn)證等相關(guān)的工作量。同時(shí)本身也會(huì)增加整個(gè)基礎(chǔ)架構(gòu)的復(fù)雜度。比如你采用了Nacos注冊(cè)中心，對(duì)于注冊(cè)中心你同樣需要去進(jìn)行集群化配置，以滿足高可用性的需求。

綜合以上描述，簡(jiǎn)單總結(jié)就是：

• 如果圖省事，沒(méi)有太高性能要求，直接采用SpingCloud整體框架

• 如果性能要求高，自己技術(shù)儲(chǔ)備足夠，可以自己進(jìn)行開(kāi)源技術(shù)組件集成

那么在我們實(shí)際的微服務(wù)架構(gòu)實(shí)施項(xiàng)目里面，我們會(huì)看到第三個(gè)場(chǎng)景。

比如一個(gè)集團(tuán)型企業(yè)，本身一個(gè)計(jì)劃管理系統(tǒng)進(jìn)行前期架構(gòu)設(shè)計(jì)后拆分為10個(gè)微服務(wù)模塊，需要招標(biāo)三家軟件開(kāi)發(fā)商來(lái)定制開(kāi)發(fā)。對(duì)開(kāi)發(fā)商要求也是進(jìn)行微服務(wù)架構(gòu)化開(kāi)發(fā)。

在這個(gè)時(shí)候我們就發(fā)現(xiàn)一個(gè)關(guān)鍵問(wèn)題，各個(gè)廠家自己采用微服務(wù)架構(gòu)沒(méi)有關(guān)系，但是從整個(gè)大應(yīng)用角度我們實(shí)際上是存在對(duì)10個(gè)微服務(wù)模塊進(jìn)行統(tǒng)一的微服務(wù)治理和管控需求的。類(lèi)似API網(wǎng)關(guān)，類(lèi)似服務(wù)配置中心等。

而這些組件就不太適合再使用SpingCLoud里面的技術(shù)組件，而是需要從單個(gè)微服務(wù)架構(gòu)體系里面提取出來(lái)，形成一個(gè)共享的服務(wù)能力。在這種時(shí)候，我們的建議就是盡量去集成和使用第三方的其它開(kāi)源技術(shù)組件來(lái)進(jìn)行管控治理。

比如上面這個(gè)例子，三家供應(yīng)商可以保留最基礎(chǔ)的配置。

即某家供應(yīng)商開(kāi)發(fā)A，B，C三個(gè)微服務(wù)模塊的時(shí)候，可以啟用Eureka+Feign+Ribbon來(lái)完成自己開(kāi)發(fā)的三個(gè)組件的內(nèi)部集成，API接口注冊(cè)和調(diào)用。

但是三個(gè)供應(yīng)商之間的模塊要協(xié)同的時(shí)候則統(tǒng)一使用外部搭建的共享技術(shù)服務(wù)平臺(tái)。

• 比如API接口注冊(cè)到統(tǒng)一的Kong網(wǎng)關(guān)上，Kong網(wǎng)關(guān)由平臺(tái)集成商管理

• 比如涉及到三家的一些共性配置由SpingCloud Config統(tǒng)一轉(zhuǎn)到Apollo配置中心

因此再簡(jiǎn)單總結(jié)下就是，評(píng)估是否采用SpingCLoud全套方案的時(shí)候，還需要評(píng)估是否存在跨有明確邊界的團(tuán)隊(duì)協(xié)同的情況?；蛘呤欠翊嬖陬?lèi)似集團(tuán)型企業(yè)，多個(gè)業(yè)務(wù)系統(tǒng)微服務(wù)大集成的情況。如果存在，那么一些共性技術(shù)服務(wù)能力就必須抽出獨(dú)立建設(shè)。

開(kāi)發(fā)團(tuán)隊(duì)如何拆分的問(wèn)題？

我們?cè)趯?shí)施微服務(wù)和云原生轉(zhuǎn)型的時(shí)候，你看起來(lái)好像是IT系統(tǒng)分為了多個(gè)微服務(wù)，但是更加重要的是業(yè)務(wù)組織和團(tuán)隊(duì)本身需要分解為微服務(wù)，分解高度獨(dú)立自治的業(yè)務(wù)團(tuán)隊(duì)。

每個(gè)團(tuán)隊(duì)都配置獨(dú)立的前后端開(kāi)發(fā)，需求，測(cè)試人員高度自治。

那么在拆分為多為業(yè)務(wù)團(tuán)隊(duì)后，如何保證原來(lái)一個(gè)大應(yīng)用和產(chǎn)品的概念一致性或架構(gòu)完整性。在這里我們提出，對(duì)于整體的產(chǎn)品規(guī)劃和總體架構(gòu)設(shè)計(jì)仍然需要集中化統(tǒng)一進(jìn)行，然后在拆分和分配到各個(gè)微服務(wù)開(kāi)發(fā)團(tuán)隊(duì)。

那么這里的架構(gòu)設(shè)計(jì)包括哪些內(nèi)容呢？具體如下：

• 各個(gè)微服務(wù)模塊的功能列表清單

• 各個(gè)微服務(wù)模塊的接口清單

• 數(shù)據(jù)庫(kù)的拆分和數(shù)據(jù)表的Owner歸屬

以上三點(diǎn)就是最重要的架構(gòu)設(shè)計(jì)需要提前進(jìn)行的點(diǎn)。這個(gè)清楚后即可以分配到各個(gè)微服務(wù)團(tuán)隊(duì)，那么微服務(wù)團(tuán)隊(duì)高度自治和扁平化，各個(gè)團(tuán)隊(duì)之間之間進(jìn)行協(xié)同和溝通，而不需要再通過(guò)架構(gòu)師來(lái)協(xié)同增加溝通路徑。

即產(chǎn)品規(guī)劃和架構(gòu)師很類(lèi)似微服務(wù)架構(gòu)里面的注冊(cè)控制中心的職責(zé)。這也是我們常說(shuō)的技術(shù)上的微服務(wù)拆分，實(shí)際上真正先行的業(yè)務(wù)組織團(tuán)隊(duì)的架構(gòu)調(diào)整和職責(zé)拆分。

那么這個(gè)開(kāi)發(fā)團(tuán)隊(duì)如何拆？

首先不可能你拆分了20個(gè)微服務(wù)，就拆分出20個(gè)開(kāi)發(fā)團(tuán)隊(duì)。這里面仍然有域劃分的概念在里面，即對(duì)20個(gè)微服務(wù)還要進(jìn)行歸類(lèi)，以方面拆分。

• 方式1：按縱向業(yè)務(wù)域進(jìn)行歸類(lèi)，參考我們前面數(shù)據(jù)庫(kù)拆分方法

• 方式2：按橫向分層歸類(lèi)，比如平臺(tái)層團(tuán)隊(duì)，中臺(tái)層團(tuán)隊(duì)，前臺(tái)和APP應(yīng)用團(tuán)隊(duì)

在團(tuán)隊(duì)拆分后，我們可以看到每一個(gè)開(kāi)發(fā)小組必須配置前端開(kāi)發(fā)，后端開(kāi)發(fā)和測(cè)試人員。對(duì)于需求可以統(tǒng)一進(jìn)行配置不拆分到開(kāi)發(fā)組。當(dāng)然也可以每個(gè)開(kāi)發(fā)組配置一個(gè)需求細(xì)化人員，而僅僅在整個(gè)大團(tuán)隊(duì)配置產(chǎn)品經(jīng)理出產(chǎn)品需求。對(duì)產(chǎn)品需求的細(xì)化還是到開(kāi)發(fā)組內(nèi)部完成。

為何如此強(qiáng)調(diào)開(kāi)發(fā)團(tuán)隊(duì)要拆？

簡(jiǎn)單來(lái)說(shuō)，就是各個(gè)開(kāi)發(fā)團(tuán)隊(duì)內(nèi)部的工作應(yīng)該是對(duì)其它開(kāi)發(fā)團(tuán)隊(duì)透明不可見(jiàn)的。開(kāi)發(fā)團(tuán)隊(duì)之間高度直治，只能夠通過(guò)粗粒度的接口交付。

如果開(kāi)發(fā)團(tuán)隊(duì)本身不拆分，你會(huì)看到，一個(gè)開(kāi)發(fā)團(tuán)隊(duì)管理多個(gè)微服務(wù)模塊的時(shí)候，我們?cè)谇懊嬷朴喌母鞣N微服務(wù)開(kāi)發(fā)規(guī)范，規(guī)約等很容易就被破壞，而這些事后審計(jì)和修改都會(huì)花費(fèi)大量的時(shí)間進(jìn)行變更和返工。

舉個(gè)簡(jiǎn)單的例子，拆分為2個(gè)DataBase庫(kù)后，同一個(gè)開(kāi)發(fā)人員管理的時(shí)候，往往就省事的通過(guò)兩個(gè)庫(kù)間的跨庫(kù)關(guān)聯(lián)查詢來(lái)解決問(wèn)題，而這在微服務(wù)開(kāi)發(fā)規(guī)約里面是不允許的。

當(dāng)然從軟件企業(yè)本身的IT治理管控來(lái)說(shuō)，這也是最好的方案，對(duì)于一個(gè)大項(xiàng)目或大應(yīng)用系統(tǒng)，并不是每個(gè)開(kāi)發(fā)人員都能夠看到所有項(xiàng)目模塊源代碼，其它非自己Owner的組件只能夠消費(fèi)和使用接口，其它內(nèi)容都是不可見(jiàn)。

對(duì)于服務(wù)注冊(cè)中心和API網(wǎng)關(guān)選擇

對(duì)于服務(wù)注冊(cè)中心和API網(wǎng)關(guān)，在前面我有專(zhuān)門(mén)文章詳細(xì)分析。

什么時(shí)候需要使用API網(wǎng)關(guān)？

如果一個(gè)微服務(wù)架構(gòu)下，雖然不會(huì)外部的其它應(yīng)用進(jìn)行交互和集成，但是整個(gè)應(yīng)用本身存在APP應(yīng)用端，而APP應(yīng)用端通過(guò)前后端分析開(kāi)發(fā)，同時(shí)需要通過(guò)互聯(lián)網(wǎng)訪問(wèn)。本身存在需要一個(gè)統(tǒng)一訪問(wèn)API訪問(wèn)入口，同時(shí)也需要考慮和內(nèi)部微服務(wù)模塊進(jìn)一步進(jìn)行安全隔離。

當(dāng)我們談到這里的時(shí)候，你會(huì)發(fā)現(xiàn)我們常說(shuō)的API網(wǎng)關(guān)的服務(wù)代理或透?jìng)髂芰?，?shí)際和我們常說(shuō)的Ngnix反向代理或路由是一個(gè)意思。

如果你僅僅是為了統(tǒng)一API接口的訪問(wèn)出口，并考慮類(lèi)似DMZ區(qū)的安全隔離，那么在你架構(gòu)前期完全不需要馬上實(shí)施API網(wǎng)關(guān)，直接采用Ngnix進(jìn)行服務(wù)路由代理即可。因?yàn)樵谶@種架構(gòu)下，API接口消費(fèi)端，提供端全部是一個(gè)開(kāi)發(fā)團(tuán)隊(duì)開(kāi)發(fā)，各種問(wèn)題分析排查都相當(dāng)方便，類(lèi)似API接口安全訪問(wèn)等也可以通過(guò)JWT，Auth3.0等統(tǒng)一實(shí)現(xiàn)，而且這個(gè)過(guò)程也并不復(fù)雜。

能力開(kāi)放或多應(yīng)用外部集成對(duì)API管控治理需要

但是當(dāng)我們面臨是和多個(gè)外部應(yīng)用集成，或者說(shuō)將自己的API接口服務(wù)能力開(kāi)放給外部多個(gè)合作伙伴使用的時(shí)候，這個(gè)時(shí)候?qū)τ贏PI接口的管控治理要求自然增加。

即在常規(guī)的服務(wù)代理路由基礎(chǔ)上，需要增加類(lèi)似負(fù)載均衡，安全，日志，限流熔斷等各種能力，而且我們不希望這些能力在API接口開(kāi)發(fā)的時(shí)候考慮，而是希望這些能力是在API接入到網(wǎng)關(guān)的時(shí)候統(tǒng)一靈活配置來(lái)實(shí)現(xiàn)管控。

那么這個(gè)時(shí)候使用API網(wǎng)關(guān)作用就體現(xiàn)出來(lái)。

多個(gè)開(kāi)發(fā)團(tuán)隊(duì)協(xié)同，服務(wù)治理標(biāo)準(zhǔn)化需要

這個(gè)是我理解的需要API網(wǎng)關(guān)的第二個(gè)場(chǎng)景，這個(gè)有點(diǎn)類(lèi)似于傳統(tǒng)IT架構(gòu)下對(duì)ESB服務(wù)總線的需求。當(dāng)存在多個(gè)開(kāi)發(fā)團(tuán)隊(duì)的時(shí)候，我們就需要對(duì)各個(gè)開(kāi)發(fā)團(tuán)隊(duì)注冊(cè)和接入的API接口服務(wù)進(jìn)行統(tǒng)一管理，而這個(gè)時(shí)候就需要有API網(wǎng)關(guān)來(lái)實(shí)現(xiàn)。

即跨開(kāi)發(fā)團(tuán)隊(duì)的API接口集成交付的統(tǒng)一管控都由API網(wǎng)關(guān)來(lái)復(fù)制，包括安全，日志審計(jì)，流量控制等，這些內(nèi)容在多團(tuán)隊(duì)協(xié)同的時(shí)候不可能再依賴單個(gè)團(tuán)隊(duì)內(nèi)部的一些技術(shù)，開(kāi)發(fā)規(guī)范約定，而是需要有一個(gè)統(tǒng)一的標(biāo)準(zhǔn)。

同時(shí)多個(gè)開(kāi)發(fā)團(tuán)隊(duì)協(xié)同和集成，必須有一個(gè)統(tǒng)一的集成方來(lái)解決協(xié)同中的問(wèn)題。即使是在ServiceMesh服務(wù)網(wǎng)格架構(gòu)下，我們也可以看到有一個(gè)控制中心來(lái)統(tǒng)一協(xié)調(diào)。

在使用API網(wǎng)關(guān)后技術(shù)組件的選擇上

注意，對(duì)于API網(wǎng)關(guān)本身具備負(fù)載均衡，限流熔斷，服務(wù)代理的能力。

即在注冊(cè)中心下，Eureka+Feign+Ribbon+Hystrix全部可以轉(zhuǎn)由API網(wǎng)關(guān)來(lái)完成。但是一個(gè)應(yīng)用的完整微服務(wù)架構(gòu)可能存在一個(gè)API接口既要滿足內(nèi)部組件的API消費(fèi)調(diào)用，又需要將該接口通過(guò)API網(wǎng)關(guān)暴露給外部應(yīng)用使用。

通過(guò)API網(wǎng)關(guān)對(duì)外保留Http Rest API接口，傳統(tǒng)API消費(fèi)訪問(wèn)而不再是類(lèi)似Feign聲明式方式進(jìn)行類(lèi)似內(nèi)部API接口方式調(diào)用。如下圖：

可以看到，微服務(wù)A既需要滿足內(nèi)部微服務(wù)B作為消費(fèi)方，通過(guò)服務(wù)注冊(cè)中心進(jìn)行消費(fèi)調(diào)用，也需要滿足外部APP通過(guò)API網(wǎng)關(guān)接口進(jìn)行消費(fèi)調(diào)用。

那么進(jìn)入到微服務(wù)A集群的流量實(shí)際上是沒(méi)有一個(gè)統(tǒng)一的入口的。

在這種場(chǎng)景下如果企業(yè)了Hystrix限流熔斷，那么也僅僅是對(duì)內(nèi)部的微服務(wù)模塊組件間的消費(fèi)調(diào)用進(jìn)行控制。而對(duì)于外部APP限流，仍然還需要啟用網(wǎng)關(guān)上的限流熔斷功能。

微服務(wù)架構(gòu)和容器云集成的集群和負(fù)載均衡

最后談下微服務(wù)架構(gòu)和Kubernetes+Docker容器云集成后的服務(wù)發(fā)現(xiàn)和負(fù)載均衡問(wèn)題。

前面談到在采用Eureka服務(wù)注冊(cè)中心的時(shí)候，對(duì)于同一個(gè)微服務(wù)模塊A，我們可以啟動(dòng)多個(gè)微服務(wù)實(shí)例，不同的端口號(hào)。在端口啟動(dòng)后通過(guò)Eureka來(lái)實(shí)現(xiàn)服務(wù)的自動(dòng)注冊(cè)和發(fā)現(xiàn)。然后通過(guò)Ribbon來(lái)實(shí)現(xiàn)服務(wù)訪問(wèn)的負(fù)載均衡處理。

也就是說(shuō)我們添加和部署微服務(wù)模塊A節(jié)點(diǎn)是手工完成的。

但是在DevOps持續(xù)集成下，在實(shí)施Kubernetes+Docker容器云后，我們可以通過(guò)k8s來(lái)實(shí)現(xiàn)微服務(wù)節(jié)點(diǎn)資源的動(dòng)態(tài)擴(kuò)展。擴(kuò)展的Pod資源統(tǒng)一由Kubernetes來(lái)實(shí)現(xiàn)集群負(fù)載均衡均衡，即對(duì)外只需要通過(guò)Node+端口號(hào)訪問(wèn)即可。

所以在這個(gè)時(shí)候?qū)嶋H有兩種做法。

做法1：不再使用Eureka服務(wù)注冊(cè)和發(fā)現(xiàn)

在這種時(shí)候，不再使用Eureka服務(wù)注冊(cè)發(fā)現(xiàn)，而是通過(guò)Kubernates動(dòng)態(tài)部署后的VIP進(jìn)行訪問(wèn)，由Kubernates來(lái)進(jìn)行后臺(tái)節(jié)點(diǎn)的負(fù)載均衡。

這個(gè)時(shí)候我們只能夠按常規(guī)調(diào)用Http  Rest  API接口的方式進(jìn)行接口消費(fèi)和調(diào)用，類(lèi)似原來(lái)的Feign聲明式調(diào)用可能不再適合。也就是說(shuō)在這種場(chǎng)景下你只使用SpringBoot開(kāi)發(fā)獨(dú)立的能夠暴露Http  Rest API接口的微服務(wù)。不再使用SpringCLoud框架中的Eureka+Feign+Ribbon。

做法2：采用Eureka來(lái)替代Kubernetes中的Service

在這種場(chǎng)景下，即不使用Kubernetes本身的集群功能，而是將動(dòng)態(tài)部署出來(lái)的微服務(wù)模塊還是自動(dòng)化注冊(cè)到Eureka服務(wù)注冊(cè)中心統(tǒng)一管理。也就是還是按傳統(tǒng)的SpringCLoud框架體系來(lái)進(jìn)行架構(gòu)搭建。

在這種思路下可以進(jìn)一步保留SpingCLoud下的限流，容錯(cuò)，心跳監(jiān)測(cè)等方面的關(guān)鍵能力。

做法3：進(jìn)一步的思路還是ServiceMesh

實(shí)際上我們看到進(jìn)一步的思路還是類(lèi)似Istio的完全去中心化微服務(wù)治理方案。在這種模式下可以更好的通過(guò)Sidecar來(lái)實(shí)現(xiàn)相關(guān)服務(wù)注冊(cè)，發(fā)現(xiàn)，限流熔斷，安全等各種關(guān)鍵服務(wù)治理管控能力。

如果微服務(wù)模塊全部是通過(guò)Kubernetes部署到Docker容器里面，那么我們可以看到完全可以在k8s進(jìn)行鏡像制作和容器部署的時(shí)候?qū)ideCar的內(nèi)容附加到具體的部署包里面實(shí)現(xiàn)集成。

簡(jiǎn)單來(lái)說(shuō)，就是：

我們?cè)陂_(kāi)發(fā)微服務(wù)模塊的時(shí)候完全不需要考慮太多的分布式API接口集成交互，但是和Kubernetes和Service Mesh集成后就具備了分布式接口調(diào)用和集成的能力。同時(shí)也具備了對(duì)API接口的安全，日志，限流熔斷的管理能力。

因此也常說(shuō)，Service Mesh是Kubernetes支撐微服務(wù)能力拼圖的最后一塊。

感謝各位的閱讀，以上就是“有哪些微服務(wù)架構(gòu)設(shè)計(jì)的問(wèn)題”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)有哪些微服務(wù)架構(gòu)設(shè)計(jì)的問(wèn)題這一問(wèn)題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！