見(jiàn)過(guò)太多把訂單表塞滿狀態(tài)字段的系統(tǒng)了三五十個(gè)字段、十來(lái)種狀態(tài)、十幾個(gè)流程節(jié)點(diǎn)每個(gè)部門(mén)對(duì)“訂單”的理解還不一樣銷(xiāo)售覺(jué)得訂單是合同財(cái)務(wù)覺(jué)得訂單是發(fā)票依據(jù)倉(cāng)儲(chǔ)覺(jué)得訂單是揀貨指令。結(jié)果就是業(yè)務(wù)一提需求開(kāi)發(fā)先吵一架改一版表結(jié)構(gòu)再吵一架。后來(lái)我接觸到一個(gè)叫REA的東西——Resource-Event-Agent徹底改變了我的建模思路。它不是某個(gè)前端框架也不是新出的編程語(yǔ)言而是一套從會(huì)計(jì)學(xué)里走出來(lái)的業(yè)務(wù)建模方法專(zhuān)門(mén)用來(lái)回答“這個(gè)系統(tǒng)里到底發(fā)生了什么經(jīng)濟(jì)事件誰(shuí)參與動(dòng)了什么資源”。這篇文章我就從一個(gè)實(shí)踐者的角度把REA模型這套東西掰開(kāi)揉碎講清楚它解決什么問(wèn)題、三個(gè)核心概念怎么落地、數(shù)據(jù)模型怎么設(shè)計(jì)、服務(wù)怎么拆分、對(duì)賬怎么做以及我在實(shí)際項(xiàng)目中踩過(guò)的坑。適合正準(zhǔn)備做中臺(tái)、微服務(wù)拆分、或者被復(fù)雜業(yè)務(wù)狀態(tài)搞到頭禿的架構(gòu)師和開(kāi)發(fā)者參考。1. REA模型的核心思想與行業(yè)價(jià)值1.1 REA到底是什么從會(huì)計(jì)學(xué)走出來(lái)的業(yè)務(wù)建模范式REA的全稱(chēng)是Resource-Event-Agent最早是上個(gè)世紀(jì)八十年代由會(huì)計(jì)信息系統(tǒng)領(lǐng)域的研究者提出來(lái)的。傳統(tǒng)會(huì)計(jì)模型關(guān)注的是借貸分錄但REA的初衷是擺脫單純面向財(cái)務(wù)報(bào)表的表單思維轉(zhuǎn)而描述業(yè)務(wù)本身的真實(shí)結(jié)構(gòu)。它的核心論斷非常簡(jiǎn)潔任何業(yè)務(wù)活動(dòng)本質(zhì)上都是Agent通過(guò)控制Resource參與Event的過(guò)程。這個(gè)論斷看起來(lái)很抽象但非常耐琢磨。舉個(gè)例子你在電商平臺(tái)買(mǎi)了一瓶水。用傳統(tǒng)建模方式我們會(huì)在數(shù)據(jù)庫(kù)里建一張訂單表字段包括商品ID、數(shù)量、金額、狀態(tài)、收貨地址、下單時(shí)間。但用REA的眼光看這瓶水從倉(cāng)庫(kù)貨架轉(zhuǎn)移到你的手中就是一次Resource的“流經(jīng)”過(guò)程而下單、付款、發(fā)貨這三個(gè)動(dòng)作才是真正值得記錄的Event買(mǎi)家、賣(mài)家、倉(cāng)庫(kù)管理員、快遞員是參與整個(gè)過(guò)程的Agent。REA的牛掰之處在于它把“業(yè)務(wù)”從“表單狀態(tài)”中解放了出來(lái)。傳統(tǒng)方式里訂單的狀態(tài)可能叫“已付款”“已發(fā)貨”“已完成”這是一種以表單為中心的視角狀態(tài)是人工定義的枚舉值既容易遺漏又容易和別的部門(mén)口徑?jīng)_突。而REA視角下系統(tǒng)里記錄的是一條一條不可變的事實(shí)在什么時(shí)間哪個(gè)參與者對(duì)什么資源執(zhí)行了什么動(dòng)作。狀態(tài)只是這些事實(shí)的投影隨時(shí)可以根據(jù)需要重新計(jì)算。這個(gè)思想跟事件溯源不謀而合所以今天聊微服務(wù)、聊消息驅(qū)動(dòng)REA模型反而越來(lái)越有參考價(jià)值。1.2 為什么要用REA傳統(tǒng)狀態(tài)機(jī)模型的痛點(diǎn)用狀態(tài)機(jī)建模業(yè)務(wù)系統(tǒng)表面上直觀實(shí)際維護(hù)成本會(huì)隨著業(yè)務(wù)復(fù)雜度指數(shù)級(jí)上升。我參與過(guò)某大型商城的訂單域重構(gòu)老系統(tǒng)訂單表里光狀態(tài)就有二十多種還不算各種標(biāo)志位。最難受的是每加一種業(yè)務(wù)規(guī)則就要重新審視所有狀態(tài)的流轉(zhuǎn)是否合理。比如“退貨中”這個(gè)狀態(tài)支付那邊已經(jīng)退款倉(cāng)儲(chǔ)那邊貨還沒(méi)收回來(lái)客服說(shuō)用戶(hù)已寄出財(cái)務(wù)說(shuō)退款失敗了——一個(gè)狀態(tài)根本描述不了這種多點(diǎn)并發(fā)的真實(shí)情況。REA把這種局面徹底改變了。訂單不是由狀態(tài)構(gòu)成的而是由一系列Event構(gòu)成的。每個(gè)Event都有明確的時(shí)間戳和參與者多個(gè)Event之間可以并行、可以亂序、甚至可以在時(shí)序上重疊。系統(tǒng)不需要維護(hù)一個(gè)“當(dāng)前狀態(tài)”字段只需要把所有Event存檔然后通過(guò)投影算法計(jì)算出最終結(jié)果。訂單是否完成不再是某個(gè)狀態(tài)位而是“買(mǎi)家確認(rèn)收貨事件”和“賣(mài)家收到貨款事件”是否都真實(shí)發(fā)生。這種范式在排查歷史問(wèn)題的時(shí)候尤其給力。狀態(tài)機(jī)模型下如果用戶(hù)說(shuō)“我收了貨但平臺(tái)顯示未完成”需要翻日志猜測(cè)當(dāng)時(shí)狀態(tài)被誰(shuí)改了REA模型下直接查“收貨事件”是否記錄在案沒(méi)有就是沒(méi)有有的就是有事實(shí)清清楚楚。1.3 REA的適用范圍與不適用場(chǎng)景REA并不是萬(wàn)能的。它天生適合那些“有明確經(jīng)濟(jì)資源流動(dòng)”的領(lǐng)域電商、ERP、進(jìn)銷(xiāo)存、供應(yīng)鏈金融、物流、賬戶(hù)賬本系統(tǒng)。這些系統(tǒng)里資源流轉(zhuǎn)清晰參與者明確每次動(dòng)作都是不可逆的經(jīng)濟(jì)事件用REA構(gòu)建會(huì)非常舒服。但對(duì)一些偏內(nèi)容運(yùn)營(yíng)、社交互動(dòng)的系統(tǒng)REA就有點(diǎn)殺雞用牛刀。你不能說(shuō)“用戶(hù)點(diǎn)贊”是一個(gè)經(jīng)濟(jì)事件“粉絲關(guān)注”是一個(gè)Agent控制資源的動(dòng)作硬套的話會(huì)非常別扭。同樣純文檔管理系統(tǒng)、后臺(tái)配置系統(tǒng)、內(nèi)容CMS也不適合。判斷的標(biāo)準(zhǔn)很樸素系統(tǒng)里有沒(méi)有“錢(qián)、貨、權(quán)、務(wù)”這些實(shí)打?qū)嵉臇|西在流動(dòng)有REA合適沒(méi)有普通CRUD就夠了。2. REA的關(guān)鍵概念拆解與設(shè)計(jì)原則2.1 三個(gè)基石概念Resource、Event、Agent的含義REA三元組中的每一個(gè)概念都有明確定義不能拍腦袋亂用。Resource是稀缺且有價(jià)值的東西企業(yè)或個(gè)人可以對(duì)其進(jìn)行控制和使用。它不一定是有形的現(xiàn)金是資源、庫(kù)存商品是資源、積分是資源、公共服務(wù)額度也是資源。關(guān)鍵屬性是“可以轉(zhuǎn)化”和“可以被擁有者支配”。在表設(shè)計(jì)時(shí)Resource通常對(duì)應(yīng)一張“主數(shù)據(jù)表”比如商品表、賬戶(hù)表、倉(cāng)庫(kù)表。Event是改變資源狀態(tài)的動(dòng)作它是REA模型的絕對(duì)核心。一次采購(gòu)、一回銷(xiāo)售、一筆轉(zhuǎn)賬、一個(gè)入庫(kù)動(dòng)作都是Event。Event最大的特點(diǎn)是不可刪改只能追加。你下錯(cuò)了單不能把“下單事件”改成“取消下單事件”只能追加一條“取消事件”。Event還需要具備冪等鍵——業(yè)務(wù)唯一標(biāo)識(shí)比如支付單號(hào)、流水號(hào)用來(lái)防止消息重試導(dǎo)致重復(fù)記錄。Agent是參與Event的個(gè)體或組織包括內(nèi)部Agent和外部Agent。內(nèi)部Agent是公司內(nèi)的部門(mén)、員工、系統(tǒng)機(jī)器人外部Agent是客戶(hù)、供應(yīng)商、承運(yùn)商、監(jiān)管機(jī)構(gòu)。設(shè)計(jì)時(shí)最重要的是區(qū)分“代理關(guān)系”——客戶(hù)付款這個(gè)Event實(shí)際參與人是客戶(hù)但內(nèi)部訂單員可能替他輸入單據(jù)。REA里這兩者是要分成不同角色記錄的不能用“操作人”一個(gè)字段糊弄過(guò)去。2.2 四類(lèi)關(guān)系與雙向性原則REA模型強(qiáng)調(diào)了四類(lèi)業(yè)務(wù)增量關(guān)系這是整個(gè)建模最精妙、也最容易被忽視的部分。第一存量與流量關(guān)系Resource的期末存量等于期初存量加上流入流量減去流出流量。這是對(duì)賬、庫(kù)存核算的根本公式。在數(shù)據(jù)庫(kù)設(shè)計(jì)時(shí)Resource表只需要記錄當(dāng)前余額而“余額變化”全部推給Event表來(lái)承載。商品庫(kù)存表里的數(shù)字不過(guò)是對(duì)入庫(kù)、出庫(kù)、報(bào)廢等Event做聚合計(jì)算的結(jié)果而不是業(yè)務(wù)事實(shí)本身。第二源與目標(biāo)關(guān)系明確資源從哪里來(lái)、到哪里去。比如“采購(gòu)入庫(kù)”事件資源的源是供應(yīng)商目標(biāo)是我們自己的倉(cāng)庫(kù)“銷(xiāo)售出庫(kù)”事件資源的源是我們的庫(kù)存目標(biāo)是客戶(hù)。第三控制關(guān)系表示Agent對(duì)Resource的支配權(quán)限?？蛻?hù)控制他的應(yīng)收賬款倉(cāng)庫(kù)管理員控制托管中的庫(kù)存商品財(cái)務(wù)控制銀行賬戶(hù)?？刂脐P(guān)系把“誰(shuí)能動(dòng)什么資源”說(shuō)清楚為權(quán)限設(shè)計(jì)提供業(yè)務(wù)底層的依據(jù)。第四配對(duì)關(guān)系緊密關(guān)聯(lián)的兩個(gè)互補(bǔ)事件必須成對(duì)出現(xiàn)。比如“收款”和“提供商品”配對(duì)“付款”和“收到服務(wù)”配對(duì)。這個(gè)關(guān)系直接支撐了冪等和事務(wù)一致性的設(shè)計(jì)——一個(gè)事件如果沒(méi)有對(duì)應(yīng)的配對(duì)事件那業(yè)務(wù)上就是不完整的系統(tǒng)就要發(fā)出告警。2.3 事件溯源與REA模型為什么會(huì)自然契合事件溯源是近幾年后端圈的熱門(mén)詞匯具體做法是不保存對(duì)象當(dāng)前狀態(tài)而是把每次狀態(tài)變化都保存為不可變事件流。這跟REA的Event思想幾乎是同一個(gè)東西只是名字不同。REA系統(tǒng)天然就是事件溯源友好的。在設(shè)計(jì)案中Event表就是那個(gè)可以重放的事件日志。訂單當(dāng)前狀態(tài)不需要單獨(dú)維護(hù)表只要把該訂單的所有Event按照時(shí)間順序重放一遍任何時(shí)刻的快照都能復(fù)原。如果發(fā)現(xiàn)某筆賬不平最直接的排查方法就是把兩條配對(duì)Event拉出來(lái)對(duì)比而不是像傳統(tǒng)系統(tǒng)那樣糾結(jié)于某一次UPDATE操作。我見(jiàn)過(guò)不少團(tuán)隊(duì)在引入REA時(shí)還要強(qiáng)行保留狀態(tài)字段理由是“查詢(xún)性能考慮”。其實(shí)這是不必要的。所有Event重放確實(shí)慢但可以引入投影表——即預(yù)計(jì)算好的當(dāng)前狀態(tài)快照本質(zhì)上是CQRS中的讀模型。業(yè)務(wù)邏輯以Event為準(zhǔn)查詢(xún)性能用投影表來(lái)扛兩邊兼顧。2.4 冪等性設(shè)計(jì)從配對(duì)關(guān)系中反推做分布式系統(tǒng)時(shí)冪等性永遠(yuǎn)是繞不開(kāi)的問(wèn)題。很多團(tuán)隊(duì)的第一反應(yīng)是“給每個(gè)接口生成一個(gè)唯一requestId”這沒(méi)錯(cuò)但如果底層數(shù)據(jù)模型不支持你還是會(huì)在對(duì)賬時(shí)發(fā)現(xiàn)重復(fù)。REA模型把冪等變成了業(yè)務(wù)約束。具體做法是每個(gè)Event都帶有全局唯一的EventKey這個(gè)EventKey必須是業(yè)務(wù)上天然唯一的值。拿支付事件來(lái)說(shuō)第三方支付回調(diào)里的交易流水號(hào)就是天然冪等鍵拿庫(kù)存扣減事件來(lái)說(shuō)出庫(kù)單號(hào)就是唯一鍵拿積分變更來(lái)說(shuō)活動(dòng)編號(hào)加用戶(hù)ID加批次號(hào)是唯一鍵。入庫(kù)前先查EventKey是否存在存在就丟棄或返回已有結(jié)果這比在業(yè)務(wù)邏輯層用分布式鎖、樂(lè)觀鎖之類(lèi)的東西要干凈得多。而且REA的配對(duì)關(guān)系會(huì)把冪等的范圍擴(kuò)大。比如訂單支付事件和訂單履約事件之間不是互相獨(dú)立的關(guān)系而是必須匹配的配對(duì)關(guān)系。系統(tǒng)在記錄一個(gè)事件的同時(shí)就要指定它與哪個(gè)既有事件配對(duì)。這樣即使某個(gè)環(huán)節(jié)被重復(fù)觸發(fā)配對(duì)關(guān)系也只會(huì)建立一次整條鏈路天然防重。3. 基于REA模型的業(yè)務(wù)系統(tǒng)落地全過(guò)程3.1 從業(yè)務(wù)事件流出發(fā)識(shí)別核心對(duì)象落地REA系統(tǒng)第一步不是建表而是做業(yè)務(wù)事件盤(pán)點(diǎn)。我習(xí)慣用一張業(yè)務(wù)事件清單來(lái)整理。以某跨平臺(tái)商城系統(tǒng)為例業(yè)務(wù)人員和我們一起梳理出了下面的清單僅展示部分事件名稱(chēng)涉及資源外部Agent內(nèi)部Agent前置事件配對(duì)事件客戶(hù)下單商品庫(kù)存、訂單客戶(hù)訂單專(zhuān)員無(wú)倉(cāng)庫(kù)發(fā)貨支付完成銀行存款、應(yīng)收賬款客戶(hù)、支付網(wǎng)關(guān)財(cái)務(wù)系統(tǒng)客戶(hù)下單訂單發(fā)貨倉(cāng)庫(kù)發(fā)貨商品庫(kù)存承運(yùn)商倉(cāng)儲(chǔ)員支付完成客戶(hù)確認(rèn)收貨客戶(hù)收貨商品所有權(quán)客戶(hù)無(wú)倉(cāng)庫(kù)發(fā)貨支付結(jié)算確認(rèn)供應(yīng)商供貨商品庫(kù)存供應(yīng)商采購(gòu)員采購(gòu)訂單財(cái)務(wù)付款這個(gè)表格是系統(tǒng)設(shè)計(jì)的藍(lán)圖。每行的“事件名稱(chēng)”就是一個(gè)微服務(wù)或模塊的核心接口“涉及資源”就是需要管理的Resource“外部Agent”和“內(nèi)部Agent”寫(xiě)清楚了誰(shuí)在什么角色下參與了動(dòng)作“配對(duì)事件”則是后續(xù)對(duì)賬、一致性校驗(yàn)的錨點(diǎn)。這個(gè)過(guò)程相比傳統(tǒng)需求分析最大的差異是我們不問(wèn)產(chǎn)品經(jīng)理“訂單有哪些狀態(tài)”而是問(wèn)“業(yè)務(wù)上一共會(huì)發(fā)生哪些事實(shí)”。狀態(tài)是主觀歸納事件是客觀記錄后者更穩(wěn)定。老系統(tǒng)里今天改一個(gè)狀態(tài)、明天加一個(gè)標(biāo)志位原因正是沒(méi)有把“事實(shí)”跟“解讀”分開(kāi)。3.2 將REA模型映射到數(shù)據(jù)表結(jié)構(gòu)事件盤(pán)點(diǎn)完成之后表結(jié)構(gòu)設(shè)計(jì)就順理成章了。一個(gè)相對(duì)完整的REA核心數(shù)據(jù)模型包含四種類(lèi)型Agent表、Resource表、Event表、Event關(guān)系表。Agent表用來(lái)記錄參與者的基礎(chǔ)信息Customer、Supplier、Employee這些可以分表也可以統(tǒng)一放在一個(gè)Agent表里然后用類(lèi)型字段區(qū)分。Resource表同樣如此不同的資源分類(lèi)可以細(xì)化成商品表、賬戶(hù)表、倉(cāng)庫(kù)表。Event表是重中之重最少包含這些字段事件ID自增主鍵、事件UUI業(yè)務(wù)冪等鍵、事件類(lèi)型、發(fā)生時(shí)間、資源多ID關(guān)聯(lián)、Agent多ID關(guān)聯(lián)、事件附屬描述信息JSON。不能把“當(dāng)前狀態(tài)”放在這張表里因?yàn)檫@張表只存“發(fā)生的事實(shí)”事實(shí)沒(méi)有狀態(tài)。Event關(guān)系表是很容易被忽略的一張表。它記錄Event與Event之間的配對(duì)關(guān)系。以付款和發(fā)貨為例發(fā)貨事件需要引用支付事件的業(yè)務(wù)UUI這就是配對(duì)關(guān)系在數(shù)據(jù)層的表達(dá)。有了這張關(guān)系查詢(xún)“某訂單是否已經(jīng)閉環(huán)”只需一條SQL查配對(duì)關(guān)系表里該訂單的“發(fā)貨事件”有沒(méi)有關(guān)聯(lián)到“支付事件”。下面是一段簡(jiǎn)化的建表語(yǔ)句以PostgreSQL為例展示Event表的核心設(shè)計(jì)思路create table business_event ( id bigserial primary key, event_uuid varchar(64) not null unique, event_type varchar(32) not null, occurred_at timestamptz not null, resource_id varchar(64) not null, source_agent varchar(64) not null, target_agent varchar(64) not null, payload jsonb not null default {}, pair_event_id bigint references business_event(id) ); create index idx_biz_event_resource on business_event(resource_id, occurred_at); create index idx_biz_event_pair on business_event(pair_event_id) where pair_event_id is not null;這里把pair_event_id直接放在同一張Event表里是因?yàn)閷?duì)一個(gè)簡(jiǎn)單案例來(lái)說(shuō)一個(gè)事件最多只會(huì)有一個(gè)配對(duì)事件。如果業(yè)務(wù)更復(fù)雜可以單獨(dú)建關(guān)聯(lián)表。設(shè)計(jì)原則就一條用事實(shí)記錄事實(shí)不要讓狀態(tài)機(jī)插足。3.3 服務(wù)拆分與服務(wù)間協(xié)作模式REA模型天然指導(dǎo)微服務(wù)拆分。傳統(tǒng)按業(yè)務(wù)狀態(tài)劃服務(wù)容易造成“訂單服務(wù)什么都管”的上帝服務(wù)而REA按經(jīng)濟(jì)事件邊界拆分每個(gè)服務(wù)負(fù)責(zé)一組高內(nèi)聚的Event。以前面那個(gè)商城為例可以拆出下單服務(wù)負(fù)責(zé)客戶(hù)下單Event、支付服務(wù)支付完成Event、履約服務(wù)倉(cāng)庫(kù)發(fā)貨Event、財(cái)務(wù)結(jié)算服務(wù)收款確認(rèn)、付款結(jié)算Event。這些服務(wù)之間不直接共享數(shù)據(jù)庫(kù)而是通過(guò)消息隊(duì)列傳遞事件。只有Event流轉(zhuǎn)沒(méi)有接口級(jí)聯(lián)調(diào)用服務(wù)的獨(dú)立性非常高。這個(gè)拆分邏輯和DDD限界上下文的做法是相通的但REA給了個(gè)更硬朗的劃分依據(jù)凡是牽涉同一資源的同類(lèi)動(dòng)作放到同一個(gè)域里。比如庫(kù)存的入庫(kù)、出庫(kù)、盤(pán)點(diǎn)、報(bào)廢都是直接改變庫(kù)存資源的Event只歸履約服務(wù)管其他服務(wù)想動(dòng)庫(kù)存只能發(fā)消息請(qǐng)求不能直連數(shù)據(jù)庫(kù)。服務(wù)之間的協(xié)作方式也有講究。下單服務(wù)發(fā)布“OrderCreated”事件支付服務(wù)訂閱后生成支付單支付網(wǎng)關(guān)回調(diào)后支付服務(wù)發(fā)布“PaymentCompleted”事件履約服務(wù)訂閱后生成發(fā)貨單。每個(gè)服務(wù)的業(yè)務(wù)邏輯都圍繞“事件來(lái)了我記錄一個(gè)事實(shí)然后判斷是否需要發(fā)起新事件”這個(gè)模式展開(kāi)。清晰、穩(wěn)定、好排查。3.4 對(duì)賬與一致性校驗(yàn)的實(shí)現(xiàn)REA模型落地后對(duì)賬不再依賴(lài)人工導(dǎo)Excel而可以寫(xiě)成一套自動(dòng)校驗(yàn)程序。核心就是存量與流量關(guān)系、配對(duì)關(guān)系兩條規(guī)則。先說(shuō)存量流量校驗(yàn)。拿庫(kù)存來(lái)說(shuō)每個(gè)資源在任何時(shí)點(diǎn)的存量都等于期初值加流入減流出。我們把每天的Event按資源ID聚合計(jì)算出理論應(yīng)存數(shù)量和資源表中的當(dāng)前數(shù)量做比對(duì)不一致就告警。對(duì)應(yīng)到賬戶(hù)余額財(cái)務(wù)總賬余額必須等于期初余額加上所有借貸Event的匯總值。這個(gè)檢查用一條SQL就可以做。再說(shuō)配對(duì)校驗(yàn)。系統(tǒng)每產(chǎn)生一個(gè)Event時(shí)我們可以給它標(biāo)記一個(gè)“配對(duì)期望”如果已發(fā)生事件在預(yù)期時(shí)間窗口內(nèi)沒(méi)有等到配套事件就進(jìn)入待核查隊(duì)列。舉一個(gè)實(shí)際場(chǎng)景支付完成事件發(fā)生后履約服務(wù)在48小時(shí)內(nèi)沒(méi)有產(chǎn)生對(duì)應(yīng)的發(fā)貨事件系統(tǒng)彈出對(duì)賬差異單。這樣的機(jī)制大幅削減了業(yè)務(wù)差錯(cuò)率也比盲目的人工追查高效得多。4. 實(shí)操中的典型問(wèn)題與排查經(jīng)驗(yàn)實(shí)錄4.1 把REA做成了ER模型的換皮這是新手最容易跳進(jìn)去的坑。團(tuán)隊(duì)覺(jué)得建了幾張Event表、加了對(duì)Agent的引用、把狀態(tài)字段挪進(jìn)了Event就叫REA。實(shí)際上他們只是把原來(lái)的訂單表改名為Event表里面的“status”字段還在狀態(tài)機(jī)的邏輯還捂在服務(wù)層代碼里。這種“換皮式REA”最要命既沒(méi)有事件不可變性也沒(méi)有配對(duì)關(guān)系還沒(méi)享受到可追溯性紅利反而多了一層抽象維護(hù)成本更高。怎么判斷自己有沒(méi)有真的落地REA我常說(shuō)一個(gè)標(biāo)準(zhǔn)如果你在Event表里加了“狀態(tài)”字段而且系統(tǒng)業(yè)務(wù)邏輯要靠修改這個(gè)字段來(lái)流轉(zhuǎn)那你就不是REA。真正的事件表是只插入、不更新的。狀態(tài)屬于投影層是讀模型的事不應(yīng)該躺在業(yè)務(wù)事件表里面。4.2 事件表數(shù)據(jù)膨脹與查詢(xún)性能下降所有Event都追加保存運(yùn)行一年后表里可能有幾千萬(wàn)行。還有人遇到過(guò)來(lái)自行查詢(xún)時(shí)有明顯的慢SQL。這個(gè)問(wèn)題需要正面面對(duì)事件數(shù)據(jù)是“寫(xiě)多讀少、按時(shí)間追加”的流式數(shù)據(jù)需要針對(duì)這種特征做專(zhuān)門(mén)優(yōu)化。我的做法是對(duì)查詢(xún)頻繁的讀模型單獨(dú)建投影表對(duì)歷史事件定期歸檔到冷存儲(chǔ)。比如三個(gè)月之前的Event搬移到歷史事件庫(kù)只保留匯總信息在在線庫(kù)。代碼層使用一個(gè)查詢(xún)路由查當(dāng)月數(shù)據(jù)走在線索引查歷史走歸檔庫(kù)然后合并結(jié)果。大多數(shù)業(yè)務(wù)場(chǎng)景下歸檔查詢(xún)頻率極低慢幾秒完全可接受而在線庫(kù)瘦身后性能能穩(wěn)定維持在個(gè)位數(shù)毫秒級(jí)。4.3 多方參與者的審批與協(xié)作建模真實(shí)業(yè)務(wù)里一個(gè)Event往往需要多個(gè)Agent審批比如供應(yīng)商送貨要質(zhì)檢差旅報(bào)銷(xiāo)要經(jīng)理批準(zhǔn)。REA初學(xué)者最容易在這里迷惑覺(jué)得一個(gè)Event怎么有這么多參與人。其實(shí)REA并不是說(shuō)一次Event只能有一個(gè)Agent它說(shuō)的是要區(qū)分Agent的角色身份。應(yīng)對(duì)方案是把“審批”動(dòng)作本身也建模為若干個(gè)子Event。比如質(zhì)檢審批質(zhì)檢員執(zhí)行“質(zhì)檢通過(guò)”事件倉(cāng)庫(kù)執(zhí)行“收貨確認(rèn)”事件采購(gòu)執(zhí)行“賬期確認(rèn)”事件。這些子Event都是獨(dú)立事實(shí)可以并發(fā)、可以亂序最終以最后一個(gè)事件作為主流程的觸發(fā)條件。這個(gè)模型比在工作流引擎里畫(huà)一排審批節(jié)點(diǎn)更有彈性也更符合業(yè)務(wù)真實(shí)面貌。4.4 時(shí)間口徑不一致導(dǎo)致的對(duì)賬爭(zhēng)議業(yè)務(wù)系統(tǒng)里最怕的是“同一個(gè)事實(shí)兩邊統(tǒng)計(jì)口徑不一樣”。下單時(shí)間、支付時(shí)間、結(jié)算時(shí)間、入賬時(shí)間看似都是時(shí)間在財(cái)務(wù)、運(yùn)營(yíng)、倉(cāng)儲(chǔ)三個(gè)部門(mén)眼里卻可能差出天和地。REA模型能統(tǒng)一口徑因?yàn)槊總€(gè)Event只有唯一的發(fā)生時(shí)間戳不能因?yàn)槿雸?bào)表就改時(shí)間。但有一個(gè)坑要提醒物理時(shí)間戳和業(yè)務(wù)時(shí)間的處理必須分開(kāi)。支付網(wǎng)關(guān)回調(diào)的時(shí)間有時(shí)和用戶(hù)實(shí)際支付時(shí)間差出幾秒如果系統(tǒng)直接使用回調(diào)時(shí)間做入賬時(shí)間就會(huì)和支付對(duì)賬單對(duì)不上。我們的做法是每條Event同時(shí)保留“實(shí)際發(fā)生時(shí)間”和“系統(tǒng)接收時(shí)間”兩個(gè)時(shí)間戳業(yè)務(wù)統(tǒng)計(jì)一律用實(shí)際發(fā)生時(shí)間系統(tǒng)排查問(wèn)題用接收時(shí)間兩不相混。寫(xiě)在最后我在實(shí)際項(xiàng)目里折騰REA模型也踩了不少坑但重構(gòu)完成之后再回頭看最大的感受是業(yè)務(wù)團(tuán)隊(duì)和開(kāi)發(fā)團(tuán)隊(duì)的對(duì)話方式徹底變了。以前討論訂單狀態(tài)大家各說(shuō)各話現(xiàn)在聊的是“這個(gè)事件有沒(méi)有發(fā)生”“誰(shuí)做的”“動(dòng)了哪個(gè)資源”問(wèn)題是照著事實(shí)來(lái)找的不再靠拍腦袋猜?tīng)顟B(tài)。無(wú)論你現(xiàn)在是用傳統(tǒng)狀態(tài)機(jī)維護(hù)老系統(tǒng)還是正在規(guī)劃新業(yè)務(wù)的領(lǐng)域模型我建議你先別急著寫(xiě)表結(jié)構(gòu)花一周時(shí)間梳理業(yè)務(wù)事件清單再用REA重新畫(huà)一遍數(shù)據(jù)關(guān)系。這套思路不會(huì)讓你多寫(xiě)出多少代碼但它能讓你少寫(xiě)無(wú)數(shù)個(gè)補(bǔ)丁。