本文主要介紹知乎訂單系統(tǒng)后端語言棧的轉(zhuǎn)型升級過程，包括其間踩過的一些坑和遇到的一些問題。

[[414486]]

圖片來自 包圖網(wǎng)

一來是想通過本篇文章為其他應(yīng)用服務(wù)轉(zhuǎn)型提供借鑒經(jīng)驗(yàn)，二來是總結(jié)對于訂單系統(tǒng)的理解。

遷移背景

隨著知乎整體技術(shù)棧的變化，原有的 Python 技術(shù)棧逐漸被拋棄，新的 Go 和 Java 技術(shù)棧逐漸興起。

知乎交易系統(tǒng)的穩(wěn)定性相比其它業(yè)務(wù)系統(tǒng)的穩(wěn)定性重要很多，因?yàn)榻灰紫到y(tǒng)核心鏈路發(fā)生故障不僅會(huì)造成數(shù)據(jù)問題，還會(huì)造成嚴(yán)重的資損問題。

隨著公司業(yè)務(wù)的不斷壯大發(fā)展，交易場景變得復(fù)雜，重構(gòu)和優(yōu)化難以避免，因?yàn)檎Z言特性，Python 雖然開始擼代碼很爽，但是后期的維護(hù)成本慢慢變高。

不過 Python 在數(shù)據(jù)分析和人工智能方向上還是有很大優(yōu)勢的，只是在交易領(lǐng)域目前看起來不太合適。

從技術(shù)生態(tài)上來說，用 Java 做交易系統(tǒng)會(huì)更有優(yōu)勢，所以接下來要說的知乎訂單系統(tǒng)語言棧轉(zhuǎn)型。

另外一個(gè)因素是 Python 的 GIL 鎖導(dǎo)致它無法發(fā)揮多核的優(yōu)勢，性能上受到很大限制，在實(shí)際情況中遇到過多次主線程被 hang 住導(dǎo)致的可用性故障，所以堅(jiān)定決心來遷移掉舊系統(tǒng)。

前期準(zhǔn)備

工欲善其事，必先利其器。

語言棧轉(zhuǎn)型首先要明確轉(zhuǎn)型的三個(gè)開發(fā)流程，即 MRO(Migration，Reconstruction，Optimization)。

• 遷移：就是把原語言代碼照著抄一遍到新語言項(xiàng)目上，按照新語言的工程實(shí)現(xiàn)風(fēng)格來做就可以。其間最忌摻雜代碼優(yōu)化和 bug 修復(fù)，會(huì)容易引起新的問題，增加驗(yàn)證代碼的難度。
• 重構(gòu)：目的是提高項(xiàng)目代碼的可維護(hù)性和可迭代性，讓代碼更優(yōu)雅和易讀懂，可以放到遷移完成來做。
• 優(yōu)化：通過在模塊依賴、調(diào)用關(guān)系、接口字段等方面的調(diào)整來降低項(xiàng)目的復(fù)雜性，提高合理性。

對于語言棧轉(zhuǎn)型來說，遷移流程是肯定要做的，重構(gòu)和優(yōu)化如何選擇，可以按模塊劃分功能拆成子任務(wù)來分別評估方案。

參考依據(jù)為現(xiàn)有模塊如果同時(shí)優(yōu)化或重構(gòu)帶來的直接收益和間接收益有多少：

• 收益：完成新舊語言棧的轉(zhuǎn)換，系統(tǒng)維護(hù)性更好，模塊邊界更清晰。
• 成本：需要投入的人力成本，遷移過程中的并行開發(fā)成本，使有更高價(jià)值的工作被阻塞的損失。
• 風(fēng)險(xiǎn)：引入新的 bug，增加測試的復(fù)雜性。

在風(fēng)險(xiǎn)可控的前提下，成本與收益要互相權(quán)衡，一般會(huì)有兩種方案可供參考：

• 第一種是鎖定需求，堆人力開發(fā)上線，一步到位。
• 第二種則是小步快走，迭代上線，分批交付。

基于以上分析，在本次轉(zhuǎn)型過程中，人力成本是一個(gè)更重要的因素，所以采用只遷移的方案，來壓縮人力成本，降低 bug 引入風(fēng)險(xiǎn)的同時(shí)也具有很好的可測試性。

并且為了不阻塞業(yè)務(wù)需求，采用小步快走的方式分批交付，以最長兩周作為一個(gè)迭代周期進(jìn)行交付。

