導讀:業務架構要隨著業務發展做相應的演進,繼而支撐業務的快速發展。本文主要通過介紹閒魚從零發展到千萬級DAU應用的不同階段的業務特點、核心問題以及針對性的架構演進,來闡述業務架構的演進思路與心得。

閒魚業務背景

技術架構的演進跟業務形態都是強相關的,閒魚的市場本質以及用戶特點如下描述:

閒魚是一個高性價比的二手交易市場。相比新品市場,二手市場的市場空間就是"用戶在付出相同成本條件下有可能獲取到更高的物品價值”，典型的比如"遊戲卡帶,樂高"等這些功能型的產品。同時,閒置市場也有著特殊存在的成本-信任成本,信任成本主要體現在:大部分二手可能沒有售後服務;每個人對二手物品殘值有著自己的主觀評價。

擴大市場空間有兩種方式，1.降低新人成本 2.提升匹配效率

閒魚與手淘差異性:

• 閒魚與手淘的賣家差異:非專業的個人賣家,利益驅動弱。
• 發佈產品差異:為保證市場供給,只能堅持輕發佈。
• 商品差異:結構化信息少,沒有歷史累計行為。

閒魚與手淘在業務、團隊結構的差異性導致架構上不同的關注點,導致不同的演進路線。

架構演進-試錯期

架構隨著業務階段不斷演進, 每個階段都有核心的問題

• 試錯期業務核心問題:業務不斷探索適合的商業模式
• 架構核心關注點:提升響應速度,快速支持業務上線
• 架構核心原則:以質量換取速度,可以犧牲一點線上質量(業務可接受範圍)來換取更快的響應速度

App發版速度(尤其是IOS)跟不上業務快速迭代的上線週期,動態性是端面臨的主要問題,因此端上採用了Hybrid的架構:

• URL Router:所有請求路由到一個H5的鏈接,通過URI Schema重定向到真正頁面,如果對應的native沒有開發出來,就用H5版本來實現,解決安卓與IOS不同步的問題。
• 開關中心:通過開關控制頁面路由,頁面入口是否開啟,分版本控制,參數變更等改動。
• Poplayer:無需發版的情況下在已有的Native界面上彈出H5的部署容器,來滿足運營隨時創建活動並需要一個活動入口的需求。

架構演進-發展期

發展期業務與架構核心問題:

• 業務核心問題:隱約看到商業模式,需要加速驗證,擴大規模
• 架構關注點:提升效率(為了有機會去做更多事情,非降低整體成本),建更多能力驗證業務方向
• 架構演進方向:前後端的協議、工具的自動化
• 服務端通過Mbaas(服務端提供基礎的數據源(商品、用戶、搜索、互動),讓客戶端/前端通過類SQL的描述一次性獲取自己想要的數據,後端不需要增加接口)來實現活動、feeds投放的自動化。將更多精力投入到本地化、個性化、數據能力(與算法、推薦、搜索打通)的建設中。

客戶端開發關注兩個點:

• 對外整體連接協議的梳理,在容器這端演化成Service Bus(類似服務端的ESB)，對具體的實現進行封裝, 以方便後續基礎能力的可替換。
• 組件庫的建立,新做一個頁面的時候,能通過現有的UI組件進行簡單組裝,不需要重0開始搭建。組件與服務端打通,組件組裝邏輯與數據直接由服務端完成,客戶端負責解析與渲染。
• 因此這個時期客戶端更多的工作是支持交互的基礎的UI組件和動態適配性。

架構演進-平臺期

隨著業務的發展,閒魚基於商品體系的業務達到十幾種,逐漸向平臺期發展。平臺期業務與架構核心問題:

• 業務核心問題:需要讓更多的二方、三方參與到共享經濟平臺的建設中,但是平臺生態建設又超出了閒魚自身的能力
• 架構核心關注點:擴展性(具備接入業務的能力)、業務隔離(已接入業務平穩運行)、平臺基礎能力建設(業務更好的發展)
• 架構原則:做一些更基礎的規劃,然後把更多的可能性、動態性留給二方或者三方完成

