作者|姜沂（傾寒）
出品|阿里巴巴新零售淘系技術(shù)部

S1 階段在使用 SwiftUI 編寫集團內(nèi)部使用的 SOT APP 時，有幸參與到 GAIA （FaaS）平臺云端一體化的探索，從頭到尾實現(xiàn)了一套基于 Swift 語言實現(xiàn)的遵守 GAIA Funtion 標(biāo)準的 Runtime Framework，并完成了從客戶端到后端使用統(tǒng)一的語言棧完成一體化鏈路的探索。

作為一個純 iOS Native 端開發(fā)者，對于后端的技術(shù)體感，大部分還遺留在上學(xué)期間做的論壇管理系統(tǒng)，加之 FaaS Serverless 等都是一些后端領(lǐng)域較前沿的技術(shù)點，尤其是在后端還算是初生牛犢的 Swift 語言，期間走過無數(shù)的彎路，但也學(xué)到了很多新的知識。

本文是對 Swift On GAIA 的階段性總結(jié)和思考。由于此次技術(shù)探索有較多跨端知識，作為一個移動端工程師的視角理解可能非常片面和有誤，如讀者發(fā)現(xiàn)對概念有解釋不對，歡迎大家留言區(qū)多多指正。由于在技術(shù)棧上前端生態(tài)已有較多探索， Native 端上的探索和技術(shù)儲備落后與前端，有些實現(xiàn)會隨著云端一體化得探索而改變，并不是一個已經(jīng)完備的解決方案，歡迎各位開發(fā)愛好者積極討論，造福生態(tài)。

PS：文末附郵箱，感興趣者可進行深入交流。

概念性介紹

Serverless

Serverless 起始是一個比較早的名詞，早到 2012年，彼時的我才剛背起小書包走進大學(xué)里，但是早期的理論基礎(chǔ)已經(jīng)被提出。

隨著 2014年 AWS 的 Lambda 產(chǎn)品出現(xiàn)， Serverless 為云中的應(yīng)用提供了一種全新的架構(gòu)體系， Serverless 開始大火，之后各大云計算廠商的加入，Google Cloud Functions, Azure Funcions, IBM OpenWhisk Aliyun 以及其他國內(nèi)的云計算廠商，如 華為云，騰訊云，百度云，短短數(shù)年時間 Serverless產(chǎn)品已遍地開花。

隨著容器技術(shù)，IoT，5G，技術(shù)的快速發(fā)展， 技術(shù)上對去中心化，輕量虛擬化，細粒度計算等技術(shù)需求愈發(fā)強烈，而 Serverless 必將借勢迅速發(fā)展，對將來的富客戶端的研發(fā)模式的改變，則需要我們這些技術(shù)人持續(xù)的去探索和創(chuàng)造了。

我們在理解 Serverless 的過程中先來看一看云服務(wù)的進化史,云計算經(jīng)歷了物理機房 -> IaaS -> PaaS -> SaaS -> FaaS/BaaS 。

? IaaS

IaaS（Infrastructure as a Service）基礎(chǔ)設(shè)施即服務(wù)。指把 IT 基礎(chǔ)設(shè)施作為一種服務(wù)通過網(wǎng)絡(luò)對外提供。在這種服務(wù)模型中，用戶不用自己構(gòu)建一個數(shù)據(jù)中心，而是通過租用的方式來使用基礎(chǔ)設(shè)施服務(wù)，包括服務(wù)器、存儲和網(wǎng)絡(luò)等。在這層公司通常購買的是存儲，網(wǎng)絡(luò)的基礎(chǔ)服務(wù)。

? PaaS

PaaS(Platform as a Service) 平臺即服務(wù)，服務(wù)商提供基礎(chǔ)設(shè)施底層服務(wù)，提供操作系統(tǒng)（Windows，Linux）、數(shù)據(jù)庫服務(wù)器、Web服務(wù)器、負載均衡器和其他中間件，相對于 Iaas 客戶僅僅需要自己控制上層的應(yīng)用程序部署與應(yīng)用托管的環(huán)境。通常在這層用戶一般購買的是操作系統(tǒng)。

? SaaS

SaaS(Software as a Service) 軟件即服務(wù)，SaaS 是一種通過 Internet 提供軟件的模式，用戶不用再購買軟件，而改用向提供商租用基于 Web 的軟件，來管理企業(yè)經(jīng)營活動，且無需對軟件進行維護，服務(wù)提供商會全權(quán)管理和維護軟件，通常這些常用的軟件有 數(shù)據(jù)庫，網(wǎng)絡(luò)服務(wù)，等。

可以通過 Microsoft Azure 服務(wù)的一張圖來直觀感受下

? FaaS

