[[395974]]

從我接觸微服務(wù)以來(lái)，迄今也得有五六年了。斷斷續(xù)續(xù)要么從零開(kāi)始，要么中途接手，也經(jīng)歷了 5 套微服務(wù)項(xiàng)目了。

從這些項(xiàng)目中的經(jīng)驗(yàn)以及和同行交流來(lái)看，根據(jù)業(yè)務(wù)切分微服務(wù)的方法總的來(lái)說(shuō)思路不復(fù)雜，但是落地總是出現(xiàn)了各種各樣的問(wèn)題。一直到現(xiàn)在，我也還在探索著最好的微服務(wù)落地的最佳辦法。

在之前的文章我也提過(guò)，一個(gè)服務(wù)一個(gè)數(shù)據(jù)庫(kù)是微服務(wù)最基本的模式，也談了為什么要搞微服務(wù)。今天這篇文章我想談?wù)劊?/p>

一個(gè)服務(wù)一個(gè)數(shù)據(jù)庫(kù)這種最基本的模式落地，大體的做法是怎么樣的。

一、搞微服務(wù)，可能是個(gè)政治問(wèn)題

我第一次接觸微服務(wù)的時(shí)候，真的是迫不得已。

公司有一套大型系統(tǒng)，這套大型系統(tǒng)當(dāng)時(shí)是負(fù)責(zé)公司的主要盈利業(yè)務(wù)，非常非常重要。但是，正因?yàn)橹匾运统蔀榱水a(chǎn)品、業(yè)務(wù)團(tuán)隊(duì)的重點(diǎn)服務(wù)對(duì)象。這些人天天想著把這套系統(tǒng)的業(yè)務(wù)做出花來(lái)，不斷對(duì)技術(shù)團(tuán)隊(duì)提出各種各樣的需求。

提出需求不說(shuō)，還要求技術(shù)能快速迭代。一旦不能及時(shí)上線他們的需求，產(chǎn)品經(jīng)理們就會(huì)在各種會(huì)議上抱怨，說(shuō)技術(shù)團(tuán)隊(duì)影響了速度，出現(xiàn)了讓競(jìng)爭(zhēng)對(duì)手迎頭趕上的風(fēng)險(xiǎn)。

技術(shù)團(tuán)隊(duì)有口難言，因?yàn)橄到y(tǒng)太龐大了，改動(dòng)那么大的系統(tǒng)真的很困難。至于原因，我也在上篇文章說(shuō)了，不再贅述。

出于這些原因，我們決定采用微服務(wù)。

什么時(shí)候使用微服務(wù)?當(dāng)你的交付時(shí)間不夠應(yīng)付產(chǎn)品團(tuán)隊(duì)，不夠應(yīng)付運(yùn)營(yíng)團(tuán)隊(duì)的時(shí)候，考慮考慮。還有，我后來(lái)搞其他新項(xiàng)目時(shí)，領(lǐng)導(dǎo)認(rèn)為系統(tǒng)太簡(jiǎn)單，沒(méi)有自己的技術(shù)特色。不得已，我又拿出了微服務(wù)，領(lǐng)導(dǎo)看了之后，眼前一亮，直說(shuō)這個(gè)好。

所以，以我的經(jīng)驗(yàn)看，有時(shí)候搞微服務(wù)，本質(zhì)是個(gè)政治問(wèn)題不是技術(shù)問(wèn)題。

總的來(lái)說(shuō)，對(duì)于微服務(wù)落地，不是特別大型的項(xiàng)目，微服務(wù)帶來(lái)的好處不大，工作量反而增大了許多。

不管什么原因，我后續(xù)接觸的微服務(wù)越來(lái)越多了，為了用好微服務(wù)，我真的是狠狠鉆研了下微服務(wù)這套體系架構(gòu)，也總結(jié)了一些自己對(duì)微服務(wù)分解實(shí)踐的經(jīng)驗(yàn)。

首先，如果是預(yù)估到業(yè)務(wù)在飛速增長(zhǎng)，那就別猶豫，一定要提前考慮微服務(wù)的拆分。

其次，如果在設(shè)計(jì)架構(gòu)的時(shí)候，發(fā)現(xiàn)需要很多異構(gòu)的技術(shù)棧，那也要考慮下微服務(wù)。

