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

稿件來源： 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/，如需轉載，請註明出處，否則將追究法律責任。