FaaS(Function as a service) 函數(shù)即服務(wù),服務(wù)商提供一個平臺，允許客戶開發(fā)、運行和管理應(yīng)用程序功能，而無需構(gòu)建和維護基礎(chǔ)架構(gòu)。按照此模型構(gòu)建應(yīng)用程序是實現(xiàn)“無服務(wù)器”體系結(jié)構(gòu)的一種方式，通常在構(gòu)建微服務(wù)應(yīng)用程序時使用。

使用 FaaS 構(gòu)建的軟件服務(wù)，開發(fā)者對底層的硬件平臺，操作系統(tǒng)平臺，軟件平臺，越發(fā)的透明，開發(fā)者只需關(guān)注核心的函數(shù)（功能實現(xiàn)）即可完成自己所需要的事，內(nèi)部的部署，運維，彈性，都不需要開發(fā)者關(guān)心。

FaaS 主要有以下的優(yōu)點：

低成本

快速擴容

更簡單的管理

綠色計算

目前國內(nèi)外云計算廠家基本都支持了 FaaS 的服務(wù)。

GAIA

GAIA是什么？

按照官方文檔 空蒙 團隊的介紹 GAIA是淘寶新一代云端一體化輕量級研發(fā)平臺 詳細的可參考 “一次編碼、到處運行”，淘寶云端一體化探索

GAIA解決的問題：

應(yīng)用”承載多業(yè)務(wù)服務(wù)，并與基礎(chǔ)設(shè)施依賴緊密耦合，“應(yīng)用”負重前行。

應(yīng)用的交付流程成本高。

以上的介紹考慮的是后端技術(shù)棧的問題，下面來看一下客戶端的視角。

作為 iOS Native 開發(fā)者看到更有體感的切入點是所見即所得（What You See Is What You Get ），function版本化交付運行。

GAIA 平臺大大縮短了后端的研發(fā)鏈路，提高了交付成本，屏蔽了運維細節(jié)，這對于一個跨棧的開發(fā)者也能簡單理解。

GAIA容器架構(gòu)

看過 GAIA 的概念，有必要簡單的了解一下 GAIA 容器架構(gòu)。

圖中右側(cè)部分，紅色的 Function是真正的業(yè)務(wù)代碼，可以以一個非常輕量，以函數(shù)級別交付，被 Function Framework 加載，并按照規(guī)范的生命周期管理函數(shù)的生命周期、健康檢查、業(yè)務(wù)調(diào)用等，通過RPC 與 SideCar 通信，SideCar Container 負責(zé)服務(wù)發(fā)現(xiàn)，流量管控，Function Event，這部分可以理解為規(guī)范，與語言無關(guān)，實現(xiàn)一套即可。

• GAIA 容器定義

GAIA 作為一個 FaaS 架構(gòu)，有很多事情需要考慮，如服務(wù)發(fā)現(xiàn)，日志監(jiān)控，運維管理，通信規(guī)則等，但這些都是內(nèi)部實現(xiàn)的細節(jié)，是不需要業(yè)務(wù)方來了解的，這里也就不做多贅述。

Swift On GAIA

作為一個端上開發(fā)者，恰逢使用 SwiftUI 構(gòu)建 SOT APP 移動版，在滿足需求的同時，有探索新技術(shù)。

但是作為一款數(shù)據(jù)大盤的 APP，數(shù)據(jù)從哪里來？從后端數(shù)據(jù)庫，由于之前從未有過移動端APP，后端同學(xué)并未對外提供 MTOP 的接口供移動端使用，了解到可以在 FaaS 平臺調(diào)用已有的 HSF 服務(wù)，返回領(lǐng)域內(nèi)的模型，GAIA 平臺可以對外發(fā)布為 MTOP 接口，剛好滿足需求。

前期的調(diào)研中，發(fā)現(xiàn) GAIA 的平臺語言棧選擇了后端的王牌語言 Java，Function Runtime Framework 最早版本只支持Java，后期隨著前端棧的探索和 閑魚團隊的 Flutter 探索，目前平臺已經(jīng)支持 Dart Runtime, Node.js Runtime。

作為一個 iOS Native 開發(fā)者，沒有自己熟悉的語言怎么辦？Swift 于 2019年 WWDC 宣布 發(fā)布 5.x 版本，Swift5.x 版本 ABI 穩(wěn)定，標(biāo)志著 Swift 正式進入成熟語言行列，加上 Swift 誕生之初就是一門跨平臺的語言，并且也有開源的 Server side workgroup推進著 Swift 在后端領(lǐng)域的探索，也涌現(xiàn)出一些 知名的庫 Kitura Vapor Perfect Zewo。

于是我們嘗試用 Swift 構(gòu)建一套 Function Runtime Framework，先來了解下 Runtime Framework 是為了完成什么？

