閑魚將使用Flutter和FaaS來建設未來的技術開發體系，這是一項長期的規劃，新的技術在現在看來猶如霧裏看花，需要我們不斷的思考，探索，實踐才能漸漸描繪出它的輪廓。本文對此提供一種思考角度，對未來基于FaaS+Flutter之上的編程形態做思考，並介紹自己的初步實踐。

Flutter，Faas，與閑魚的一體化

閑魚長期在做技術一體化的探索與實踐：我們希望使用一門語言，一套技術棧，能讓開發工程師在任何場景完成業務開發，實現開發模式和技術棧的統一。這是對開發效率的極致追求，也是對開發人員的深度賦能，更好的釋放人員價值，驅動業務成長。

閑魚已經借助Flutter良好的跨棧能力來對App上的技術棧做統一，並取得了初步的成果。因此想更近一步的整合前後端，結合Flutter來建立統一的技術棧。FaaS的興起給我們帶來了新的視角和機會，在後端開發場景中，FaaS將運行環境和部署運維從日常開發中剝離出來，讓開發者更聚焦于業務，降低了後端開發准入門檻，閑魚基于此已經在做Flutter+FaaS的一體化開發體系建設。

技術在發展中會對當前的解決方案不斷的抽象，總結和提煉，逐漸分離出其中的變化的部分與不變的部分，讓原來的問題變得收斂，開發的關注點會變的更聚焦，開發效率得以提升。這樣會出現分層，進而沉澱出基礎設施，這也是技術體系演進的一般規律，如圖 1-1。

圖 1-1

Flutter+FaaS的技術方案也是如此，我們在當前的中台的基礎設施之上建設用于一體化開發的新的基礎設施層，讓業務開發更加聚焦。由此需要思考兩個基本的問題：

• Flutter+FaaS的技術體系作爲支撐一體化開發的基礎設施該提供什麽樣的能力？

• 基于新的一體化基礎設施的業務開發是什麽樣的形態？

圖 2-1

這是一體兩面的兩個問題，只要回答其中一個問題，另一個問題的答案也會變得清晰起來。本文是思考和探索第二個問題。

Flutter+Faas一體化下的開發形態思考

也許只有到了最後一刻我們才能最終回答這個問題，但是技術總是帶著疑問前行，我們先從嘗試做頂層做抽象定義開始，然後落地實踐，在實踐後總結提煉，完善頂層抽象，叠代往複，最終將概念變清晰。

先來看看當前的業務開發形態，如圖 2-1，當前在業務開發中幾個主要的關注點我大概的歸納爲：數據處理，網絡通信，狀態管理和界面繪制。從這4個點出發，逐一思考，在新的一體化的場景下會有什麽變化：

圖 2-1

• 數據處理：泛指傳統的服務端REST API這部分，在一體化的場景下，這部分會由FaaS函數來實現，其實這一部分的職責和定位並沒有改變，只是開發的組織溝通形式變了。傳統開發頁面會由服務端和客戶端同學合力完成，後面可能由一位同學前後一體化開發完成。康威定律指出，軟件的設計和開發人員的組織溝通結構是息息相關的，所以這一部分可能有較大的變化，但首先是他與客戶端的交互方式上的變化，即網絡通信。

• 網絡通信：在一體化場景下，前後端都由一人實現，代碼也會是一個工程中的同種語言，網絡通信會加輕量安全，使用起來也會更加自然，接近于普通的函數調用。一個可能的變化是，通信模式可能會突破CS模式，在一次通信“會話”中，Client端和Server端能更加自然的相互調用，實現“對等對話”，而不是傳統的客戶端請求，服務端響應。隨著網絡硬件升級，網速在變快，通信成本在下降，創新的空間很大。

• 狀態管理：應用狀態很大程度上是緩存在客戶端上的數據，受技術體系隔離，開發溝通成本，網絡通信成本的影響，在客戶端上緩存狀態是有必要的。但在一體化的場景中，這些因素的影響在減小和消失，所以我們想進一步的消滅狀態，將狀態管理降至最小，盡可能的由底層管理。

