一個(gè)多業(yè)務(wù)、多狀態(tài)、多操作的交易鏈路？閑魚架構(gòu)這樣演進(jìn)

時(shí)間：2023-03-26 21:08:01 | 來源：電子商務(wù)

時(shí)間：2023-03-26 21:08:01 來源：電子商務(wù)

作者：閑魚技術(shù)-君愛

前言

雙十一剛剛結(jié)束，成交額2684億震驚全世界，每秒訂單峰值達(dá)54.4W筆。在閑魚2000萬DAU，交易數(shù)額同樣增長(zhǎng)迅速的今天，我們?nèi)绾伪Ｕ辖灰祖溌返姆€(wěn)定與快速支撐業(yè)務(wù)？這篇文章從客戶端開發(fā)的角度，介紹閑魚交易鏈路業(yè)務(wù)的架構(gòu)演進(jìn)過程，在保證性能的前提下，不斷提升研發(fā)效率，與大家一起交流過程中的思考。

業(yè)務(wù)特征

我們今天定義閑魚交易鏈路，從閑魚特有的交易模式“邊聊邊買”，由交易聊天為入口，下單、訂單詳情、訂單列表及相關(guān)二級(jí)頁(yè)面，包含契約簽訂、履行、違約服務(wù)。履約區(qū)分為正向交易流程（付款、發(fā)貨、收貨、評(píng)價(jià)等）、逆向交易流程（退款、退貨等）。

圖1-交易鏈路關(guān)鍵場(chǎng)景（聊天-購(gòu)買-訂單）

交易鏈路所承接的業(yè)務(wù)有：普通交易、見一見交易、擔(dān)保交易、閑魚幣交易、玩家交易、回收交易、寄賣交易等。不同業(yè)務(wù)在不同狀態(tài)下提供不同的交易操作。以普通C2C交易正向交易流程為例：

圖2-普通C2C交易正向交易流程

交易鏈路具有多業(yè)務(wù)、多狀態(tài)、多操作的特征。作為應(yīng)用的關(guān)鍵鏈路中的一環(huán)，業(yè)務(wù)相對(duì)固化，需要保證性能與體驗(yàn)，同時(shí)也需要一定的動(dòng)態(tài)性，能夠快速地承接新增業(yè)務(wù)類型、新增業(yè)務(wù)狀態(tài)、新增交易操作，視覺不常改變，對(duì)頁(yè)面組件動(dòng)態(tài)性無強(qiáng)訴求。

圖3-交易鏈路業(yè)務(wù)特征

演進(jìn)過程

淘寶的方案

類似的交易場(chǎng)景，手淘提出來不錯(cuò)的解決方案——新奧創(chuàng)。新奧創(chuàng)通過頁(yè)面區(qū)塊化與行為通信協(xié)議，提供基于業(yè)務(wù)的頁(yè)面、組件、規(guī)則，前端實(shí)現(xiàn)動(dòng)態(tài)模板，后端根據(jù)業(yè)務(wù)將頁(yè)面進(jìn)行編排，實(shí)現(xiàn)跨端、組件動(dòng)態(tài)化。

圖4-手淘新奧創(chuàng)

閑魚的問題

在閑魚業(yè)務(wù)場(chǎng)景中，特有的C2C交易模式，與手淘B2C交易模式下差別較大，沒有購(gòu)物車、沒有多商品聚合訂單。手淘的交易流程可以在天貓、飛豬、盒馬等通用。但閑魚的交易模式，出于業(yè)務(wù)特點(diǎn)，不適合在手淘完成閑魚交易流程。

閑魚C2C交易鏈路業(yè)務(wù)相對(duì)固化，沒有強(qiáng)頁(yè)面動(dòng)態(tài)化的需求。在這樣的背景下，前后端向新奧創(chuàng)遷移，成本較高且收益較少。并且，新奧創(chuàng)的后端開發(fā)仍然需要關(guān)心頁(yè)面編排，并不是更終態(tài)的研發(fā)模式。因此，閑魚沒有將新奧創(chuàng)作為技術(shù)選型。閑魚交易鏈路的側(cè)重點(diǎn)是：