Swift Runtime Framework 需要完成如下操作

Swift 運行時初始化。

日志監(jiān)控

通信協(xié)議

集團已有中間件調(diào)用

Function 調(diào)度

發(fā)布系統(tǒng)構(gòu)建

在后端部署的服務(wù)都是可彈性的，GAIA 也不例外，Swift Function Runtime， Swift Function 交付都是制作成 Docker Image 統(tǒng)一交付。簡化如圖所示。

• Swift 運行時構(gòu)建

Swift 語言是跨平臺的，包括 Apple‘s OS， Linux Windows Android，RespibarryPi，但是官方放出的 ToolChain 只有 Ubuntu，其他都需要從源碼手動構(gòu)建， 集團提供的云 Server 是 CentOS，需要手動構(gòu)建并制作 Docker Image。

• 日志監(jiān)控

作為一個后端系統(tǒng)，不可能像移動端程序次次通過斷點調(diào)試，排查線上問題時，日志規(guī)范非常重要，這里按照 GAIA 的 Function 規(guī)范實現(xiàn)即可。

• 通信協(xié)議

由于業(yè)務(wù) Function 都是通過容器交付，業(yè)務(wù)方實現(xiàn)的部分都是一個簡單的函數(shù)，這個函數(shù)被調(diào)用時是通過 SideCar 進程通過 RPC 調(diào)用而來的，因此需要實現(xiàn)GRPC 通信，這里使用的是 Google 開源的 Protobuffer 和 GRPC 的 Swift 版本實現(xiàn)。

由于 Swift 語言通常的開發(fā)者都是 Apple 平臺的開發(fā)者，使用的開發(fā)工具都是 Xcode，但是為了交付到后端，只能使用 Swift Package Manager 交付，開發(fā)使用 Xcode 或者 Visual Studio Code Remote 開發(fā)。

• 集團已有服務(wù)通信

任何新平臺，新架構(gòu)的出現(xiàn)都需要一個漸進式遷移舊技術(shù)的能力，GAIA 也不例外，GAIA 背后屏蔽了很多集團已有中間件的能力和生態(tài)，在阿里的語言棧是 Java ，但是對于一個新的語言棧則是困擾，因為原有的的語言棧并不是語言中立，平臺中立的，如 HSF Tair EagleEye 等。

但幸好的是目前這些中間件生態(tài)還有一套 CPP 版本的 SDK 維護，Swift 天然就是和 C 混編的，C 可以調(diào)用 CPP，目前調(diào)用其他中間件服務(wù)通過 Swift 和 CPP 混編實現(xiàn)。

一個典型的業(yè)務(wù)交互時序圖如下：

正式上線

Funtion Runtime Framework 完成后，就可以通過 GAIA 的發(fā)布平臺創(chuàng)建函數(shù)，編寫自己的業(yè)務(wù)代碼里，這里就不分享如何操作了，直接上示例代碼和效果圖。

// File.swift // // // Created by nero on 2019/9/12. //import GAIA import HSF import Foundationstruct EventResult: GAIA.EventResult {var isSuccess: Bool = truevar code: String = "200"var message: String = "SOT Test"var payLoad: TestContentinit(payLoad: String) {self.payLoad = TestContent(content: payLoad)} }struct MtopUserQuery: Codable {let pageNo: String let pageSize: Stringlet appName: String }struct PageQuery: HSFModel {let javaClassName = "com.xx.PageQuery"let request: PageQueryRequestlet pageNo: Intlet pageSize: Intinit(pageNo: Int, pageSize: Int, appName: String) {self.pageNo = pageNoself.pageSize = pageSizeself.request = PageQueryRequest(appName: appName)}let apiConsumer = PageQueryAPIConsumer() }struct PageQueryAPIConsumer: HSFModel {let javaClassName = "com.xx.ApiConsumer"let clientName = "SOT-APP"let token = "xxx"}struct PageQueryRequest: HSFModel {let javaClassName = "com.xx.AppQueryRequest"let appName: String }class Handler: GAIA.FunctionHandler {init(){}var consume: ConsumerServicefunc handle(when event: Event, context: FunctionContext) throws -> AnyEventResult {switch event.payLoad {case .mtop(body: let mtopRequest):do {let query = try JSONDecoder().decode(MtopUserQuery.self, from: mtopRequest.data)let sotQuery = PageQuery(pageNo: query.pageNo, pageSize: query.pageSize, appName: query.appName)let jsonStr = try consume.invoke(methodName: "queryApp", args: [sotQuery])return EventResult(payLoad: jsonStr).erasedEventResult} catch {}default:break;}return EmptyEventResult().erasedEventResult}func active(when context: FunctionContext) {}func destroy(when context: FunctionContext) {}func isHealth(when context: FunctionContext) -> Bool {return true} }

