閒魚基於Dart生態的FaaS前端一體化建設

背景

隨著Flutter對現有業務的不斷參透，閒魚Serverless基建的重心也傾向了dart生態，先是將dart容器打包到伺服器上，實現dart程式語言的統一，在統一的容器之上實現程式設計框架一體化(nexus、story)，以及後端領域服務一體化。基於dart生態下，前端的FaaS在研發交付其實並不高效，研發階段主要面臨的問題是：
程式語言不統一：程式語言本身雖然不是最大的障礙，但這也確實給前端開發者增加不少門檻，而且更重要的是語言背後的生態、環境與體系更是一道高高的牆。
工程割裂與背後環境複雜：端側一個工程，FaaS側也有一個獨立的工程，它們背後都有著自己的一套構建、除錯、整合/釋出的工具鏈；除此之外FaaS還有自己配套的環境、runtime、框架作為支撐。開發者面對這樣複雜的FaaS研發環境與雙重的研發工作流是無法做到高效交付的。

程式語言一體化

Typescript作為Javascript的超集，彌補了Javascript的靜態型別檢查，同時擴充套件了很多OOP的語法特性，使得TS跟dart在語法特性上有非常多相似的地方，為後面的轉換提供了可能與便利。要實現語言層面轉換背後都會有一個小型的編譯器在支撐著，不過幸運的是Typescript官方已經提供語法解析器，透過它我們很容易就拿到一份可靠的AST，所以我們只需要實現一個dart generator就行了。生成器大致可以分為四個層面的工作：

• 基礎語法轉換

• 原生方法差異轉換

• 業務框架橋接

• 依賴庫與標頭檔案橋接

基礎語法轉換

這部分很好理解，就是最基本的語法層面轉換，用個最簡單的例子看下。

原生方法差異轉換

兩種語言在內建原生方法上也有很大區別，舉個例子：可以看到下面陣列的例項方法在兩種語言體系上是不一致的，除了陣列插入還有很多很多原生方法是不一致的。當然也沒太必要被這個難以想象的數量嚇到，大多數情況：90%的場景只會用到那10%的方法，完成了10%的轉換就能cover到90%的場景。

// ts
list2.push(10)

// dart
list2.add(10)

要實現系統方法的差異轉化首先要識別出該方法是來自於哪個類，比如說 list2.push(10) 我不可能只檢查 push ，因為隨便一個類/物件都可以實現一個push方法。我們必須識別出 list2.push 的 push 屬於 Array.push，別忘了整個typescript編譯器中佔比最大的型別檢查器 ts.TypeChecker ，它可以很好的幫我們解決這個問題。大致思路如下：

業務框架橋接

在完成上面兩塊能力轉換後，常規裸寫一段邏輯進行轉換問題是不大的；但業務是不可能裸寫，業務需要框架，需要藉助框架進行通訊、與容器打交道。需要藉助框架進行業務抽象，更好的組織、管理業務邏輯。我們來看個例子：

DartMtopResult<String> result = awaitHsfServices.request(moduleName, parameter);

上面的這段程式碼是用於在dart側進行內部服務請求的，從程式碼表明我們可以獲取到三部分資訊：

1. 有一個HsfServices的類

2. HsfServices有一個同步返回結果的request方法，接收兩個引數

3. 最終返回DartMtopResult的資料結構

我們再翻一下 request 的實現與 DartMtopResult 的申明：

// DartMtopResult.dart
classDartMtopResult<T> implements xxxx {
  T data;
bool success;
String errMsg;
String errCode;

// more code hidden
}

// HsfServices.dart
classHsfServices{
// more code hidden
staticFuture<DartMtopResult<String>> request(String moduletName, String parameter) async{
// more code hidden
}
// more code hidden
}

就看這麼多足夠了，打個比方如果我希望在typescript側編寫一個能用 HsfServices.request 發請求的ts程式碼且不報錯，那應該怎麼做呢？像下面這樣申明一個：