最后，如果公司技術(shù)基礎(chǔ)設(shè)施非常完備，對(duì)應(yīng)的業(yè)務(wù)起初就設(shè)計(jì)的非常復(fù)雜，那么也別猶豫，起手就上微服務(wù)。

二、遷移到微服務(wù)可以很粗暴，也可以很溫柔

回過(guò)頭來(lái)，繼續(xù)說(shuō)我當(dāng)時(shí)第一次搞微服務(wù)的事情。

由于遷移微服務(wù)不是一蹴而就的事情，但是我又急需一些微服務(wù)的部署簡(jiǎn)單、開(kāi)發(fā)快速的優(yōu)點(diǎn)。所以，當(dāng)時(shí)不得已，想了個(gè)折中的辦法。

我把一些急需實(shí)現(xiàn)的業(yè)務(wù)需求分析了下，發(fā)現(xiàn)這些需求大體可以分為以下兩類(lèi):

1. 有些需求本身是一套獨(dú)立的邊緣業(yè)務(wù)
2. 有些需求是集中在核心業(yè)務(wù)的邊緣上

我后來(lái)想想，覺(jué)得這是理所應(yīng)當(dāng)?shù)?。業(yè)務(wù)和我們技術(shù)一樣，如果動(dòng)了核心業(yè)務(wù)的邏輯，萬(wàn)一出現(xiàn)了問(wèn)題，他們是要背大責(zé)任的。但是他們又要體現(xiàn)自己的價(jià)值，那最保險(xiǎn)的就是在核心業(yè)務(wù)的邊邊角角動(dòng)些手腳。

知道了這些，那就好辦了。

對(duì)于第一類(lèi)獨(dú)立的業(yè)務(wù)需求，我直接就設(shè)計(jì)出一套獨(dú)立服務(wù)，讓它和已有的老系統(tǒng)通過(guò)網(wǎng)絡(luò)遠(yuǎn)程互聯(lián)。這樣的話，新搭建的服務(wù)很小，維護(hù)也簡(jiǎn)單。以前的老系統(tǒng)也成為新服務(wù)的服務(wù)。這樣，一部分需求，就可以快速迭代了。

對(duì)于第二類(lèi)需求，原有系統(tǒng)核心邊緣的需求，我是這樣做的。

• 首先，我爭(zhēng)取了領(lǐng)導(dǎo)的支持，優(yōu)先對(duì)經(jīng)常被提需求的業(yè)務(wù)模塊做了剝離。這樣，就剩下了一些不經(jīng)常變動(dòng)的業(yè)務(wù)模塊還在老系統(tǒng)。其實(shí)這些時(shí)候，系統(tǒng)也沒(méi)那么大了，也能滿足業(yè)務(wù)偶然提出的業(yè)務(wù)變動(dòng)需求了。
• 然后，我會(huì)在后續(xù)的時(shí)間里，慢慢的抽空把剩下的業(yè)務(wù)模塊沒(méi)事兒就剝離一些出來(lái)。但是，優(yōu)先級(jí)很低。
• 這樣，慢慢的抽絲剝繭，最后，我發(fā)現(xiàn)，核心業(yè)務(wù)我們都沒(méi)有動(dòng)，一套微服務(wù)體系就已經(jīng)搭建出來(lái)了。

有人可能會(huì)比較好奇，你這樣剝離，同時(shí)存在老系統(tǒng)和新系統(tǒng)。那外面的用戶(hù)使用會(huì)不會(huì)受影響呢?

其實(shí)，這里還有個(gè)小技巧。就是我在拆微服務(wù)之前，先搭建了一個(gè)代理。這個(gè)代理就是專(zhuān)門(mén)路由外面用戶(hù)請(qǐng)求的。每次上線服務(wù)的時(shí)候，都會(huì)對(duì)這套代理進(jìn)行一次微調(diào)整。這樣搞下來(lái)，用戶(hù)是感知不到背后新老系統(tǒng)并存的狀態(tài)的。

但是，說(shuō)到這里，我也要說(shuō)一下，這個(gè)方法真的是比較粗暴的，是實(shí)在沒(méi)辦法才選擇這種方法。