GAIA 云端一體化的思考

Swift On GAIA 在云端一體化的探索一期圓滿結(jié)束，一個 iOSer 也可以同時開發(fā)前后端程序，這對研發(fā)模式也創(chuàng)造了一些新的可能，最近也多次聽大佬們的一些分享，如閑魚團隊使用 Dart+flutter 在云端一體化研發(fā)模式的探索，有一些不成熟的視角，暫且記錄一下。

技術(shù)棧日常研發(fā)調(diào)試的困難？

在研發(fā)模式交流和一些實際探索的體驗中發(fā)現(xiàn)，端上的研發(fā)風(fēng)格和后端的研發(fā)風(fēng)格差異較大，端上的同學(xué)傾向于打斷調(diào)試，實時預(yù)覽效果，背后的原力是因為端上要更快的交付，端上的環(huán)境更容易構(gòu)建，但是后端的同學(xué)更傾向于日志系統(tǒng)，鏈路追蹤。但其實無論是斷點調(diào)試還是日志系統(tǒng)，本質(zhì)上需要一個有效排查問題的系統(tǒng)，不然在實際開發(fā)中，由于跨技術(shù)棧會讓調(diào)試的成本變大， 系統(tǒng)一旦復(fù)雜起來反而會拖慢效率。

工程結(jié)構(gòu)的升級

在 Swift On GAIA 的實際體驗中，使用的開發(fā)工具，應(yīng)用交付方式，都不統(tǒng)一，各個語言棧都有自己的研發(fā)風(fēng)格，工具鏈支撐，研發(fā)模式和工具鏈體系也需要對應(yīng)的升級，避免鏈路過長，工具鏈割裂。

領(lǐng)域的邊界是什么？

目前閑魚的大佬在 GAIA 完成了 Dart Function 環(huán)境的支持，可以讓客戶端同學(xué)向前更進一步，自己完成后端的能力，實現(xiàn)無上下游依賴的業(yè)務(wù)閉環(huán)，并且屏蔽后端的細節(jié)。

不過在一些細節(jié)上的分析，發(fā)現(xiàn)不同的業(yè)務(wù)場景碰見的挑戰(zhàn)還是不同，如果一個 Function 只使用已有的基礎(chǔ)設(shè)施，如接口聚合，簡單的邏輯處理是比較合適的，但如果這個業(yè)務(wù)連數(shù)據(jù)的生產(chǎn)者也由客戶端的同學(xué)來寫復(fù)雜度就變大了，因為跨端的思維方式不同，大前端同學(xué)可能不會思考更多存儲的設(shè)計，未來在業(yè)務(wù)擴大時就可能不容易擴展。

那么在實現(xiàn)業(yè)務(wù)的的時候，如何界定一些領(lǐng)域的邊界是一個值得思考的點，需要一些方法論或者指導(dǎo)原則，來幫助 Function 同學(xué)決策這款技術(shù)選型的可擴展性。

人員組織架構(gòu)升級

如果研發(fā)模式大升級，傳統(tǒng)的后端 API 發(fā)布，各端接入的人員上下游關(guān)系勢必會發(fā)聲比較大的變化，如何找到人員組織的方式也是需要重新定義和調(diào)整的。往小了說干的活分配不一樣了，往大了說 組織架構(gòu)也需要適應(yīng)時代調(diào)整。

中間件語言中立，平臺中立

目前后端大部分的語言棧都是 Java ，其中集團部分團隊使用 CPP，涌現(xiàn)了多個 CPP 版本的 SDK 用來調(diào)用 Java 的生態(tài)框架，如 HSF CPP 版本 Tail CPP 版本 ，隨著 GAIA 平臺接入語言棧的變多，加上富客戶端 Swift/Kotlin/Java/Javascript，要不要做一些類似 Protobuffer 這種通過中立的 DSL 定義解決語言差異性。

這里作者是不太認可一套語言解決所有環(huán)境的，一是目前手淘的生態(tài)分為 Native+Weex+H5+小程序，本身就難以聚合，二是單拿 iOS 端，在蘋果限制下的跨平臺總是有部分取舍的，不能解決全部問題。

領(lǐng)域特定/通用

未來 Swift 在 FaaS 平臺上是朝著解決通用能力去前進還是構(gòu)建領(lǐng)域模型，構(gòu)建領(lǐng)域特征可以構(gòu)建領(lǐng)域生態(tài)的 API，定義業(yè)務(wù)的模式，類似星環(huán)的風(fēng)格，如果構(gòu)建的是通用能力，解法可能是另外一種。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的Swift 在 GAIA 平台云端一体化的探索的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。