遷移方案

確定了交付方式，下面我們需要梳理當(dāng)前系統(tǒng)中的功能模塊，做好任務(wù)拆分和排期計(jì)劃。

知乎交易系統(tǒng)在遷移前的業(yè)務(wù)是針對虛擬商品的交易場景，交易路徑比較短，用戶從購買到消費(fèi)內(nèi)容的流程如下：

• 在商品詳情頁瀏覽
• 生成訂單進(jìn)入收銀臺(tái)和用戶支付
• 確認(rèn)支付后訂單交付
• 用戶回到詳情頁消費(fèi)內(nèi)容
• 特定商品的七天無理由退款

當(dāng)時(shí)訂單系統(tǒng)支持的功能還不多，業(yè)務(wù)模型和訂單模型沒有足夠地抽象，梳理訂單系統(tǒng)業(yè)務(wù)如下：

完成了訂單模塊的拆分后，新老系統(tǒng)如何無縫切換?如何做到業(yè)務(wù)無感?如何保障交易系統(tǒng)穩(wěn)定性?出現(xiàn)故障如何及時(shí)止損?

基于上面講述的原則，將整個(gè)系統(tǒng)的遷移劃分成兩個(gè)階段，遷移前后的數(shù)據(jù)存儲(chǔ)和模型都不變。

①接口驗(yàn)證

不論是在遷移的哪個(gè)階段，總需要調(diào)整訂單接口，可以從訂單操作角度分為讀操作和寫操作，需要針對讀接口和寫接口做不同的驗(yàn)證方案。

寫操作可以通過白名單測試以及灰度放量的方式進(jìn)行驗(yàn)證上線，將接口未預(yù)期異常輸出到 IM 工具以得到及時(shí)響應(yīng)。

主要的寫操作相關(guān)接口有：

• 訂單的創(chuàng)建接口。
• 訂單綁定支付單的提交接口。
• 用戶支付后回調(diào)確認(rèn)接口。
• 用戶發(fā)起退款接口。

下圖展示的是 AB 平臺(tái)的流量配置界面：

下圖展示了部分交易預(yù)警通知消息：

讀操作往往伴隨在寫操作中。我們利用平臺(tái)的錄制回放功能進(jìn)行接口的一致性檢查，通過對比得出差異排查問題。

主要的讀操作接口有：

• 獲取支付方式列表接口
• 獲取訂單支付履約狀態(tài)接口
• 獲取充值列表接口
• 批量查詢用戶新客狀態(tài)接口

下圖展示的是流量錄制回放系統(tǒng)的數(shù)據(jù)大盤：

②指標(biāo)梳理

監(jiān)控是我們系統(tǒng)的『第三只眼』，可以及時(shí)反應(yīng)系統(tǒng)的健康狀況，及時(shí)發(fā)出告警信息，并幫助我們在出現(xiàn)故障時(shí)分析問題和快速縮小排查范圍。

硬件、數(shù)據(jù)庫、中間件的監(jiān)控已經(jīng)在平臺(tái)層得到支持，這里只需要梳理出應(yīng)用的監(jiān)控指標(biāo)。

日志監(jiān)控：請求日志、服務(wù)端的錯(cuò)誤日志。

訂單業(yè)務(wù)指標(biāo)：

• 下單量、成單量、掉單量
• 單量環(huán)比數(shù)據(jù)
• 首次履約異常量
• 補(bǔ)償機(jī)制履約量
• 各通知事件 P95 耗時(shí)
• 成功履約 P95 耗時(shí)
• 履約準(zhǔn)時(shí)率/成功率

支付業(yè)務(wù)指標(biāo)：

• 支付渠道履約延遲 P95
• 支付履約延遲 P95
• 用戶購買完整耗時(shí) P95

③可用性保障

在整個(gè)交付的過程中，轉(zhuǎn)型前后對 SLA 要提供一致的可用性保障，可以看看下面的幾個(gè)衡量標(biāo)準(zhǔn)：

一般 3 個(gè) 9 的可用性全年宕機(jī)時(shí)間約為 8.76 小時(shí)，不同系統(tǒng)不同用戶規(guī)模對于系統(tǒng)可用性的要求不一樣，邊緣業(yè)務(wù)的要求可能會(huì)低一些，但是對于核心鏈路場景 TPS 可能不高，但是必須要求保證高可用級別。

