從我接觸微服務以來，迄今也得有五六年了。斷斷續續要麼從零開始，要麼中途接手，也經歷了 5 套微服務項目了。程序員
從這些項目中的經驗以及和同行交流來看，根據業務切分微服務的方法總的來講思路不復雜，可是落地老是出現了各類各樣的問題。一直到如今，我也還在探索着最好的微服務落地的最佳辦法。數據庫
在以前的文章我也提過，一個服務一個數據庫是微服務最基本的模式，也談了爲何要搞微服務。今天這篇文章我想談談：網絡
一個服務一個數據庫這種最基本的模式落地，大致的作法是怎麼樣的。架構
1、搞微服務，多是個政治問題
我第一次接觸微服務的時候，真的是無可奈何。異步
公司有一套大型系統，這套大型系統當時是負責公司的主要盈利業務，很是很是重要。可是，正由於重要，因此它就成爲了產品、業務團隊的重點服務對象。這些人每天想着把這套系統的業務作出花來，不斷對技術團隊提出各類各樣的需求。微服務
提出需求不說，還要求技術能快速迭代。一旦不能及時上線他們的需求，產品經理們就會在各類會議上抱怨，說技術團隊影響了速度，出現了讓競爭對手迎頭遇上的風險。工具
技術團隊有口難言，由於系統太龐大了，改動那麼大的系統真的很困難。至於緣由，我也在上篇文章說了，再也不贅述。性能
出於這些緣由，咱們決定採用微服務。設計
何時使用微服務？當你的交付時間不夠應付產品團隊，不夠應付運營團隊的時候，考慮考慮。還有，我後來搞其餘新項目時，領導認爲系統太簡單，沒有本身的技術特點。不得已，我又拿出了微服務，領導看了以後，眼前一亮，直說這個好。代理
因此，以個人經驗看，有時候搞微服務，本質是個政治問題不是技術問題。
總的來講，對於微服務落地，不是特別大型的項目，微服務帶來的好處不大，工做量反而增大了許多。
無論什麼緣由，我後續接觸的微服務愈來愈多了，爲了用好微服務，我真的是狠狠鑽研了下微服務這套體系架構，也總結了一些本身對微服務分解實踐的經驗。
- 首先，若是是預估到業務在飛速增加，那就別猶豫，必定要提早考慮微服務的拆分。
- 其次，若是在設計架構的時候，發現須要不少異構的技術棧，那也要考慮下微服務。
- 最後，若是公司技術基礎設施很是完備，對應的業務起初就設計的很是複雜，那麼也別猶豫，起手就上微服務。
2、遷移到微服務能夠很粗暴，也能夠很溫柔
回過頭來，繼續說我當時第一次搞微服務的事情。
因爲遷移微服務不是一蹴而就的事情，可是我又急需一些微服務的部署簡單、開發快速的優勢。因此，當時不得已，想了個折中的辦法。
我把一些急需實現的業務需求分析了下，發現這些需求大致能夠分爲如下兩類:
- 有些需求自己是一套獨立的邊緣業務
- 有些需求是集中在核心業務的邊緣上
我後來想一想，以爲這是理所應當的。業務和咱們技術同樣，若是動了核心業務的邏輯，萬一出現了問題，他們是要背大責任的。可是他們又要體現本身的價值，那最保險的就是在覈心業務的邊邊角角動些手腳。
知道了這些，那就好辦了。
對於第一類獨立的業務需求，我直接就設計出一套獨立服務，讓它和已有的老系統經過網絡遠程互聯。這樣的話，新搭建的服務很小，維護也簡單。之前的老系統也成爲新服務的服務。這樣，一部分需求，就能夠快速迭代了。
對於第二類需求，原有系統核心邊緣的需求，我是這樣作的。
- 首先，我爭取了領導的支持，優先對常常被提需求的業務模塊作了剝離。這樣，就剩下了一些不常常變更的業務模塊還在老系統。其實這些時候，系統也沒那麼大了，也能知足業務偶然提出的業務變更需求了。
- 而後，我會在後續的時間裏，慢慢的抽空把剩下的業務模塊沒事兒就剝離一些出來。可是，優先級很低。
- 這樣，慢慢的抽絲剝繭，最後，我發現，核心業務咱們都沒有動，一套微服務體系就已經搭建出來了。
有人可能會比較好奇，你這樣剝離，同時存在老系統和新系統。那外面的用戶使用會不會受影響呢？
其實，這裏還有個小技巧。就是我在拆微服務以前，先搭建了一個代理。這個代理就是專門路由外面用戶請求的。每次上線服務的時候，都會對這套代理進行一次微調整。這樣搞下來，用戶是感知不到背後新老系統並存的狀態的。
可是，說到這裏，我也要說一下，這個方法真的是比較粗暴的，是實在沒辦法才選擇這種方法。
後來，我再搞微服務的時候，吸收了不少教訓。總的方向仍是須要優先劃分出清晰的業務模塊，而後再根據業務模塊的劃分搞出微服務來。
總的來講，後期我設計微服務架構須要分爲兩個時期。而在這兩個時期，我又採用了不一樣的辦法。我分別來講說。
3、土法煉鋼的傳統業務劃分
在第一次被迫搞了微服務後，我對微服務這個架構開始了本身的研究。我知道了不少技術方面的細節，而如何劃分業務，我認可當時本身有點疏忽。因此，後來再有了新項目，我搞微服務的時候，是用的傳統業務劃分方法搞得微服務。
步驟以下:
第一步：劃分功能模塊
功能模塊劃分清楚這事兒其實還好，若是是從零開始的系統，業務尚不復雜，因此模塊也很容易劃分清楚。
若是是已有的大項目，那還得看看系統的源碼，根據源碼和業務文檔，把總體業務模塊搞清楚。
第二步：梳理功能模塊的方法
搞清楚業務模塊了還不夠，你還須要搞成分開的服務，因此，一定須要把服務之間的聯繫也給肯定好。這時候，若是是從零開始就很好搞了，本身根據業務劃分的狀況，直接自行建立對應的方法就好。
若是針對已有項目拆分，那就很差搞了。非得仔細梳理源碼，而後根據源碼的類和方法，逐次清理出各個模塊的之間的方法調用。很是麻煩。
第三步：對方法進行分類
把梳理出來的全部方法作一次分類，分紅兩類：功能模塊直接對外部用戶的方法，功能模塊內部之間須要調用的方法。
第四步：模塊映射服務，方法映射 API
方法梳理好了，分類完畢了，這時候得把功能模塊映射成服務了，這個過程是必不可少的。功能模塊映射成服務每每一開始其實很粗糙，就是先把一個功能模塊和服務進行一對一的映射。
可是，就個人經驗來講，這麼簡單的映射幾乎是不可能的。老是有各類落地問題迫使你再調整。
好了，作出了業務模塊和服務的一對一映射的假設，我們也梳理了業務模塊的方法調用了。那就把這些方法調用和服務的 API 方法作個一對一映射。固然，這個方法也是很粗糙的，幾乎老是存在須要調整的問題。
第五步： 根據實際狀況作調整。
最後，就開始根據我們上面的假設開始微調了，業務模塊和服務之間的映射被迫調整，主要由於如下幾個緣由:
1. 拆分後過多的網絡交互引發性能降低
當咱們拆分服務後，之前有些業務模塊間頻繁的方法調用，映射到服務之間，就變成了頻繁的網絡交互了。
咱們確定不能任其這樣頻繁的網絡調用。對這種狀況，就會有兩個辦法處理：1. 把服務之間的交互改爲批量處理的方式；2. 乾脆就不拆服務。
服務之間改爲批量處理還好，一旦決定不拆，就影響了之前設計好的映射關係了。
2. 同步調用可能引發的阻塞
還有些時候，之前本地調用搞成同步的方式，其實無傷大雅。由於你們在同一個進程裏，處理事件均可以忽略不計。
可是，現在分家了，搞成了服務之間的網絡調用，那事兒可就來了。網絡同步調用必須考慮容錯和阻塞，因此，對於同步調用這種，也得從兩個方面處理：1. 設置超時；2. 搞成異步方式處理。
若是一些同步方法搞成了異步方式，那服務的 API 和之前的方法映射關係可能就要調整了。
例如一個方法得對應兩個異步 API：一個是訪問，一個是獲取響應。
3. 原來的數據一致性可能要從新考慮
劃分服務後，最很差搞得就是數據一致性，而數據一致性這東西每每也避免不了。因此，微服務體系裏專門會有套模式來解決這個問題。我們放到之後的文章裏說。
4. 原來有些核心業務類可能和大部分業務緊密關聯
一套複雜的業務系統，一定會有一些核心的業務存在。在代碼實現裏，每每就會是一個字段不少的業務類。
好比電商系統裏的訂單，這就是個很核心的業務類。它會在不少業務裏用到。對於這種類，他們有個專業名詞叫作 God 類。
God 類自己由於和太多的業務掛鉤了，等到你分服務的時候，你才意識到，我跋山涉水都快走完拆分步驟了，猛然由於一個 God 類，把哥們兒整的都快不會了。
God 類字段太多，不少業務都須要。
因此，它真的阻礙了不少業務被拆分。而在此時，我尚沒仔細領會到領域驅動設計的精髓，因此，沒辦法，此時我只能把這些個 God 類給單獨拎出來弄成個微服務。
可是，這真的是很醜陋的。
首先，這純粹是因陋就簡搞的土法分微服務，它徹底沒有任何業務。
其次，因爲沒有業務，因此也就沒有方向沒有限制，到時候誰想加訪問數據的 API 了，就隨意加了。
最後，這些 God 類對應的微服務會被不少的微服務模塊訪問，它的壓力很是大，還得爲此搞一些集羣，得不償失。
4、換種思路解決難題的領域驅動工具
其實，一路走來，我使用傳統的業務劃分真沒有遇到太多的問題。就是 God 類把我打擊的不行，我老是想找個辦法去解決它。
當我看了領域驅動設計以後，我明白了，這玩意兒就是換個思路就行了。領域驅動設計其實沒啥特殊的地方，可是
它引入了一個子域和限界上下文的概念。
也就這兩個概念對我拆分微服務幫助最大。
子域自己其實就是之前的傳統手藝，就是拆分業務模塊就好。可是呢，它還引入了個思想——不一樣子域之間的一樣名稱的專業術語，可能不是同一個東西。
而這，就是我解決 God 類拆分須要的辦法。怎麼解決的呢？就是配合着「限界上下文」這個概念來實現的。
子域和限界上下文聽着很玄幻，其實就是傳統的業務模塊和業務模塊對應的服務。只是限界上下文明確指出了，服務包含了實現的代碼，他們統稱限界上下文。
在領域驅動設計思想裏，每一個子域間的同名專業術語其實多是不同的。而這對應到實現裏，就是把原來的 God 類給拆分了，在不一樣的子域裏變成了不一樣的類，每一個子域中的類都包含了之前 God 類中的某些字段。好比，
- 原來電商系統裏的訂單類，它之前可能包含了用戶、訂購的商品、用戶地址、金額等等。
- 可是在支付子域，對應了支付限界上下文，一樣有一個訂單類，只須要用戶，金額這兩個字段。
- 而在物流子域，對應了物流限界上下文，一樣也有個叫訂單類，可能只須要商品和用戶地址兩個字段。
因此，經過這種思想，God 類阻礙微服務拆分的問題就被解決了。
可是，在實現上還有個問題沒有解決。由於咱們對用戶來講是一套系統，因此，用戶看到的展現信息可能仍是對應着原來的 God 類包含的全部字段信息。
好比電商系統，對用戶來說，訂單類信息就包含了許多別的信息：商品、金額（支付子域）、用戶地址（物流子域）……
而這時候，其實微服務是有本身的 API 網關的，就須要經過微服務網關，把各微服務的數據聚合成用戶看到的訂單。
同時也是經過 API 網關，會把用戶看到的訂單轉換成各個微服務之間須要的訂單信息，在其中不停流轉。而這種又是另外的模式了，之後的文章裏會詳細說到它。
5、還有不少問題
我在這篇文章裏說我本身如何拆分微服務的經歷。可是呢，微服務並非想象的那麼完美的，它其實還引出了許多新的問題須要解決。
在下一篇文章裏，我會談談劃分服務後，引起的一些問題。
咱們下篇文章見。
你好，我是四猿外，一家上市公司的技術總監，管理的技術團隊一百餘人。
我從一名非計算機專業的畢業生，轉行到程序員，一路打拼，一路成長。
我會把本身的成長故事寫成文章，把枯燥的技術文章寫成故事。
歡迎關注個人公衆號：四猿外