服務(wù)拆分的前提

服務(wù)拆分的前提，首先要有一個(gè)持續(xù)集成的平臺(tái)，使得服務(wù)在拆分的過程中，保持功能的一致性。

這種一致性不能通過人的經(jīng)驗(yàn)來，而是需要經(jīng)過大量的回歸測試集，并且持續(xù)的拆分，持續(xù)的演進(jìn)，持續(xù)的集成，從而保證系統(tǒng)時(shí)刻處于可以驗(yàn)證交付的狀態(tài)。

而非閉門拆分一段時(shí)間，最終誰也不知道功能最終究竟有沒有 Bug，因而需要另外一個(gè)月的時(shí)間專門修改 Bug。

其次在接入層，API 和 UI 要?jiǎng)屿o分離，API 由 API 網(wǎng)關(guān)統(tǒng)一的管理，這樣后端無論如何拆分，可以保證對(duì)于前端來講，是統(tǒng)一的入口。

而且可以實(shí)現(xiàn)拆分過程中的灰度發(fā)布，路由分發(fā)，流量切分，從而保證拆分的平滑進(jìn)行。

拆分后的微服務(wù)之間，為了高性能，是不建議每次調(diào)用都進(jìn)行認(rèn)證鑒權(quán)的，而是在 API 網(wǎng)關(guān)上做統(tǒng)一的認(rèn)證鑒權(quán)，一旦進(jìn)入網(wǎng)關(guān)，服務(wù)之間的調(diào)用就是可信的。

其三對(duì)于數(shù)據(jù)庫，需要進(jìn)行良好的設(shè)計(jì)，不應(yīng)該有大量的聯(lián)合查詢，而是將數(shù)據(jù)庫當(dāng)成一個(gè)簡單的 key-value 查詢。

復(fù)雜的聯(lián)合查詢通過應(yīng)用層，或者通過 Elasticsearch 進(jìn)行。如果數(shù)據(jù)庫表之間的耦合非常嚴(yán)重，那么服務(wù)拆分是拆不出來的。

其四要做應(yīng)用的無狀態(tài)化，只有無狀態(tài)的應(yīng)用，才能橫向擴(kuò)展，這樣拆分才有意義。

服務(wù)拆分的時(shí)機(jī)

滿足了服務(wù)拆分的前提之后，那先拆哪個(gè)模塊，后拆哪個(gè)模塊呢?什么情況下，一個(gè)模塊應(yīng)該拆分出來呢?

微服務(wù)拆分絕非一個(gè)大躍進(jìn)運(yùn)動(dòng)，由高層發(fā)起，把一個(gè)應(yīng)用拆分的七零八落的，最終大大增加運(yùn)維成本，但是并不會(huì)帶來收益。

微服務(wù)拆分的過程，應(yīng)該是一個(gè)由痛點(diǎn)驅(qū)動(dòng)的，是業(yè)務(wù)真正遇到了快速迭代和高并發(fā)的問題。

如果不拆分，將對(duì)于業(yè)務(wù)的發(fā)展帶來影響，只有這個(gè)時(shí)候，微服務(wù)的拆分是有確定收益的，增加的運(yùn)維成本才是值得的。

微服務(wù)解決的問題之一：快速迭代

互聯(lián)網(wǎng)產(chǎn)品的特點(diǎn)就是迭代速度快，一般一年半就能決出勝負(fù)，***一統(tǒng)天下，第二被***收購，其他死翹翹。

所以快速上線，快速迭代，就是生命線，而且一旦成功就是百億身家，所以無論付出多大運(yùn)維成本，使用微服務(wù)架構(gòu)都是值得的。

這也就是為什么大部分使用微服務(wù)架構(gòu)的都是互聯(lián)網(wǎng)企業(yè)，因?yàn)閷?duì)于這些企業(yè)來講收益明顯。

而對(duì)于很多傳統(tǒng)的應(yīng)用，半年更新一次，企業(yè)運(yùn)營相對(duì)平穩(wěn)，IT 系統(tǒng)的好壞對(duì)于業(yè)務(wù)沒有關(guān)鍵性影響，在他們眼中，微服務(wù)化改造帶來的效果，還不如開發(fā)多加幾次班。

