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

閑魚業(yè)務(wù)背景

技術(shù)架構(gòu)的演進跟業(yè)務(wù)形態(tài)都是強相關(guān)的,閑魚的市場本質(zhì)以及用戶特點如下描述:

閑魚是一個高性價比的二手交易市場。相比新品市場,二手市場的市場空間就是"用戶在付出相同成本條件下有可能獲取到更高的物品價值”，典型的比如"游戲卡帶,樂高"等這些功能型的產(chǎn)品。同時,閑置市場也有著特殊存在的成本-信任成本,信任成本主要體現(xiàn)在:大部分二手可能沒有售后服務(wù);每個人對二手物品殘值有著自己的主觀評價。?
擴大市場空間有兩種方式，1.降低新人成本 2.提升匹配效率

閑魚與手淘差異性:

• 閑魚與手淘的賣家差異:非專業(yè)的個人賣家,利益驅(qū)動弱。
• 發(fā)布產(chǎn)品差異:為保證市場供給,只能堅持輕發(fā)布。
• 商品差異:結(jié)構(gòu)化信息少,沒有歷史累計行為。

閑魚與手淘在業(yè)務(wù)、團隊結(jié)構(gòu)的差異性導致架構(gòu)上不同的關(guān)注點,導致不同的演進路線。

架構(gòu)演進-試錯期

架構(gòu)隨著業(yè)務(wù)階段不斷演進, 每個階段都有核心的問題

• 試錯期業(yè)務(wù)核心問題:業(yè)務(wù)不斷探索適合的商業(yè)模式
• 架構(gòu)核心關(guān)注點:提升響應(yīng)速度,快速支持業(yè)務(wù)上線
• 架構(gòu)核心原則:以質(zhì)量換取速度,可以犧牲一點線上質(zhì)量(業(yè)務(wù)可接受范圍)來換取更快的響應(yīng)速度

App發(fā)版速度(尤其是IOS)跟不上業(yè)務(wù)快速迭代的上線周期,動態(tài)性是端面臨的主要問題,因此端上采用了Hybrid的架構(gòu):

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

架構(gòu)演進-發(fā)展期

發(fā)展期業(yè)務(wù)與架構(gòu)核心問題:

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

客戶端開發(fā)關(guān)注兩個點:

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

架構(gòu)演進-平臺期

隨著業(yè)務(wù)的發(fā)展,閑魚基于商品體系的業(yè)務(wù)達到十幾種,逐漸向平臺期發(fā)展。平臺期業(yè)務(wù)與架構(gòu)核心問題:

• 業(yè)務(wù)核心問題:需要讓更多的二方、三方參與到共享經(jīng)濟平臺的建設(shè)中,但是平臺生態(tài)建設(shè)又超出了閑魚自身的能力
• 架構(gòu)核心關(guān)注點:擴展性(具備接入業(yè)務(wù)的能力)、業(yè)務(wù)隔離(已接入業(yè)務(wù)平穩(wěn)運行)、平臺基礎(chǔ)能力建設(shè)(業(yè)務(wù)更好的發(fā)展)
• 架構(gòu)原則:做一些更基礎(chǔ)的規(guī)劃,然后把更多的可能性、動態(tài)性留給二方或者三方完成

業(yè)務(wù)隔離框架Swak

核心解決因業(yè)務(wù)發(fā)展帶來的代碼耦合問題,問題主要體現(xiàn)在整體開發(fā)、運維效率低，穩(wěn)定性差。核心思路是分離系統(tǒng)中不可變和可變的部分;分離出”做什么”與”怎么做”、“誰去做”。?
將業(yè)務(wù)中不變的部分放入主干,定義出做什么;變化的部分以擴展點形式開放出來,讓具體的業(yè)務(wù)放自己來實現(xiàn),完成怎么做，誰去做。Swak的擴展點實現(xiàn)支持遠程調(diào)用,可以讓業(yè)務(wù)實現(xiàn)應(yīng)用級別的隔離 ,相比傳統(tǒng)的分包、分模塊隔離方式更加徹底。?
當前,閑魚商品主鏈路完成基于Swak的升級。下面是一個閑魚幣個性化業(yè)務(wù)的代碼案例:

平臺通用能力

平臺必須提供一些通用能力更好的支持業(yè)務(wù)發(fā)展：

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

架構(gòu)演進-云端一體化

云端一體化--背景

隨著無線發(fā)展,移動研發(fā)逐漸向多端化發(fā)展(IOT、小程序)。傳統(tǒng)的基于Native＋Web＋服務(wù)端的開發(fā)方式，逐漸出現(xiàn)瓶頸，我們會發(fā)現(xiàn)例如:

• 端上同學離業(yè)務(wù)越來越遠，服務(wù)端同學沒時間做底層領(lǐng)域沉淀。
• 各端研發(fā)之間存在大量的協(xié)同, 整體研發(fā)效率低下。
• 招人也難了,需要同時招多個技術(shù)棧的同學?
  在這種背景下, 我們的關(guān)注點回到研發(fā)效率上,從整體研發(fā)架構(gòu)、研發(fā)模式出發(fā), 思考什么樣的架構(gòu)演進、關(guān)系重塑才能適合當前的業(yè)務(wù)形態(tài)。我們希望探索出適合“ 閑魚這樣規(guī)模的具有獨立APP” 的高效研發(fā)架構(gòu), 形成云端一體化的研發(fā)能力，支持一云多端的發(fā)展。