業務隔離框架Swak

核心解決因業務發展帶來的代碼耦合問題,問題主要體現在整體開發、運維效率低，穩定性差。核心思路是分離系統中不可變和可變的部分;分離出”做什麼”與”怎麼做”、“誰去做”。

將業務中不變的部分放入主幹,定義出做什麼;變化的部分以擴展點形式開放出來,讓具體的業務放自己來實現,完成怎麼做，誰去做。Swak的擴展點實現支持遠程調用,可以讓業務實現應用級別的隔離 ,相比傳統的分包、分模塊隔離方式更加徹底。

當前,閒魚商品主鏈路完成基於Swak的升級。下面是一個閒魚幣個性化業務的代碼案例:

平臺通用能力

平臺必須提供一些通用能力更好的支持業務發展：

• 實時選品投放能力--馬赫：解決因閒魚商品特性(結構化信息少,新品成交佔比高)導致傳統離線選品轉換率差的問題。
• 實時線上故障定位能力--神探:解決類閒魚規模系統因依賴多、場景多,導致線上問題頻發、問題定位投入成本高的問題。核心思路是對系統每一次錯誤的請求鏈路進行實時採集、分析、聚合再可視化展現,將整體故障定位過程變成自動化。

架構演進-雲端一體化

雲端一體化--背景

隨著無線發展,移動研發逐漸向多端化發展(IOT、小程序)。傳統的基於Native＋Web＋服務端的開發方式，逐漸出現瓶頸，我們會發現例如:

• 端上同學離業務越來越遠，服務端同學沒時間做底層領域沉澱。
• 各端研發之間存在大量的協同, 整體研發效率低下。
• 招人也難了,需要同時招多個技術棧的同學
• 在這種背景下, 我們的關注點回到研發效率上,從整體研發架構、研發模式出發, 思考什麼樣的架構演進、關係重塑才能適合當前的業務形態。我們希望探索出適合“ 閒魚這樣規模的具有獨立APP” 的高效研發架構, 形成雲端一體化的研發能力，支持一雲多端的發展。

雲端一體化--演進步驟

朝著雲端一體化的方向,架構的升級大概分成3個步驟:

1. 端上用Flutter實現了兩端(IOS、Android)統一。無線發展了現在,跨平臺的需求已經非常強烈,團隊招聘需要考慮 Android,IOS配比、一個業務需要在兩端都寫一次, 考慮雙端邏輯一致、測試要測兩遍。所以跨平臺的方案能非常直接有效的降低研發成本,解決資源均衡的問題。
2. Flutter+dart實現了三端(IOS、Android、服務端)技術棧統一。端上統一了，再通過雲端技術棧的打通來減少雲端的協同。參考前端＋Node.js的方案 ,閒魚服務端用dart(Flutter也是dart語言)替換Java,作為服務端server的語言。
3. Flutter+ Faas(dart runtime)+Nexus。技術棧統一了,人員還不能互補, 最新閒魚將Dart容器嵌入到Faas容器中,配合跨雲端的一體化業務研發框架Nexus,進行了一體化的研發模式的探索,使得一個研發人員能從端到服務端完成整個業務的閉環。

雲端一體化--跨端方案選擇

架構方案的選擇,可能造成巨大並且長遠的影響。在架構的演進中, 我們要善於定義問題,然後通過不斷迭代來解決問題,最後才能形成適合自己業務特性的架構。

閒魚也是一樣,所謂沒有銀彈的解決方案,在跨平臺方案的選型中, 充分對比了Flutter與RN的差異性,優缺點。

閒魚認為"跨平臺與高性能是我們當前的核心訴求”, 再結合團隊內native技術棧的同學較多這個因素,我們最終選擇了Flutter作為跨端解決方案。

雲端一體化--雲端協同

Flutter兩端統一後,會發現客戶端與服務端雖然都在做同一個業務,不僅技術棧沒有統一,而且存在著大量協同的工作,同時端、雲的同學仍然無法真正互補和一體化打通。