后來(lái)，我再搞微服務(wù)的時(shí)候，吸取了很多教訓(xùn)?？偟姆较蜻€是需要優(yōu)先劃分出清晰的業(yè)務(wù)模塊，然后再根據(jù)業(yè)務(wù)模塊的劃分搞出微服務(wù)來(lái)。

總的來(lái)說(shuō)，后期我設(shè)計(jì)微服務(wù)架構(gòu)需要分為兩個(gè)時(shí)期。而在這兩個(gè)時(shí)期，我又采用了不同的辦法。我分別來(lái)說(shuō)說(shuō)。

三、土法煉鋼的傳統(tǒng)業(yè)務(wù)劃分

在第一次被迫搞了微服務(wù)后，我對(duì)微服務(wù)這個(gè)架構(gòu)開(kāi)始了自己的研究。我知道了很多技術(shù)方面的細(xì)節(jié)，而如何劃分業(yè)務(wù)，我承認(rèn)當(dāng)時(shí)自己有點(diǎn)疏忽。所以，后來(lái)再有了新項(xiàng)目，我搞微服務(wù)的時(shí)候，是用的傳統(tǒng)業(yè)務(wù)劃分方法搞的微服務(wù)。

步驟如下:

第一步：劃分功能模塊

功能模塊劃分清楚這事兒其實(shí)還好，如果是從零開(kāi)始的系統(tǒng)，業(yè)務(wù)尚不復(fù)雜，所以模塊也很容易劃分清楚。

如果是已有的大項(xiàng)目，那還得看看系統(tǒng)的源碼，根據(jù)源碼和業(yè)務(wù)文檔，把整體業(yè)務(wù)模塊搞清楚。

第二步：梳理功能模塊的方法

搞清楚業(yè)務(wù)模塊了還不夠，你還需要搞成分開(kāi)的服務(wù)，所以，必定需要把服務(wù)之間的聯(lián)系也給確定好。這時(shí)候，如果是從零開(kāi)始就很好搞了，自己根據(jù)業(yè)務(wù)劃分的情況，直接自行創(chuàng)建對(duì)應(yīng)的方法就好。

如果針對(duì)已有項(xiàng)目拆分，那就不好搞了。非得仔細(xì)梳理源碼，然后根據(jù)源碼的類(lèi)和方法，逐次清理出各個(gè)模塊的之間的方法調(diào)用。非常麻煩。

第三步：對(duì)方法進(jìn)行分類(lèi)

把梳理出來(lái)的所有方法做一次分類(lèi)，分成兩類(lèi)：功能模塊直接對(duì)外部用戶(hù)的方法，功能模塊內(nèi)部之間需要調(diào)用的方法。

第四步：模塊映射服務(wù)，方法映射 API

方法梳理好了，分類(lèi)完畢了，這時(shí)候得把功能模塊映射成服務(wù)了，這個(gè)過(guò)程是必不可少的。功能模塊映射成服務(wù)往往一開(kāi)始其實(shí)很粗糙，就是先把一個(gè)功能模塊和服務(wù)進(jìn)行一對(duì)一的映射。

但是，就我的經(jīng)驗(yàn)來(lái)說(shuō)，這么簡(jiǎn)單的映射幾乎是不可能的?？偸怯懈鞣N落地問(wèn)題迫使你再調(diào)整。

好了，做出了業(yè)務(wù)模塊和服務(wù)的一對(duì)一映射的假設(shè)，咱們也梳理了業(yè)務(wù)模塊的方法調(diào)用了。那就把這些方法調(diào)用和服務(wù)的 API 方法做個(gè)一對(duì)一映射。當(dāng)然，這個(gè)方法也是很粗糙的，幾乎總是存在需要調(diào)整的問(wèn)題。

第五步：根據(jù)實(shí)際情況做調(diào)整。

最后，就開(kāi)始根據(jù)咱們上面的假設(shè)開(kāi)始微調(diào)了，業(yè)務(wù)模塊和服務(wù)之間的映射被迫調(diào)整，主要因?yàn)橐韵聨讉€(gè)原因:

1. 拆分后過(guò)多的網(wǎng)絡(luò)交互引起性能下降

當(dāng)我們拆分服務(wù)后，以前有些業(yè)務(wù)模塊間頻繁的方法調(diào)用，映射到服務(wù)之間，就變成了頻繁的網(wǎng)絡(luò)交互了。