如何保證或者提升服務(wù)的 SLA 是我們接下來要探討的內(nèi)容，一般有下面兩個(gè)影響因素：

• MTBF(Mean Time Between Failures)：系統(tǒng)服務(wù)平均故障時(shí)間間隔
• MTTR(Mean Time To Recover)：系統(tǒng)服務(wù)平均故障恢復(fù)時(shí)長

也就是說我們要盡可能地降低故障頻率，并確保出現(xiàn)故障后可以快速恢復(fù)?；谶@兩點(diǎn)我們在做系統(tǒng)平穩(wěn)過渡時(shí)，要充分測試所有 case ，并且進(jìn)行灰度方案和流量錄制回放，發(fā)現(xiàn)異常立即回滾，定位問題解決后再重新灰度。

④MTTR 快速響應(yīng)

持續(xù)監(jiān)控：感知系統(tǒng)穩(wěn)定性的第一步就是監(jiān)控，通過監(jiān)控來反映系統(tǒng)的健康狀況以及輔助定位問題。

監(jiān)控有兩個(gè)方向：第一個(gè)方向是指標(biāo)型監(jiān)控，這里監(jiān)控是在系統(tǒng)代碼中安排各種實(shí)時(shí)打點(diǎn)，上報(bào)數(shù)據(jù)后通過配置報(bào)表呈現(xiàn)出來的。

基礎(chǔ)設(shè)施提供的機(jī)器監(jiān)控以及接口粒度的響應(yīng)穩(wěn)定性監(jiān)控：

• 物理資源監(jiān)控，如 CPU、硬盤、內(nèi)存、網(wǎng)絡(luò) IO 等。
• 中間件監(jiān)控，消息隊(duì)列、緩存、Nginx 等。
• 服務(wù)接口，HTTP、RPC 接口等。
• 數(shù)據(jù)庫監(jiān)控，連接數(shù)、QPS、TPS、緩存命中率、主從延遲等。

業(yè)務(wù)數(shù)據(jù)層面的多維度監(jiān)控，從客戶端和服務(wù)端兩個(gè)角度來劃分。

• 從客戶端角度來監(jiān)控服務(wù)端的接口成功率，支付成功率等維度：

從服務(wù)端角度從單量突變、環(huán)比變化、交易各階段耗時(shí)等維度持續(xù)監(jiān)控。

以上兩點(diǎn)基于公司的 statsd 組件進(jìn)行業(yè)務(wù)打點(diǎn)，通過配置 Grafana 監(jiān)控大盤實(shí)時(shí)展示系統(tǒng)的健康狀況。

第二個(gè)方向是日志型監(jiān)控，這主要依賴公司的 ELK 日志分析平臺(tái)和 Sentry 異常捕獲平臺(tái)。

通過 Sentry 平臺(tái)可以及時(shí)發(fā)現(xiàn)系統(tǒng)告警日志和新發(fā)生的異常，便于快速定位異常代碼的發(fā)生位置。

ELK 平臺(tái)則可以將關(guān)鍵的日志詳細(xì)記錄下來以便于分析產(chǎn)生的場景和復(fù)現(xiàn)問題，用來輔助修復(fù)問題。

⑤異常告警

基于以上實(shí)時(shí)監(jiān)控?cái)?shù)據(jù)配置異常告警指標(biāo)，能夠提前預(yù)知故障風(fēng)險(xiǎn)，并及時(shí)發(fā)出告警信息。然而達(dá)到什么閾值需要告警?對應(yīng)的故障等級是多少呢?

首先我們要在交易的黃金鏈路上制定比較嚴(yán)格的告警指標(biāo)，從下單、提單、確認(rèn)支付到履約發(fā)貨的每個(gè)環(huán)節(jié)做好配置，配置的嚴(yán)重程度依次遞增分為 Info、Warning、Critical。

按照人員類別和通知手段來舉例說明告警渠道：

IM 中的預(yù)警消息截圖如下：

訂單主要預(yù)警點(diǎn)如下：

• 核心接口異常
• 掉單率、成單率突變
• 交易各階段耗時(shí)增加
• 用戶支付后履約耗時(shí)增加
• 下單成功率過低

⑥MTBF 降低故障率

系統(tǒng)監(jiān)控告警以及日志系統(tǒng)可以幫我們快速的發(fā)現(xiàn)和定位問題，以及時(shí)止損。