云端一體化--演進步驟

朝著云端一體化的方向,架構(gòu)的升級大概分成3個步驟:

端上用Flutter實現(xiàn)了兩端(IOS、Android)統(tǒng)一。無線發(fā)展了現(xiàn)在,跨平臺的需求已經(jīng)非常強烈,團隊招聘需要考慮 Android,IOS配比、一個業(yè)務(wù)需要在兩端都寫一次, 考慮雙端邏輯一致、測試要測兩遍。所以跨平臺的方案能非常直接有效的降低研發(fā)成本,解決資源均衡的問題。

Flutter+dart實現(xiàn)了三端(IOS、Android、服務(wù)端)技術(shù)棧統(tǒng)一。端上統(tǒng)一了，再通過云端技術(shù)棧的打通來減少云端的協(xié)同。參考前端＋Node.js的方案 ,閑魚服務(wù)端用dart(Flutter也是dart語言)替換Java,作為服務(wù)端server的語言。

Flutter+ Faas(dart runtime)+Nexus。技術(shù)棧統(tǒng)一了,人員還不能互補, 最新閑魚將Dart容器嵌入到Faas容器中,配合跨云端的一體化業(yè)務(wù)研發(fā)框架Nexus,進行了一體化的研發(fā)模式的探索,使得一個研發(fā)人員能從端到服務(wù)端完成整個業(yè)務(wù)的閉環(huán)。

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

架構(gòu)方案的選擇,可能造成巨大并且長遠的影響。在架構(gòu)的演進中, 我們要善于定義問題,然后通過不斷迭代來解決問題,最后才能形成適合自己業(yè)務(wù)特性的架構(gòu)。?
閑魚也是一樣,所謂沒有銀彈的解決方案,在跨平臺方案的選型中, 充分對比了Flutter與RN的差異性,優(yōu)缺點。
閑魚認為"跨平臺與高性能是我們當前的核心訴求”, 再結(jié)合團隊內(nèi)native技術(shù)棧的同學較多這個因素,我們最終選擇了Flutter作為跨端解決方案。

云端一體化--云端協(xié)同

Flutter兩端統(tǒng)一后,會發(fā)現(xiàn)客戶端與服務(wù)端雖然都在做同一個業(yè)務(wù),不僅技術(shù)棧沒有統(tǒng)一,而且存在著大量協(xié)同的工作,同時端、云的同學仍然無法真正互補和一體化打通。?
因此,我們開始思考是否能有一體的架構(gòu) ,能讓一個同學可以Cover一個云到端的完整業(yè)務(wù)，形成業(yè)務(wù)閉環(huán)。?
這不僅僅是效率的提升,更能為業(yè)務(wù)開發(fā)同學帶來更大的成長空間，可以完整的和專注的思考業(yè)務(wù)。

云端一體化--關(guān)鍵問題以及解法

我們梳理了需要解決的關(guān)鍵問題:

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

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

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

云端一體化--業(yè)務(wù)落地

目前一體化的研發(fā)模式已經(jīng)在閑魚多個場景落地,我們以下單頁的改造舉例:?
改造前:下單頁有著復雜的 渲染 交互邏輯,之前大部分邏輯都是在端上。需要兩個客戶端+一個服務(wù)端的同學來維護。?
改造后:

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

框架下沉：?
跨云端業(yè)務(wù)研發(fā)框架Nexus:寓意著能將客戶端與服務(wù)端連接在一起。?
核心思想：將UI與邏輯分離,框架限定了端上只負責UI與狀態(tài)的存儲, 所有的邏輯都在Faas中完成。?
非常適合類似下單頁的領(lǐng)域穩(wěn)定的的場景。

云端一體化--收益

云端一體化能在多個方面給我們帶來收益, 包括團隊人員資源的均衡、協(xié)同效率的提升、業(yè)務(wù)的一致性以及人員的新的成長空間。?
特別適合類似閑魚規(guī)模的具有獨立app的研發(fā)團隊

小結(jié)

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

我們會發(fā)現(xiàn)，架構(gòu)的演化總是優(yōu)于一步到位,沒有一個大而全或者特效的方法可以一直提升系統(tǒng)效率。軟件工程是一個超級復雜的系統(tǒng),尤其是業(yè)務(wù)架構(gòu),需要隨著業(yè)務(wù)隨時變化。明確當前業(yè)務(wù)特點和核心問題才是設(shè)計的根本，不符合業(yè)務(wù)的架構(gòu)再領(lǐng)先也沒用。相信所有架構(gòu)師都有這樣的體會。?
希望通過以上的分享對大家有所啟發(fā)！

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

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的QCon演讲|闲鱼从零到千万DAU的应用架构演进的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。