閑魚是從阿裡巴巴某一茶水間“遊”出來的。2014 年 6 月，閑魚誕生，2 年時間不到，其用戶數突破 1 億。如今，它已經成為國內最知名的閑置交易平臺，擁有數億用戶，年交易額超過 2000 億，並開啟瞭一個萬億市場。閑魚能有今天的成績，離不開背後的技術迭代、架構升級和技術人的付出。
閑魚初創時，架構設計面臨著哪些挑戰？閑魚服務端架構在 6 年時間裡是怎樣演進的？閑魚在服務端架構上還在做哪些新嘗試？…… 帶著這些問題，InfoQ 記者采訪瞭閑魚技術部高級技術專傢巴滕。自閑魚創立以來，他一直參與閑魚服務端架構持續演進的工作。
閑魚的業務特點
據巴滕介紹，閑魚是一個典型的雙邊市場，買傢和賣傢規模相互影響，“如何同時服務好買傢和賣傢雙方，這是我們一直努力的方向”。
對買傢來說，要提升商品發現效率，幫助他們盡快地買到商品。
對賣傢而言，要降低發佈門檻，幫助他們盡快地把商品賣出去。
對於平臺，要持續優化用戶的使用體驗，比如降低糾紛和欺詐問題，同時持續擴大市場規模。
閑魚服務端最初的架構設計
眾所周知，閑魚的前身是 PC 時代的淘寶二手，它屬於淘寶的一個小頻道。當時，閑魚整體業務規模和用戶量都非常小。基本上，單一應用就支撐所有業務，並且整體架構和服務完全是面向 PC 設計的。
“當時，服務端同學需要時常編寫 Velocity 模板代碼，又由於部分前端代碼也部署在業務服務器中，前端和服務端同學還要經常需要修改同一個應用。”巴滕說。
當時，閑魚服務端的基本架構如下圖所示：
據悉，webx 是阿裡內部大量使用的一套基於 Java Servlet API 的通用 web 框架，可以類比為 Spring MVC，“在阿裡 PC 站點上經過多年應用，不僅成熟可靠，而且具備極高的擴展性和開放性”。
巴滕稱，“這套架構當時跟淘寶的 PC 架構是基本一致的。由於業務規模小，還未做服務化拆分，並且負責維護開發的技術同學經常調換，所以采用這種單一服務架構，維護成本相對較低又能支撐業務訴求。”
閑魚服務端架構演進
剛創立時，閑魚的定位是做移動端獨立 App。這樣，他們在做架構設計時就面臨兩大問題：
- 整體架構必須從 PC 全面切換為無線，這需要進行大量的 0 到 1 的技術基礎設施的完善和引入；
- 業務形態復雜化，單一應用帶來的耦合問題和開發效率問題，因此要進行服務端的服務化改造。
不過，手機淘寶當時已經積累瞭一些無線端的基礎設施，例如統一無線網關、開關系統、hotpatch 等。
這樣，第一波的改造更多的是接入和集成阿裡集團的這些無線中間件。客戶端（包括前端）和服務端的工作界面也以無線網關的接口為分割線，服務端主要負責基礎的數據返回，客戶端則完成數據到 MVC 模型的綁定和控制。
服務端則進行瞭一些服務化改造，從單一應用進行橫向拆分（按業務拆分）和縱向拆分（對數據層的訪問進行收斂，並根據服務能力讓一些基礎能力下沉形成公共服務）。業務層做薄，更輕量化的支撐業務快速迭代，拆分獨立業務網關層來對接無線接入層網關，收口完成所有的客戶端業務數據，最後拼裝。
此時，閑魚服務端的架構基本如下圖所示：
在第一輪無線化和服務化改造後，閑魚服務端初步能夠應對 App 的正常迭代。但是業務發展速度太快，用戶規模以極快的速度增長，業務團隊的需求快速膨脹，這讓技術又面臨新的挑戰：
- 線上服務性能不足
- 迭代速度不夠快
用兩個典型例子來說明。
案例 1：閑魚商品量從數十萬快速膨脹到數千萬，而閑魚原來用 Lucene+solar 搭建的搜索引擎出現問題：無論是服務能力，還是算法能力接入，以及運維成本，都已經不堪重負。閑魚必須要升級整個搜索引擎。“當時，我們的選擇是升級到集團的大規模搜索引擎 HA3 上，同時接入集團統一推薦平臺 TPP 上“。
案例 2：隨著業務需求的不斷增多，大量的活動類型開發需要前端上線，但是每個活動對服務端數據又有略微的差異。如果全部都需要服務端人員每個接口定制開發，服務層網關開發以及發佈等工作量和周期都較大。因此，團隊在服務端上參考 Facebook 的 GraphQL 做瞭一套自己的 MBaaS 的解決方案。它被稱之為 Card 模型，其核心思想是基於 MVVM 的概念，將一部分 Model 和 View Model 以及部分的 View Controller 前置到服務端下發，客戶端做薄。
在巴滕看來，應對服務能力不足，他們更多的是在做一些基礎能力的升級，比如更徹底的業務服務化拆分和解耦、存儲層優化（數據庫拆分和擴容，大規模多級緩存等）和一些關鍵服務的升級。而應對研發迭代速度慢的問題，更多的是做一些動態化和復用性的嘗試，盡可能降低協同成本，提高代碼和模塊的復用性。
當時的系統架構如下圖所示：
經過第二輪的升級改造，服務端在性能上已經不懼任何規模的流量。基本上，隻要做好容量規劃和采取各種高可用措施，就能保障系統的服務能力足以應對業務增長。
而在這一輪的改造中，團隊又看到從原來純粹的工程主導，開始逐步有更多算法能力的接入，“我們在整個搜索和推薦鏈路中初步具備智能化的能力”。
很快，服務端又面臨新挑戰：來自業務需要帶來的新增長點的壓力。巴滕表示，“近幾年來，最大的技術紅利莫過於 AI 和數據，如何讓 AI 和數據在閑魚有效地落地和發揮價值，這是算法和工程團隊共同面臨的問題，因此第三輪的技術優化應運而生。”
想擁抱 AI 和數據，首當其沖的是透徹的分析業務本身面臨的核心問題。因為算法最擅長的是解決明確目標下的優化問題，所以團隊又對閑魚的業務進行抽象，分析找到閑魚最核心的業務問題。
下圖是將閑置市場和新品市場做的對比。由圖可知，在新品市場上，由於商品和服務的確定性，價格基本上可以反映商品本身的價值。但是，在閑置市場上，無論是賣傢，還是買傢，都面臨較高的信任成本。信任成本不僅僅體現在防范欺詐，還有買傢和賣傢對商品本身新舊程度認知差異帶來的糾紛。
從圖可以得知，閑置市場的特點決定瞭團隊擴大市場空間的兩個核心路徑：
- 提高匹配效率
- 降低信任成本
因此，閑魚的很多工程和算法就開始圍繞這兩個核心方向展開，並構建一整套的產品技術體系。
巴滕稱，“對於降低信任成本，暫且按下不表，因為信任的解決和構建涉及到大量的瑣碎和細致的工作，甚至依賴於整個社會的進步，我們主要介紹如何提升交易效率的一些思路。”
首先分析導致閑魚交易效率低的關鍵要素：
- 輕發佈。商品發佈門檻低，隻需少量圖片 / 視頻和簡單的描述即可發佈成功，但是輕發佈帶來的核心問題是商品本身有效信息量太少。舉個例子，用戶發瞭一張圖，寫瞭八個字——剛買的蘋果轉手出。系統就無法準確判斷用戶發的是蘋果手機，還是真的水果，這樣商品在搜索推薦鏈路的準確率必然受到影響。
- 商品單庫存。商品隻有一件，售出立即就下架瞭，那麼整個搜索推薦鏈路對實時性要求就極高，不然就會帶來大量的流量浪費。
基於這兩個問題，“我們做瞭兩個關鍵系統：一個是系統解決商品結構化問題，一個是系統解決整個流量分發鏈路上的實時性問題”。
與此同時，在面臨團隊進一步擴大、協作成本和穩定性風險增高的前提下，他們還孵化出一系列支撐業務解耦和隔離（SWAK 解耦框架）、線上故障實施定位（神探系統）等一系列的服務端系統和工具。
此外，他們在端上全面擁抱 Flutter，逐步構建瞭一系列基於 Flutter 和 native 混合棧一系列工程化和規模化開發框架，同時還在端上進行瞭一些智能化的探索。
這時候，閑魚服務端架構演化成下圖模樣：
現在，除瞭繼續解決業務領域的問題，團隊還在進一步持續探索適應未來多端一體化的研發架構，希望通過底層技術的升級，進一步壓縮業務開發同學在客戶端雙端加上服務端這三個端上的協同成本。
這套架構的核心思想是基於 dart 語言完成三端在協議層和通信層的統一，將傳統服務端最後一步的數據拼裝的膠水層工作全部交由一個客戶端的一位技術人員就能完成。
巴滕說：“得益於 Serverless 的快速發展，我們的膠水層服務端接口已全部托管在阿裡自研的 FAAS 平臺 GAIA 上，可以實現非常低成本的運維開發，讓業務開發同學更多的聚焦在業務上。”
在服務端架構上的新嘗試
據巴滕透露，閑魚服務端架構目前在一體化開發模式和智能化上進行一些嘗試。
對他們來說，Serverless 更多是基礎設施。他們的工作重點是基於集團不斷構建的 Serverless 能力上，持續迭代和演化他們的一體化業務開發架構。而 Serverless 本身還是交給更專業的中間件和阿裡雲的相關團隊。“一體化開發模式有可能改變我們整體的研發模式，前後端工作邊界將再一次改寫”。
智能化有兩個含義：一個是在業務各種場景和工程環節中，如何充分的融入算法能力。這需要充分考慮算法能力邊界，構建服務於算法的實時 / 離線數據能力、ab 能力等基礎設施。同時，他們還在進行雲智能和端智能結合的探索、商品和內容結構化工程體系等。
智能化的第二個含義是通過智能化提升研發效率。眾所周知，整個研發流程鏈路是非常長的，從腦圖到 PRD 到視覺交互再到開發測試，每一個環節都可能由於信息傳遞差帶來的效率降低和 bug 出現。他們希望通過一些自動化的方式降低整個研發流程中一些信息傳遞的損失，降低重復性勞動，比如一直不斷優化的 UI2Code 項目希望把視覺稿通過圖像識別自動轉化為可讀性高的代碼。
對服務端架構的思考
在巴滕看來，服務端架構目前最火的就是 Serverless，“但是我們要透過現象看本質，服務端架構永遠在做兩個方向的優化”。
- 研發效率。如何讓業務開發效率更高，更少的人可以做更多的事，並且保證做的又快又穩又好。其實，Serverless 隻是給出瞭一個解法，且目前還沒有事實上的行業標準（做到類似 Spring 一樣），這也是他們一個持續探索的方向。
- 業務賦能。技術要想在公司財報上不僅僅體現為成本，就要持續的創新，尤其是在 AI 浪潮下，服務端架構如何更全面的擁抱算法，讓算法在工程平臺上可以充分的發揮價值，這也是尤其要關註和思考的。“可以不做算法工程師，但是不懂算法的業務架構師一定做不好業務架構，這是我個人最近的一個認知。”他說。
寫在最後
從閑魚創立至今，巴滕見證瞭閑魚從無到有、從小變大的過程。回首這 6 年，他這樣總結——凡是過往，皆為序章，閑魚依然有大量的問題需要解決，還有更廣闊的空間需要探索。而在架構方面，他現在更多的思考：一是如何真正的賦能業務，如何讓不可能成為可能，讓在發生的事情變得更高效；二是如何進一步解放技術，讓我們的時間和精力花費在更令人愉悅的 coding 上，而非簡單的消費型代碼。