快捷導(dǎo)航

微服務(wù)架構(gòu)拆分策略詳解

更新時(shí)間：2022年01月28日 10:48:43 作者：Brand

這一章我們就來探討如何做微服務(wù)架構(gòu)的拆分，微服務(wù)拆分沒有一個(gè)絕對的標(biāo)準(zhǔn)答案，服務(wù)拆分的粒度需要根據(jù)業(yè)務(wù)場景來規(guī)劃，而隨著業(yè)務(wù)的發(fā)展，原先的架構(gòu)方案也需要做調(diào)整雖然沒有固定的套路，但是我們在業(yè)務(wù)實(shí)踐過程中總結(jié)的一些經(jīng)驗(yàn)，以做參考

對于新啟動的項(xiàng)目，我們在權(quán)衡之后可以大方的使用微服務(wù)架構(gòu)。但其實(shí)大部分情況下，我們還要去維護(hù)一些以前研發(fā)的單體系統(tǒng)，這些系統(tǒng)可能因?yàn)樵L問流量的膨脹、功能的擴(kuò)張而顯得非常臃腫不堪，急需要向微服務(wù)架構(gòu)遷移。

1 微服務(wù)遷移準(zhǔn)備

1、需對業(yè)務(wù)充分了解，這是服務(wù)拆分，通信設(shè)計(jì)，資源整合的必要前提。

2、適應(yīng)微服務(wù)架構(gòu)設(shè)計(jì)原則：小版本，高速迭代。

3、快速的環(huán)境提供能力：依賴于云計(jì)算、容器技術(shù)，快速交付環(huán)境。

4、服務(wù)合理拆分：需符合團(tuán)隊(duì)結(jié)構(gòu)或能逆向影響，能對組織架構(gòu)進(jìn)行微調(diào)并劃分職責(zé)。（康威定律和逆康威定律）

5、基本的監(jiān)控能力：包括基礎(chǔ)的技術(shù)監(jiān)控和業(yè)務(wù)監(jiān)控。

6、快速的應(yīng)用部署能力：需要部署管道提供快速的部署能力。

7、DevOps 自動化運(yùn)維能力：需要具有良好的持續(xù)集成和持續(xù)交付能力，還需要對問題、故障的快速響應(yīng)能力，開發(fā)、測試和運(yùn)維能協(xié)同工作。

2 微服務(wù)顆粒的拆分策略

前面兩篇文章我們學(xué)習(xí)了What & Why（什么是微服務(wù)和為什么需要做微服務(wù)架構(gòu)），這一章我們就來探討如何做微服務(wù)架構(gòu)的拆分（How）。

微服務(wù)拆分沒有一個(gè)絕對的標(biāo)準(zhǔn)答案，服務(wù)拆分的粒度需要根據(jù)業(yè)務(wù)場景來規(guī)劃，而隨著業(yè)務(wù)的發(fā)展，原先的架構(gòu)方案也需要做調(diào)整。

雖然沒有固定的套路，但是我們在業(yè)務(wù)實(shí)踐過程中總結(jié)的一些經(jīng)驗(yàn)，以做參考。

2.1 基于業(yè)務(wù)邏輯拆分

基于業(yè)務(wù)邏輯拆分相對好理解一點(diǎn)，典型的單一職責(zé)原則，我們將功能相近的業(yè)務(wù)整合到一個(gè)服務(wù)顆粒上。比如一個(gè)辦公領(lǐng)域系統(tǒng)，考勤、工作流、音視頻會議是是三個(gè)截然不同的業(yè)務(wù)領(lǐng)域，這可能就是我們拆分的一個(gè)入手點(diǎn)。

2.1.1 領(lǐng)域模型拆分

領(lǐng)域驅(qū)動設(shè)計(jì)DDD（Domain-Driven Design 領(lǐng)域驅(qū)動設(shè)計(jì)）是一個(gè)很簡單的概念，表示我們對系統(tǒng)的劃分是基于領(lǐng)域的，也即是基于業(yè)務(wù)方向去思考的。

舉一個(gè)典型的電商業(yè)務(wù)例子。電商的業(yè)務(wù)體系龐大，涉及各方面的細(xì)節(jié)。但是我們大概能夠根據(jù)業(yè)務(wù)的職能做一個(gè)拆分，比如阿里的電商中臺業(yè)務(wù)，包含用戶賬號子系統(tǒng)、商品子系統(tǒng)、訂單子系統(tǒng)、客戶子系統(tǒng)、物流子系統(tǒng) 等。

因?yàn)槁毮懿煌?，這些領(lǐng)域之間包含清晰的界限，所以我們可以按照這個(gè)方向?qū)⒎?wù)于不同領(lǐng)域（商品域和訂單域）的子系統(tǒng)拆成獨(dú)立的服務(wù)顆粒。如下圖：

2.1.2 用戶群體拆分

根據(jù)用戶群體做拆分，我們首先要了解自己的系統(tǒng)業(yè)務(wù)里的用戶角色領(lǐng)域是否沒有功能耦合，有清晰的領(lǐng)域界限。

比如教育信息化系統(tǒng)，教師的業(yè)務(wù)場景和學(xué)生的業(yè)務(wù)場景，基本比較獨(dú)立，而且拆分后流量上有明顯的削弱，這時(shí)候結(jié)合具體的業(yè)務(wù)分析，看是否有價(jià)值。如下圖所示：

2.2 基于可擴(kuò)展拆分

這個(gè)需要區(qū)分系統(tǒng)中變與不變的部分，不變的部分一般是成熟的、通用的服務(wù)功能，變的部分一般是改動比較多、滿足業(yè)務(wù)迭代擴(kuò)展性需要的功能，我們可以將不變的部分拆分出來，作為共用的服務(wù)，將變的部分獨(dú)立出來滿足個(gè)性化擴(kuò)展需要。

同時(shí)根據(jù)二八原則，系統(tǒng)中經(jīng)常變動的部分大約只占 20%，而剩下的 80% 基本不變或極少變化，這樣的拆分也解決了發(fā)布頻率過多而影響成熟服務(wù)穩(wěn)定性的問題。

比如一個(gè)電商領(lǐng)域的系統(tǒng)，用戶信息、基本商品信息、物流信息等模塊的管理能力和視圖界面，一般是比較穩(wěn)定的；而類似運(yùn)營活動的功能和頁面一般是經(jīng)常變化的（520、618、雙11），會有不同的活動策略和視圖界面，需要經(jīng)常迭代發(fā)布。如下圖所示< /p>

2.3 基于可靠性拆分

2.3.1 核心模塊拆分

我們團(tuán)隊(duì)在做MySQL數(shù)據(jù)庫和Redis集群拆分的時(shí)候，總會把一些重要的模塊獨(dú)立放在一個(gè)集群上，不與其他模塊混用，而這個(gè)獨(dú)立的集群，服務(wù)機(jī)性能要是最好的。這樣做的目的是，當(dāng)重要度較低的模塊發(fā)生故障時(shí)，不會影響重要度高的模塊。

同要的道理，我們會將賬號信息、登錄信息、服務(wù)中心等重要度最高的要害模塊單獨(dú)拆分在一個(gè)服務(wù)顆粒上（因?yàn)檫@類模塊不可用之后，整個(gè)系統(tǒng)基本完全癱瘓），再做成服務(wù)集群，來保障它的高可用。如下圖所示：