我們肯定不能任其這樣頻繁的網(wǎng)絡(luò)調(diào)用。對(duì)這種情況，就會(huì)有兩個(gè)辦法處理：1. 把服務(wù)之間的交互改成批量處理的方式;2. 干脆就不拆服務(wù)。

服務(wù)之間改成批量處理還好，一旦決定不拆，就影響了以前設(shè)計(jì)好的映射關(guān)系了。

2. 同步調(diào)用可能引起的阻塞

還有些時(shí)候，以前本地調(diào)用搞成同步的方式，其實(shí)無(wú)傷大雅。因?yàn)榇蠹以谕粋€(gè)進(jìn)程里，處理事件都可以忽略不計(jì)。

但是，如今分家了，搞成了服務(wù)之間的網(wǎng)絡(luò)調(diào)用，那事兒可就來(lái)了。網(wǎng)絡(luò)同步調(diào)用必須考慮容錯(cuò)和阻塞，所以，對(duì)于同步調(diào)用這種，也得從兩個(gè)方面處理：1. 設(shè)置超時(shí);2. 搞成異步方式處理。

如果一些同步方法搞成了異步方式，那服務(wù)的 API 和以前的方法映射關(guān)系可能就要調(diào)整了。

例如一個(gè)方法得對(duì)應(yīng)兩個(gè)異步 API：一個(gè)是訪問(wèn)，一個(gè)是獲取響應(yīng)。

3. 原來(lái)的數(shù)據(jù)一致性可能要重新考慮

劃分服務(wù)后，最不好搞的就是數(shù)據(jù)一致性，而數(shù)據(jù)一致性這東西往往也避免不了。所以，微服務(wù)體系里專(zhuān)門(mén)會(huì)有套模式來(lái)解決這個(gè)問(wèn)題。咱們放到以后的文章里說(shuō)。

4. 原來(lái)有些核心業(yè)務(wù)類(lèi)可能和大部分業(yè)務(wù)緊密關(guān)聯(lián)

一套復(fù)雜的業(yè)務(wù)系統(tǒng)，必定會(huì)有一些核心的業(yè)務(wù)存在。在代碼實(shí)現(xiàn)里，往往就會(huì)是一個(gè)字段很多的業(yè)務(wù)類(lèi)。

比如電商系統(tǒng)里的訂單，這就是個(gè)很核心的業(yè)務(wù)類(lèi)。它會(huì)在很多業(yè)務(wù)里用到。對(duì)于這種類(lèi)，他們有個(gè)專(zhuān)業(yè)名詞叫做 God 類(lèi)。

God 類(lèi)本身因?yàn)楹吞嗟臉I(yè)務(wù)掛鉤了，等到你分服務(wù)的時(shí)候，你才意識(shí)到，我跋山涉水都快走完拆分步驟了，猛然因?yàn)橐粋€(gè) God 類(lèi)，把哥們兒整的都快不會(huì)了。

God 類(lèi)字段太多，很多業(yè)務(wù)都需要。

所以，它真的阻礙了很多業(yè)務(wù)被拆分。而在此時(shí)，我尚沒(méi)仔細(xì)領(lǐng)會(huì)到領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的精髓，所以，沒(méi)辦法，此時(shí)我只能把這些個(gè) God 類(lèi)給單獨(dú)拎出來(lái)弄成個(gè)微服務(wù)。

但是，這真的是很丑陋的。

首先，這純粹是因陋就簡(jiǎn)搞的土法分微服務(wù)，它完全沒(méi)有任何業(yè)務(wù)。

其次，由于沒(méi)有業(yè)務(wù)，所以也就沒(méi)有方向沒(méi)有限制，到時(shí)候誰(shuí)想加訪問(wèn)數(shù)據(jù)的 API 了，就隨意加了。

最后，這些 God 類(lèi)對(duì)應(yīng)的微服務(wù)會(huì)被很多的微服務(wù)模塊訪問(wèn)，它的壓力非常大，還得為此搞一些集群，得不償失。

四、換種思路解決難題的領(lǐng)域驅(qū)動(dòng)工具

