有贊的交易系統(tǒng)架構(gòu)困局以及破局之道

在開始下面的話題之前，我們先看一看有贊原有的核心交易架構(gòu)。

初步看去，這套架構(gòu)方案似乎看不出什么問題。事實情況也這樣，我們做這套交易方案支持了日百萬級的交易規(guī)模，取得了很不錯的成果。

在2016年，公司經(jīng)歷了飛速的成長， 整體團隊人員擴張了數(shù)倍， 公司整體業(yè)務(wù)線從單一的微商城電商交易型態(tài)擴張到支持多個垂直行業(yè)。交易團隊也碰到了很多尷尬的情況：

垂直行業(yè)接入交易很困難，交易團隊對于業(yè)務(wù)團隊的支撐響應(yīng)速度趕不上業(yè)務(wù)的迭代速度，最后垂直行業(yè)被迫自己完全重做了一套針對垂直業(yè)務(wù)的交易系統(tǒng)。比如：商業(yè)化服務(wù)訂購，收營，批發(fā)等業(yè)務(wù)。浪費了公司寶貴的技術(shù)資源。

交易團隊的新同學(xué)，上手交易核心的開發(fā)非常困難，在沒有完合弄懂整套系統(tǒng)之間，不敢放手讓新同學(xué)開發(fā)。學(xué)習(xí)成本極高。

很多的玩法不能進行組合，如果想進行組合，必須要求進行重新編碼，把組合的方案當(dāng)做一個新方案來做。比如：虛擬商品的拼團業(yè)務(wù)， 酒店的分銷業(yè)務(wù)，等等， 都不能用很簡單的方案做支持。 產(chǎn)品運營同學(xué)的創(chuàng)造性想法，得不到很快的支持。

上線了一個小需求，導(dǎo)致的主流的核心交易大面積出現(xiàn)故障。影響范圍不能進行隔離。

我們的困難根源

在此之前，我們先看一看公司對于交易團隊的要求，以及業(yè)務(wù)團隊對于交易能力的訴求。

從上圖中，可以看到，從業(yè)務(wù)團隊的視角上來看，交易能力，其實是一種云化能力。不管是什么樣的業(yè)務(wù)場景，只要交易場景存在，那么交易能力就應(yīng)該能覆蓋。換句話說，交易團隊存在的價值，就是”能夠很快速地支持所有業(yè)務(wù)的交易“。

這個時候稍微清晰了一點當(dāng)前的困難的原因：原來的我們，一直是在做微商城的業(yè)務(wù)，認(rèn)為”微商城的業(yè)務(wù)規(guī)則=交易的能力“。這個定位與垂直業(yè)務(wù)的期望很不匹配。

既然”微商城的交易規(guī)則“不等于”交易能力“，那么交易能力是什么？ 有什么內(nèi)容？與垂直業(yè)務(wù)又有什么關(guān)系？

這三個是很有意思的問題。 在弄明白這三個問題之前，我們先把我們從一個互聯(lián)網(wǎng)從業(yè)者的角色，轉(zhuǎn)變成一個普通的人。假設(shè)我們要去做三件事情，我們看一看現(xiàn)實生活的交易細(xì)節(jié)：

我要去路邊攤買一斤瓜子。

“老板，多少錢一斤瓜子” ?！?2元一斤奶油的” ?！敖o我稱一斤”。 然后老板給我稱了一斤，我付錢， 拿瓜子，走人。

我要去樓下吃一碗面。

“老板，熱干面多少錢一碗” 。“15元一碗”。“給我來一碗” 。然后我坐下， 吃完面，付錢， 走人。

我要去售樓處，買一套期房。

這個場景就更復(fù)雜了，我需要先看房周邊的環(huán)境，看價格，然后弄清楚開發(fā)商的承諾， 然后，找售樓小姐聊價格，拿合同，簽字， 付現(xiàn)金首付，然后找銀行貸款付完余下的錢。 待房子開發(fā)完之后，再找開發(fā)商確認(rèn)收房。最后整個交易才算完畢。（PS：如果房子跟原來說的面積不一致，還需要補款。如果差距太大，還要房鬧退款等）。

上面例子，都很平常。但是平常的事情，蘊含著幾千年的交易規(guī)律。我們仔細(xì)品味一下上面的細(xì)節(jié)，發(fā)現(xiàn)從大到小的交易，有幾個共同的點：

交易必須有買賣雙方。

在初期，買賣雙方必須達(dá)成一致（如何付錢，如何交貨）。達(dá)不成一致，就不存在交易。（契約）

