作者：閒魚技術-匠修
原文鏈接：閒魚技術：基於Flutter+FaaS的業務框架思考與實踐
來源：知乎
閒魚將使用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作爲跨平臺開發技術、Flutter以其美觀、快速、高效、開放等優勢迅速俘獲人心，但很多FLutter興趣愛好者進階學習確實資料，今天我把我搜集和整理的這份學習資料分享給有需要的人，若有關Flutter學習進階可以與我在Flutter跨平臺開發終極之選交流羣一起討論交流。下載地址：https://shimo.im/docs/yTD3t8Pjq3XJtGv8