接下來說的質(zhì)量提升則可以幫助我們降低故障發(fā)生率以避免損失，主要從兩個(gè)方向來說明：

規(guī)范化的驗(yàn)收方案：

• 開發(fā)完成包括邏輯功能和單元測試，優(yōu)先保證單測行數(shù)覆蓋率再去保證分支覆蓋率。然后在聯(lián)調(diào)測試環(huán)境中自測，通過后向 QA 同學(xué)提測。
• QA 同學(xué)可以在測試環(huán)境下同時(shí)進(jìn)行功能驗(yàn)收和接口測試，測試通過后便部署到 Staging 環(huán)境。
• 在 Staging 環(huán)境下進(jìn)行功能驗(yàn)收并通過。
• 灰度交付以及雙讀驗(yàn)證可以根據(jù)實(shí)際情況選擇性使用。

上線后需要最后進(jìn)行回歸測試。

統(tǒng)一的編碼規(guī)約以及多輪 CR 保障：代碼上線前一般至少要經(jīng)過兩次代碼評審，太小的 MR 直接拉一位同事在工位 CR 即可，超過百行的變更需要拉會(huì)研討，兩次評審的關(guān)注點(diǎn)也不同。

第一次評審應(yīng)關(guān)注編碼風(fēng)格，這樣可以避免一些因在寫法上自由發(fā)揮而帶來的坑，以此來沉淀出組內(nèi)相對統(tǒng)一的編碼規(guī)約，在編碼的穩(wěn)定性上建立基本的共識(shí)，提升代碼質(zhì)量。

第二次評審應(yīng)關(guān)注代碼邏輯，這里有個(gè)需要注意的點(diǎn)是，如果明確只做遷移，那么其間發(fā)現(xiàn)舊邏輯難理解的地方不要隨便優(yōu)化，因?yàn)樵诓涣私獗尘暗那闆r下很有可能會(huì)寫一個(gè) bug 帶上線(這種事見過好幾次)。

另外這樣也好去對比驗(yàn)證，驗(yàn)證通過上線后再去優(yōu)化。只有通過明確目的和流程并且遵循這個(gè)流程做，才能更快更好地交付有質(zhì)量的代碼。

一致性保障：每一個(gè)微服務(wù)都有自己的數(shù)據(jù)庫，微服務(wù)內(nèi)部的數(shù)據(jù)一致性由數(shù)據(jù)庫事務(wù)來保障，Java 中采用 Spring 的 @Transtaction注解可以很方便地實(shí)現(xiàn)。

而跨微服務(wù)的分布式事務(wù)，像支付、訂單、會(huì)員三個(gè)微服務(wù)之間采用最終一致性，類似 TCC 模式的兩階段提交，訂單通過全局發(fā)號器生成訂單 ID，然后基于訂單 ID 創(chuàng)建支付單。

如果用戶支付后訂單會(huì)變更自身狀態(tài)后通知會(huì)員微服務(wù)，履約成功則事務(wù)結(jié)束，履約失敗則觸發(fā)退款，如果用戶未支付，那么訂單系統(tǒng)將該訂單以及支付單做關(guān)單處理。

對應(yīng)一致性保障，我們對訂單接口做了兩個(gè)方面的處理：

分布式鎖：對于上游的支付消息監(jiān)聽、支付 HTTP 回調(diào)、訂單主動(dòng)查詢支付結(jié)果三個(gè)同步機(jī)制分別基于訂單 ID 加鎖后再處理，保證同步機(jī)制不會(huì)被并發(fā)處理。

接口冪等：加鎖后對訂單狀態(tài)做了檢查，處理過則響應(yīng)成功，否則處理后響應(yīng)成功，保證上游消息不會(huì)被重復(fù)處理。

訂單對于下游的履約，是通過訂單 ID 作為冪等 key 來實(shí)現(xiàn)的，以保證同一個(gè)訂單不會(huì)被重復(fù)履約，并且通過 ACK 機(jī)制保證履約后不會(huì)再重復(fù)調(diào)到下游。

其中分布式鎖采用 etcd 鎖，通過鎖租約續(xù)期機(jī)制以及數(shù)據(jù)庫唯一索引來進(jìn)一步保障數(shù)據(jù)的一致性。

補(bǔ)償模式，雖然我們通過多種手段來保證了系統(tǒng)最終一致，但是分布式環(huán)境下會(huì)有諸多的因素，如網(wǎng)絡(luò)抖動(dòng)、磁盤 IO、數(shù)據(jù)庫異常等都可能導(dǎo)致我們的處理中斷。