• 穩(wěn)定：保證雙端一致，減少雙端邏輯不一致的場(chǎng)景；
• 支持一定的動(dòng)態(tài)化能力：端側(cè)僅處理頁(yè)面渲染，業(yè)務(wù)邏輯上云；
• 新研發(fā)模式：前端深入業(yè)務(wù)，實(shí)現(xiàn)服務(wù)端頁(yè)面渲染相關(guān)邏輯，后端領(lǐng)域下沉，專注領(lǐng)域建設(shè)，云端一體；

為達(dá)到這個(gè)目標(biāo)，交易鏈路架構(gòu)演進(jìn)經(jīng)過3個(gè)階段：

圖5-閑魚交易鏈路演進(jìn)方向

我們來簡(jiǎn)單看一下閑魚交易鏈路的架構(gòu)演進(jìn)過程：

圖6-閑魚交易鏈路架構(gòu)演進(jìn)

第一階段-業(yè)務(wù)解耦

在2017年-2018年，交易鏈路由原有業(yè)務(wù)快速迭代時(shí)期的簡(jiǎn)單代碼結(jié)構(gòu)，進(jìn)行了頁(yè)面區(qū)塊化改造。 此時(shí)，服務(wù)端大致分為3層：底層數(shù)據(jù)模型、閑魚C2X交易域、業(yè)務(wù)解決方案。后端基于底層數(shù)據(jù)模型，根據(jù)閑魚不同業(yè)務(wù)特性與業(yè)務(wù)邏輯，搭建閑魚C2X交易域，再以業(yè)務(wù)解決方案提供不同場(chǎng)景業(yè)務(wù)數(shù)據(jù)。

而端側(cè)分為兩層，業(yè)務(wù)數(shù)據(jù)解析將后端的業(yè)務(wù)數(shù)據(jù)，根據(jù)不同業(yè)務(wù)類型、不同交易狀態(tài)進(jìn)行解析、整合，轉(zhuǎn)換為頁(yè)面渲染協(xié)議ViewModel，同時(shí)將頁(yè)面區(qū)塊化，抽離出不同業(yè)務(wù)通用組件，根據(jù)ViewModel直接渲染。

• 頁(yè)面區(qū)塊化
• 操作Action化

第二階段-雙端一體，逐步上云

2019年，在第一階段的基礎(chǔ)上，我們首先解決雙端邏輯不一致的問題，選擇了Flutter作為跨平臺(tái)解決方案，同時(shí)通過FishRedux進(jìn)行頁(yè)面區(qū)塊化改造。交易操作也通過CommonAction完成邏輯一致，實(shí)現(xiàn)端上的交易操作中臺(tái)，提供給交易鏈路多業(yè)務(wù)場(chǎng)景進(jìn)行調(diào)用。

• Flutter&Fish Redux
• 交易操作中心
• 業(yè)務(wù)上云

此時(shí)，服務(wù)端仍分為3層：底層數(shù)據(jù)模型、閑魚C2X交易域、業(yè)務(wù)層。業(yè)務(wù)層包含業(yè)務(wù)解決方案、頁(yè)面渲染解析?？蛻舳松蟽H保留渲染層。

第三階段-云端一體

在前一階段，客戶端將端側(cè)業(yè)務(wù)邏輯完整上云，但同樣出現(xiàn)了瓶頸，在交易業(yè)務(wù)場(chǎng)景，后端需要更多的精力進(jìn)行領(lǐng)域建設(shè)和沉淀，更少關(guān)心頁(yè)面渲染交互的邏輯，我們希望能有更高效的研發(fā)模式，減少各端研發(fā)之間的大量的協(xié)同, 提升整體研發(fā)效率。