• 界面繪制：也許是受Flutter的影響，響應式風格結合數據驅動的UI理念非常契合我們的思路，這也是業界UI開發框架的潮流。

Flutter+FaaS一體化技術體系下，應用開發應該會更加簡單，前後端之間的差異變小，通信更加輕量自然，職責更加聚焦,如圖 2-2。

圖 2-2

一體化框架設計實踐

在一體化的場景下，業務可以由一個同學負責前後端的開發，最大限度的減小溝通協作成本。當然，大體量的業務必然需要協作的，但協作的方式有所改變，工作的劃分可以由傳統的前後端的橫向劃分，變成前後一體的垂直劃分，如圖 3-1，協作方式的改變也會影響到我們設計的思路。

圖 3-1

基于前面的討論，我們嘗試做了框架設計：首先我們將要開發的業務命名爲一個Story，即一個Story代表一個産品業務，Story會按照上面垂直劃分的方式，將業務劃分爲一系列的Scene。Scene對應于傳統意義上的”頁面”的概念，但和産品設計上的頁面不強求一一對應，如圖 3-2-(1)。Scene是個前後一體的虛擬概念，運行時並沒有實體。它由3部分組成，如圖 3-2-(2), Model部分處理業務數據（RawData）,Converter將業務數據轉換成渲染所使用的數據(State), 最後Render使用渲染數據繪制界面。Model和Converter部署在後端，在FaaS函數中運行，Render運行在客戶端，他們之間的數據流是單向的。在實現邏輯處理的時候，統一使用事件，事件優先在本端處理，本端不處理則路由到另一端，如果另一端也不處理，則丟棄，如圖 3-2-(3)。

圖 3-2

Story已經開始在閑魚的業務中落地實踐，後期帶來實踐效果的分享。

實踐中的挑戰與借鑒

要建設完善一體化技術體系不是容易的事情，實踐中肯定會有諸多挑戰。好消息是FaaS和它背後的Serverless理念已經是業內潮流了，實踐也在如火如荼的進行中。其中，阿裏的前端同學集中力量，對Serverless已經實踐的很深入了，雖然並不是一體化的理念，但實踐上很多的思路可以做相互印證和借鑒：

• 開發部署工具鏈：閑魚一體化工程依賴于底層開發部署工具鏈的支持，是基礎設施的一部分，部署也是Serverless體系中關鍵一環，從前端同學的實踐中看，工具，插件和平台都有。閑魚有直接使用的平台，也會有自建的工具插件，長遠會做一步的體系標准化建設。

• 全鏈路追蹤監控：這是工程化必須的系統，閑魚直接受益于集團的平台，但也會建設自己特殊場景的工具，比如借鑒Flutter的函數熱更新，本地一體化調試等。

當然，閑魚也有自己感興趣探索的方向：

• 網絡通信：我們的很多設想對網絡通信有著很高的要求，誠然，網絡質量會越來越好，成本也會也來越低，但弱網場景總會存在，如何保證服務的穩定可用依然是挑戰。一體化會弱化開發對網絡的感知，提供新的網絡使用方式。

• 組件分治：在閑魚的業務中，複雜頁面是始終要考慮的問題。在前面的設計中，我們對此做了預留(Converter部分)，但前後一體化的組件該怎麽抽象，又如何組合複用，我們還在探索中。

閑魚團隊是Flutter+Dart FaaS前後端一體化新技術的行業領軍者，就是現在！客戶端／服務端java／架構／前端／質量工程師面向社會招聘，base杭州阿裏巴巴西溪園區，一起做有創想空間的社區産品、做深度頂級的開源項目，一起拓展技術邊界成就極致！

*投餵簡曆給小閑魚→guicai.gxy@alibaba-inc.com

開源項目、峰會直擊、關鍵洞察、深度解讀

請認准閑魚技術