微服務(wù)進(jìn)階這件事很多人會把它理解成“把應(yīng)用拆開、注冊到注冊中心、走一遍OpenFeign調(diào)用”就算完事了。但真正在線上待過幾年你就會發(fā)現(xiàn)拆服務(wù)從來不是最難的最難的是拆完之后數(shù)據(jù)該怎么辦。服務(wù)之間的數(shù)據(jù)依賴像蜘蛛網(wǎng)一樣纏在一起A服務(wù)查B服務(wù)的庫B服務(wù)等C服務(wù)的數(shù)據(jù)C服務(wù)又回頭依賴A服務(wù)最后誰都不敢動表結(jié)構(gòu)誰改字段誰挨罵。我給這種狀態(tài)起了個(gè)名字叫“微服務(wù)數(shù)據(jù)依賴癥”。這篇文章不聊理論就結(jié)合我自己在一個(gè)訂單域項(xiàng)目里真實(shí)踩過的一次大坑從發(fā)病機(jī)制、排查鏈路到根治方案完整過一遍。如果你所在團(tuán)隊(duì)也經(jīng)常因?yàn)椤安閯e人數(shù)據(jù)”吵架這篇文章值得你花十分鐘看完。1. 一句話診斷什么是“微服務(wù)數(shù)據(jù)依賴癥”1.1 自測清單你的服務(wù)“病”到第幾期了所謂“數(shù)據(jù)依賴癥”本質(zhì)上指的是微服務(wù)拆分之后服務(wù)之間的數(shù)據(jù)訪問關(guān)系沒有跟著服務(wù)邊界一起被切開還在用單體時(shí)代那種“誰能拿到數(shù)據(jù)誰就查”的思路來完成業(yè)務(wù)協(xié)作。接口是分開了數(shù)據(jù)庫卻藕斷絲連服務(wù)是自治了數(shù)據(jù)卻還是大家共享的公共食堂。你可以對照下面這幾個(gè)癥狀給自己團(tuán)隊(duì)打個(gè)分超過兩條基本可以確診階段典型癥狀后果一期輕度某個(gè)服務(wù)偶爾直連另一個(gè)服務(wù)的庫查一張明細(xì)表偶發(fā)耦合還沒形成事故但已經(jīng)在埋雷二期中度一個(gè)詳情查詢接口要串行或并行調(diào)用3個(gè)以上服務(wù)接口P99明顯上升下游一抖動自己先超時(shí)三期重度核心表被多個(gè)服務(wù)同時(shí)讀寫沒有明確的Owner改任何字段都要全組待命線上故障變成每周固定節(jié)目我見過最夸張的一個(gè)場景是訂單服務(wù)接口層面它已經(jīng)是一個(gè)獨(dú)立部署的微服務(wù)了但數(shù)據(jù)層面幾乎退化成了全公司的公共數(shù)據(jù)庫用戶服務(wù)來查訂單量支付服務(wù)來核對金額物流服務(wù)來取收貨地址營銷服務(wù)來判斷是否首單全都直接從訂單庫拉數(shù)。一個(gè)訂單表的讀QPS能到寫QPS的12倍其中將近一半是別的服務(wù)“借數(shù)”借走的。這種狀態(tài)說白了就是用微服務(wù)的殼跑著單體的數(shù)據(jù)邏輯。1.2 反面案例訂單服務(wù)被七個(gè)兄弟服務(wù)輪番“借數(shù)”說一個(gè)我印象特別深的例子。當(dāng)時(shí)我們訂單服務(wù)的核心庫里有訂單主表和訂單明細(xì)表本來只應(yīng)該由訂單服務(wù)自己讀寫。但因?yàn)楦鳂I(yè)務(wù)方都覺得“訂單數(shù)據(jù)是公共資產(chǎn)”于是紛紛找我們要數(shù)據(jù)庫只讀賬號或者要求我們提供查詢接口。到后來訂單服務(wù)一個(gè)月內(nèi)給其他服務(wù)開了七個(gè)調(diào)用入口用戶服務(wù)要統(tǒng)計(jì)用戶累計(jì)訂單數(shù)支付服務(wù)要對賬訂單金額物流服務(wù)要拉取收貨人地址營銷服務(wù)要判斷用戶是否首單用戶數(shù)據(jù)分析平臺要抽訂單明細(xì)做報(bào)表售后要查原始訂單快照連積分服務(wù)都要按訂單金額給用戶發(fā)積分。每個(gè)調(diào)用方來的時(shí)候都是同一套說辭“我們就查一次量不大幫幫忙?！钡懿蛔∑邨l鏈路疊加在一起訂單服務(wù)每天光處理這些“別人的查詢”就要消耗掉一大半的數(shù)據(jù)庫連接池資源。更致命的是訂單服務(wù)自己的核心鏈路過一段時(shí)間就會因?yàn)橄掠畏?wù)頻繁變更接口而跟著發(fā)版本質(zhì)上已經(jīng)被這些數(shù)據(jù)依賴綁架了。這個(gè)案例里最諷刺的地方在于業(yè)務(wù)架構(gòu)圖上每個(gè)服務(wù)都是獨(dú)立的框但真實(shí)的數(shù)據(jù)流一畫出來完全是一張密密麻麻的蛛網(wǎng)。我當(dāng)時(shí)就跟團(tuán)隊(duì)說這不是微服務(wù)這是“人人為我而我沒人可求”的共享數(shù)據(jù)庫服務(wù)化。要想治這個(gè)病得先搞清楚它的根在哪。2. 病灶根源為什么微服務(wù)拆著拆著就成了數(shù)據(jù)麻花2.1 只拆應(yīng)用、不拆數(shù)據(jù)庫的“偽微服務(wù)”數(shù)據(jù)依賴癥最直接的病根就是數(shù)據(jù)庫沒有跟著服務(wù)一起拆。很多團(tuán)隊(duì)為了控制風(fēng)險(xiǎn)第一步只把Spring Boot應(yīng)用拆成多個(gè)服務(wù)數(shù)據(jù)庫仍然共用一個(gè)MySQL大庫。所有服務(wù)連的是同一個(gè)實(shí)例只是通過不同的schema或不同的表名來區(qū)分歸屬。這個(gè)模式運(yùn)行起來特別順暢服務(wù)A可以直接SQL join服務(wù)B的表服務(wù)B想要服務(wù)A的數(shù)據(jù)也不用調(diào)接口直接查就行。表面上每個(gè)服務(wù)都是獨(dú)立部署的代碼倉庫也分開了但數(shù)據(jù)邊界形同虛設(shè)。一旦幾十個(gè)服務(wù)共享上百張表加一列索引都可能引發(fā)跨服務(wù)的鎖等待改一個(gè)字段的類型就可能讓不知道哪個(gè)角落里寫SQL的服務(wù)直接報(bào)錯(cuò)。所以我的第一個(gè)判斷是要治病第一步永遠(yuǎn)是“數(shù)據(jù)跟著服務(wù)走”。每個(gè)服務(wù)必須擁有自己獨(dú)立的庫至少是獨(dú)立的schema其他服務(wù)想拿數(shù)據(jù)物理上就沒有直連通道。這個(gè)前提不落地后面所有治理動作都是空中樓閣。2.2 領(lǐng)域邊界模糊以為拆了服務(wù)其實(shí)沒拆業(yè)務(wù)第二個(gè)病根是領(lǐng)域邊界模糊。拆服務(wù)這件事正確的姿勢是按業(yè)務(wù)能力拆而不是按技術(shù)功能拆。但很多團(tuán)隊(duì)在劃分服務(wù)時(shí)習(xí)慣性地把“用戶”“訂單”“商品”這些詞直接搬過來用卻沒有仔細(xì)想清楚用戶信息到底歸用戶服務(wù)管還是訂單服務(wù)也需要一份真正屬于自己的用戶數(shù)據(jù)這里最大的坑是“同名實(shí)異”。用戶服務(wù)里的“用戶”是一個(gè)包含賬號、等級、手機(jī)號的完整實(shí)體訂單服務(wù)里的“用戶”其實(shí)只需要ID、昵稱、收貨地址這幾個(gè)快照字段營銷服務(wù)眼里的“用戶”又是另一套畫像數(shù)據(jù)。三者都叫user各自持久化但語義完全不同。問題就出在當(dāng)一個(gè)服務(wù)發(fā)現(xiàn)自己手里的“用戶數(shù)據(jù)”不夠用時(shí)它不是去訂閱事件、同步副本而是直接RPC到用戶服務(wù)實(shí)時(shí)查。一次兩次還能接受時(shí)間一長所有服務(wù)都把用戶服務(wù)當(dāng)成“公共用戶中心”數(shù)據(jù)依賴癥就從偶發(fā)變成了日常。所以要破解這個(gè)病灶必須確立“單一事實(shí)源”原則每一份數(shù)據(jù)只能有一個(gè)Owner服務(wù)其他服務(wù)需要時(shí)要么調(diào)Owner的API要么通過事件拿到副本但永遠(yuǎn)不能讓兩個(gè)服務(wù)同時(shí)擁有同一個(gè)數(shù)據(jù)的寫入權(quán)。否則數(shù)據(jù)不一致了連該怪誰都說不清楚。2.3 康威定律在助攻協(xié)作機(jī)制也在推著系統(tǒng)走向耦合第三個(gè)病根很多人沒意識到是組織協(xié)作機(jī)制在反向推著系統(tǒng)走向數(shù)據(jù)耦合?？低烧f系統(tǒng)架構(gòu)最終會趨同于組織的溝通結(jié)構(gòu)。現(xiàn)實(shí)中我見過這樣的場景業(yè)務(wù)方半個(gè)月內(nèi)要上線一個(gè)活動等不到訂單服務(wù)的排期于是提了一個(gè)“臨時(shí)需求”——直接給數(shù)據(jù)庫開一個(gè)只讀賬號?！熬瓦@一個(gè)活動兩個(gè)星期就下線?！苯Y(jié)果這個(gè)“臨時(shí)賬號”在訂單庫里活了兩年期間被七個(gè)小組用過。還有一種是接口版本失控。訂單服務(wù)對外提供的查詢接口經(jīng)常因?yàn)閮?nèi)部優(yōu)化調(diào)整字段調(diào)用方跟不上節(jié)奏就容易“另辟蹊徑”——繞過接口直接連庫拉數(shù)。這看起來是技術(shù)問題本質(zhì)上契約管理缺位數(shù)據(jù)提供方?jīng)]有穩(wěn)定承諾數(shù)據(jù)消費(fèi)方?jīng)]有約束機(jī)制。這一點(diǎn)我會在第五章專門展開。這里先記住一個(gè)結(jié)論數(shù)據(jù)依賴癥不單是技術(shù)問題它一定夾雜著團(tuán)隊(duì)協(xié)作、契約管理和架構(gòu)紀(jì)律的問題。只靠修代碼是修不干凈的。3. 從P99飆升到超時(shí)雪崩一次跨服務(wù)數(shù)據(jù)依賴事故的完整排查鏈路3.1 現(xiàn)象詳情接口P99從80ms飆到3s錯(cuò)誤率跟著起飛理論說再多不如一個(gè)真實(shí)事故有說服力。那次事故發(fā)生在周二晚高峰訂單詳情接口的P99從平時(shí)的80ms左右飆到3s以上接口錯(cuò)誤率從0.1%漲到8%。訂單詳情是App首頁的必經(jīng)接口用戶點(diǎn)開任何一單都要經(jīng)過它所以很快引起了客服側(cè)反饋。我們的第一反應(yīng)是看資源監(jiān)控訂單服務(wù)的CPU、內(nèi)存、磁盤IO、網(wǎng)絡(luò)全部正常沒有任何資源瓶頸。當(dāng)時(shí)值班同事還懷疑是中間件抖動先把訂單服務(wù)節(jié)點(diǎn)快速重啟了一輪。重啟之后確實(shí)緩了十來分鐘但很快P99又一次拉滿而且報(bào)警群里開始刷OpenFeign調(diào)用用戶服務(wù)和商品服務(wù)的超時(shí)異常。這里有個(gè)經(jīng)驗(yàn)可以分享遇到接口變慢先不要急著重啟節(jié)點(diǎn)。重啟只能清掉“已堆積的線程”但只要你代碼里的依賴關(guān)系還是錯(cuò)的請求一進(jìn)來線程池照樣會再次被打滿。那次重啟沒有解決任何實(shí)際問題只是幫我們把“這是個(gè)代碼問題”這個(gè)事實(shí)確認(rèn)得更清楚了。3.2 排查第一輪資源全沒事問題指向線程池重啟無效之后我們開始翻線程池。一查Tomcat線程池發(fā)現(xiàn)線程數(shù)已經(jīng)頂?shù)?00的上限大量新請求在隊(duì)列里排隊(duì)。這不是流量浪涌而是線程被某個(gè)遠(yuǎn)程調(diào)用“粘住”了。我們馬上抓了一個(gè)線程dump看到線程棧幾乎都停在同一個(gè)地方UserServiceClient.getUserById()。而且更讓人頭大的是這個(gè)方法是在一個(gè)for循環(huán)里被調(diào)用的。什么意思呢一個(gè)訂單帶10個(gè)商品SKU代碼就會循環(huán)調(diào)用10次商品服務(wù)RPC再去用戶服務(wù)拉一次頭像昵稱單是詳情頁一次請求就產(chǎn)生了11次同步RPC調(diào)用。正常來說Tomcat有200個(gè)線程每個(gè)請求就算慢一點(diǎn)200個(gè)并發(fā)也夠扛。但問題是每個(gè)請求都要同步等這11次RPC而下游用戶服務(wù)當(dāng)時(shí)剛好在做滾動發(fā)布大約5%的請求會變慢到兩三秒。這5%的慢請求經(jīng)過線程池排隊(duì)機(jī)制一放大直接把可用線程全部占滿最終表現(xiàn)就是誰來了都超時(shí)整個(gè)訂單詳情接口雪崩。那次排查給我的感覺是雪崩發(fā)生時(shí)上游不一定是掛了它就是慢了那么一點(diǎn)點(diǎn)但只要你把那么多同步依賴串在自己的核心路徑上慢請求就一定會被放大成系統(tǒng)級故障。3.3 鏈路追蹤找到藏了半年的“幽靈回源”確認(rèn)線程池被打滿之后我們立刻開了全鏈路追蹤當(dāng)時(shí)用的是SkyWalking把訂單詳情接口的完整調(diào)用鏈拉出來看。不看不知道一看嚇一跳。一個(gè)訂單詳情trace里包含了訂單服務(wù) - 用戶服務(wù) getUserById平均耗時(shí)120ms最慢達(dá)到2.8s訂單服務(wù) - 商品服務(wù) getProductById循環(huán)調(diào)用10次累計(jì)耗時(shí)超過500ms訂單服務(wù) - 物流服務(wù) getLogisticsByOrderId平均耗時(shí)80ms也就是說所謂“訂單詳情查詢”訂單服務(wù)自己只執(zhí)行了一次本地訂單表查詢其余時(shí)間全部在等下游的13次RPC。這種依賴關(guān)系平時(shí)是隱形的因?yàn)橄掠味己芊€(wěn)定QPS也不高大家根本感知不到。可一旦下游哪個(gè)服務(wù)抖一下這個(gè)隱藏的同步依賴就會變成事故放大器。我們內(nèi)部把這種“表面上是查詳情、實(shí)際上背了一身遠(yuǎn)程調(diào)用”的代碼稱為“幽靈回源”。它不在架構(gòu)圖里不在設(shè)計(jì)文檔里可能就是一個(gè)半年前“為了補(bǔ)個(gè)昵稱字段”留下來的邏輯但它在生產(chǎn)環(huán)境里就是一顆定時(shí)炸彈。3.4 止血與根解先恢復(fù)再給數(shù)據(jù)依賴叫停事故的臨時(shí)止血動作相對簡單我們分了三步走第一步給所有遠(yuǎn)程調(diào)用加超時(shí)。連接超時(shí)200ms讀取超時(shí)500ms絕不允許一個(gè)下游請求無限期掛住上游線程。第二步用Sentinel對用戶服務(wù)、商品服務(wù)的調(diào)用做熔斷降級。我們當(dāng)時(shí)給OpenFeign接口包了一層SentinelResource配置了異常比例熔斷規(guī)則一旦失敗比例超過閾值就快速失敗直接返回兜底值用戶昵稱顯示“用戶已注銷”商品圖片顯示占位圖。第三步訂單詳情接口改為優(yōu)先讀本地緩存即使緩存沒有命中也不允許在核心鏈路上做同步RPC補(bǔ)全。這三步做完P(guān)99立刻降回120ms以內(nèi)錯(cuò)誤率歸零。但所有人都清楚這只是止血不是治病。緩存兜底只是讓故障不再快速傳播而“詳情頁為什么要去用戶服務(wù)拉昵稱、去商品服務(wù)拉圖片”這個(gè)問題才是真正要解決的數(shù)據(jù)依賴癥。從我的經(jīng)驗(yàn)來說止血和根治必須分開對待。線上事故面前先恢復(fù)業(yè)務(wù)永遠(yuǎn)是對的但恢復(fù)之后如果不把依賴關(guān)系切斷同樣的事故一定會改頭換面再來一次。4. 切斷依賴鏈的四種實(shí)戰(zhàn)解藥4.1 數(shù)據(jù)冗余加異步同步用空間換解耦事故之后我們做的第一件事就是給訂單詳情頁建了一張“訂單展示寬表”。核心思路很簡單把需要跨服務(wù)實(shí)時(shí)查詢的數(shù)據(jù)變成訂單服務(wù)自己擁有的副本。用戶昵稱、頭像、商品名稱、商品圖片、物流狀態(tài)全都冗余到寬表里。具體流程是這樣設(shè)計(jì)的訂單服務(wù)在自己的事務(wù)內(nèi)寫入訂單主表和明細(xì)表同時(shí)發(fā)送“訂單創(chuàng)建”領(lǐng)域事件監(jiān)聽用戶信息變更事件的消費(fèi)者異步更新寬表里的昵稱、頭像字段監(jiān)聽商品信息變更事件的消費(fèi)者異步更新寬表里的商品名、圖片字段物流狀態(tài)由物流服務(wù)在狀態(tài)變更時(shí)推送消息訂單服務(wù)消費(fèi)后更新這套方案落地后訂單詳情頁的查詢就變成了純本地查詢不再有任何RPC。空間換解耦代價(jià)是寬表字段變多、同步鏈路變長但換來的是核心鏈路徹底穩(wěn)定。這里有三個(gè)坑必須提醒一是冗余字段必須明確“只讀”寫操作永遠(yuǎn)走事實(shí)源服務(wù)二是消息消費(fèi)要做冪等重復(fù)投遞不能造成數(shù)據(jù)錯(cuò)亂三是必須配定時(shí)對賬任務(wù)防止消息丟失導(dǎo)致寬表數(shù)據(jù)陳舊。沒有對賬機(jī)制的異步同步本質(zhì)上是在用另一個(gè)隱患換當(dāng)前的隱患。4.2 事件驅(qū)動把“我查你”變成“你推給我”如果你的場景冗余不太夠另一個(gè)解法是事件驅(qū)動。思路是一個(gè)服務(wù)不應(yīng)該頻繁去查詢別的服務(wù)的數(shù)據(jù)事實(shí)源服務(wù)應(yīng)該在數(shù)據(jù)變化時(shí)主動發(fā)布領(lǐng)域事件其他服務(wù)按需訂閱各自更新自己的副本。比如訂單創(chuàng)建完成后訂單服務(wù)向MQ發(fā)送一個(gè)事件事件體大概是這樣的{ eventId: 0b7f3e6a-8d4f-4e1a-9c6d-2e8f1a4b5c6d, eventType: ORDER_CREATED, timestamp: 1700000000000, payload: { orderId: 10001, userId: 8888, totalAmount: 199.00, items: [ {productId: P001, skuId: SKU001, quantity: 2, price: 99.50} ] } }消費(fèi)方收到ORDER_CREATED事件后把訂單ID、金額、商品快照寫入自己的讀模型或緩存。這樣原來下單后“你去訂單服務(wù)查一下”的邏輯變成了“訂單服務(wù)主動告訴你”。調(diào)用鏈從同步變異步任何一個(gè)服務(wù)抖動都不會拖垮另一個(gè)服務(wù)。代價(jià)也很明顯系統(tǒng)變成最終一致。某個(gè)瞬間營銷服務(wù)看到的訂單數(shù)據(jù)可能不是最新的。但大多數(shù)業(yè)務(wù)場景比如展示、統(tǒng)計(jì)、風(fēng)控特征提取天然是接受最終一致的。設(shè)計(jì)的時(shí)候要特別注意消費(fèi)冪等和亂序處理尤其要區(qū)分“消息ID冪等”和“業(yè)務(wù)冪等”比如下單事件冪等鍵應(yīng)該用業(yè)務(wù)訂單號而不是消息ID否則重復(fù)投遞會造出兩份重復(fù)的統(tǒng)計(jì)記錄。4.3 CQRS與查詢側(cè)獨(dú)立讓讀模型不再綁架業(yè)務(wù)服務(wù)第三種解法針對的是那種“查詢場景特別復(fù)雜、導(dǎo)致服務(wù)被迫暴露大量接口”的情況。很多數(shù)據(jù)依賴其實(shí)不是直接連庫而是業(yè)務(wù)方要求提供五花八門的查詢接口訂單服務(wù)為了應(yīng)付這些查詢把自己整成了一個(gè)“報(bào)表中心”。對于這種讀多寫少、查詢維度復(fù)雜的場景我會用CQRS的思路讓查詢側(cè)獨(dú)立出來。做法是業(yè)務(wù)服務(wù)正常寫自己的庫通過CDC組件Canal訂閱MySQL binlog或者Debezium訂閱PostgreSQL的WAL把數(shù)據(jù)變更同步到一個(gè)獨(dú)立的查詢庫或者Elasticsearch。所有復(fù)雜查詢、組合篩選都打到這里業(yè)務(wù)服務(wù)數(shù)據(jù)庫只承擔(dān)核心增刪改。這么做有兩個(gè)實(shí)實(shí)在在的好處。第一業(yè)務(wù)服務(wù)的數(shù)據(jù)邊界終于可以收緊別人再也不會因?yàn)椤拔乙瓷唐肪S度查訂單”來打擾核心鏈路。第二查詢側(cè)的索引結(jié)構(gòu)可以完全獨(dú)立設(shè)計(jì)不用遷就業(yè)務(wù)表之前讓人頭疼的復(fù)雜慢查詢也順勢解決了。需要提醒的是CQRS的復(fù)雜度明顯高于普通分層還要專門維護(hù)CDC的穩(wěn)定性它不是銀彈。但如果你的服務(wù)已經(jīng)出現(xiàn)了“為了一個(gè)報(bào)表功能被迫加一堆接口”的癥狀它是一個(gè)非常值得考慮的根治方向。4.4 分布式事務(wù)的選擇別一上來就上Seata講到跨服務(wù)寫數(shù)據(jù)很多人的第一反應(yīng)是上Seata。在這里我要潑一盆冷水大部分跨服務(wù)寫數(shù)據(jù)需要解決的問題根本用不上分布式事務(wù)。比如“下單同時(shí)扣庫存”很多人覺得這是強(qiáng)一致需求必須Seata。但實(shí)際上用“本地消息表異步消息”就能實(shí)現(xiàn)可靠的最終一致訂單服務(wù)在本地事務(wù)里寫訂單同時(shí)往本地消息表插一條待發(fā)送消息后臺任務(wù)掃描消息表把消息可靠投遞到MQ庫存服務(wù)消費(fèi)消息執(zhí)行扣減。因?yàn)橛唵螖?shù)據(jù)和待發(fā)消息在同一個(gè)本地事務(wù)里要么一起提交、要么一起回滾根本不存在“訂單提交了消息沒發(fā)出”的中間狀態(tài)所以數(shù)據(jù)最終一定是一致的。我整理了一張跨服務(wù)寫數(shù)據(jù)的方案對比表方便你選型方案一致性復(fù)雜度適用場景本地消息表 MQ最終一致中大多數(shù)跨服務(wù)寫推薦首選Seata AT模式強(qiáng)一致高短事務(wù)、低并發(fā)、跨庫寫必須強(qiáng)一致TCC強(qiáng)一致很高需要業(yè)務(wù)層顯示補(bǔ)償?shù)膹?fù)雜場景Outbox模式最終一致中高需要可靠事件流的核心業(yè)務(wù)域我見過太多團(tuán)隊(duì)一上來就給每個(gè)跨服務(wù)寫操作配Seata結(jié)果一個(gè)月之后因?yàn)槿宙i沖突頻繁整個(gè)下單成功率下降又灰頭土臉地把Seata摘掉。正確順序永遠(yuǎn)是先用最終一致真的不滿足業(yè)務(wù)約束再由架構(gòu)組評審是否需要強(qiáng)一致。直接用Seata解決一切問題跟用一把牛刀切所有菜一樣看著專業(yè)實(shí)際上處處別扭。5. 防止復(fù)發(fā)用“數(shù)據(jù)所有權(quán)評審”把依賴關(guān)進(jìn)籠子5.1 畫一張服務(wù)-數(shù)據(jù)歸屬矩陣解藥再多如果不建立長效機(jī)制數(shù)據(jù)依賴癥遲早復(fù)發(fā)。我們團(tuán)隊(duì)在根治階段做的最重要的一件事就是畫了一張“服務(wù)-數(shù)據(jù)歸屬矩陣”。矩陣的行是服務(wù)列是數(shù)據(jù)域單元格里填三種關(guān)系之一Owner表示該服務(wù)是這份數(shù)據(jù)唯一的事實(shí)源Reader表示該服務(wù)只允許持有只讀副本Denied表示禁止直接訪問。一個(gè)簡化的例子數(shù)據(jù)域 / 服務(wù)訂單服務(wù)用戶服務(wù)物流服務(wù)訂單數(shù)據(jù)OwnerDeniedReader副本用戶基礎(chǔ)信息Reader副本OwnerDenied物流單數(shù)據(jù)DeniedDeniedOwner每個(gè)新表、每次新的跨服務(wù)數(shù)據(jù)訪問都要拿這張矩陣來過評審。沒有Owner的僵尸表要清理。矩陣?yán)锩髅鳂?biāo)著Denied卻有人在代碼里偷偷訪問的要拉閘整改。數(shù)據(jù)邊界一旦變成白紙黑字的架構(gòu)資產(chǎn)就不再依賴某幾個(gè)人記住了。這個(gè)矩陣不需要做成很復(fù)雜的系統(tǒng)開始用Excel或者Wiki表格都行但一定要強(qiáng)制所有服務(wù)負(fù)責(zé)人更新。半年之后你會發(fā)現(xiàn)它能幫你在一分鐘里回答一個(gè)此前需要開會才能確認(rèn)的問題“到底哪些服務(wù)在讀寫我的庫”5.2 用ArchUnit把“禁止跨服務(wù)查庫”變成CI紅線矩陣是管理制度但光靠制度管不住代碼。我們當(dāng)時(shí)的下一步是把這個(gè)約束固化到自動化檢查里。既然最核心的紅線是“禁止跨服務(wù)訪問Mapper/Repository”那就直接用ArchUnit在測試階段把鏈路斷掉。簡單示例AnalyzeClasses(packages com.example.order) public class DataOwnershipTest { Test void 禁止訂單服務(wù)使用用戶服務(wù)的Mapper() { JavaClasses classes new ClassFileImporter().importPackages(com.example.order.api); ArchRule rule noClasses() .should().dependOnClassesThat().resideInAPackage(com.example.user.mapper..) .because(用戶服務(wù)的數(shù)據(jù)只能通過用戶服務(wù)API訪問禁止跨服務(wù)直連數(shù)據(jù)庫); rule.check(classes); } }這段代碼的作用是在CI階段掃描訂單服務(wù)模塊一旦發(fā)現(xiàn)代碼里引用了用戶服務(wù)Mapper包下的類構(gòu)建直接失敗根本走不到代碼評審環(huán)節(jié)。ArchRule還可以配合配置中心掃描“連接串是否指向了別人的數(shù)據(jù)源”這種更隱蔽的違規(guī)。我個(gè)人的體驗(yàn)是這類自動化守護(hù)規(guī)則的價(jià)值在于“消滅例外”。代碼評審本質(zhì)上靠人盯人總有漏網(wǎng)之魚但CI紅線不存在疲勞問題每一次提交它都會嚴(yán)格審查數(shù)據(jù)訪問邊界。新的團(tuán)隊(duì)成員進(jìn)來也會被這條紅線直接教育到位。5.3 數(shù)據(jù)消費(fèi)者契約讓依賴從潛規(guī)則變成明規(guī)則最后一項(xiàng)治理措施是數(shù)據(jù)消費(fèi)者契約。所有跨服務(wù)的數(shù)據(jù)訪問都必須走提供方正式發(fā)布的契約而不是“找DBA開個(gè)賬號就能查”。契約分兩類。一類是查詢API契約用OpenAPI定義接口、參數(shù)、限流閾值和調(diào)用協(xié)議另一類是事件契約比如RocketMQ的Topic規(guī)范、事件payload的版本號、上線通知機(jī)制。消費(fèi)者只依賴契約不依賴提供方內(nèi)部實(shí)現(xiàn)。提供方做契約變更要遵守兼容性原則字段只增不改不刪先灰度后全量如果確實(shí)要做破壞性變更至少提前兩個(gè)版本周期通知所有訂閱方。這一條乍看是流程制度但恰恰是治本的。數(shù)據(jù)依賴癥的病根一半在技術(shù)、一半在管理把數(shù)據(jù)訪問納入了契約管理就等于在“臨時(shí)想查就查”的沖動前面攔了一道硬性閘門。我們當(dāng)時(shí)把這條規(guī)則更新到研發(fā)規(guī)范里之后跨服務(wù)直連數(shù)據(jù)庫的新增案例基本清零。最后說點(diǎn)個(gè)人體會。把這個(gè)病徹底治過來我們前后花了一個(gè)多季度代碼改動量說實(shí)話并不大最費(fèi)勁的是讓整個(gè)團(tuán)隊(duì)接受“數(shù)據(jù)是有邊界的”這個(gè)觀念?，F(xiàn)在每次新服務(wù)上線或者老服務(wù)重構(gòu)我都會先問三個(gè)問題這個(gè)服務(wù)的數(shù)據(jù)庫有幾個(gè)其他服務(wù)在連它一條核心鏈路上要RPC查幾個(gè)服務(wù)的數(shù)據(jù)這些數(shù)據(jù)依賴有沒有契約、有沒有兜底如果你發(fā)現(xiàn)答案全是“數(shù)不清、沒想過、不知道”那基本可以確診了。數(shù)據(jù)依賴癥這東西越拖越貴越早治越輕松。