達(dá)到一致之后，買方付錢，賣家交貨。PS：可能是先交貨，再付錢。也可能是多次付錢。也可能是多次交貨。

只有買賣雙方達(dá)不成一致，才存在交易退款維權(quán)的情況，包括售后服務(wù)。

從理論上來說， 線上系統(tǒng)處理的也是真實世界的問題， 只是手段略有不同。我們再回顧一下自己平常碰到過的交易場景，都逃不出這個范疇。 我們完全有理由把這個結(jié)論當(dāng)成線上交易系統(tǒng)的指導(dǎo)思想。我們對于交易系統(tǒng)的抽象理解就是： 交易的本質(zhì)是：買賣雙方就付款細(xì)節(jié)／交貨細(xì)節(jié)／商品質(zhì)量細(xì)節(jié)／賠償細(xì)節(jié)，先簽定一個契約。而后雙方履行契約的全過程。訂單僅僅表示雙方履約的過程和憑證。

我們看一下新交易的最骨干的模型。

破局之道

搞明白了我們的核心問題， 那么很多事情就迎刃而解了。

快速接入問題：如果我們的交易核心是穩(wěn)定的，不是給某個業(yè)務(wù)定制的，那么只要是契約精神可以解決的問題，就應(yīng)該是交易系統(tǒng)能解決的問題。業(yè)務(wù)系統(tǒng)只需要做一些適配，就可以無縫接入。接入速度會極大提升。

搞定小需求，影響主流交易的問題：這個是原系統(tǒng)在代碼組織層面，只要做好隔離，就可以解決的。

新人學(xué)習(xí)成本高的問題： 同理，交易的核心是穩(wěn)定的，不需要關(guān)心太多的業(yè)務(wù)上的問題，理解成本就會極大的降低。新人接手速度會提升。

玩法不能組合的問題：這個問題同樣是原設(shè)計上的一些缺陷，沒有區(qū)分橫向業(yè)務(wù)，跟垂直交易。PS：這個會在后面闡述。

要根治交易系統(tǒng)當(dāng)前碰到的困局，除了重構(gòu)之外，沒有別的捷徑可走。

架構(gòu)演進

在進行本章節(jié)的講解之前，我們再回顧一下，上面講的三個生活中的交易場景，我們繼續(xù)仔細(xì)品味一下，三個交易場景的細(xì)節(jié)點，突然有了一個驚人的發(fā)現(xiàn)：

如何付錢是標(biāo)準(zhǔn)化程度很高。在日常生活中，付現(xiàn)金／刷卡／三方支付， 可以覆蓋大部分的場景。

跟賣家商量，簽定契約的過程，標(biāo)準(zhǔn)化程度稍低點。但是，似乎一個行業(yè)一個標(biāo)準(zhǔn)。但是都沒有逃出，“如何付錢，如何交貨，售后保障約束，以及如何違約賠付”的范疇。

如何交貨，是標(biāo)準(zhǔn)化程度是最低的。每個場景似乎都不一樣。就算是同樣行業(yè)的不同的店也可能略有不同。PS：比如一頓飯，可以上門吃然后飯館準(zhǔn)備餐具，也可以是送貨上門自己吃。

整條交易的流程，是最不可控的，每個階段的過程，可能是亂序的。PS：比如去餐館吃飯，可能先付錢再吃飯，也可能是先吃飯再付錢。

弄明白這些特性，直接決定了，我們跟垂直行業(yè)的關(guān)系。即：什么東西應(yīng)該交給垂直行業(yè)，什么東西，交易系統(tǒng)應(yīng)該搞定。

以下的新交易的架構(gòu)大圖：

在上圖中，明顯出現(xiàn)了幾個原來沒有出現(xiàn)過的一些名詞。我們做一下解釋：

buy: 業(yè)務(wù)的buy，由垂直業(yè)務(wù)掌控，它不一定是一個獨立系統(tǒng), 它的核心使命是包裝交易平臺提供的各種能力，根據(jù)垂直業(yè)務(wù)規(guī)則，做定制。例如，美業(yè)的理發(fā)業(yè)務(wù)調(diào)用下單接口的時候，可能要做預(yù)約時間的選擇，buy系統(tǒng)需要做一下這方面的校驗與參數(shù)拼裝。另外，垂直業(yè)務(wù)的交易確認(rèn)頁面，也是有不同的顯示規(guī)則，這個需要buy系統(tǒng)做支持。