微服務(wù)拆分時(shí)機(jī)一：提交代碼頻繁出現(xiàn)大量沖突

微服務(wù)對(duì)于快速迭代的效果，首先是開發(fā)獨(dú)立，如果是一單體應(yīng)用，幾百人開發(fā)一個(gè)模塊，如果使用 Git 做代碼管理，則經(jīng)常會(huì)遇到的事情就是代碼提交沖突。

同樣一個(gè)模塊，你也改，他也改，幾百人根本沒辦法溝通。所以當(dāng)你想提交一個(gè)代碼的時(shí)候，發(fā)現(xiàn)和別人提交的沖突了，于是因?yàn)槟闶呛筇峤坏娜?，你有?zé)任去 Merge 代碼。

好不容易 Merge 成功了，等再次提交的時(shí)候，發(fā)現(xiàn)又沖突了，你是不是很惱火。隨著團(tuán)隊(duì)規(guī)模越大，沖突概率越大。

所以應(yīng)該拆分成不同的模塊，每十個(gè)人左右維護(hù)一個(gè)模塊，也即一個(gè)工程，首先代碼沖突的概率小多了，而且有了沖突，一個(gè)小組一吼，基本上問題就解決了。

每個(gè)模塊對(duì)外提供接口，其他依賴模塊可以不用關(guān)注具體的實(shí)現(xiàn)細(xì)節(jié)，只需要保證接口正確就可以。

微服務(wù)拆分時(shí)機(jī)二：小功能要積累到大版本才能上線，上線開總監(jiān)級(jí)別大會(huì)

微服務(wù)對(duì)于快速迭代的效果，首先是上線獨(dú)立。如果沒有拆分微服務(wù)，每次上線都是一件很痛苦的事情。

當(dāng)你修改了一個(gè)邊角的小功能，但是你不敢馬上上線，因?yàn)槟阋蕾嚨钠渌K才開發(fā)了一半，你要等他，等他好了，也不敢馬上上線，因?yàn)榱硪粋€(gè)被依賴的模塊也開發(fā)了一半。

當(dāng)所有的模塊都耦合在一起，互相依賴，誰也沒辦法獨(dú)立上線，而是需要總監(jiān)協(xié)調(diào)各個(gè)團(tuán)隊(duì)，大家開大會(huì)，約定一個(gè)時(shí)間點(diǎn)，無論大小功能，死活都要這天上線。

這種模式導(dǎo)致上線的時(shí)候，單次上線的需求列表非常長，風(fēng)險(xiǎn)比較大，可能小功能的錯(cuò)誤會(huì)導(dǎo)致大功能的上線不正常。

將如此長的功能，需要一點(diǎn)點(diǎn) Check，且要非常小心，這樣上線時(shí)間長，影響范圍大。因而這種的迭代速度快不了，頂多一個(gè)月一次就不錯(cuò)了。

服務(wù)拆分后，在接口穩(wěn)定的情況下，不同的模塊可以獨(dú)立上線。這樣上線的次數(shù)增多，單次上線的需求列表變小，可以隨時(shí)回滾，風(fēng)險(xiǎn)變小，時(shí)間變短，影響面小，從而迭代速度加快。

對(duì)于接口要升級(jí)部分，保證灰度，先做接口新增，而非原接口變更，當(dāng)注冊(cè)中心中監(jiān)控到的調(diào)用情況，發(fā)現(xiàn)接口已經(jīng)不用了，再刪除。

微服務(wù)解決的問題之二：高并發(fā)

互聯(lián)網(wǎng)一個(gè)產(chǎn)品的特點(diǎn)就是在短期內(nèi)要積累大量的用戶，這甚至比營收和利潤還重要，如果沒有大量的用戶基數(shù)，融資都會(huì)有問題。

因而對(duì)于并發(fā)量不大的系統(tǒng)，進(jìn)行微服務(wù)化的驅(qū)動(dòng)力差一些，如果只有不多的用戶在線，多線程就能解決問題，最多做好無狀態(tài)化，前面部署個(gè)負(fù)載均衡，單體應(yīng)用部署多份。