這時(shí)我們有兩種補(bǔ)償機(jī)制來恢復(fù)我們的處理：

• 帶懲罰機(jī)制的延時(shí)重試：如果通知中斷，或者未收到下游的 ACK 響應(yīng)，則可以將任務(wù)放到延遲隊(duì)列進(jìn)行有限次的重試，重試間隔逐次遞增。最后一次處理失敗報(bào)警人工處理。
• 定時(shí)任務(wù)兜底：為了防止以上機(jī)制都失效，我們的兜底方案是定時(shí)掃描異常中斷的訂單再進(jìn)行處理。如果處理依然失敗則報(bào)警人工處理。

事后總結(jié)

①目標(biāo)回顧

目標(biāo)一：統(tǒng)一技術(shù)棧，降低項(xiàng)目維護(hù)成本。目標(biāo)結(jié)果是下線舊訂單系統(tǒng)。

目標(biāo)二：簡化下單流程，降低端接入成本。目標(biāo)結(jié)果是后端統(tǒng)一接口，端上整合 SDK。

②執(zhí)行計(jì)劃

遷移的執(zhí)行總共分成了三個(gè)大階段：

第一階段是遷移邏輯，即將客戶端發(fā)起的 HTTP 請求轉(zhuǎn)發(fā)到 RPC 接口，再由新系統(tǒng)執(zhí)行。第一階段做到所有的新功能需求都在新系統(tǒng)上開發(fā)，舊系統(tǒng)只需要日常維護(hù)。

第二階段是通過和客戶端同學(xué)合作，遷移并整合當(dāng)前知乎所有下單場景，提供統(tǒng)一的下單購買接口，同時(shí)客戶端也統(tǒng)一提供交易 SDK，新組件相對更加穩(wěn)定和可監(jiān)控，在經(jīng)過灰度放量后于去年底完全上線。

第二階段做到了接口層的統(tǒng)一，更利于系統(tǒng)的維護(hù)和穩(wěn)定，隨著新版的發(fā)布，舊接口流量已經(jīng)變得很低，大大降低了下階段遷移的風(fēng)險(xiǎn)。

第三階段是舊 HTTP 接口遷移，由新系統(tǒng)承載所有端的請求，提供相同規(guī)格的 HTTP 接口，最后通過修改 NGINX 配置完成接口遷移。第三階段遷移完成后舊系統(tǒng)最終實(shí)現(xiàn)了下線。

③執(zhí)行結(jié)果

截至此文撰寫時(shí)間，語言棧已經(jīng) 100% 遷移到新的系統(tǒng)上，舊系統(tǒng)已經(jīng)完全下線，總計(jì)下線 12 個(gè)系統(tǒng)服務(wù)， 32 個(gè)對外 HTTP 接口，21 個(gè) RPC 接口，15 個(gè)后臺(tái) HTTP 接口。

根據(jù) halo 指標(biāo)，遷移前后接口 P95 耗時(shí)平均減少約 40%，硬件資源消耗減少約 20%。根據(jù)壓測結(jié)果比較，遷移后支撐的業(yè)務(wù)容量增長約 10 倍。

系統(tǒng)遷移完成只是取得了階段性的勝利，接下來系統(tǒng)還需要經(jīng)過一些小手術(shù)來消除病灶。

主要是以下幾點(diǎn)：

• 不斷細(xì)化監(jiān)控粒度，優(yōu)化告警配置，繼續(xù)提高服務(wù)的穩(wěn)定性。
• 對于 Python 的硬翻譯還需要不斷重構(gòu)和優(yōu)化，這里借鑒 DDD 設(shè)計(jì)思想。
• 完善監(jiān)控大盤，通過數(shù)據(jù)驅(qū)動(dòng)來運(yùn)營優(yōu)化我們的流程。
• 項(xiàng)目復(fù)盤總結(jié)以及業(yè)務(wù)普及宣講，提升人員對于業(yè)務(wù)細(xì)節(jié)的認(rèn)知。

④問題整理

遷移總是不能一帆風(fēng)順的，期間遇到了很多奇奇怪怪的問題，為此頭發(fā)是真沒少掉。

問題 1：遷移了一半新需求來了，又沒有人力補(bǔ)上來怎么辦?

