摘要微服務(wù)并不是把一個(gè)項(xiàng)目簡(jiǎn)單拆成幾個(gè) Spring Boot 應(yīng)用。真正的微服務(wù)改造需要重新設(shè)計(jì)業(yè)務(wù)邊界、數(shù)據(jù)所有權(quán)、服務(wù)通信、部署方式、故障處理和團(tuán)隊(duì)協(xié)作模式。單體應(yīng)用在早期通常開發(fā)效率高、部署簡(jiǎn)單、事務(wù)邊界清晰但隨著業(yè)務(wù)增長(zhǎng)代碼耦合、發(fā)布風(fēng)險(xiǎn)、團(tuán)隊(duì)協(xié)作和系統(tǒng)擴(kuò)展會(huì)逐漸變得困難。微服務(wù)可以讓不同業(yè)務(wù)能力獨(dú)立演進(jìn)卻也會(huì)引入網(wǎng)絡(luò)延遲、數(shù)據(jù)一致性、分布式事務(wù)、鏈路追蹤和運(yùn)維復(fù)雜度。本文從一個(gè)包含用戶、商品、訂單和支付功能的單體系統(tǒng)出發(fā)介紹微服務(wù)拆分前的判斷方法、領(lǐng)域邊界設(shè)計(jì)、數(shù)據(jù)庫拆分、同步與異步通信、遷移步驟和治理能力。讀完本文后你應(yīng)該能夠判斷一個(gè)單體應(yīng)用是否真的需要拆分使用業(yè)務(wù)邊界而不是代碼數(shù)量設(shè)計(jì)服務(wù)規(guī)劃服務(wù)之間的調(diào)用和數(shù)據(jù)所有權(quán)避免共享數(shù)據(jù)庫和分布式事務(wù)帶來的常見問題設(shè)計(jì)從單體到微服務(wù)的漸進(jìn)式遷移路徑了解微服務(wù)上線后必須補(bǔ)齊的治理能力。一、背景與問題1. 單體應(yīng)用是什么單體應(yīng)用通常將多個(gè)業(yè)務(wù)模塊打包成一個(gè)可部署單元一個(gè)代碼倉庫 - 一個(gè)構(gòu)建產(chǎn)物 - 一個(gè)進(jìn)程 - 一個(gè)數(shù)據(jù)庫在電商系統(tǒng)中用戶、商品、訂單、庫存和支付可能都在同一個(gè)應(yīng)用內(nèi)Web 層 - 用戶模塊 - 商品模塊 - 訂單模塊 - 庫存模塊 - 支付模塊 - 數(shù)據(jù)訪問層 - 一個(gè)數(shù)據(jù)庫單體不代表設(shè)計(jì)差。模塊邊界清晰、團(tuán)隊(duì)規(guī)模較小、系統(tǒng)規(guī)模適中的單體應(yīng)用往往比過早拆分的微服務(wù)更容易開發(fā)和運(yùn)維。2. 單體應(yīng)用什么時(shí)候開始出現(xiàn)問題常見信號(hào)包括修改一個(gè)小功能需要重新發(fā)布整個(gè)系統(tǒng)不同團(tuán)隊(duì)頻繁修改同一批代碼某個(gè)模塊的流量增長(zhǎng)拖慢所有模塊應(yīng)用啟動(dòng)和回歸測(cè)試耗時(shí)越來越長(zhǎng)數(shù)據(jù)庫表被多個(gè)模塊隨意讀寫一個(gè)模塊升級(jí)依賴導(dǎo)致其他模塊受到影響故障影響范圍無法隔離不同業(yè)務(wù)需要不同的擴(kuò)容策略發(fā)布窗口和回滾風(fēng)險(xiǎn)持續(xù)增加。這些信號(hào)說明系統(tǒng)的邊界可能已經(jīng)不適合當(dāng)前規(guī)模但不一定意味著必須立即微服務(wù)化。也可以先通過模塊化、代碼分層、數(shù)據(jù)庫治理和發(fā)布優(yōu)化解決一部分問題。3. 微服務(wù)解決什么問題微服務(wù)通常希望實(shí)現(xiàn)業(yè)務(wù)能力獨(dú)立 - 服務(wù)獨(dú)立構(gòu)建 - 服務(wù)獨(dú)立部署 - 服務(wù)獨(dú)立擴(kuò)容 - 服務(wù)故障隔離 - 團(tuán)隊(duì)獨(dú)立負(fù)責(zé)例如用戶服務(wù) 商品服務(wù) 訂單服務(wù) 庫存服務(wù) 支付服務(wù) 通知服務(wù)每個(gè)服務(wù)圍繞一個(gè)業(yè)務(wù)能力負(fù)責(zé)而不是圍繞一個(gè)技術(shù)組件隨意切分。4. 微服務(wù)帶來的新問題拆分以后原來的進(jìn)程內(nèi)調(diào)用變成網(wǎng)絡(luò)調(diào)用單體 訂單模塊 - 庫存模塊 直接方法調(diào)用 微服務(wù) 訂單服務(wù) - 網(wǎng)絡(luò) - 庫存服務(wù)隨之而來的問題包括網(wǎng)絡(luò)可能超時(shí)或失敗服務(wù)之間有延遲請(qǐng)求可能重復(fù)到達(dá)數(shù)據(jù)不再共享一個(gè)事務(wù)服務(wù)發(fā)現(xiàn)和配置變復(fù)雜日志需要跨服務(wù)關(guān)聯(lián)部署和監(jiān)控對(duì)象數(shù)量增加一個(gè)請(qǐng)求可能依賴多個(gè)下游服務(wù)。微服務(wù)的價(jià)值必須大于它引入的復(fù)雜度不能把拆分本身當(dāng)成目標(biāo)。二、核心概念1. 服務(wù)邊界服務(wù)邊界是一個(gè)業(yè)務(wù)能力的責(zé)任邊界。它應(yīng)該回答這個(gè)服務(wù)負(fù)責(zé)什么業(yè)務(wù)規(guī)則哪些數(shù)據(jù)歸它所有哪些操作由它決定其他服務(wù)如何請(qǐng)求它它需要發(fā)布什么事件它對(duì)外承諾什么接口。一個(gè)好的服務(wù)邊界通常具有高內(nèi)聚相關(guān)業(yè)務(wù)規(guī)則和數(shù)據(jù)放在一起低耦合跨服務(wù)依賴盡量少獨(dú)立演進(jìn)可以單獨(dú)發(fā)布和擴(kuò)展清晰所有權(quán)某類數(shù)據(jù)只有一個(gè)權(quán)威服務(wù)。2. 按業(yè)務(wù)能力拆分而不是按技術(shù)層拆分不推薦按技術(shù)層拆分用戶 Controller 服務(wù) 訂單 Controller 服務(wù) 公共 Service 服務(wù) 數(shù)據(jù)庫 Service 服務(wù)這種拆分會(huì)讓一次業(yè)務(wù)請(qǐng)求跨越很多技術(shù)服務(wù)反而增加耦合。更合理的是按業(yè)務(wù)能力拆分用戶服務(wù)用戶資料、賬戶狀態(tài) 商品服務(wù)商品信息、價(jià)格、上下架 訂單服務(wù)訂單生命周期和訂單金額 庫存服務(wù)庫存數(shù)量和扣減規(guī)則 支付服務(wù)支付單和支付狀態(tài)每個(gè)服務(wù)內(nèi)部仍然可以有 Controller、Service 和 Repository但服務(wù)邊界應(yīng)首先由業(yè)務(wù)職責(zé)決定。3. 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中的限界上下文限界上下文可以理解為一組擁有明確模型和規(guī)則的業(yè)務(wù)邊界。同一個(gè)詞在不同上下文中可能有不同含義概念用戶上下文訂單上下文支付上下文用戶賬戶和身份下單人快照付款人商品收藏對(duì)象購買條目支付描述狀態(tài)賬戶狀態(tài)訂單狀態(tài)支付狀態(tài)金額賬戶額度訂單應(yīng)付金額實(shí)際支付金額拆分時(shí)不能因?yàn)槎鄠€(gè)模塊都使用“用戶”這個(gè)詞就讓所有服務(wù)共享同一個(gè) User Entity。服務(wù)可以保存自己需要的用戶快照通過用戶服務(wù)接口或事件獲取必要信息。4. 數(shù)據(jù)所有權(quán)微服務(wù)中的核心原則是一個(gè)業(yè)務(wù)數(shù)據(jù)有一個(gè)權(quán)威擁有者 其他服務(wù)通過 API、事件或只讀副本獲取數(shù)據(jù)例如商品服務(wù)擁有商品名稱和商品狀態(tài)庫存服務(wù)擁有可售庫存訂單服務(wù)擁有訂單狀態(tài)和訂單金額支付服務(wù)擁有支付狀態(tài)用戶服務(wù)擁有賬戶基礎(chǔ)信息。其他服務(wù)可以保存必要的快照但不能繞過擁有者直接修改原始數(shù)據(jù)。5. 服務(wù)通信方式服務(wù)之間常見兩類通信方式特點(diǎn)適用場(chǎng)景同步 HTTP/RPC調(diào)用關(guān)系直觀實(shí)時(shí)返回查詢、必須立即得到結(jié)果異步消息解耦、削峰、最終一致領(lǐng)域事件、通知、耗時(shí)任務(wù)批量接口減少網(wǎng)絡(luò)往返列表查詢和批量處理本地緩存降低重復(fù)調(diào)用穩(wěn)定、可短暫過期的數(shù)據(jù)選擇通信方式時(shí)要看業(yè)務(wù)是否必須同步得到結(jié)果。不是所有跨服務(wù)調(diào)用都應(yīng)該使用同步 HTTP。6. API 契約服務(wù)之間通信需要穩(wěn)定契約請(qǐng)求路徑和方法 請(qǐng)求參數(shù)和響應(yīng)字段 狀態(tài)碼和錯(cuò)誤碼 超時(shí)和重試約定 冪等要求 權(quán)限要求 版本兼容策略API 契約不是 Controller 方法簽名的簡(jiǎn)單復(fù)制。服務(wù)之間應(yīng)該隱藏內(nèi)部實(shí)體和數(shù)據(jù)庫結(jié)構(gòu)只暴露穩(wěn)定的業(yè)務(wù)接口。7. 事件驅(qū)動(dòng)事件表示某件已經(jīng)發(fā)生的業(yè)務(wù)事實(shí)OrderCreated PaymentSucceeded StockDeducted OrderCancelled事件的特點(diǎn)過去發(fā)生的事實(shí)不是命令生產(chǎn)者不必知道所有消費(fèi)者消費(fèi)者可以異步處理適合傳播狀態(tài)變化需要考慮重復(fù)消費(fèi)和順序。事件不是萬能的。對(duì)必須立即得到結(jié)果的校驗(yàn)仍然需要同步調(diào)用。8. 分布式事務(wù)與最終一致性單體中可以使用一個(gè)數(shù)據(jù)庫事務(wù)創(chuàng)建訂單 - 扣減庫存 - 創(chuàng)建支付單 - 一個(gè)數(shù)據(jù)庫事務(wù)提交拆分后不同服務(wù)通常擁有不同數(shù)據(jù)庫無法簡(jiǎn)單使用同一個(gè)本地事務(wù)。常見方案包括可靠事件和最終一致性本地消息表Saga 編排或協(xié)同補(bǔ)償事務(wù)TCC盡量避免跨服務(wù)強(qiáng)一致事務(wù)。方案選擇取決于業(yè)務(wù)能否接受短暫中間狀態(tài)、補(bǔ)償是否可行以及失敗后的人工處理成本。三、工作原理1. 單體到微服務(wù)的演進(jìn)一個(gè)漸進(jìn)式演進(jìn)過程可以是模塊化單體識(shí)別業(yè)務(wù)邊界穩(wěn)定內(nèi)部接口抽離一個(gè)低風(fēng)險(xiǎn)服務(wù)建立服務(wù)通信和觀測(cè)遷移數(shù)據(jù)所有權(quán)逐步拆分其他能力不建議一次性把所有模塊拆成幾十個(gè)服務(wù)。每拆一個(gè)服務(wù)都應(yīng)該獲得明確收益并能驗(yàn)證遷移是否成功。2. 服務(wù)邊界示例假設(shè)原單體中包含以下模塊UserModule ProductModule OrderModule InventoryModule PaymentModule NotificationModule可以先形成候選邊界用戶服務(wù) - 用戶資料、賬戶狀態(tài)、用戶認(rèn)證關(guān)聯(lián) 商品服務(wù) - 商品信息、價(jià)格、上下架 庫存服務(wù) - 庫存、預(yù)占、釋放、扣減 訂單服務(wù) - 訂單創(chuàng)建、狀態(tài)流轉(zhuǎn)、訂單查詢 支付服務(wù) - 支付單、支付狀態(tài)、支付回調(diào) 通知服務(wù) - 短信、郵件、站內(nèi)通知候選邊界還需要結(jié)合團(tuán)隊(duì)職責(zé)、數(shù)據(jù)依賴和發(fā)布頻率驗(yàn)證。3. 從同步調(diào)用到異步事件訂單創(chuàng)建可能經(jīng)歷通知服務(wù)支付服務(wù)庫存服務(wù)訂單服務(wù)客戶端通知服務(wù)支付服務(wù)庫存服務(wù)訂單服務(wù)客戶端創(chuàng)建訂單請(qǐng)求預(yù)占庫存返回預(yù)占結(jié)果創(chuàng)建支付單返回支付單返回待支付訂單發(fā)布支付成功事件發(fā)布訂單狀態(tài)變化事件發(fā)送通知這里可以把支付成功后的通知改成異步事件讓訂單服務(wù)不必同步等待通知服務(wù)完成。4. 數(shù)據(jù)遷移的核心流程從共享數(shù)據(jù)庫遷移到服務(wù)獨(dú)立數(shù)據(jù)庫不能只復(fù)制表梳理表和字段所有者 - 確定服務(wù)邊界 - 建立服務(wù)內(nèi)部模型 - 遷移歷史數(shù)據(jù) - 建立雙寫或變更同步 - 校驗(yàn)新舊數(shù)據(jù) - 切換讀取 - 停止舊寫入 - 刪除共享訪問雙寫期間需要處理一邊寫成功、一邊寫失敗兩邊寫入順序不一致重復(fù)寫入數(shù)據(jù)格式不同歷史數(shù)據(jù)缺失補(bǔ)償和校驗(yàn)。如果無法可靠保證雙寫一致應(yīng)優(yōu)先采用事件同步或分階段遷移避免長(zhǎng)期維護(hù)不可控的雙寫邏輯。5. 服務(wù)調(diào)用的超時(shí)與重試一次同步調(diào)用至少要明確連接超時(shí) 讀取超時(shí) 總調(diào)用超時(shí) 最大重試次數(shù) 退避時(shí)間 是否允許重試 降級(jí)結(jié)果不是所有失敗都適合重試查詢通常比較容易重試創(chuàng)建操作必須具備冪等鍵后才能重試支付請(qǐng)求需要嚴(yán)格遵循業(yè)務(wù)冪等超時(shí)不代表服務(wù)端沒有執(zhí)行成功重試可能放大下游壓力。6. 服務(wù)故障的傳播如果訂單服務(wù)同步依賴庫存、優(yōu)惠、地址和支付服務(wù)訂單請(qǐng)求 - 庫存慢 - 訂單線程等待 - 優(yōu)惠慢 - 更多線程等待 - 連接池耗盡 - 訂單服務(wù)超時(shí) - 上游重試 - 故障擴(kuò)大微服務(wù)必須配合超時(shí)限流熔斷艙壁隔離降級(jí)異步化依賴分級(jí)資源池隔離。四、實(shí)戰(zhàn)示例下面以訂單服務(wù)調(diào)用庫存服務(wù)為例展示 API 契約、冪等、事件和補(bǔ)償設(shè)計(jì)。1. 定義服務(wù)接口庫存服務(wù)可以提供預(yù)占接口POST /api/inventories/reservations Idempotency-Key: order-10001-create { orderId: 10001, items: [ { productId: 10, quantity: 2 } ] }響應(yīng){reservationId:reservation-90001,status:RESERVED,expiresAt:2026-09-05T12:00:00Z}接口契約需要明確orderId 是否必須唯一重復(fù)請(qǐng)求返回什么庫存不足返回什么錯(cuò)誤碼預(yù)占多久自動(dòng)過期如何釋放預(yù)占訂單取消后誰負(fù)責(zé)觸發(fā)釋放。2. 訂單服務(wù)調(diào)用庫存服務(wù)ServicepublicclassOrderApplicationService{privatefinalInventoryClientinventoryClient;privatefinalOrderRepositoryorderRepository;publicOrderApplicationService(InventoryClientinventoryClient,OrderRepositoryorderRepository){this.inventoryClientinventoryClient;this.orderRepositoryorderRepository;}TransactionalpublicOrderResultcreateOrder(CreateOrderCommandcommand){OrderorderorderRepository.createPending(command.userId(),command.items());ReservationResultreservationinventoryClient.reserve(newReserveInventoryCommand(order.id(),command.items()),order-order.id());if(!reservation.success()){orderRepository.markFailed(order.id(),INSUFFICIENT_STOCK);returnOrderResult.failed(order.id(),庫存不足);}orderRepository.markReserved(order.id(),reservation.reservationId());returnOrderResult.success(order.id());}}這里的 Transactional 只覆蓋訂單服務(wù)自己的數(shù)據(jù)庫不能自動(dòng)覆蓋庫存服務(wù)。庫存調(diào)用失敗時(shí)訂單狀態(tài)需要通過本地事務(wù)和明確的業(yè)務(wù)狀態(tài)表達(dá)。3. 設(shè)計(jì)客戶端超時(shí)和冪等ComponentpublicclassInventoryClient{privatefinalRestClientrestClient;publicInventoryClient(RestClient.Builderbuilder){this.restClientbuilder.baseUrl(http://inventory-service).build();}publicReservationResultreserve(ReserveInventoryCommandcommand,StringidempotencyKey){returnrestClient.post().uri(/api/inventories/reservations).header(Idempotency-Key,idempotencyKey).body(command).retrieve().body(ReservationResult.class);}}實(shí)際項(xiàng)目還需要在 HTTP 客戶端層配置連接超時(shí)、讀取超時(shí)、狀態(tài)碼映射和重試策略。創(chuàng)建類接口必須傳遞穩(wěn)定冪等鍵避免客戶端超時(shí)重試導(dǎo)致重復(fù)預(yù)占。4. 庫存服務(wù)實(shí)現(xiàn)冪等庫存服務(wù)可以保存請(qǐng)求冪等記錄idempotency_key service_name request_hash response_body status created_at expires_at處理流程收到請(qǐng)求 - 根據(jù)冪等鍵查記錄 - 已成功返回原響應(yīng) - 處理中返回處理中狀態(tài)或等待 - 已失敗根據(jù)策略重試或返回原錯(cuò)誤 - 未找到執(zhí)行業(yè)務(wù)并保存結(jié)果如果同一個(gè)冪等鍵對(duì)應(yīng)的請(qǐng)求內(nèi)容發(fā)生變化應(yīng)返回參數(shù)沖突而不是靜默復(fù)用原結(jié)果。5. 使用事件完成后續(xù)流程訂單服務(wù)可以發(fā)布訂單已預(yù)占事件{eventId:event-10001,eventType:OrderInventoryReserved,aggregateId:10001,occurredAt:2026-09-05T12:00:00Z,payload:{orderId:10001,reservationId:reservation-90001}}支付服務(wù)、通知服務(wù)或履約服務(wù)可以訂閱這個(gè)事件。事件消費(fèi)者必須支持重復(fù)消費(fèi)ComponentpublicclassInventoryReservedHandler{privatefinalEventRecordRepositoryeventRecordRepository;privatefinalPaymentServicepaymentService;Transactionalpublicvoidhandle(OrderInventoryReservedevent){if(eventRecordRepository.exists(event.eventId())){return;}paymentService.createPayment(event.orderId(),event.reservationId());eventRecordRepository.markProcessed(event.eventId());}}事件去重記錄和業(yè)務(wù)更新最好放在同一個(gè)本地事務(wù)中避免業(yè)務(wù)處理成功但去重記錄沒有保存。6. 本地消息表如果訂單數(shù)據(jù)庫和消息系統(tǒng)之間沒有統(tǒng)一事務(wù)可以使用本地消息表CREATETABLEoutbox_event(idBIGINTPRIMARYKEYAUTO_INCREMENT,event_idVARCHAR(64)NOTNULLUNIQUE,event_typeVARCHAR(100)NOTNULL,aggregate_idVARCHAR(64)NOTNULL,payload JSONNOTNULL,statusVARCHAR(20)NOTNULL,retry_countINTNOTNULLDEFAULT0,next_retry_atDATETIMENULL,created_atDATETIMENOTNULL,published_atDATETIMENULL);訂單創(chuàng)建時(shí)本地事務(wù) - 保存訂單 - 保存 outbox_event - 一起提交后臺(tái)發(fā)布器查詢待發(fā)布事件 - 發(fā)送到消息系統(tǒng) - 標(biāo)記已發(fā)布 - 失敗則增加重試次數(shù)消息可能重復(fù)發(fā)布因此消費(fèi)者必須冪等。Outbox 解決的是“業(yè)務(wù)數(shù)據(jù)和待發(fā)布事件不一致”的問題不會(huì)自動(dòng)解決所有分布式事務(wù)問題。7. 統(tǒng)一錯(cuò)誤響應(yīng)服務(wù)間錯(cuò)誤響應(yīng)應(yīng)包含穩(wěn)定的錯(cuò)誤碼{code:INVENTORY_NOT_ENOUGH,message:庫存不足,requestId:req-202609050001,retryable:false}不要讓調(diào)用方依賴異常堆棧、數(shù)據(jù)庫錯(cuò)誤字符串或可變的 message。retryable 可以幫助調(diào)用方區(qū)分是否允許重試但最終仍需結(jié)合接口冪等性判斷。8. 遷移一個(gè)模塊的步驟以商品服務(wù)為例1. 梳理商品模塊的表、接口和業(yè)務(wù)規(guī)則 2. 在單體內(nèi)部建立 ProductFacade 3. 禁止其他模塊直接訪問商品表 4. 為 ProductFacade 編寫契約測(cè)試 5. 創(chuàng)建獨(dú)立商品服務(wù) 6. 將商品數(shù)據(jù)同步到新庫 7. 先灰度讀取新服務(wù) 8. 校驗(yàn)新舊結(jié)果 9. 切換寫入和數(shù)據(jù)所有權(quán) 10. 刪除單體中的舊實(shí)現(xiàn)先在單體內(nèi)部建立邊界能夠降低后續(xù)抽離難度也可以提前發(fā)現(xiàn)模塊間隱藏耦合。五、常見問題與實(shí)踐建議1. 是否所有系統(tǒng)都適合微服務(wù)不一定。以下情況可以優(yōu)先保持模塊化單體團(tuán)隊(duì)規(guī)模較小業(yè)務(wù)還在快速試錯(cuò)訪問規(guī)模不大模塊邊界尚未穩(wěn)定沒有完善的部署和監(jiān)控能力事務(wù)一致性要求很高服務(wù)拆分收益不明確。微服務(wù)不是成熟度徽章。能夠穩(wěn)定交付和快速演進(jìn)比服務(wù)數(shù)量更多更重要。2. 服務(wù)是不是越小越好服務(wù)過小會(huì)導(dǎo)致調(diào)用鏈變長(zhǎng)網(wǎng)絡(luò)開銷增加數(shù)據(jù)一致性更復(fù)雜部署單元數(shù)量膨脹團(tuán)隊(duì)需要維護(hù)更多接口故障定位困難。合理邊界應(yīng)該讓服務(wù)內(nèi)部有足夠業(yè)務(wù)內(nèi)聚同時(shí)避免一個(gè)業(yè)務(wù)動(dòng)作跨越過多服務(wù)。拆分粒度要結(jié)合團(tuán)隊(duì)和系統(tǒng)規(guī)模動(dòng)態(tài)調(diào)整。3. 為什么共享數(shù)據(jù)庫會(huì)破壞微服務(wù)邊界如果多個(gè)服務(wù)直接訪問同一張表訂單服務(wù)直接修改庫存表 商品服務(wù)直接修改訂單表 支付服務(wù)直接查詢訂單內(nèi)部字段會(huì)導(dǎo)致數(shù)據(jù)所有權(quán)不清晰表結(jié)構(gòu)變更互相影響服務(wù)無法獨(dú)立發(fā)布本地事務(wù)邊界失去意義權(quán)限難以控制未來拆庫成本很高。過渡階段可以暫時(shí)共享數(shù)據(jù)庫但應(yīng)通過訪問層、表權(quán)限和遷移計(jì)劃限制這種狀態(tài)不能把它當(dāng)作長(zhǎng)期架構(gòu)。4. 是否應(yīng)該為每個(gè)服務(wù)準(zhǔn)備獨(dú)立數(shù)據(jù)庫獨(dú)立數(shù)據(jù)庫有利于數(shù)據(jù)隔離和獨(dú)立演進(jìn)但也會(huì)增加數(shù)據(jù)同步分布式事務(wù)運(yùn)維實(shí)例備份恢復(fù)跨服務(wù)查詢數(shù)據(jù)分析整合。可以先做到“邏輯所有權(quán)獨(dú)立”再根據(jù)規(guī)模和發(fā)布需求物理拆庫。不要為了形式上的獨(dú)立數(shù)據(jù)庫而過早承擔(dān)不必要的復(fù)雜度。5. 服務(wù)間調(diào)用為什么不能直接共享 Entity共享 Entity 會(huì)造成一個(gè)服務(wù)修改字段影響所有調(diào)用方內(nèi)部字段暴露依賴同一版本類庫數(shù)據(jù)模型無法獨(dú)立演進(jìn)序列化兼容變復(fù)雜。服務(wù)之間應(yīng)使用 DTO、Command、Query 和 Event 等契約對(duì)象必要時(shí)進(jìn)行顯式映射。6. 重試為什么可能造成重復(fù)操作網(wǎng)絡(luò)超時(shí)只說明調(diào)用方?jīng)]有及時(shí)收到響應(yīng)不說明服務(wù)端沒有執(zhí)行成功客戶端發(fā)送創(chuàng)建請(qǐng)求 - 服務(wù)端執(zhí)行成功 - 響應(yīng)在網(wǎng)絡(luò)中丟失 - 客戶端認(rèn)為失敗并重試 - 服務(wù)端再次執(zhí)行因此創(chuàng)建訂單、支付、扣庫存等操作必須設(shè)計(jì)冪等鍵、業(yè)務(wù)唯一約束或狀態(tài)機(jī)不能只依賴調(diào)用方“不要重復(fù)請(qǐng)求”。7. 分布式事務(wù)應(yīng)該怎么選先問業(yè)務(wù)能否接受中間狀態(tài)可以接受優(yōu)先使用事件、狀態(tài)機(jī)和補(bǔ)償不可接受評(píng)估 Saga、TCC 或重新設(shè)計(jì)邊界只涉及同一數(shù)據(jù)庫優(yōu)先使用本地事務(wù)依賴外部系統(tǒng)考慮冪等、對(duì)賬和人工補(bǔ)償。不要為了追求“看起來像一個(gè)事務(wù)”把多個(gè)遠(yuǎn)程調(diào)用強(qiáng)行串在長(zhǎng)事務(wù)中。8. 調(diào)用鏈變長(zhǎng)怎么辦優(yōu)化方向合并批量接口使用并行調(diào)用將非核心流程異步化增加本地緩存減少跨服務(wù)查詢?cè)O(shè)置依賴分級(jí)對(duì)弱依賴提供降級(jí)用聚合服務(wù)封裝復(fù)雜編排。并行調(diào)用需要考慮線程池隔離和下游承載能力不能簡(jiǎn)單地把所有調(diào)用都改成并行。9. 如何處理跨服務(wù)查詢不要讓一個(gè)服務(wù)直接連接另一個(gè)服務(wù)的數(shù)據(jù)庫。可選方式調(diào)用對(duì)方查詢 API使用事件構(gòu)建本地只讀視圖使用數(shù)據(jù)同步任務(wù)由查詢聚合服務(wù)統(tǒng)一編排對(duì)報(bào)表場(chǎng)景進(jìn)入獨(dú)立分析庫。實(shí)時(shí)一致性和查詢性能需要權(quán)衡。面向用戶的核心交易查詢通常優(yōu)先保持業(yè)務(wù)邊界面向報(bào)表的復(fù)雜跨域查詢可以使用數(shù)據(jù)同步和分析模型。10. 服務(wù)發(fā)現(xiàn)和配置中心是不是必需服務(wù)數(shù)量少、部署環(huán)境簡(jiǎn)單時(shí)可以先使用固定地址或平臺(tái)服務(wù)發(fā)現(xiàn)。隨著實(shí)例動(dòng)態(tài)擴(kuò)縮容和環(huán)境增多再引入統(tǒng)一服務(wù)發(fā)現(xiàn)、配置管理和密鑰管理。無論是否使用配置中心都要做到配置與代碼分離敏感信息不進(jìn)代碼倉庫配置變更可審計(jì)配置錯(cuò)誤可快速回滾關(guān)鍵配置啟動(dòng)時(shí)校驗(yàn)。11. 日志中只看服務(wù)本地 requestId 可以嗎不夠。一次請(qǐng)求可能經(jīng)過多個(gè)服務(wù)需要使用貫穿全鏈路的 traceId網(wǎng)關(guān) - 訂單服務(wù) - 庫存服務(wù) - 支付服務(wù) - 消息消費(fèi)者每個(gè)服務(wù)可以有自己的 spanId但必須傳播 traceId。日志、指標(biāo)和分布式追蹤應(yīng)該能夠關(guān)聯(lián)同一次業(yè)務(wù)請(qǐng)求。12. 微服務(wù)部署后如何回滾每個(gè)服務(wù)應(yīng)具備可重復(fù)構(gòu)建的版本獨(dú)立鏡像或構(gòu)建產(chǎn)物健康檢查灰度或分批發(fā)布數(shù)據(jù)庫遷移回滾策略API 兼容窗口舊版本和新版本并存能力。代碼可以快速回滾但數(shù)據(jù)庫結(jié)構(gòu)和消息格式可能已經(jīng)變化。因此發(fā)布前要設(shè)計(jì)向后兼容避免新版本寫入舊版本無法理解的數(shù)據(jù)。六、進(jìn)階思考1. 模塊化單體是很好的中間形態(tài)模塊化單體可以做到一個(gè)部署單元 清晰的業(yè)務(wù)模塊 獨(dú)立的內(nèi)部接口 明確的數(shù)據(jù)訪問邊界 模塊級(jí)測(cè)試 統(tǒng)一但可觀察的運(yùn)行環(huán)境它可以先解決代碼和責(zé)任邊界問題同時(shí)保留本地調(diào)用、單庫事務(wù)和簡(jiǎn)單部署的優(yōu)勢(shì)。未來只有真正需要獨(dú)立擴(kuò)展的模塊才抽離為微服務(wù)。2. 服務(wù)拆分應(yīng)該由變化驅(qū)動(dòng)一個(gè)服務(wù)是否應(yīng)該獨(dú)立通?？此欠裼歇?dú)立發(fā)布頻率它是否有獨(dú)立擴(kuò)容需求它是否需要不同技術(shù)棧它是否由獨(dú)立團(tuán)隊(duì)負(fù)責(zé)它是否需要故障隔離它的數(shù)據(jù)和規(guī)則是否邊界清晰。如果兩個(gè)模塊總是一起修改、一起發(fā)布、一起擴(kuò)容拆成兩個(gè)服務(wù)可能只是增加遠(yuǎn)程調(diào)用。3. 領(lǐng)域事件和狀態(tài)機(jī)訂單狀態(tài)通常不應(yīng)該允許任意修改PENDING - RESERVED - PAID - COMPLETED PENDING - CANCELLED RESERVED - CANCELLED服務(wù)可以通過狀態(tài)機(jī)限制合法轉(zhuǎn)換并通過領(lǐng)域事件傳播狀態(tài)變化。狀態(tài)機(jī)讓補(bǔ)償、重試和異常恢復(fù)更容易設(shè)計(jì)。4. 可觀測(cè)性是微服務(wù)的基礎(chǔ)設(shè)施至少需要指標(biāo)請(qǐng)求量、錯(cuò)誤率、延遲、資源使用日志結(jié)構(gòu)化、帶 traceId追蹤跨服務(wù)調(diào)用鏈健康檢查存活和就緒狀態(tài)告警超時(shí)、錯(cuò)誤、積壓和資源異常審計(jì)關(guān)鍵狀態(tài)和權(quán)限操作。沒有可觀測(cè)性服務(wù)拆分后只能看到“某個(gè)接口失敗”卻無法知道是哪個(gè)下游、哪條消息或哪個(gè)版本造成的。5. 依賴治理可以把依賴分級(jí)核心依賴失敗時(shí)請(qǐng)求不能完成 重要依賴失敗時(shí)可以降級(jí)部分功能 弱依賴可以異步處理 可選依賴可以直接關(guān)閉根據(jù)分級(jí)配置不同的超時(shí)、線程池、熔斷和降級(jí)策略。不要讓非核心服務(wù)占滿核心業(yè)務(wù)的線程池和連接池。6. 數(shù)據(jù)一致性與業(yè)務(wù)補(bǔ)償最終一致性需要有可執(zhí)行的補(bǔ)償流程訂單已創(chuàng)建 - 庫存預(yù)占失敗 - 訂單標(biāo)記失敗 - 釋放已預(yù)占資源 - 發(fā)布失敗事件 - 重試或轉(zhuǎn)人工補(bǔ)償不是簡(jiǎn)單地再調(diào)用一次接口。需要記錄狀態(tài)、重試次數(shù)、最后錯(cuò)誤、下次重試時(shí)間和人工處理入口。7. API 版本和兼容策略服務(wù)升級(jí)時(shí)舊調(diào)用方可能還沒有同步發(fā)布?？梢圆捎眯略鲎侄味皇莿h除字段保持舊字段一段時(shí)間對(duì)接口進(jìn)行版本化對(duì)事件采用向后兼容格式先升級(jí)消費(fèi)者再升級(jí)生產(chǎn)者通過契約測(cè)試驗(yàn)證兼容性。API 兼容不僅包括 JSON 字段還包括狀態(tài)碼、錯(cuò)誤碼、分頁規(guī)則、時(shí)間格式和冪等行為。8. 微服務(wù)拆分的收益評(píng)估每次拆分前后都應(yīng)該評(píng)估發(fā)布耗時(shí)是否降低 故障影響范圍是否縮小 擴(kuò)容是否更精準(zhǔn) 團(tuán)隊(duì)交付是否更獨(dú)立 調(diào)用延遲是否增加 運(yùn)維成本是否上升 數(shù)據(jù)一致性問題是否增加 問題定位是否更容易如果只統(tǒng)計(jì)服務(wù)數(shù)量沒有統(tǒng)計(jì)交付速度、故障恢復(fù)時(shí)間和業(yè)務(wù)穩(wěn)定性就很難判斷拆分是否真的成功。9. 微服務(wù)治理的最小清單一個(gè)服務(wù)上線前至少應(yīng)具備明確的業(yè)務(wù)邊界和數(shù)據(jù)所有權(quán) 穩(wěn)定的 API 契約 超時(shí)和重試策略 冪等處理 健康檢查 結(jié)構(gòu)化日志和 traceId 核心指標(biāo)和告警 權(quán)限認(rèn)證 灰度和回滾能力 數(shù)據(jù)庫遷移方案 消息重試和積壓處理 故障降級(jí)和補(bǔ)償流程這些能力比注冊(cè)中心、網(wǎng)關(guān)數(shù)量和服務(wù)數(shù)量更能決定微服務(wù)是否可維護(hù)。結(jié)論從單體應(yīng)用到微服務(wù)不是一次代碼搬家而是業(yè)務(wù)邊界、數(shù)據(jù)所有權(quán)、通信方式、事務(wù)模型和運(yùn)維能力的整體變化。單體應(yīng)用適合早期快速交付微服務(wù)適合在業(yè)務(wù)邊界穩(wěn)定、團(tuán)隊(duì)和流量規(guī)模達(dá)到一定程度后按實(shí)際收益逐步引入。本文的重點(diǎn)可以歸納為微服務(wù)拆分的目標(biāo)是獨(dú)立演進(jìn)、擴(kuò)展和故障隔離服務(wù)邊界應(yīng)優(yōu)先依據(jù)業(yè)務(wù)能力和數(shù)據(jù)所有權(quán)設(shè)計(jì)模塊化單體是低風(fēng)險(xiǎn)的過渡形態(tài)每個(gè)業(yè)務(wù)數(shù)據(jù)應(yīng)有明確的權(quán)威擁有者同步調(diào)用適合實(shí)時(shí)結(jié)果異步事件適合解耦和最終一致跨服務(wù)操作不能直接依賴本地?cái)?shù)據(jù)庫事務(wù)冪等、超時(shí)、重試、熔斷和補(bǔ)償是微服務(wù)的基礎(chǔ)能力共享數(shù)據(jù)庫會(huì)削弱服務(wù)邊界應(yīng)設(shè)置遷移計(jì)劃可觀測(cè)性和發(fā)布回滾能力必須與服務(wù)拆分同步建設(shè)服務(wù)不是越多越好拆分收益必須大于分布式復(fù)雜度。下一篇可以繼續(xù)學(xué)習(xí) Spring Cloud 微服務(wù)架構(gòu)進(jìn)一步了解注冊(cè)中心、配置中心、網(wǎng)關(guān)和服務(wù)間調(diào)用如何落地。