微服務(wù)拆分時(shí)機(jī)三：橫向擴(kuò)展流程復(fù)雜，主要業(yè)務(wù)和次要業(yè)務(wù)耦合

單體應(yīng)用無狀態(tài)化之后，雖然通過部署多份，可以承載一定的并發(fā)量，但是資源非常浪費(fèi)。

因?yàn)橛械臉I(yè)務(wù)是需要擴(kuò)容的，例如下單和支付，有的業(yè)務(wù)是不需要擴(kuò)容的，例如注冊(cè)。如果一起擴(kuò)容，消耗的資源可能是拆分后的幾倍，成本可能多出幾個(gè)億。

而且由于配置復(fù)雜，在同一個(gè)工程里面，往往在配置文件中是這樣組織的：這一塊是這個(gè)模塊的，下一塊是另一個(gè)模塊的。

這樣擴(kuò)容的時(shí)候，一些邊角的業(yè)務(wù)，也是需要對(duì)配置進(jìn)行詳細(xì)審核，否則不敢貿(mào)然擴(kuò)容。

微服務(wù)拆分時(shí)機(jī)四：熔斷降級(jí)全靠 if-else

在高并發(fā)場景下，我們希望一個(gè)請(qǐng)求如果不成功，不要占用資源，應(yīng)該盡快失敗，盡快返回，而且希望當(dāng)一些邊角的業(yè)務(wù)不正常的情況下，主要業(yè)務(wù)流程不受影響。

這就需要熔斷策略，也即當(dāng) A 調(diào)用 B，而 B 總是不正常的時(shí)候，為了讓 B 不要波及到 A，可以對(duì) B 的調(diào)用進(jìn)行熔斷，也即 A 不調(diào)用 B，而是返回暫時(shí)的 fallback 數(shù)據(jù)，當(dāng) B 正常的時(shí)候，再放開熔斷，進(jìn)行正常的調(diào)用。

有時(shí)候?yàn)榱吮ＷC核心業(yè)務(wù)流程，邊角的業(yè)務(wù)流程，如評(píng)論，庫存數(shù)目等，人工設(shè)置為降級(jí)的狀態(tài)，也即默認(rèn)不調(diào)用，將所有的資源用于大促的下單和支付流程。

如果核心業(yè)務(wù)流程和邊角業(yè)務(wù)流程在同一個(gè)進(jìn)程中，就需要使用大量的 if-else 語句，根據(jù)下發(fā)的配置來判斷是否熔斷或者降級(jí)，這會(huì)使得配置異常復(fù)雜，難以維護(hù)。

如果核心業(yè)務(wù)和邊角業(yè)務(wù)分成兩個(gè)進(jìn)程，就可以使用標(biāo)準(zhǔn)的熔斷降級(jí)策略，配置在某種情況下，放棄對(duì)另一個(gè)進(jìn)程的調(diào)用，可以進(jìn)行統(tǒng)一的維護(hù)。

服務(wù)拆分的方法

好了，當(dāng)你覺得要將一個(gè)程序的某個(gè)部分拆分出來的時(shí)候，有什么方法可以保障平滑嗎?

首先要做的，就是原有工程代碼的標(biāo)準(zhǔn)化，我們常稱為“任何人接手任何一個(gè)模塊都能看到熟悉的面孔”。

例如打開一個(gè) Java 工程，應(yīng)該有以下的 package：

• API 接口包：所有的接口定義都在這里，對(duì)于內(nèi)部的調(diào)用，也要實(shí)現(xiàn)接口，這樣一旦要拆分出去，對(duì)于本地的接口調(diào)用，就可以變?yōu)檫h(yuǎn)程的接口調(diào)用。
• 訪問外部服務(wù)包：如果這個(gè)進(jìn)程要訪問其他進(jìn)程，對(duì)于外部訪問的封裝都在這里，對(duì)于單元測試來講，對(duì)于這部分的 Mock，可以使得不用依賴第三方，就能進(jìn)行功能測試。對(duì)于服務(wù)拆分，調(diào)用其他的服務(wù)，也是在這里。
• 數(shù)據(jù)庫 DTO：如果要訪問數(shù)據(jù)庫，在這里定義原子的數(shù)據(jù)結(jié)構(gòu)。
• 訪問數(shù)據(jù)庫包：訪問數(shù)據(jù)庫的邏輯全部在這個(gè)包里面。
• 服務(wù)與商務(wù)邏輯：這里實(shí)現(xiàn)主要的商業(yè)邏輯，拆分也是從這里拆分出來。
• 外部服務(wù)：對(duì)外提供服務(wù)的邏輯在這里，對(duì)于接口的提供方，要實(shí)現(xiàn)在這里。

