[[395974]]

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

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

在之前的文章我也提過，一個服務一個數(shù)據(jù)庫是微服務最基本的模式，也談了為什么要搞微服務。今天這篇文章我想談談：

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

一、搞微服務，可能是個政治問題

我第一次接觸微服務的時候，真的是迫不得已。

公司有一套大型系統(tǒng)，這套大型系統(tǒng)當時是負責公司的主要盈利業(yè)務，非常非常重要。但是，正因為重要，所以它就成為了產(chǎn)品、業(yè)務團隊的重點服務對象。這些人天天想著把這套系統(tǒng)的業(yè)務做出花來，不斷對技術團隊提出各種各樣的需求。

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

技術團隊有口難言，因為系統(tǒng)太龐大了，改動那么大的系統(tǒng)真的很困難。至于原因，我也在上篇文章說了，不再贅述。

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

什么時候使用微服務?當你的交付時間不夠應付產(chǎn)品團隊，不夠應付運營團隊的時候，考慮考慮。還有，我后來搞其他新項目時，領導認為系統(tǒng)太簡單，沒有自己的技術特色。不得已，我又拿出了微服務，領導看了之后，眼前一亮，直說這個好。

所以，以我的經(jīng)驗看，有時候搞微服務，本質(zhì)是個政治問題不是技術問題。

總的來說，對于微服務落地，不是特別大型的項目，微服務帶來的好處不大，工作量反而增大了許多。

不管什么原因，我后續(xù)接觸的微服務越來越多了，為了用好微服務，我真的是狠狠鉆研了下微服務這套體系架構，也總結了一些自己對微服務分解實踐的經(jīng)驗。

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

其次，如果在設計架構的時候，發(fā)現(xiàn)需要很多異構的技術棧，那也要考慮下微服務。

最后，如果公司技術基礎設施非常完備，對應的業(yè)務起初就設計的非常復雜，那么也別猶豫，起手就上微服務。

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

回過頭來，繼續(xù)說我當時第一次搞微服務的事情。

由于遷移微服務不是一蹴而就的事情，但是我又急需一些微服務的部署簡單、開發(fā)快速的優(yōu)點。所以，當時不得已，想了個折中的辦法。

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

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

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

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

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

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

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

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

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

但是，說到這里，我也要說一下，這個方法真的是比較粗暴的，是實在沒辦法才選擇這種方法。

后來，我再搞微服務的時候，吸取了很多教訓。總的方向還是需要優(yōu)先劃分出清晰的業(yè)務模塊，然后再根據(jù)業(yè)務模塊的劃分搞出微服務來。

總的來說，后期我設計微服務架構需要分為兩個時期。而在這兩個時期，我又采用了不同的辦法。我分別來說說。

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

在第一次被迫搞了微服務后，我對微服務這個架構開始了自己的研究。我知道了很多技術方面的細節(jié)，而如何劃分業(yè)務，我承認當時自己有點疏忽。所以，后來再有了新項目，我搞微服務的時候，是用的傳統(tǒng)業(yè)務劃分方法搞的微服務。

步驟如下:

第一步：劃分功能模塊

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

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

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

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

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

第三步：對方法進行分類

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

第四步：模塊映射服務，方法映射 API

方法梳理好了，分類完畢了，這時候得把功能模塊映射成服務了，這個過程是必不可少的。功能模塊映射成服務往往一開始其實很粗糙，就是先把一個功能模塊和服務進行一對一的映射。

但是，就我的經(jīng)驗來說，這么簡單的映射幾乎是不可能的。總是有各種落地問題迫使你再調(diào)整。

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

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

最后，就開始根據(jù)咱們上面的假設開始微調(diào)了，業(yè)務模塊和服務之間的映射被迫調(diào)整，主要因為以下幾個原因:

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

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

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

服務之間改成批量處理還好，一旦決定不拆，就影響了以前設計好的映射關系了。

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

還有些時候，以前本地調(diào)用搞成同步的方式，其實無傷大雅。因為大家在同一個進程里，處理事件都可以忽略不計。

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

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

例如一個方法得對應兩個異步 API：一個是訪問，一個是獲取響應。

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

劃分服務后，最不好搞的就是數(shù)據(jù)一致性，而數(shù)據(jù)一致性這東西往往也避免不了。所以，微服務體系里專門會有套模式來解決這個問題。咱們放到以后的文章里說。

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

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

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

God 類本身因為和太多的業(yè)務掛鉤了，等到你分服務的時候，你才意識到，我跋山涉水都快走完拆分步驟了，猛然因為一個 God 類，把哥們兒整的都快不會了。

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

所以，它真的阻礙了很多業(yè)務被拆分。而在此時，我尚沒仔細領會到領域驅(qū)動設計的精髓，所以，沒辦法，此時我只能把這些個 God 類給單獨拎出來弄成個微服務。

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

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

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

最后，這些 God 類對應的微服務會被很多的微服務模塊訪問，它的壓力非常大，還得為此搞一些集群，得不償失。

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

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

當我看了領域驅(qū)動設計之后，我明白了，這玩意兒就是換個思路就好了。領域驅(qū)動設計其實沒啥特殊的地方，但是

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

也就這兩個概念對我拆分微服務幫助最大。

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

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

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

在領域驅(qū)動設計思想里，每個子域間的同名專業(yè)術語其實可能是不一樣的。而這對應到實現(xiàn)里，就是把原來的 God 類給拆分了，在不同的子域里變成了不同的類，每個子域中的類都包含了以前 God 類中的某些字段。比如，

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

所以，通過這種思想，God 類阻礙微服務拆分的問題就被解決了。

但是，在實現(xiàn)上還有個問題沒有解決。因為我們對用戶來說是一套系統(tǒng)，所以，用戶看到的展示信息可能還是對應著原來的 God 類包含的所有字段信息。

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

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

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

五、還有很多問題

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

在下一篇文章里，我會談談劃分服務后，引發(fā)的一些問題。

我們下篇文章見。

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