阿裡妹導讀：閑魚品牌創立于14年阿裡的某個茶水間，從0開始到現在千萬DAU，5年時間裡閑魚見證了閑置物品從線下到線上交易的轉移。而線上交易的繁榮，則需要業務架構做相應的調整、演進才能支撐業務的快速發展。本文主要通過介紹閑魚從0發展到千萬級DAU應用的不同階段的業務特點、核心問題以及針對性的架構演進，來闡述業務架構的演進思路與心得。
閑魚業務背景
技術架構的演進跟業務形态都是強相關的，閑魚的市場本質以及使用者特點如下描述：
閑魚是一個高成本效益的二手交易市場。相比新品市場，二手市場的市場空間就是"使用者在付出相同成本條件下有可能擷取到更高的物品價值”，典型的比如"遊戲卡帶、樂高"等這些功能型的産品。同時，閑置市場也有着特殊存在的成本——信任成本，信任成本主要展現在：大部分二手可能沒有售後服務；每個人對二手物品殘值有着自己的主觀評價。
擴大市場空間有兩種方式：
- 降低新人成本
- 提升比對效率
閑魚與手淘差異性：
- 閑魚與手淘的賣家差異：非專業的個人賣家，利益驅動弱。
- 釋出産品差異：為保證市場供給，隻能堅持輕釋出。
- 商品差異：結構化資訊少，沒有曆史累計行為。
閑魚與手淘在業務、團隊結構的差異性導緻架構上不同的關注點，導緻不同的演進路線。
架構演進——試錯期
架構随着業務階段不斷演進，每個階段都有核心的問題：
- 試錯期業務核心問題：業務不斷探索适合的商業模式；
- 架構核心關注點：提升響應速度，快速支援業務上線；
- 架構核心原則：以品質換取速度，可以犧牲一點線上品質(業務可接受範圍)來換取更快的響應速度。
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個步驟：
- 端上用Flutter實作了兩端(IOS、Android)統一。無線發展了現在,跨平台的需求已經非常強烈，團隊招聘需要考慮 Android,IOS配比、一個業務需要在兩端都寫一次, 考慮雙端邏輯一緻、測試要測兩遍。是以跨平台的方案能非常直接有效的降低研發成本，解決資源均衡的問題。
- Flutter+dart實作了三端(IOS、Android、服務端)技術棧統一。端上統一了，再通過雲端技術棧的打通來減少雲端的協同。參考前端＋Node.js的方案，閑魚服務端用dart(Flutter也是dart語言)替換Java，作為服務端server的語言。
- 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的研發團隊。
說在最後
本文分别介紹了閑魚從快速試錯期→發展期→平台期→雲端一體化的整體架構演進及過程中的思考。對核心問題的定義，以及做的具體演進。
我們會發現，架構的演化總是優于一步到位，沒有一個大而全或者特效的方法可以一直提升系統效率。軟體工程是一個超級複雜的系統，尤其是業務架構,需要随着業務随時變化。明确目前業務特點和核心問題才是設計的根本，不符合業務的架構再領先也沒用。相信所有架構師都有這樣的體會。
原文釋出時間為：2019-11-5
作者： 揚羽
本文來自雲栖社群合作夥伴“
阿裡技術”，了解相關資訊可以關注“
”。