有贊的交易系統架構困局以及破局之道

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

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

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

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

交易團隊的新同學，上手交易核心的開發非常困難，在沒有完合弄懂整套系統之間，不敢放手讓新同學開發。學習成本極高。

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

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

我們的困難根源

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

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

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

既然”微商城的交易規則“不等于”交易能力“，那么交易能力是什么？ 有什么內容？與垂直業務又有什么關系？

這三個是很有意思的問題。 在弄明白這三個問題之前，我們先把我們從一個互聯網從業者的角色，轉變成一個普通的人。假設我們要去做三件事情，我們看一看現實生活的交易細節：

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

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

我要去樓下吃一碗面。

“老板，熱干面多少錢一碗” ?！?5元一碗”?！敖o我來一碗” 。然后我坐下， 吃完面，付錢， 走人。

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

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

上面例子，都很平常。但是平常的事情，蘊含著幾千年的交易規律。我們仔細品味一下上面的細節，發現從大到小的交易，有幾個共同的點：

交易必須有買賣雙方。

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

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

只有買賣雙方達不成一致，才存在交易退款維權的情況，包括售后服務。

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

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

破局之道

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

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

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

新人學習成本高的問題： 同理，交易的核心是穩定的，不需要關心太多的業務上的問題，理解成本就會極大的降低。新人接手速度會提升。

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

要根治交易系統當前碰到的困局，除了重構之外，沒有別的捷徑可走。

架構演進

在進行本章節的講解之前，我們再回顧一下，上面講的三個生活中的交易場景，我們繼續仔細品味一下，三個交易場景的細節點，突然有了一個驚人的發現：

如何付錢是標準化程度很高。在日常生活中，付現金／刷卡／三方支付， 可以覆蓋大部分的場景。

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

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

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

弄明白這些特性，直接決定了，我們跟垂直行業的關系。即：什么東西應該交給垂直行業，什么東西，交易系統應該搞定。

以下的新交易的架構大圖：

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

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

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

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

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

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

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

行業維度（酒店預訂，普通實物交易，外賣，虛擬交易，批發，美業等）

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

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

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

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

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

1.橫向業務與垂直業務

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

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

實施路徑

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

1. 正向交易優先啟動重構，用新的模型做業務支持。

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

上線時，優先灰度內部商戶，而后小商戶，最后大商戶的原則。

上線后，通知外圍業務，做消息機制的改造。

優先支持新業務，然后灰度老業務的原則。

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

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

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

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

原文來自:聊聊架構

免責聲明：以上內容為本網站轉自其它媒體，相關信息僅為傳遞更多信息之目的，不代表本網觀點，亦不代表本網站贊同其觀點或證實其內容的真實性。