此時(shí)我們選擇統(tǒng)一技術(shù)棧Dart，通過FaaS無服務(wù)器能力建設(shè)，采用Flutter+FaaS(Dart Runtime)云端一體的研發(fā)模式，讓客戶端同學(xué)來寫服務(wù)端膠水層代碼，同時(shí)還無需關(guān)心傳統(tǒng)服務(wù)端運(yùn)維、擴(kuò)容等工作。原有的業(yè)務(wù)聚合、渲染協(xié)議解析，由客戶端同學(xué)在Server完成，實(shí)現(xiàn)邏輯歸一，完成端到端的研發(fā)閉環(huán)，實(shí)現(xiàn)資源配置的優(yōu)化。

圖7-云端一體化工程體系

在云端一體的研發(fā)模式中，Server進(jìn)行了重新的分層，后端能夠?qū)Ｗ㈩I(lǐng)域建設(shè)，客戶端開發(fā)完成原有的業(yè)務(wù)解決方案以及到渲染協(xié)議的解析，即下圖標(biāo)紅部分。當(dāng)然，在實(shí)際開發(fā)過程中，F(xiàn)aaS與領(lǐng)域的邊界因?qū)嶋H業(yè)務(wù)有一定交集。

• 服務(wù)端開發(fā)：完成領(lǐng)域建設(shè)；
• 客戶端開發(fā)：聚合多域信息，實(shí)現(xiàn)渲染協(xié)議，端側(cè)直接進(jìn)行UI渲染；

圖8-云端一體階段詳細(xì)架構(gòu)

同時(shí)，在交易鏈路，我們將后端接口劃分為渲染接口與交互接口：

• 渲染接口提供頁(yè)面渲染數(shù)據(jù)，下圖為FaaS部分的代碼結(jié)構(gòu)，完成接口校驗(yàn)后，定義頁(yè)面協(xié)議，同時(shí)根據(jù)業(yè)務(wù)需求，將多領(lǐng)域數(shù)據(jù)進(jìn)行聚合填充。

圖9-渲染接口設(shè)計(jì)

• 前文中，我們介紹過，交易包含有多操作，在不同業(yè)務(wù)中，時(shí)常有新增操作的需求。不同訂單類型不同訂單狀態(tài)包含哪些操作，由渲染接口實(shí)現(xiàn)操作動(dòng)態(tài)可配置，例如”已下單未付款“C2C普通交易訂單，包含“付款”、”關(guān)閉交易“操作。操作觸發(fā)后的實(shí)現(xiàn)，需要業(yè)務(wù)校驗(yàn)、觸發(fā)領(lǐng)域服務(wù)的交互行為，由端側(cè)完全遷移至FaaS，通過閑魚的Nexus框架使用Logic Engine的Action通信協(xié)議，例如，用戶觸發(fā)創(chuàng)建訂單行為，即觸發(fā)CREATE_ORDER的Action，F(xiàn)aaS部分調(diào)用下單的領(lǐng)域服務(wù)后，通過NativeApi，觸發(fā)端上相應(yīng)的操作喚起收銀臺(tái)、跳轉(zhuǎn)鏈接。

圖10-交互接口設(shè)計(jì)

最后

當(dāng)前閑魚交易鏈路在云端一體的階段不斷深耕，目前已經(jīng)落地了下單頁(yè)面，由原有的前后端3人開發(fā)變?yōu)?人開發(fā)，研發(fā)效率有效提升，其他場(chǎng)景也已經(jīng)在規(guī)劃落地中。下單頁(yè)云端一體版本閑魚11月版本開始灰度，有興趣的同學(xué)可以親身體驗(yàn)。

本文介紹了閑魚交易鏈路的架構(gòu)演進(jìn)的過程與思考，不同業(yè)務(wù)場(chǎng)景適用不同的業(yè)務(wù)架構(gòu)，在業(yè)務(wù)發(fā)展過程中，會(huì)遇到各式各樣的問題或瓶頸，針對(duì)業(yè)務(wù)當(dāng)前問題與發(fā)展方向，選用合理的、收益與成本得宜的技術(shù)方案，是順勢(shì)而為。閑魚云端一體化應(yīng)用架構(gòu)的落地場(chǎng)景不僅是交易鏈路，后續(xù)會(huì)以交易鏈路為范例不斷演進(jìn)與擴(kuò)展，