5G時代|閒魚在Flutter&FaaS雲端一體化架構的探索實踐之路

開發者學習指南發表於2019-07-25

稿件來源: https://developer.aliyun.com/article/710460

 

導讀:

隨著無線, IoT 的發展, 5G 的到來,移動研發越發向多端化發展。傳統的基於 Native Web 服務端的開發方式研發效率低下,顯然已經無法適應發展需要。本文將會介紹閒魚近一年來在 Flutter&FaaS 一體化專案上的探索和實踐。

傳統 Native+Web+ 服務端混合開發的挑戰

我們希望探索閒魚這樣規模的獨立 APP 的高效研發架構。主要思路是圍繞 Flutter 解決多端問題,並使 Flutter FaaS 等無服務容能力打通,形成雲端一體化的研發能力,支援一雲多端的發展需要。

在某些場景已經取得效果,過程中的思考與大家交流。

跨端方案 Flutter RN 的對比與選擇

閒魚選擇 Flutter 主要是出於高效能的考慮。 Flutter 高效能主要來源於 2 個原因:

·          Dart AOT 編譯能力。

·          自建渲染引擎,不需要轉換到 Native 控制元件,避免了執行緒跳躍等問題。

更多比較:

沒有銀彈的解決方案, Flutter RN 各有優點。如何選擇因素很多,關鍵看如何取捨,舉個例子:

·          當前團隊人員以前端 JS 棧為主還是 Native 為主?如果 JS 為主,寫 RN 會更習慣。如果 Android iOS 為主,寫 Flutter 會更習慣,因為 Flutter 的研發工具和體驗與 Native 更相似。

·          動態性和複雜互動的效能,哪個更重要?動態性重要 RN 合適,效能體驗重要 Flutter 不會失望。雖然 Flutter 也有一些動態化解決方案,例如 JS 轉接 Flutter 引擎的方案, Dart 程式碼 CodePush 的方案,元件化服務端組裝方案等,但這些動態方案都沒有 RN 這樣從 JS 層解決的這麼好。

·          是否需要 IoT 等多端佈局? Flutter 在嵌入式設計上有佈局,效能有更好的表現。

Dart 作為 FaaS 層的首選語言

雲端技術棧的打通,是減少協同的不錯的解法。以往前端 Node.js 的一體化方案大家應該不會陌生,然而如果端側使用了 Flutter ,那雲側 Dart 自然是第一選擇。

FaaS 的本質是執行在雲端,那 Dart 適合用在雲 /Server 上嗎?

Dart 語言早於 Flutter ,在最初的設計上, Dart 就可以用於 Web Server Dart 具備一些服務端語言的特點:

·          強型別,可預測性

·          GC 非同步和併發

·          高效能的 JIT

·          Profiler

閒魚首先嚐試將 Dart 作為普通的 Server ,替代傳統的 Java   Server ,然後再將 Dart 容器嵌入到 FaaS 容器中。建立 Dart Server 能力是第一步,也是主要的工作量所在。

閒魚在 Dart   Server 方面的建設思路:

開發期:

·          Flutter HotReload 啟發,將 HotReload 移植到了 Server 側。

·          利用 Isolate ,在開發環境中為每個開發人員分配一個 Isolate ,解決以往的環境衝突的問題。

執行期:

·          Dart 本身是單執行緒非同步模型,併發能力需要用 Isolate 支援。

·          利用 Dart Zone 的特性,可以方便的實現呼叫鏈路的跟蹤,方便記錄 Trace 日誌。

·          利用 Dart 支援的 C++ Extension 能力,可以在 Dart 中訪問支援了 C++ 的中介軟體包。另外, Server Mesh 也是一個重要的思路,用於解耦異構語言之間的服務呼叫。

一體化的更深層思考

上述內容實現了 Flutter & Dart FaaS 的技術棧的統一,但僅技術棧統一還遠遠不夠,端、雲的同學仍然無法真正互補和一體化打通,原因在於還有更多深入問題需要考慮:

·          一體化的業務閉環紅利如何最大化?一體化不僅是效率的提升,還使一個同學可以 Cover 一個雲到端的業務,使業務閉環。

·          如何消除雲端技術壁壘?僅技術棧打通,端人員還是不會寫雲,原因在於對雲的思維模式的不理解,需要真正消除雲端的技術壁壘。

·          如何使工作總量減少 ( 1+1<2 ) ?如果一體化後把工作量壓到一個人身上,那意義不大,需要使一體化下的總工作量降低。

·          如何促進生產關係重塑? 生產關係需要適應新的生產力。

面向這些問題,閒魚的解法思路:

·          業務閉環為業務開發同學帶來更好的成長空間,可以完整和專注的思考業務。這是人上的核心動力。

·          業務閉環是業務流程沉澱的方向

·          以往的架構是雲、端分開架構的,一體化後有了更多的架構下沉空間,從而帶來了總工作量 1 1<2 的可能

·          領域下沉和工具支撐是一體化的保證

案例效果

案例一:一體化在資源均衡方面的體現。在近期的一個專案中,雲端一體化使原本 2 個月的專案時間,減少了 20 天。

案例二:一體化在業務閉環方面的體現。負責增長的一位開發同學,專注在增長業務上,在合適的情況下為合適的人投放合適的內容,以此帶來使用者的增長和活躍效果。一體化的方式下,可以統一雲、端的切面,業務研發不再受雲、端的限制。

說在最後

一體化是建設高效研發框架的方向,並不是所有場景都需要一體化的開發,但一體化的 Flutter FaaS 等技術元件,可以獨立使用,也會帶來效率提升,並且與原有的開發模式相容。從一體化的思路去建設,可以使整體架構體系更加一致,也有機會做一體的架構沉澱。未來閒魚希望在一體化上做更多嘗試和深入探索,包括一體化工具、一體化業務平臺、資料化智慧化等方向。

 



來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69926013/viewspace-2651729/,如需轉載,請註明出處,否則將追究法律責任。

相關文章