從我接觸微服務以來，迄今也得有五六年了。斷斷續續要麼從零開始，要麼中途接手，也經歷了 5 套微服務專案了。
從這些專案中的經驗以及和同行交流來看，根據業務切分微服務的方法總的來說思路不復雜，但是落地總是出現了各種各樣的問題。一直到現在，我也還在探索著最好的微服務落地的最佳辦法。
在上一篇文章我也提過，一個服務一個資料庫是微服務最基本的模式，也談了為什麼要搞微服務。今天這篇文章我想談談：
一個服務一個資料庫這種最基本的模式落地，大體的做法是怎麼樣的。
一、搞微服務，可能是個政治問題
我第一次接觸微服務的時候，真的是迫不得已。
公司有一套大型系統，這套大型系統當時是負責公司的主要盈利業務，非常非常重要。但是，正因為重要，所以它就成為了產品、業務團隊的重點服務物件。這些人天天想著把這套系統的業務做出花來，不斷對技術團隊提出各種各樣的需求。
提出需求不說，還要求技術能快速迭代。一旦不能及時上線他們的需求，產品經理們就會在各種會議上抱怨，說技術團隊影響了速度，出現了讓競爭對手迎頭趕上的風險。
技術團隊有口難言，因為系統太龐大了，改動那麼大的系統真的很困難。至於原因，我也在上篇文章說了，不再贅述。
出於這些原因，我們決定採用微服務。
什麼時候使用微服務？當你的交付時間不夠應付產品團隊，不夠應付運營團隊的時候，考慮考慮。還有，我後來搞其他新專案時，領導認為系統太簡單，沒有自己的技術特色。不得已，我又拿出了微服務，領導看了之後，眼前一亮，直說這個好。
所以，以我的經驗看，有時候搞微服務，本質是個政治問題不是技術問題。
總的來說，對於微服務落地，不是特別大型的專案，微服務帶來的好處不大，工作量反而增大了許多。
不管什麼原因，我後續接觸的微服務越來越多了，為了用好微服務，我真的是狠狠鑽研了下微服務這套體系架構，也總結了一些自己對微服務分解實踐的經驗。
- 首先，如果是預估到業務在飛速增長，那就別猶豫，一定要提前考慮微服務的拆分。
- 其次，如果在設計架構的時候，發現需要很多異構的技術棧，那也要考慮下微服務。
- 最後，如果公司技術基礎設施非常完備，對應的業務起初就設計的非常複雜，那麼也別猶豫，起手就上微服務。
二、遷移到微服務可以很粗暴，也可以很溫柔
回過頭來，繼續說我當時第一次搞微服務的事情。
由於遷移微服務不是一蹴而就的事情，但是我又急需一些微服務的部署簡單、開發快速的優點。所以，當時不得已，想了個折中的辦法。
我把一些急需實現的業務需求分析了下，發現這些需求大體可以分為以下兩類:
- 有些需求本身是一套獨立的邊緣業務
- 有些需求是集中在核心業務的邊緣上
我後來想想，覺得這是理所應當的。業務和我們技術一樣，如果動了核心業務的邏輯，萬一出現了問題，他們是要背大責任的。但是他們又要體現自己的價值，那最保險的就是在核心業務的邊邊角角動些手腳。
知道了這些，那就好辦了。
對於第一類獨立的業務需求，我直接就設計出一套獨立服務，讓它和已有的老系統通過網路遠端互聯。這樣的話，新搭建的服務很小，維護也簡單。以前的老系統也成為新服務的服務。這樣，一部分需求，就可以快速迭代了。
對於第二類需求，原有系統核心邊緣的需求，我是這樣做的。
- 首先，我爭取了領導的支援，優先對經常被提需求的業務模組做了剝離。這樣，就剩下了一些不經常變動的業務模組還在老系統。其實這些時候，系統也沒那麼大了，也能滿足業務偶然提出的業務變動需求了。
- 然後，我會在後續的時間裡，慢慢的抽空把剩下的業務模組沒事兒就剝離一些出來。但是，優先順序很低。
- 這樣，慢慢的抽絲剝繭，最後，我發現，核心業務我們都沒有動，一套微服務體系就已經搭建出來了。
有人可能會比較好奇，你這樣剝離，同時存在老系統和新系統。那外面的使用者使用會不會受影響呢？
其實，這裡還有個小技巧。就是我在拆微服務之前，先搭建了一個代理。這個代理就是專門路由外面使用者請求的。每次上線服務的時候，都會對這套代理進行一次微調整。這樣搞下來，使用者是感知不到背後新老系統並存的狀態的。
但是，說到這裡，我也要說一下，這個方法真的是比較粗暴的，是實在沒辦法才選擇這種方法。
後來，我再搞微服務的時候，吸取了很多教訓。總的方向還是需要優先劃分出清晰的業務模組，然後再根據業務模組的劃分搞出微服務來。
總的來說，後期我設計微服務架構需要分為兩個時期。而在這兩個時期，我又採用了不同的辦法。我分別來說說。
三、土法煉鋼的傳統業務劃分
在第一次被迫搞了微服務後，我對微服務這個架構開始了自己的研究。我知道了很多技術方面的細節，而如何劃分業務，我承認當時自己有點疏忽。所以，後來再有了新專案，我搞微服務的時候，是用的傳統業務劃分方法搞得微服務。
步驟如下:
第一步：劃分功能模組
功能模組劃分清楚這事兒其實還好，如果是從零開始的系統，業務尚不復雜，所以模組也很容易劃分清楚。
如果是已有的大專案，那還得看看系統的原始碼，根據原始碼和業務文件，把整體業務模組搞清楚。
第二步：梳理功能模組的方法
搞清楚業務模組了還不夠，你還需要搞成分開的服務，所以，必定需要把服務之間的聯絡也給確定好。這時候，如果是從零開始就很好搞了，自己根據業務劃分的情況，直接自行建立對應的方法就好。
如果針對已有專案拆分，那就不好搞了。非得仔細梳理原始碼，然後根據原始碼的類和方法，逐次清理出各個模組的之間的方法呼叫。非常麻煩。
第三步：對方法進行分類
把梳理出來的所有方法做一次分類，分成兩類：功能模組直接對外部使用者的方法，功能模組內部之間需要呼叫的方法。
第四步：模組對映服務，方法對映 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 閘道器，會把使用者看到的訂單轉換成各個微服務之間需要的訂單資訊，在其中不停流轉。而這種又是另外的模式了，以後的文章裡會詳細說到它。
五、還有很多問題
我在這篇文章裡說我自己如何拆分微服務的經歷。但是呢，微服務並不是想象的那麼完美的，它其實還引出了許多新的問題需要解決。
在下一篇文章裡，我會談談劃分服務後，引發的一些問題。
我們下篇文章見。
你好，我是四猿外。
一家上市公司的技術總監，管理的技術團隊一百餘人。
我從一名非計算機專業的畢業生，轉行到程式設計師，一路打拼，一路成長。
我會通過公眾號，
把自己的成長故事寫成文章，
把枯燥的技術文章寫成故事。
我建了一個讀者交流群，裡面大部分是程式設計師，一起聊技術、工作、八卦。歡迎加我微信，拉你入群