// HsfServices.d.ts
export declare classHsfServices{
static request(moduletName: string, parameter: string): Promise<DartMtopResult<string>>;
}
// DartMtopResult.d.ts
export declare classDartMtopResult<T> {
  data: T;
  success: boolean;
  errMsg: string;
  errCode: string;
}

// business.ts
import{HsfServices} from"HsfServices.d.ts"
import{DartMtopResult} from"DartMtopResult.d.ts"
const result: DartMtopResult<string>= awaitHsfServices.request<DartMtopResult<string>>('recycleGet', parameter);

非常簡單就能讓業務邏輯正常寫下去並且不報錯。但你肯定會說這樣的程式碼也沒法執行起來，是的，但我並不需要上面程式碼執行起來，我需要的是將它轉成dart，並能在dart runtime中執行就可以了。大致的橋接思路如下：

依賴庫與標頭檔案橋接

// business.tsimport {HsfServices} from "@ali/faas-hsf"import {DartMtopResult} from "@ali/faas-mtop-result"const result: DartMtopResult<string> = await HsfServices.request<DartMtopResult<string>>('recycleGet', parameter);

// business.dartimport 'package:hsf_services/hsf_services.dart';import 'package:dart_mtop_result/dart_mtop_result.dart';DartMtopResult<String> result = await HsfServices.request(moduleName, parameter);

@ali/faas-hsf
|--lib/
|--faas.yaml
|--package.json

// faas.yaml
faas_pub:
    # 對映的dart側依賴包
    hsf_services: ^1.1.7
    # 對映引入標頭檔案
    index: hsf_services.dart

研發過程中再透過工程腳手架來自動完成這之間的對映關係的提取：標頭檔案對映與依賴包對映。標頭檔案對映最終會交給轉換器，而依賴包對映會交給背後自動維護著的dart工程（後面會提到背後自動維護的dart工程）。大概的思路如下圖所示：

程式語言一體化只是整個FaaS一體化研發的第一步，也只有統一了程式語言之後，背後的生態(npm)、工具鏈(build)與工程才可能一體化。我們看下現狀：開發者面對的是兩個割裂的工程，兩套不同的環境、生態。這正如文章一開始所說的：程式語言本身不是最大的障礙，但語言背後的環境與生態卻是一道高高的牆。在我們統一程式語言之後，研發工程一體化就變得可行了。

正如上圖所示，FaaS工程本身的複雜在於整個工程需要執行在一個本地容器之中，因為容器要為工程提供runtime、相應的工具鏈、框架依賴等能力。所以本地容器本身是必不可少的，我們能做的只是儘可能讓開發者無感容器的存在；除此之外還要對兩個工程的邏輯做一定的融合，大致可以抽象成四部分工作：

├── faas_pub.yaml├── faas_src│   └── Home│       └── index.ts├── package.json├── src│   ├── components│   └── pages│       └── Home│           ├── index.css│           └── index.js└── README.md

使端側腳手架全權接管FaaS側的工程初始化、熱部署、除錯資訊，暴露出來給開發者的只有一套工具鏈，只有兩個指令 init  dev ，讓開發者0門檻初始化出一套統一而可靠環境的FaaS工程。

對接編譯器進行研發實時編譯

這部分主要負責對接轉換器實時將ts編譯成dart，並同步到黑盒中的FaaS工程。在實時編譯過程有兩部分內容：一部分是純ts邏輯編譯成dart，另一部分是依賴包的同步安裝，其中 faas_pub.yaml 由腳手架透過探測端側package.json中的faas依賴包來進行提取生成的，並不需要人工維護。

從儲存每一個改動到在瀏覽器上能成功發起一個faas函式請求，這之間大致經過這些步驟：監控改動、編譯程式碼、產物部署的流，由統一的端側腳手架進行串聯起來。

經過程式語言的一體化後，我們不僅為開發者提供一種熟悉的技術棧，也為後面工程一體化提供了可能性；再經過工程一體化後，我們為開發者解決了工程割裂，解決背後複雜的FaaS本地執行環境，帶來與原研發模式基本一致的研發體驗。