遷移后再做重構(gòu)和優(yōu)化過程，其實(shí)很大一部分考量是因?yàn)槿肆Σ蛔惆?，而且現(xiàn)狀也不允許鎖定需求。那么只能寫兩遍了，優(yōu)先支持需求，后面再遷移。如果人力充足可以選擇一個(gè)小組維護(hù)新的系統(tǒng)一個(gè)小組維護(hù)舊的系統(tǒng)。

問題 2：我明明請求了，可日志怎么就是不出來呢?

不要懷疑平臺(tái)的問題，要先從自身找問題。總結(jié)兩個(gè)原因吧：

• 一個(gè)是新舊系統(tǒng)的遷移點(diǎn)太分散導(dǎo)致灰度不好控制。
• 另一個(gè)是灰度開關(guān)忘記操作了，導(dǎo)致流量沒有成功導(dǎo)到新系統(tǒng)上。這里要注意一個(gè)點(diǎn)就是在遷移過程中要盡可能的快速交付上線。

問題 3：公司 Java 基礎(chǔ)服務(wù)不夠完善，很多基礎(chǔ)平臺(tái)沒有支持怎么辦?

于是自研了分布式延遲隊(duì)列、分布式定時(shí)任務(wù)等組件，這里就不展開聊了。

問題 4：如何保證遷移過程中兩個(gè)系統(tǒng)數(shù)據(jù)的一致性?

首先我們前面講到的是系統(tǒng)代碼遷移，而數(shù)據(jù)存儲(chǔ)不變，也就是說兩個(gè)系統(tǒng)處理的數(shù)據(jù)會(huì)存在競爭，解決的辦法是在處理時(shí)加上分布式鎖，同時(shí)接口的處理也是要冪等的。

這樣即使在上下游系統(tǒng)做數(shù)據(jù)同步的時(shí)候也能避免競爭，保證數(shù)據(jù)的一致性。

就用戶支付后支付結(jié)果同步到訂單系統(tǒng)這一機(jī)制來說，采用推拉的機(jī)制：

• 用戶支付后訂單主動(dòng)輪詢支付結(jié)果，則是在主動(dòng)拉取數(shù)據(jù)。
• 支付系統(tǒng)發(fā)出 MQ 消息被訂單系統(tǒng)監(jiān)聽到，這是被動(dòng)推送。
• 支付成功后觸發(fā)的訂單系統(tǒng) HTTP 回調(diào)機(jī)制，這也是被動(dòng)推送。

以上三種機(jī)制結(jié)合使用使得我們系統(tǒng)數(shù)據(jù)一致性有一個(gè)比較高的保障。我們要知道，一個(gè)系統(tǒng)絕非 100% 可靠，作為交易支付的核心鏈路，需要有多條機(jī)制保證數(shù)據(jù)的一致性。

問題 5：用戶支付后沒有收到會(huì)員權(quán)益是怎么回事?

在交易過程中，訂單、支付、會(huì)員是三個(gè)獨(dú)立的服務(wù)，如果訂單丟失了支付的消息或者會(huì)員丟失了訂單的消息都會(huì)導(dǎo)致用戶收不到會(huì)員權(quán)益。

上一個(gè)問題中已經(jīng)講到最終一致性同步機(jī)制，可能因?yàn)橹虚g件或者網(wǎng)絡(luò)故障導(dǎo)致消息無法同步。

這時(shí)可以再增加一個(gè)補(bǔ)償機(jī)制，通過定時(shí)任務(wù)掃描未完成的訂單，主動(dòng)檢查支付狀態(tài)后去會(huì)員業(yè)務(wù)履約，這是兜底策略，可保障數(shù)據(jù)的最終一致。

⑤業(yè)務(wù)沉淀

從接收項(xiàng)目到現(xiàn)在也是對訂單系統(tǒng)從懵懂到逐漸加深理解的一個(gè)過程，對于當(dāng)前交易的業(yè)務(wù)和業(yè)務(wù)架構(gòu)也有了一個(gè)理解。

交易系統(tǒng)本身作為支付系統(tǒng)的上層系統(tǒng)，提供商品管理能力、交易收單能力、履約核銷能力。

外圍業(yè)務(wù)子系統(tǒng)主要關(guān)注業(yè)務(wù)內(nèi)容資源的管理。業(yè)務(wù)的收單履約管理接入交易系統(tǒng)即可，可減輕業(yè)務(wù)的開發(fā)復(fù)雜度。

