從我接觸微服務以來，迄今也得有五六年了，斷斷續續要么從零開始，要么中途接手，也經歷了 5 套微服務專案了，

從這些專案中的經驗以及和同行交流來看，根據業務切分微服務的方法總的來說思路不復雜，但是落地總是出現了各種各樣的問題，一直到現在，我也還在探索著最好的微服務落地的最佳辦法，

在上一篇文章我也提過，一個服務一個資料庫是微服務最基本的模式，也談了為什么要搞微服務，今天這篇文章我想談談：

一個服務一個資料庫這種最基本的模式落地，大體的做法是怎么樣的，

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

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

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

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

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

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

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

所以，以我的經驗看，有時候搞微服務，本質是個政治問題不是技術問題，

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

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

• 首先，如果是預估到業務在飛速增長，那就別猶豫，一定要提前考慮微服務的拆分，
• 其次，如果在設計架構的時候，發現需要很多異構的技術堆疊，那也要考慮下微服務，
• 最后，如果公司技識訓礎設施非常完備，對應的業務起初就設計的非常復雜，那么也別猶豫，起手就上微服務，

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

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

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

我把一些急需實作的業務需求分析了下，發現這些需求大體可以分為以下兩類:

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

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

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

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

對于第二類需求，原有系統核心邊緣的需求，我是這樣做的，

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

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

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

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

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

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

三、土法煉鋼的傳統業務劃分

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

步驟如下:

第一步：劃分功能模塊

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

如果是已有的大專案，那還得看看系統的原始碼，根據原始碼和業務檔案，把整體業務模塊搞清楚，

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

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

如果針對已有專案拆分，那就不好搞了，非得仔細梳理原始碼，然后根據原始碼的類和方法，逐次清理出各個模塊的之間的方法呼叫，非常麻煩，

第三步：對方法進行分類

把梳理出來的所有方法做一次分類，分成兩類：功能模塊直接對外部用戶的方法，功能模塊內部之間需要呼叫的方法，

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

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

但是，就我的經驗來說，這么簡單的映射幾乎是不可能的，總是有各種落地問題迫使你再調整，

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

第五步： 根據實際情況做調整，

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

1. 拆分后過多的網路互動引起性能下降

當我們拆分服務后，以前有些業務模塊間頻繁的方法呼叫，映射到服務之間，就變成了頻繁的網路互動了，

我們肯定不能任其這樣頻繁的網路呼叫，對這種情況，就會有兩個辦法處理：1. 把服務之間的互動改成批量處理的方式；2. 干脆就不拆服務，

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

2. 同步呼叫可能引起的阻塞

還有些時候，以前本地呼叫搞成同步的方式，其實無傷大雅，因為大家在同一個行程里，處理事件都可以忽略不計，

但是，如今分家了，搞成了服務之間的網路呼叫，那事兒可就來了，網路同步呼叫必須考慮容錯和阻塞，所以，對于同步呼叫這種，也得從兩個方面處理：1. 設定超時；2. 搞成異步方式處理，

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

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

3. 原來的資料一致性可能要重新考慮

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

4. 原來有些核心業務類可能和大部分業務緊密關聯

一套復雜的業務系統，必定會有一些核心的業務存在，在代碼實作里，往往就會是一個欄位很多的業務類，

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

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

God 類欄位太多，很多業務都需要，

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

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

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

其次，由于沒有業務，所以也就沒有方向沒有限制，到時候誰想加訪問資料的 API 了，就隨意加了，

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

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

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

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

它引入了一個子域和限界背景關系的概念，

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

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

而這，就是我解決 God 類拆分需要的辦法，怎么解決的呢？就是配合著“限界背景關系”這個概念來實作的，

子域和限界背景關系聽著很玄幻，其實就是傳統的業務模塊和業務模塊對應的服務，只是限界背景關系明確指出了，服務包含了實作的代碼，他們統稱限界背景關系，

在領域驅動設計思想里，每個子域間的同名專業術語其實可能是不一樣的，而這對應到實作里，就是把原來的 God 類給拆分了，在不同的子域里變成了不同的類，每個子域中的類都包含了以前 God 類中的某些欄位，比如，

• 原來電商系統里的訂單類，它以前可能包含了用戶、訂購的商品、用戶地址、金額等等，
• 但是在支付子域，對應了支付限界背景關系，同樣有一個訂單類，只需要用戶，金額這兩個欄位，
• 而在物流子域，對應了物流限界背景關系，同樣也有個叫訂單類，可能只需要商品和用戶地址兩個欄位，

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

但是，在實作上還有個問題沒有解決，因為我們對用戶來說是一套系統，所以，用戶看到的展示資訊可能還是對應著原來的 God 類包含的所有欄位資訊，

比如電商系統，對用戶來講，訂單類資訊就包含了許多別的資訊：商品、金額（支付子域）、用戶地址（物流子域）……

而這時候，其實微服務是有自己的 API 網關的，就需要通過微服務網關，把各微服務的資料聚合成用戶看到的訂單，

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

五、還有很多問題

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

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

我們下篇文章見，

你好，我是四猿外，

一家上市公司的技術總監，管理的技術團隊一百余人，

我從一名非計算機專業的畢業生，轉行到程式員，一路打拼，一路成長，

我會通過公眾號，
把自己的成長故事寫成文章，
把枯燥的技術文章寫成故事，

我建了一個讀者交流群，里面大部分是程式員，一起聊技術、作業、八卦，歡迎加我微信，拉你入群

標籤：架構設計

上一篇：mybatis學習筆記

下一篇：Kafka原始碼分析(二) - 生產者