從0到千萬DAU，這5年閒魚架構如何演進？

阿里妹導讀：閒魚品牌創立於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個步驟：

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

 

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。