微服務(wù)業(yè)務(wù)拆分規(guī)范與邊界設(shè)計(jì)老板說咱們把系統(tǒng)拆成微服務(wù)吧你二話不說把每個(gè) Controller 拆成一個(gè)服務(wù)。第二天發(fā)現(xiàn)要用 30 個(gè) Git 倉(cāng)庫(kù)、40 個(gè)端口、50 個(gè) Docker 容器你崩潰了。拆分不是數(shù)學(xué)除法拆分是一門如何優(yōu)雅地切蛋糕的藝術(shù)。一、拆分前先問自己三個(gè)問題在動(dòng)手之前請(qǐng)對(duì)著鏡子問自己團(tuán)隊(duì)有幾個(gè)人3個(gè)人維護(hù)15個(gè)微服務(wù) 災(zāi)難系統(tǒng)真的需要嗎日均PV不到1萬的單體改微服務(wù) 自找麻煩部署能力跟得上嗎微服務(wù)需要容器化、CI/CD、監(jiān)控體系微服務(wù)不是銀彈。它解決的是組織復(fù)雜度和規(guī)?；瘑栴}但對(duì)小團(tuán)隊(duì)、小系統(tǒng)而言它帶來的運(yùn)維成本遠(yuǎn)高于收益。二、核心原則三大鐵律2.1 單一職責(zé)原則SRP一個(gè)微服務(wù)只做一件事并且把它做好。不是一個(gè)Controller拆一個(gè)服務(wù)而是一個(gè)業(yè)務(wù)邊界對(duì)應(yīng)一個(gè)服務(wù)。反面例子把用戶注冊(cè)、商品管理、優(yōu)惠券三個(gè)無關(guān)功能塞進(jìn)一個(gè)服務(wù)——改個(gè)優(yōu)惠券規(guī)則要重啟整個(gè)服務(wù)炸得所有人登錄不了。2.2 限界上下文Bounded Context這是 DDD領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的核心概念。簡(jiǎn)單說就是在一個(gè)邊界里每個(gè)術(shù)語(yǔ)有唯一的、不產(chǎn)生歧義的含義。舉例電商系統(tǒng)里有商品這個(gè)詞——在商品域商品 名稱/描述/圖片/SKU用于商品展示在訂單域商品 下單時(shí)的快照/價(jià)格/數(shù)量用于訂單結(jié)算在庫(kù)存域商品 SKU編號(hào)/庫(kù)存量/倉(cāng)庫(kù)位置用于庫(kù)存管理同一個(gè)詞在不同上下文里長(zhǎng)得完全不同。如果不劃分限界上下文一個(gè)商品類就變成了萬能上帝類字段上百個(gè)誰(shuí)都不敢改。2.3 高內(nèi)聚、低耦合高內(nèi)聚相關(guān)功能放在同一個(gè)服務(wù)里改一個(gè)需求只動(dòng)一個(gè)服務(wù)低耦合服務(wù)間的依賴要少你改你的我完全不受影響判斷標(biāo)準(zhǔn)如果改功能A必然要改服務(wù)B那A和B應(yīng)該在同一個(gè)服務(wù)里。三、DDD 快速入門DDD 不是玄學(xué)它的核心概念就四個(gè)概念通俗解釋舉例領(lǐng)域Domain整個(gè)業(yè)務(wù)范圍電商系統(tǒng)子域Subdomain拆分出來的子業(yè)務(wù)商品子域、訂單子域限界上下文Bounded Context一個(gè)明確邊界內(nèi)部術(shù)語(yǔ)自洽訂單上下文中商品的含義聚合根Aggregate Root一組對(duì)象的老大外部只能通過它訪問內(nèi)部Order聚合根內(nèi)部有OrderItem拆分的方法論本質(zhì)上就兩種按業(yè)務(wù)能力拆分從業(yè)務(wù)流程出發(fā)把端到端的能力拆出來更直觀、更推薦按子域拆分先識(shí)別核心子域和支撐子域再分別拆更DDD、更學(xué)術(shù)四、無人售貨柜項(xiàng)目拆分實(shí)戰(zhàn)以一個(gè)無人售貨柜項(xiàng)目為例演示從業(yè)務(wù)出發(fā)的拆分過程┌─────────────────────────────────────────────┐ │ 業(yè)務(wù)分析 → 識(shí)別業(yè)務(wù)能力 → 劃分限界上下文 → 獨(dú)立服務(wù) │ └─────────────────────────────────────────────┘服務(wù)業(yè)務(wù)能力核心數(shù)據(jù)接口示例設(shè)備服務(wù)設(shè)備注冊(cè)、狀態(tài)監(jiān)控、固件升級(jí)設(shè)備表、貨道表POST /api/device/openDoor商品服務(wù)商品管理、分類、SKU商品表、分類表GET /api/product/{id}訂單服務(wù)下單、支付回調(diào)、退款訂單表、訂單明細(xì)表POST /api/order/create支付服務(wù)微信/支付寶對(duì)接、對(duì)賬支付流水表POST /api/pay/callback用戶服務(wù)注冊(cè)、登錄、會(huì)員、積分用戶表、會(huì)員表GET /api/user/profile庫(kù)存服務(wù)庫(kù)存扣減、補(bǔ)貨預(yù)警庫(kù)存表、庫(kù)存流水PUT /api/inventory/deduct拆分后每個(gè)服務(wù)有自己的數(shù)據(jù)庫(kù)業(yè)務(wù)邊界清晰團(tuán)隊(duì)可以并行開發(fā)。五、服務(wù)邊界的黃金規(guī)則什么應(yīng)該放一起強(qiáng)數(shù)據(jù)一致性需求的操作下單扣庫(kù)存用 Saga 事務(wù)不是強(qiáng)一致但放在同一個(gè)服務(wù)里用本地事務(wù)就很香頻繁協(xié)同修改的數(shù)據(jù)共享核心業(yè)務(wù)邏輯什么必須拆開不同變化頻率的功能用戶模塊很少改訂單模塊天天改不同性能要求的功能查詢要快 vs 寫入要準(zhǔn)不同團(tuán)隊(duì)負(fù)責(zé)的功能康威定律系統(tǒng)架構(gòu)反映組織架構(gòu)六、數(shù)據(jù)庫(kù)拆分原則鐵律每個(gè)微服務(wù)獨(dú)占數(shù)據(jù)庫(kù)禁止跨庫(kù) Join。這不是 Redis 的橫向擴(kuò)容這是硬性約束。一旦你允許跨庫(kù) Join兩個(gè)數(shù)據(jù)庫(kù)就耦合了微服務(wù)的所有好處全沒了——你拆了半天又回來一個(gè)大單體。替代方案需求方案示例訂單需要商品名稱API 調(diào)用orderService → productService訂單狀態(tài)變更通知庫(kù)存MQ 異步事件訂單支付成功 → 發(fā)MQ → 庫(kù)存服務(wù)出庫(kù)報(bào)表需要跨服務(wù)聚合數(shù)據(jù)CQRS 讀寫分離從多個(gè)服務(wù)采集數(shù)據(jù)到只讀報(bào)表庫(kù)用戶信息高頻關(guān)聯(lián)數(shù)據(jù)冗余訂單表存 userId userName允許少量不一致互聯(lián)網(wǎng)的真實(shí)世界里數(shù)據(jù)冗余是常態(tài)。訂單表里存一份商品快照當(dāng)時(shí)的標(biāo)題、價(jià)格不怕不一致反而避免了每次查單都要調(diào)商品服務(wù)。七、API 設(shè)計(jì)規(guī)范RestControllerRequestMapping(/api/v1/orders)publicclassOrderController{PostMappingpublicResultOrderVOcreateOrder(ValidRequestBodyCreateOrderRequestreq){// 冪等同樣的請(qǐng)求多次執(zhí)行結(jié)果一樣// 不做冪等的 POST請(qǐng)求超時(shí)重試可能創(chuàng)建兩條訂單}GetMapping(/{orderId})publicResultOrderVOgetOrder(PathVariableLongorderId){// RESTful資源用名詞操作用 HTTP 方法}GetMappingpublicResultPageOrderVOlistOrders(RequestParamIntegerpage,RequestParamIntegersize,RequestParam(requiredfalse)Stringstatus){// 版本管理/api/v1/ 前綴防止破壞性變更}}冪等設(shè)計(jì)是微服務(wù) API 最容易被忽視的要點(diǎn)。用戶網(wǎng)絡(luò)不好點(diǎn)了兩次支付你總不能讓人家扣兩次錢。做法請(qǐng)求帶上唯一冪等鍵服務(wù)端判斷重復(fù)直接返回第一次的結(jié)果。八、拆分粒度的權(quán)衡粒度特征問題太粗沒拆干凈一個(gè)服務(wù) 20 張表、50 個(gè)接口改一行代碼重啟整個(gè)世界太細(xì)拆過頭了一個(gè)接口一個(gè)服務(wù)運(yùn)維成本爆炸調(diào)用鏈繞地球一圈適中一個(gè)服務(wù) 3-10 張表獨(dú)立部署團(tuán)隊(duì)能 hold 住運(yùn)維成本可控過度拆分的反模式一個(gè) Controller 拆一個(gè)服務(wù)綜合征所有服務(wù)共享同一個(gè)數(shù)據(jù)庫(kù)偽微服務(wù)大量同步 HTTP 調(diào)用形成分布式單體九、演進(jìn)路線階段1單體應(yīng)用 ↓ 業(yè)務(wù)增長(zhǎng)團(tuán)隊(duì)擴(kuò)大 階段2適度拆分3-5個(gè)核心服務(wù) ↓ 能力成熟工具鏈到位 階段3精細(xì)化拆分按業(yè)務(wù)需求繼續(xù)細(xì)化不需要一開始就拆得天花爛?？梢韵劝炎兓瘎×摇⑿阅苊舾械哪K拆出來比如訂單、支付其他模塊留在單體里慢慢遷。這就是 Martin Fowler 說的絞殺者模式——新功能在微服務(wù)里做舊功能逐步替換。小結(jié)微服務(wù)拆分不是技術(shù)問題是業(yè)務(wù)理解問題。核心口訣看業(yè)務(wù)邊界而不是看代碼行數(shù)看變化頻率而不是看表有多少?gòu)埧磮F(tuán)隊(duì)結(jié)構(gòu)而不是看文件夾數(shù)。拆分之前先畫一張限界上下文圖這比寫 100 行配置更有價(jià)值。