另外是測試文件夾，每個(gè)類都應(yīng)該有單元測試，要審核單元測試覆蓋率，模塊內(nèi)部應(yīng)該通過 Mock 的方法實(shí)現(xiàn)集成測試。

接下來是配置文件夾，配置 profile，配置分為幾類：

• 內(nèi)部配置項(xiàng)。(啟動(dòng)后不變，改變需要重啟)
• 集中配置項(xiàng)。(配置中心，可動(dòng)態(tài)下發(fā))
• 外部配置項(xiàng)。(外部依賴，和環(huán)境相關(guān))

當(dāng)一個(gè)工程的結(jié)構(gòu)非常標(biāo)準(zhǔn)化之后，接下來在原有服務(wù)中，先獨(dú)立功能模塊 ，規(guī)范輸入輸出，形成服務(wù)內(nèi)部的分離。

在分離出新的進(jìn)程之前，先分離出新的 jar，只要能夠分離出新的 jar，基本也就實(shí)現(xiàn)了松耦合。

接下來，應(yīng)該新建工程，新啟動(dòng)一個(gè)進(jìn)程，盡早的注冊(cè)到注冊(cè)中心，開始提供服務(wù)，這個(gè)時(shí)候，新的工程中的代碼邏輯可以先沒有，只是轉(zhuǎn)調(diào)用原來的進(jìn)程接口。

為什么要越早獨(dú)立越好呢?哪怕還沒實(shí)現(xiàn)邏輯先獨(dú)立呢?因?yàn)榉?wù)拆分的過程是漸進(jìn)的。

伴隨著新功能的開發(fā)，新需求的引入，這個(gè)時(shí)候，對(duì)于原來的接口，也會(huì)有新的需求進(jìn)行修改。

如果你想把業(yè)務(wù)邏輯獨(dú)立出來，獨(dú)立了一半，新需求來了，改舊的，改新的都不合適。

新的還沒獨(dú)立提供服務(wù)，舊的如果改了，會(huì)造成從舊工程遷移到新工程，邊遷移邊改變，合并更加困難。

如果盡早獨(dú)立，所有的新需求都進(jìn)入新的工程，所有調(diào)用方更新的時(shí)候，都改為調(diào)用新的進(jìn)程，對(duì)于老進(jìn)程的調(diào)用會(huì)越來越少，最終新進(jìn)程將老進(jìn)程全部代理。

接下來就可以將老工程中的邏輯逐漸遷移到新工程，由于代碼遷移不能保證邏輯的完全正確，因而需要持續(xù)集成，灰度發(fā)布，微服務(wù)框架能夠在新老接口之間切換。

最終當(dāng)新工程穩(wěn)定運(yùn)行，并且在調(diào)用監(jiān)控中，已經(jīng)沒有對(duì)于老工程的調(diào)用的時(shí)候，就可以將老工程下線了。

服務(wù)拆分的規(guī)范

微服務(wù)拆分之后，工程會(huì)比較的多，如果沒有一定的規(guī)范，將會(huì)非?；靵y，難以維護(hù)。