流程編排引擎：這個是整個新交易的核心思想。業(yè)務(wù)規(guī)則是通過配置化形成的。流程配置化的最小顆粒度是組件。引擎把所有的組件形成一個串，執(zhí)行業(yè)務(wù)規(guī)則。流程編排引擎的配置規(guī)則，是DB中的數(shù)據(jù)，可以隨時添加數(shù)據(jù)。 所以這個引擎的設(shè)計，對于快速支持新的業(yè)務(wù)形態(tài)，起了至關(guān)重要的作用。

交貨/退貨路由引擎：對于交易系統(tǒng)來說，所有的交貨/退貨過程，都可以看成黑盒子。只要知道路由引擎會把相應(yīng)的交貨過程做掉就可以的。原因是：我們認(rèn)為交貨是一個不可歸納的行為。交貨的細(xì)節(jié)，是需要交還給垂直業(yè)務(wù)自己去做的。

組件：對于流程中所有元素來說， 所有的東西都是組件，都可以納入到流程編排的范圍之內(nèi)。如：扣庫存組件，校驗用戶合法性組件，校驗地址可達(dá)性組件，進入支付組件等等。

對于上面的解釋，可能還有三個問題核心未回答：

1. 既然是通過流程編排來配置出一個業(yè)務(wù)流程，那么，如何定位到一個業(yè)務(wù)？

行業(yè)維度（酒店預(yù)訂，普通實物交易，外賣，虛擬交易，批發(fā)，美業(yè)等）

商品類型維度（酒店商品，普通實物商品，會員卡商品，二維碼核銷商品等等）

營銷維度（積分商城，拼團，秒殺，老拼團，普通營銷/無營銷，等）

交貨方式維度（上門自提，快遞，同城送，二維碼核銷，酒店入住，會員卡授權(quán)等）

付款方式維度（線上付，代付，貨到付款，線下收銀等）

2. 交易的核心流程階段與主模型數(shù)據(jù)模擬是怎么樣的？

1.橫向業(yè)務(wù)與垂直業(yè)務(wù)

2.垂直業(yè)務(wù)：垂直業(yè)務(wù)就是我們要支持的業(yè)務(wù)場景，如“微商城的普通商品拼團的業(yè)務(wù)”。

3.橫向業(yè)務(wù)：各種橫向業(yè)務(wù)通過一定規(guī)則相互拼裝，可以形成垂直業(yè)務(wù)。在新交易里，橫向業(yè)務(wù)被包裝成一個一個的組件，可以通過流程編排的形式串成垂直業(yè)務(wù)。如：拼團組件。

實施路徑

交易是非常核心的系統(tǒng)，新交易系統(tǒng)的上線流程，無異于飛行中換發(fā)動機，難度可想而知。我們把實施路徑定為以下幾個階段：

1. 正向交易優(yōu)先啟動重構(gòu)，用新的模型做業(yè)務(wù)支持。

正向交易實行雙寫策略，即新模型寫一份，再同步寫到老模型數(shù)據(jù)一份。為了不影響外圍系統(tǒng)。

上線時，優(yōu)先灰度內(nèi)部商戶，而后小商戶，最后大商戶的原則。

上線后，通知外圍業(yè)務(wù)，做消息機制的改造。

優(yōu)先支持新業(yè)務(wù)，然后灰度老業(yè)務(wù)的原則。

2. 訂單管理啟動重構(gòu)，在正向交易做完全量切流程之后，再做灰度上線。

訂單管理的同步策略，不再依賴DB做數(shù)據(jù)的導(dǎo)出/查詢業(yè)務(wù)的存儲介質(zhì)。采用寬表的一些介質(zhì)，做到dump可配置化，導(dǎo)出可配置化。通過這樣的方式，一次性丟棄老的數(shù)據(jù)模型，同時獲到業(yè)務(wù)配置化能力。如ES、HBase。

3. 逆向交易啟動重構(gòu)， 在正向交易做完全量切流程之后，再做灰度上線。 遵循逆向交易流程配置化的原則。

4. 等到逆向交易與訂單管理做完全量分流之后， 再停用雙寫策略（原有的老模型自然全量失效）。

原文來自:聊聊架構(gòu)

免責(zé)聲明：以上內(nèi)容為本網(wǎng)站轉(zhuǎn)自其它媒體，相關(guān)信息僅為傳遞更多信息之目的，不代表本網(wǎng)觀點，亦不代表本網(wǎng)站贊同其觀點或證實其內(nèi)容的真實性。