其實(shí)，一路走來(lái)，我使用傳統(tǒng)的業(yè)務(wù)劃分真沒(méi)有遇到太多的問(wèn)題。就是 God 類(lèi)把我打擊的不行，我總是想找個(gè)辦法去解決它。

當(dāng)我看了領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)之后，我明白了，這玩意兒就是換個(gè)思路就好了。領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)其實(shí)沒(méi)啥特殊的地方，但是

它引入了一個(gè)子域和限界上下文的概念。

也就這兩個(gè)概念對(duì)我拆分微服務(wù)幫助最大。

子域本身其實(shí)就是以前的傳統(tǒng)手藝，就是拆分業(yè)務(wù)模塊就好。但是呢，它還引入了個(gè)思想——不同子域之間的同樣名稱(chēng)的專(zhuān)業(yè)術(shù)語(yǔ)，可能不是同一個(gè)東西。

而這，就是我解決 God 類(lèi)拆分需要的辦法。怎么解決的呢?就是配合著“限界上下文”這個(gè)概念來(lái)實(shí)現(xiàn)的。

子域和限界上下文聽(tīng)著很玄幻，其實(shí)就是傳統(tǒng)的業(yè)務(wù)模塊和業(yè)務(wù)模塊對(duì)應(yīng)的服務(wù)。只是限界上下文明確指出了，服務(wù)包含了實(shí)現(xiàn)的代碼，他們統(tǒng)稱(chēng)限界上下文。

在領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)思想里，每個(gè)子域間的同名專(zhuān)業(yè)術(shù)語(yǔ)其實(shí)可能是不一樣的。而這對(duì)應(yīng)到實(shí)現(xiàn)里，就是把原來(lái)的 God 類(lèi)給拆分了，在不同的子域里變成了不同的類(lèi)，每個(gè)子域中的類(lèi)都包含了以前 God 類(lèi)中的某些字段。比如，

• 原來(lái)電商系統(tǒng)里的訂單類(lèi)，它以前可能包含了用戶(hù)、訂購(gòu)的商品、用戶(hù)地址、金額等等。
• 但是在支付子域，對(duì)應(yīng)了支付限界上下文，同樣有一個(gè)訂單類(lèi)，只需要用戶(hù)，金額這兩個(gè)字段。
• 而在物流子域，對(duì)應(yīng)了物流限界上下文，同樣也有個(gè)叫訂單類(lèi)，可能只需要商品和用戶(hù)地址兩個(gè)字段。

所以，通過(guò)這種思想，God 類(lèi)阻礙微服務(wù)拆分的問(wèn)題就被解決了。

但是，在實(shí)現(xiàn)上還有個(gè)問(wèn)題沒(méi)有解決。因?yàn)槲覀儗?duì)用戶(hù)來(lái)說(shuō)是一套系統(tǒng)，所以，用戶(hù)看到的展示信息可能還是對(duì)應(yīng)著原來(lái)的 God 類(lèi)包含的所有字段信息。

比如電商系統(tǒng)，對(duì)用戶(hù)來(lái)講，訂單類(lèi)信息就包含了許多別的信息：商品、金額(支付子域)、用戶(hù)地址(物流子域)……

而這時(shí)候，其實(shí)微服務(wù)是有自己的 API 網(wǎng)關(guān)的，就需要通過(guò)微服務(wù)網(wǎng)關(guān)，把各微服務(wù)的數(shù)據(jù)聚合成用戶(hù)看到的訂單。

同時(shí)也是通過(guò) API 網(wǎng)關(guān)，會(huì)把用戶(hù)看到的訂單轉(zhuǎn)換成各個(gè)微服務(wù)之間需要的訂單信息，在其中不停流轉(zhuǎn)。而這種又是另外的模式了，以后的文章里會(huì)詳細(xì)說(shuō)到它。

五、還有很多問(wèn)題

我在這篇文章里說(shuō)我自己如何拆分微服務(wù)的經(jīng)歷。但是呢，微服務(wù)并不是想象的那么完美的，它其實(shí)還引出了許多新的問(wèn)題需要解決。

在下一篇文章里，我會(huì)談?wù)剟澐址?wù)后，引發(fā)的一些問(wèn)題。

我們下篇文章見(jiàn)。

本文轉(zhuǎn)載自微信公眾號(hào)「 四猿外」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系四猿外公眾號(hào)。