首先人們經(jīng)常問的一個(gè)問題是，服務(wù)拆分之后，原來都在一個(gè)進(jìn)程里面的函數(shù)調(diào)用，現(xiàn)在變成了 A 調(diào)用 B 調(diào)用 C 調(diào)用 D 調(diào)用 E，會(huì)不會(huì)因?yàn)檎{(diào)用鏈路過長而使得調(diào)用相應(yīng)變慢呢?

服務(wù)拆分的規(guī)范一：服務(wù)拆分最多三層，兩次調(diào)用

服務(wù)拆分是為了橫向擴(kuò)展，因而應(yīng)該橫向拆分，而非縱向拆成一串。也即應(yīng)該將商品和訂單拆分，而非下單的十個(gè)步驟拆分，然后一個(gè)調(diào)用一個(gè)。

縱向的拆分最多三層：

• 基礎(chǔ)服務(wù)層：用于屏蔽數(shù)據(jù)庫，緩存層，提供原子的對(duì)象查詢接口。有了這一層，當(dāng)數(shù)據(jù)層做一定改變的時(shí)候，例如分庫分表，數(shù)據(jù)庫擴(kuò)容，緩存替換等。對(duì)于上層透明，上層僅僅調(diào)用這一層的接口，不直接訪問數(shù)據(jù)庫和緩存。

• 組合服務(wù)層：這一層調(diào)用基礎(chǔ)服務(wù)層，完成較為復(fù)雜的業(yè)務(wù)邏輯，實(shí)現(xiàn)分布式事務(wù)也多在這一層。
• Controller 層：接口層，調(diào)用組合服務(wù)層對(duì)外。

服務(wù)拆分的規(guī)范二：僅僅單向調(diào)用，嚴(yán)禁循環(huán)調(diào)用

微服務(wù)拆分后，服務(wù)之間的依賴關(guān)系復(fù)雜，如果循環(huán)調(diào)用，升級(jí)的時(shí)候就很頭疼，不知道應(yīng)該先升級(jí)哪個(gè)，后升級(jí)哪個(gè)，難以維護(hù)。

因而層次之間的調(diào)用規(guī)定如下：

• 基礎(chǔ)服務(wù)層主要做數(shù)據(jù)庫的操作和一些簡單的業(yè)務(wù)邏輯，不允許調(diào)用其他任何服務(wù)。
• 組合服務(wù)層，可以調(diào)用基礎(chǔ)服務(wù)層，完成復(fù)雜的業(yè)務(wù)邏輯，可以調(diào)用組合服務(wù)層，不允許循環(huán)調(diào)用，不允許調(diào)用 Controller 層服務(wù)。
• Controller 層，可以調(diào)用組合業(yè)務(wù)層服務(wù)，不允許被其他服務(wù)調(diào)用。

如果出現(xiàn)循環(huán)調(diào)用，例如 A 調(diào)用 B，B 也調(diào)用 A，則分成 Controller 層和組合服務(wù)層兩層，A 調(diào)用 B 的下層，B 調(diào)用 A 的下層。也可以使用消息隊(duì)列，將同步調(diào)用，改為異步調(diào)用。

服務(wù)拆分的規(guī)范三：將串行調(diào)用改為并行調(diào)用，或者異步化

如果有的組合服務(wù)處理流程的確很長，需要調(diào)用多個(gè)外部服務(wù)，應(yīng)該考慮如何通過消息隊(duì)列，實(shí)現(xiàn)異步化和解耦。

例如下單之后，要刷新緩存，要通知倉庫等，這些都不需要再下單成功的時(shí)候就要做完，而是可以發(fā)一個(gè)消息給消息隊(duì)列，異步通知其他服務(wù)。

而且使用消息隊(duì)列的好處是，你只要發(fā)送一個(gè)消息，無論下游依賴方有一個(gè)，還是有十個(gè)，都是一條消息搞定，只不過多幾個(gè)下游監(jiān)聽消息即可。

對(duì)于下單必須同時(shí)做完的，例如扣減庫存和優(yōu)惠券等，可以進(jìn)行并行調(diào)用，這樣處理時(shí)間會(huì)大大縮短，不是多次調(diào)用的時(shí)間之和，而是最長的那個(gè)系統(tǒng)調(diào)用時(shí)間。

服務(wù)拆分的規(guī)范四：接口應(yīng)該實(shí)現(xiàn)冪等

微服務(wù)拆分之后，服務(wù)之間的調(diào)用當(dāng)出現(xiàn)錯(cuò)誤的時(shí)候，一定會(huì)重試，但是為了不要下兩次單，支付兩次，需要所有的接口實(shí)現(xiàn)冪等。

冪等一般需要設(shè)計(jì)一個(gè)冪等表來實(shí)現(xiàn)，冪等表中的主鍵或者唯一鍵可以是 transaction id，或者 business id，可以通過這個(gè) id 的唯一性標(biāo)識(shí)一個(gè)唯一的操作。

也有冪等操作使用狀態(tài)機(jī)，當(dāng)一個(gè)調(diào)用到來的時(shí)候，往往觸發(fā)一個(gè)狀態(tài)的變化，當(dāng)下次調(diào)用到來的時(shí)候，發(fā)現(xiàn)已經(jīng)不是這個(gè)狀態(tài)，就說明上次已經(jīng)調(diào)用過了。

狀態(tài)的變化需要是一個(gè)原子操作，也即并發(fā)調(diào)用的時(shí)候，只有一次可以執(zhí)行。可以使用分布式鎖，或者樂觀鎖 CAS 操作實(shí)現(xiàn)。

服務(wù)拆分的規(guī)范五：接口數(shù)據(jù)定義嚴(yán)禁內(nèi)嵌，透傳

微服務(wù)接口之間傳遞數(shù)據(jù)，往往通過數(shù)據(jù)結(jié)構(gòu)，如果數(shù)據(jù)結(jié)構(gòu)透傳，從底層一直到上層使用同一個(gè)數(shù)據(jù)結(jié)構(gòu)。

或者上層的數(shù)據(jù)結(jié)構(gòu)內(nèi)嵌底層的數(shù)據(jù)結(jié)構(gòu)，當(dāng)數(shù)據(jù)結(jié)構(gòu)中添加或者刪除一個(gè)字段的時(shí)候，波及的面會(huì)非常大。

因而接口數(shù)據(jù)定義，在每兩個(gè)接口之間約定，嚴(yán)禁內(nèi)嵌和透傳，即便差不多，也應(yīng)該重新定義。

這樣接口數(shù)據(jù)定義的改變，影響面僅僅在調(diào)用方和被調(diào)用方，當(dāng)接口需要更新的時(shí)候，比較可控，也容易升級(jí)。

服務(wù)拆分的規(guī)范六：規(guī)范化工程名

微服務(wù)拆分后，工程名非常多，開發(fā)人員，開發(fā)團(tuán)隊(duì)也非常多，如何讓一個(gè)開發(fā)人員看到一個(gè)工程名，或者 jar 的名稱，就大概知道是干什么的，需要一個(gè)規(guī)范化的約定。

例如出現(xiàn) pay 就是支付，出現(xiàn) order 就是下單，出現(xiàn) account 就是用戶。

再如出現(xiàn) compose 就是組合層，controller 就是接口層，basic 就是基礎(chǔ)服務(wù)層。

出現(xiàn) api 就是接口定義，impl 就是實(shí)現(xiàn)。pay-compose-api 就是支付組合層接口定義。account-basic-impl 就是用戶基礎(chǔ)服務(wù)層的實(shí)現(xiàn)。

服務(wù)發(fā)現(xiàn)的選型

微服務(wù)拆分后，服務(wù)之間的調(diào)用需要服務(wù)發(fā)現(xiàn)和注冊(cè)中心進(jìn)行維護(hù)。主流的有如下幾種方法：

Dubbo

***是 Dubbo。Dubbo 是 SOA 架構(gòu)的微服務(wù)框架的標(biāo)準(zhǔn)，已經(jīng)被大量使用。

雖然中間中斷維護(hù)過一段時(shí)間，但是隨著微服務(wù)的興起，重新進(jìn)行了維護(hù)，是很多熟悉 Dubbo RPC 開發(fā)人員的***。

Spring Cloud

第二種是 Spring Cloud。Spring Cloud 為微服務(wù)而生，在 Dubbo 已經(jīng)沒有人維護(hù)的情況下，推出了支撐微服務(wù)的成熟框架。

Dubbo VS Spring Cloud 的對(duì)比：Dubbo 更加注重服務(wù)治理，原生功能不夠全面，而 Spring Cloud 注重整個(gè)微服務(wù)生態(tài)，工具鏈非常全面。

Spring Cloud 可定制性強(qiáng)，通過各種組件滿足各種微服務(wù)場景，使用 Spring Boot 統(tǒng)一編程模型，能夠快速構(gòu)建應(yīng)用，基于注解，使用方便，但是學(xué)習(xí)門檻比較高。

Dubbo 注冊(cè)到 ZooKeeper 里面的是接口，而 Spring Cloud 注冊(cè)到 Eureka 或者 Consul 里面的是實(shí)例。

在規(guī)模比較小的情況下沒有分別，但是規(guī)模一旦大了，例如實(shí)例數(shù)目萬級(jí)別，接口數(shù)據(jù)就算十萬級(jí)別，對(duì)于 ZooKeeper 中的樹規(guī)模比較大。

而且 ZooKeeper 是強(qiáng)一致性的，當(dāng)一個(gè)節(jié)點(diǎn)掛了的時(shí)候，節(jié)點(diǎn)之間的數(shù)據(jù)同步會(huì)影響線上使用，而 Spring Cloud 就好很多，實(shí)例級(jí)別少一個(gè)量級(jí)，另外 Consul 也非強(qiáng)一致的。

Kubernetes

第三是 Kubernetes。Kubernetes 雖然是容器平臺(tái)，但是他設(shè)計(jì)出來，就是為了跑微服務(wù)的，因而提供了微服務(wù)運(yùn)行的很多組件。

很多 Spring Cloud 可以做的事情，Kubernetes 也有相應(yīng)的機(jī)制，而且由于是容器平臺(tái)，相對(duì)比較通用，可以支持多語言，對(duì)于業(yè)務(wù)無侵入。

但是也正因?yàn)槭侨萜髌脚_(tái)，對(duì)于微服務(wù)的運(yùn)行生命周期的維護(hù)比較全面，對(duì)于服務(wù)之間的調(diào)用和治理，比較弱，Service 只能滿足最最基本的服務(wù)發(fā)現(xiàn)需求。