因此,我們開始思考是否能有一體的架構 ,能讓一個同學可以Cover一個雲到端的完整業務，形成業務閉環。

這不僅僅是效率的提升,更能為業務開發同學帶來更大的成長空間，可以完整的和專注的思考業務。

雲端一體化--關鍵問題以及解法

我們梳理了需要解決的關鍵問題:

• 如何消除雲端技術壁壘？首先要統一技術棧，其次端同學對雲的思維模式、知識儲備上的差異，需要有辦法消除。
• 如何使工作總量減少 ( 1+1<2 )？一體化下需要使總工作量降低,不是簡單的進行工作量轉移。
• 如何促進生產關係重塑？生產力發生變化,需要建立新的生產關係。

面向這些問題，閒魚的解法思路：

• 統一技術棧: Dart具備服務端語言特點,強類型,支持異步與併發,甚至更快的啟動速度，因此作為服務端的server完全沒有問題。Dart落地過程中更多的解決的是生態的問題(阿里的大部分生態都是基於java來建設的,例如中間件、消息、遠程調用)。我們主要通過通過C++擴展、SideCar方式做橋接,Service Mesh來解決。
• 雲端差異抹平: 通過Faas , Baas等無服務器能力的建設, 抹平除寫代碼外的其他差異性(運維、故障定位等),使得客戶端同學能寫服務端;通過UI2Code(根據圖片生成UI代碼),頁面代碼模板化(頁面容器，數據管理)使得服務端寫客戶端
• 一體化總體效率提升:以往的架構是雲、端分開架構的，一體化後下沉跨雲端的研發框架Nexus，通過框架、工程體系的支持, 消除協議層, 重新定義UI與邏輯分層, 帶來了總工作量1＋1<2
• 關係重塑:領域下沉能讓原來服務端同學更加專注領域建設, 使領域層更加穩定, 讓業務層與領域層的變化比例,從當前的2:1,提高到5:1 甚至更高。讓大家的關注點都集中在自己的範圍內。

雲端一體化--業務落地

目前一體化的研發模式已經在閒魚多個場景落地,我們以下單頁的改造舉例:

改造前:下單頁有著複雜的 渲染 交互邏輯,之前大部分邏輯都是在端上。需要兩個客戶端+一個服務端的同學來維護。

改造後:

• 將客戶端界面從 IOS、Android兩端統一成了Flutter, 後續只需要一個同學維護即可,也不會出現邏輯不一致的情況。
• 原來雲端分離的業務邏輯全部下沉到了Faas(Dart),將原來分散在端與服務端的邏輯進行歸一,有機會做更多的規劃建設,同時也是端的同一個同學來維護。
• Faas層調用底層領域服務來完成自己的業務，原來服務端的同學更多投入到交易能力的建設上。

框架下沉：

跨雲端業務研發框架Nexus:寓意著能將客戶端與服務端連接在一起。

核心思想：將UI與邏輯分離,框架限定了端上只負責UI與狀態的存儲, 所有的邏輯都在Faas中完成。

非常適合類似下單頁的領域穩定的的場景。

雲端一體化--收益

雲端一體化能在多個方面給我們帶來收益, 包括團隊人員資源的均衡、協同效率的提升、業務的一致性以及人員的新的成長空間。

特別適合類似閒魚規模的具有獨立app的研發團隊

小結

本文分別介紹了閒魚從快速試錯期、發展期、平臺期、雲端一體化的整體架構演進以及過程中的思考。對核心問題的定義,以及做的具體演進。

我們會發現，架構的演化總是優於一步到位,沒有一個大而全或者特效的方法可以一直提升系統效率。軟件工程是一個超級複雜的系統,尤其是業務架構,需要隨著業務隨時變化。明確當前業務特點和核心問題才是設計的根本，不符合業務的架構再領先也沒用。相信所有架構師都有這樣的體會。

希望通過以上的分享對大家有所啟發！

阿里雲雙11億元補貼提前領，進入抽取iPhone 11 Pro：https://www.aliyun.com/1111/2019/home?utm_content=g_1000083110