如何落實微服務模式

本篇內容主要講解“如何落實微服務模式”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“如何落實微服務模式”吧!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. 有些需求本身是一套獨立的邊緣業務

3. 有些需求是集中在核心業務的邊緣上

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

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

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

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

• 首先，我爭取了領導的支持，優先對經常被提需求的業務模塊做了剝離。這樣，就剩下了一些不經常變動的業務模塊還在老系統。其實這些時候，系統也沒那么大了，也能滿足業務偶然提出的業務變動需求了。

• 然后，我會在后續的時間里，慢慢的抽空把剩下的業務模塊沒事兒就剝離一些出來。但是，優先級很低。

• 這樣，慢慢的抽絲剝繭，最后，我發現，核心業務我們都沒有動，一套微服務體系就已經搭建出來了。

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

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

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

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

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

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

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

步驟如下:

第一步：劃分功能模塊

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

如果是已有的大項目，那還得看看系統的源碼，根據源碼和業務文檔，把整體業務模塊搞清楚。

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

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

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

第三步：對方法進行分類

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

第四步：模塊映射服務，方法映射 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  網關，會把用戶看到的訂單轉換成各個微服務之間需要的訂單信息，在其中不停流轉。而這種又是另外的模式了，以后的文章里會詳細說到它。

到此，相信大家對“如何落實微服務模式”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！