問題

今天我們聊電商系統實際業務場景的問題，考查對業務系統問題的分析能力、解決問題的能力和對系統長期發展的整體規劃能力。

一電商平臺在早期階段業務發展迅速，DAU在 10W+；整個電商系統按水平分層架構進行設計，包括【入口網關層】、【業務邏輯層】和【數據訪問層】。為了進一步提升電商平臺的DAU，幾乎每周都會做幾次運營活動，因此電商系統基本每天都會有新業務上線和服務重啟，這導致電商系統的核心交易邏輯（下訂單、支付等）極易受到影響。另外，電商系統的每個業務單元（如：風控系統、廣告系統、營銷系統等）也都處在不斷地更新迭代中。

如果你是該電商系統的架構師，如何解決現有問題？對該電商系統的后續發展應該如何規劃？

解析

該電商系統目前處于早期階段，業務發展迅速，系統按水平分層架構在運行；這里多啰嗦幾句，對【水平分層架構】進行簡單描述。

水平分層架構一般是在“技術”擴展驅動之下，對單體架構進行水平拆分，通常可劃分出【入口網關層】、【業務邏輯層】和【數據訪問層】；入口網關層負責外部請求的路由、過濾和轉換，業務邏輯層負責處理復雜的業務規則流程，數據訪問層負責對持久化數據進行讀寫。

水平分層架構的每一層是整體系統的橫向切面，沒有拆分出獨立的業務單元，也就是說：業務邏輯層是一個獨立服務或進程在運行，這個獨立的進程中既有運營活動邏輯也有核心的交易邏輯；?即在同一個工程中，運營活動程序很容易影響核心的交易邏輯程序，這是最根本的問題所在。然后業務邏輯層程序除了核心的交易邏輯和運營活動之外，還包括其他業務單元，比如：風控、廣告、營銷等；任何一個業務的升級迭代和重啟，都會導致其他業務單元也需要重啟，正所謂“城門失火殃及池魚”！

那怎么解決現有問題呢？

目前最緊急的問題是“運營活動”影響“核心邏輯”，成本最低的解決方案是：對業務邏輯層拆分出一個附加的業務邏輯模塊，假設目前的業務邏輯層程序叫做 Logic，那就從Logic中把運營活動邏輯單獨拆分出來，不妨叫做 Extlogic；由 Logic 負責最核心的業務邏輯內容（比如下單、交易等），由 Extlogic 負責運營活動內容。

上述問題解決之后，就可以開始著手解決很重要但相對不緊急的問題，即很多業務單元（風控、廣告、營銷、下單、交易等）目前都還糅雜在 Logic 中，最徹底的解決方案是：對每一個業務單元進行服務化拆分；在當前的業務場景中，也叫做垂直化拆分。就是從 Logic 中分別拆分出 SpamLogic（風控邏輯服務）、AdLogic（廣告邏輯服務）、MarketingLogic（營銷邏輯服務）、OrderLogic（訂單邏輯服務）、TradeLogic（交易邏輯服務）等。

這個問題解決之后，就可以坐等業務的發展了，如果業務發展良好，百花齊放，前端孵化出各種業務線時，就可以考慮中臺化了，比如對交易業務、風控業務、廣告業務等進行下沉形成可復用的業務中臺。

簡單總結一下：

1. 從 Logic 中拆分出 Extlogic，解決運營活動影響核心業務邏輯的問題；

2. 從 Logic 中拆分出 SpamLogic、AdLogic、MarketingLogic、OrderLogic、TradeLogic 等，解決業務單元之間互相影響的問題；

3. 業務單元中臺化，解決業務復用問題，助力前端業務發展。