收單流程展示如下：

• 業(yè)務(wù)定制商品詳情頁，然后通過詳情頁底欄調(diào)用端能力進(jìn)入訂單收銀臺(tái)。在這里客戶端需要調(diào)用業(yè)務(wù)后端接口來獲取商品詳情，然后調(diào)用交易底欄的展示接口獲取底部按鈕的情況。
• 用戶通過底部按鈕進(jìn)入收銀臺(tái)后，在收銀臺(tái)可以選擇支付方式和優(yōu)惠券，點(diǎn)擊確認(rèn)支付調(diào)起微信或者支付寶付款。收銀臺(tái)展示以及獲取支付參數(shù)的接口由交易系統(tǒng)提供。
• 訂單后臺(tái)確認(rèn)收款后會(huì)通知業(yè)務(wù)履約，用戶端會(huì)回到詳情頁，用戶在詳情頁進(jìn)入內(nèi)容播放頁享受權(quán)益。履約核銷流程是業(yè)務(wù)后端與交易系統(tǒng)后端的接口調(diào)用來完成的。

現(xiàn)在知乎站內(nèi)主要是虛擬商品的交易，一個(gè)通用的交易流程如下圖：

用戶經(jīng)歷了從商品的瀏覽到進(jìn)入收銀臺(tái)下單支付，再回到內(nèi)容頁消費(fèi)內(nèi)容。隨著業(yè)務(wù)的發(fā)展，不同的交易場景和交易流程疊加，系統(tǒng)開始變得復(fù)雜，一個(gè)交易的業(yè)務(wù)架構(gòu)慢慢呈現(xiàn)。

訂單系統(tǒng)主要承載知乎站內(nèi)站外的各種交易服務(wù)，提供穩(wěn)定可靠的交易場景支撐。

主要分為以下幾個(gè)部分：

• 首先產(chǎn)品服務(wù)層是面向用戶能感受到的交互界面，提供對于這些頁面的統(tǒng)一下單支付 API 網(wǎng)關(guān)。
• 然后是訂單服務(wù)層，由上層網(wǎng)關(guān)調(diào)用，提供著不同場景下的交易服務(wù)支撐。
• 再往下是訂單領(lǐng)域?qū)樱休d訂單最核心邏輯代碼，首先是用戶購買需要的算價(jià)聚合，然后是管理訂單模型的交易聚合，最后是買完商品后的履約處理的交付聚合。
• 最底層是基礎(chǔ)支撐服務(wù)層，主要是提供基本的服務(wù)支持以及交易依賴的一些服務(wù)。
• 最后是運(yùn)營服務(wù)，提供交易相關(guān)的后臺(tái)功能支持。

⑥方法論實(shí)踐

凡此以上，不論系統(tǒng)遷移方案還是架構(gòu)理解都?xì)w結(jié)于參與人員的理解與認(rèn)知，一個(gè)優(yōu)秀的方案或合適的架構(gòu)不是設(shè)計(jì)出來的，是迭代出來的。

人的認(rèn)知也是這樣，需要不斷的迭代升級，和很多的方法論一樣，PDCA 循環(huán)為我們提煉了一個(gè)提升路徑：

• Plan 計(jì)劃：明確我們遷移的目標(biāo)，調(diào)研現(xiàn)狀指定計(jì)劃。
• Do 執(zhí)行：實(shí)現(xiàn)計(jì)劃中的內(nèi)容。
• Check 檢查：歸納總結(jié)，分析哪些做好了，還有什么問題。
• Action 調(diào)整：總結(jié)經(jīng)驗(yàn)教訓(xùn)，在下一個(gè)循環(huán)中解決。

很多時(shí)候，也許你只做了前兩步，但其實(shí)后兩步對你的提升會(huì)有很大幫助。

所以一個(gè)項(xiàng)目的復(fù)盤，一次 Code Review 很重要，有語言的交流和碰撞才更容易打破你的固有思維，做到業(yè)務(wù)認(rèn)知的提升。

作者：張旭，知乎后端開發(fā)工程師，主要負(fù)責(zé)知乎商業(yè)基礎(chǔ)相關(guān)系統(tǒng)研發(fā)，專注于電商交易營銷領(lǐng)域。

編輯：陶家龍

出處：轉(zhuǎn)載自公眾號高可用架構(gòu)(ID：ArchNotes)