作者|熊華麗(匠修)
出品|阿裡巴巴新零售淘系技術部
前言
閑魚将使用 Flutter 和 FaaS 來建設未來的技術開發體系，這是一項長期的規劃，新的技術在現在看來猶如霧裡看花，需要我們不斷的思考，探索，實踐才能漸漸描繪出它的輪廓。本文對此提供一種思考角度，對未來基于 FaaS+Flutter 之上的程式設計形态做思考，并介紹自己的初步實踐。
Flutter，Faas，與閑魚的一體化
閑魚長期在做技術一體化的探索與實踐：我們希望使用一門語言，一套技術棧，能讓開發工程師在任何場景完成業務開發，實作開發模式和技術棧的統一。這是對開發效率的極緻追求，也是對開發人員的深度賦能，更好的釋放人員價值，驅動業務成長。
閑魚已經借助 Flutter 良好的跨棧能力來對 App 上的技術棧做統一，并取得了初步的成果。是以想更近一步的整合前後端，結合 Flutter 來建立統一的技術棧。 FaaS 的興起給我們帶來了新的視角和機會，在後端開發場景中，FaaS 将運作環境和部署運維從日常開發中剝離出來，讓開發者更聚焦于業務，降低了後端開發準入門檻，閑魚基于此已經在做 Flutter+FaaS 的一體化開發體系建設。
技術在發展中會對目前的解決方案不斷的抽象，總結和提煉，逐漸分離出其中的變化的部分與不變的部分，讓原來的問題變得收斂，開發的關注點會變的更聚焦，開發效率得以提升。這樣會出現分層，進而沉澱出基礎設施，這也是技術體系演進的一般規律，如圖 1-1。
Flutter+FaaS 的技術方案也是如此，我們在目前的中台的基礎設施之上建設用于一體化開發的新的基礎設施層，讓業務開發更加聚焦。由此需要思考兩個基本的問題：
Flutter+FaaS 的技術體系作為支撐一體化開發的基礎設施該提供什麼樣的能力？
基于新的一體化基礎設施的業務開發是什麼樣的形态？
這是一體兩面的兩個問題，隻要回答其中一個問題，另一個問題的答案也會變得清晰起來。本文是思考和探索第二個問題。
Flutter+Faas 一體化下的開發形态思考
也許隻有到了最後一刻我們才能最終回答這個問題，但是技術總是帶着疑問前行，我們先從嘗試做頂層做抽象定義開始，然後落地實踐，在實踐後總結提煉，完善頂層抽象，疊代往複，最終将概念變清晰。
先來看看目前的業務開發形态，如圖 2-1，目前在業務開發中幾個主要的關注點我大概的歸納為：資料處理，網絡通信，狀态管理和界面繪制。從這4個點出發，逐一思考，在新的一體化的場景下會有什麼變化：
- 資料處理：泛指傳統的服務端 REST API 這部分，在一體化的場景下，這部分會由 FaaS 函數來實作，其實這一部分的職責和定位并沒有改變，隻是開發的組織溝通形式變了。傳統開發頁面會由服務端和用戶端同學合力完成，後面可能由一位同學前後一體化開發完成。康威定律指出，軟體的設計和開發人員的組織溝通結構是息息相關的，是以這一部分可能有較大的變化，但首先是他與用戶端的互動方式上的變化，即網絡通信。
- 網絡通信：在一體化場景下，前後端都由一人實作，代碼也會是一個工程中的同種語言，網絡通信會加輕量安全，使用起來也會更加自然，接近于普通的函數調用。一個可能的變化是，通信模式可能會突破 CS 模式，在一次通信“會話”中，Client 端和 Server 端能更加自然的互相調用，實作“對等對話”，而不是傳統的用戶端請求，服務端響應。随着網絡硬體更新，網速在變快，通信成本在下降，創新的空間很大。
- 狀态管理：應用狀态很大程度上是緩存在用戶端上的資料，受技術體系隔離，開發溝通成本，網絡通信成本的影響，在用戶端上緩存狀态是有必要的。但在一體化的場景中，這些因素的影響在減小和消失，是以我們想進一步的消滅狀态，将狀态管理降至最小，盡可能的由底層管理。
- 界面繪制：也許是受 Flutter 的影響，響應式風格結合資料驅動的UI理念非常契合我們的思路，這也是業界 UI 開發架構的潮流。
Flutter+FaaS 一體化技術體系下，應用開發應該會更加簡單，前後端之間的差異變小，通信更加輕量自然，職責更加聚焦,如圖 2-2。
一體化架構設計實踐
在一體化的場景下，業務可以由一個同學負責前後端的開發，最大限度的減小溝通協作成本。當然，大體量的業務必然需要協作的，但協作的方式有所改變，工作的劃分可以由傳統的前後端的橫向劃分，變成前後一體的垂直劃分，如圖 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)。
Story 已經開始在閑魚的業務中落地實踐，後期帶來實踐效果的分享。
實踐中的挑戰與借鑒
要建設完善一體化技術體系不是容易的事情，實踐中肯定會有諸多挑戰。好消息是 FaaS 和它背後的 Serverless 理念已經是業内潮流了，實踐也在如火如荼的進行中。其中，阿裡的前端同學集中力量，對 Serverless 已經實踐的很深入了，雖然并不是一體化的理念，但實踐上很多的思路可以做互相印證和借鑒：
- 開發部署工具鍊：閑魚一體化工程依賴于底層開發部署工具鍊的支援，是基礎設施的一部分，部署也是 Serverless 體系中關鍵一環，從前端同學的實踐中看，工具，插件和平台都有。閑魚有直接使用的平台，也會有自建的工具插件，長遠會做一步的體系标準化建設。
- 全鍊路追蹤監控：這是工程化必須的系統，閑魚直接受益于集團的平台，但也會建設自己特殊場景的工具，比如借鑒 Flutter 的函數熱更新，本地一體化調試等。
當然，閑魚也有自己感興趣探索的方向：
-
網絡通信：
我們的很多設想對網絡通信有着很高的要求，誠然，網絡品質會越來越好，成本也會也來越低，但弱網場景總會存在，如何保證服務的穩定可用依然是挑戰。一體化會弱化開發對網絡的感覺，提供新的網絡使用方式。
-
元件分治：
在閑魚的業務中，複雜頁面是始終要考慮的問題。在前面的設計中，我們對此做了預留( Converter 部分)，但前後一體化的元件該怎麼抽象，又如何組合複用，我們還在探索中。
We are hiring
淘系技術部依托淘系豐富的業務形态和海量的使用者，我們持續以技術驅動産品和商業創新，不斷探索和衍生颠覆型網際網路新技術，以更加智能、友好、普惠的科技深度重塑産業和使用者體驗，打造新商業。我們不斷吸引使用者增長、機器學習、視覺算法、音視訊通信、數字媒體、移動技術、端側智能等領域全球頂尖專業人才加入，讓科技引領面向未來的商業創新和進步。
請投遞履歷至郵箱：[email protected]
更多技術幹貨，關注「淘系技術」微信公衆号