一、閒魚的業務特色
據巴滕介紹，閒魚是一個典型的雙邊市場，買家和賣家規模相互影響，「如何同時服務好買家和賣家雙方，這是咱們一直努力的方向」。前端
對買家來講，要提高商品發現效率，幫助他們儘快地買到商品。web
對賣家而言，要下降發佈門檻，幫助他們儘快地把商品賣出去。算法
對於平臺，要持續優化用戶的使用體驗，好比下降糾紛和欺詐問題，同時持續擴大市場規模。數據庫
二、閒魚服務端最初的架構設計
衆所周知，閒魚的前身是 PC 時代的淘寶二手，它屬於淘寶的一個小頻道。當時，閒魚總體業務規模和用戶量都很是小。基本上，單一應用就支撐全部業務，而且總體架構和服務徹底是面向 PC 設計的。後端
「當時，服務端同窗須要時常編寫 Velocity 模板代碼，又因爲部分前端代碼也部署在業務服務器中，前端和服務端同窗還要常常須要修改同一個應用。」巴滕說。緩存
當時，閒魚服務端的基本架構以下圖所示：服務器
據悉，webx 是阿里內部大量使用的一套基於 Java Servlet API 的通用 web 框架，能夠類比爲 Spring MVC，「在阿里 PC 站點上通過多年應用，不只成熟可靠，並且具有極高的擴展性和開放性」。微信
巴滕稱，「這套架構當時跟淘寶的 PC 架構是基本一致的。因爲業務規模小，還未作服務化拆分，而且負責維護開發的技術同窗常常調換，因此採用這種單一服務架構，維護成本相對較低又能支撐業務訴求。」架構
三、閒魚服務端架構演進
剛創立時，閒魚的定位是作移動端獨立 App。這樣，他們在作架構設計時就面臨兩大問題：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 上，而非簡單的消費型代碼。
本文分享自微信公衆號 - K8S中文社區（k8schina）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。