微服務(wù)架構(gòu)及其演進史

微服務(wù)全景架構(gòu)全面瓦解

前面我們學(xué)習(xí)了微服務(wù)的全景架構(gòu)，了解到相對于傳統(tǒng)單體架構(gòu)，微服務(wù)的優(yōu)勢，以及系統(tǒng)服務(wù)化的發(fā)展趨勢。 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1.2 用戶群體拆分

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

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

2.2 基于可擴展拆分 

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

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

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

2.3 基于可靠性拆分

2.3.1 核心模塊拆分

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

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

2.3.2 主次鏈路拆分

在各個業(yè)務(wù)系統(tǒng)中，其實都會有主次業(yè)務(wù)鏈路。主業(yè)務(wù)鏈條，完成了業(yè)務(wù)系統(tǒng)中最核心的那部分工作。而次鏈路是保證其他基礎(chǔ)功能的穩(wěn)定運行。

以電商為例子：商品搜索->商品詳情頁->購物車模塊->訂單結(jié)算->支付業(yè)務(wù)，就是一條最簡單的主鏈路。主鏈路是整個系統(tǒng)的核心主戰(zhàn)場，最好的資源跟火力都要放在這里，保證不失守。

一個系統(tǒng)一般有多條核心鏈路和多條次鏈路，互相支持構(gòu)成一個完整的系統(tǒng)。而我們將主次鏈路進行拆分，主要為了以下幾個目標(biāo)。

異常容錯

為主鏈路建立層次化的降級策略（多級降級），以及合理的熔斷策略，這部分我們將在Hystrix服務(wù)容錯降級的文章中詳細解釋。

計算資源分配

主鏈路通常來講都是高頻場景，自然需要更多的計算資源，最主要的體現(xiàn)就是集群里分配的虛機數(shù)量多。比如電商場景中特惠專場搶購等。

但是無論是虛機的分配，還是kubernetes的動態(tài)擴縮容，應(yīng)該都需要單獨優(yōu)待，如資源分配傾斜，獨立治理等。

服務(wù)隔離

主鏈路是高頻且核心的主業(yè)務(wù)模塊，把主鏈路的服務(wù)與其他起輔助作用的業(yè)務(wù)服務(wù)隔離開來，避免次鏈路服務(wù)的異常情況影響到主鏈路服務(wù)。 

2.4 基于性能需求拆分

根據(jù)性能需求來進行拆分。簡單來說就是訪問量特別大，訪問頻率特別高的業(yè)務(wù)，又要保證高效的響應(yīng)能力，這些業(yè)務(wù)對性能的要求特別高。比如積分競拍、低價秒殺、**搶購。

我們要識別出某些超高并發(fā)量的業(yè)務(wù)，盡可能把這部分業(yè)務(wù)獨立拆分出來。這么做的原因非常簡單，一個保證滿足高性能業(yè)務(wù)需求，另一個保證業(yè)務(wù)的獨立性，不互相影響。 

類似積分競拍、超低價秒殺、**搶購，對瞬間峰值和計算性能要求是非常高的。這部分的業(yè)務(wù)如果跟其他通用業(yè)務(wù)放在一塊，一個是可能互相影響，比如某個鏈路阻塞，會導(dǎo)致雪崩沿調(diào)用鏈向上傳遞。

另外一個是如果多個業(yè)務(wù)耦合在一塊，發(fā)布頻率變高、服務(wù)擴縮容變難、維護復(fù)雜度變高。

3 總結(jié)拆分原則

• 先少后多（微服務(wù)數(shù)量）、先粗后細(粒度)
• 基于業(yè)務(wù)邏輯進行拆分（用戶群體、業(yè)務(wù)領(lǐng)域等模型）
• 基于可靠性（核心模塊獨立化、主次鏈路隔離）
• 基于性能拆分（獨立拆分高性能場景）
• 接口需保證冪等
• 接口數(shù)據(jù)定義嚴(yán)禁內(nèi)嵌，透傳
• 規(guī)范化工程結(jié)構(gòu)，符合微服務(wù)風(fēng)格
• 不止對計算服務(wù)記性拆分，服務(wù)層 -> 緩存層 -> 數(shù)據(jù)層 的逐步拆解，才能發(fā)揮最大功效。

以上就是微服務(wù)架構(gòu)拆分策略詳解的詳細內(nèi)容，更多關(guān)于微服務(wù)拆分策略的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論