因而實(shí)踐中使用的時(shí)候，往往是 Kubernetes 和 Spring Cloud 結(jié)合使用，Kubernetes 負(fù)責(zé)提供微服務(wù)的運(yùn)行環(huán)境;服務(wù)之間的調(diào)用和治理，由 Spring Cloud 搞定。

Service Mesh

第四是 Service Mesh。Service Mesh 一定程度上彌補(bǔ)了 Kubernetes 對(duì)于服務(wù)治理方面的不足，對(duì)業(yè)務(wù)代碼 0 侵入，將服務(wù)治理下沉到平臺(tái)層，是服務(wù)治理的一個(gè)趨勢。

然而 Service Mesh 需要使用單獨(dú)的進(jìn)程進(jìn)行請(qǐng)求轉(zhuǎn)發(fā)，性能還不能讓人滿意，另外社區(qū)比較新，成熟度不足，暫時(shí)沒有達(dá)到大規(guī)模生產(chǎn)使用的標(biāo)準(zhǔn)。

福利來啦

結(jié)合自身情況請(qǐng)談?wù)勀鷮?duì)微服務(wù)架構(gòu)的理解。掃描下方二維碼，關(guān)注51CTO技術(shù)棧公眾號(hào)。歡迎在技術(shù)棧微信公眾號(hào)留言探討。小編將選出留言最精彩的 10 名網(wǎng)友，送出《Spring Cloud微服務(wù)架構(gòu)開發(fā)實(shí)戰(zhàn)》圖書一本~活動(dòng)截止時(shí)間 9 月 20 日十二時(shí)整，特別鳴謝機(jī)械工業(yè)出版社為本次活動(dòng)提供的圖書贊助。等不及送書的小伙伴，可以點(diǎn)擊閱讀原文直接購買。

書籍簡介

本書首先從微服務(wù)架構(gòu)興起的背景講起，探討了為何在分布式系統(tǒng)開發(fā)中微服務(wù)架構(gòu)將逐漸取代單體架構(gòu);然后對(duì) Spring Cloud 所提供的微服務(wù)組件及解決方案進(jìn)行了一一講解，從而讓讀者不但可以系統(tǒng)地學(xué)習(xí) Spring Cloud 的相關(guān)知識(shí)，而且還可以全掌握微服務(wù)架構(gòu)應(yīng)用的設(shè)計(jì)、開發(fā)、部署和運(yùn)維等知識(shí)。