Swift 在 GAIA 平臺雲端一體化的探索

時間 2019-11-18

原文原文鏈接

做者|姜沂（傾寒）
出品|阿里巴巴新零售淘系技術部前端

S1 階段在使用 SwiftUI 編寫集團內部使用的 SOT APP 時，有幸參與到 GAIA （FaaS）平臺雲端一體化的探索，從頭至尾實現了一套基於 Swift 語言實現的遵照 GAIA Funtion 標準的 Runtime Framework，並完成了從客戶端到後端使用統一的語言棧完成一體化鏈路的探索。java

做爲一個純 iOS Native 端開發者，對於後端的技術體感，大部分還遺留在上學期間作的論壇管理系統，加之 FaaS Serverless 等都是一些後端領域較前沿的技術點，尤爲是在後端還算是初生牛犢的 Swift 語言，期間走過無數的彎路，但也學到了不少新的知識。算法

本文是對 Swift On GAIA 的階段性總結和思考。因爲這次技術探索有較多跨端知識，做爲一個移動端工程師的視角理解可能很是片面和有誤，如讀者發現對概念有解釋不對，歡迎你們留言區多多指正。因爲在技術棧上前端生態已有較多探索， Native 端上的探索和技術儲備落後與前端，有些實現會隨着雲端一體化得探索而改變，並非一個已經完備的解決方案，歡迎各位開發愛好者積極討論，造福生態。數據庫

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

概念性介紹

Serverless小程序

Serverless 起始是一個比較早的名詞，早到 2012年，彼時的我纔剛背起小書包走進大學裏，可是早期的理論基礎已經被提出。swift

隨着 2014年 AWS 的 Lambda 產品出現， Serverless 爲雲中的應用提供了一種全新的架構體系， Serverless 開始大火，以後各大雲計算廠商的加入，Google Cloud Functions, Azure Funcions, IBM OpenWhisk Aliyun 以及其餘國內的雲計算廠商，如華爲雲，騰訊雲，百度雲，短短數年時間 Serverless產品已遍地開花。後端

隨着容器技術，IoT，5G，技術的快速發展，技術上對去中心化，輕量虛擬化，細粒度計算等技術需求愈發強烈，而 Serverless 必將借勢迅速發展，對未來的富客戶端的研發模式的改變，則須要咱們這些技術人持續的去探索和創造了。api

咱們在理解 Serverless 的過程當中先來看一看雲服務的進化史,雲計算經歷了物理機房 -> IaaS -> PaaS -> SaaS -> FaaS/BaaS 。服務器

▐ IaaS

IaaS（Infrastructure as a Service）基礎設施即服務。指把 IT 基礎設施做爲一種服務經過網絡對外提供。在這種服務模型中，用戶不用本身構建一個數據中心，而是經過租用的方式來使用基礎設施服務，包括服務器、存儲和網絡等。在這層公司一般購買的是存儲，網絡的基礎服務。

▐ PaaS

PaaS(Platform as a Service) 平臺即服務，服務商提供基礎設施底層服務，提供操做系統（Windows，Linux）、數據庫服務器、Web服務器、負載均衡器和其餘中間件，相對於 Iaas 客戶僅僅須要本身控制上層的應用程序部署與應用託管的環境。一般在這層用戶通常購買的是操做系統。

▐ SaaS

SaaS(Software as a Service) 軟件即服務，SaaS 是一種經過 Internet 提供軟件的模式，用戶不用再購買軟件，而改用向提供商租用基於 Web 的軟件，來管理企業經營活動，且無需對軟件進行維護，服務提供商會全權管理和維護軟件，一般這些經常使用的軟件有數據庫，網絡服務，等。

能夠經過 Microsoft Azure 服務的一張圖來直觀感覺下

▐ FaaS

FaaS(Function as a service) 函數即服務,服務商提供一個平臺，容許客戶開發、運行和管理應用程序功能，而無需構建和維護基礎架構。按照此模型構建應用程序是實現「無服務器」體系結構的一種方式，一般在構建微服務應用程序時使用。

使用 FaaS 構建的軟件服務，開發者對底層的硬件平臺，操做系統平臺，軟件平臺，愈加的透明，開發者只需關注核心的函數（功能實現）便可完成本身所須要的事，內部的部署，運維，彈性，都不須要開發者關心。

FaaS 主要有如下的優勢：

低成本
快速擴容
更簡單的管理
綠色計算

目前國內外雲計算廠家基本都支持了 FaaS 的服務。

GAIA

GAIA是什麼？

按照官方文檔空濛團隊的介紹 GAIA是淘寶新一代雲端一體化輕量級研發平臺詳細的可參考「一次編碼、處處運行」，淘寶雲端一體化探索

GAIA解決的問題：

應用」承載多業務服務，並與基礎設施依賴緊密耦合，「應用」負重前行。

應用的交付流程成本高。

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

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

GAIA 平臺大大縮短了後端的研發鏈路，提升了交付成本，屏蔽了運維細節，這對於一個跨棧的開發者也能簡單理解。

GAIA容器架構

看過 GAIA 的概念，有必要簡單的瞭解一下 GAIA 容器架構。

圖中右側部分，紅色的 Function是真正的業務代碼，能夠以一個很是輕量，以函數級別交付，被 Function Framework 加載，並按照規範的生命週期管理函數的生命週期、健康檢查、業務調用等，經過RPC 與 SideCar 通訊，SideCar Container 負責服務發現，流量管控，Function Event，這部分能夠理解爲規範，與語言無關，實現一套便可。

GAIA 容器定義

GAIA 做爲一個 FaaS 架構，有不少事情須要考慮，如服務發現，日誌監控，運維管理，通訊規則等，但這些都是內部實現的細節，是不須要業務方來了解的，這裏也就不作多贅述。

Swift On GAIA

做爲一個端上開發者，恰逢使用 SwiftUI 構建 SOT APP 移動版，在知足需求的同時，有探索新技術。

可是做爲一款數據大盤的 APP，數據從哪裏來？從後端數據庫，因爲以前從未有過移動端APP，後端同窗並未對外提供 MTOP 的接口供移動端使用，瞭解到能夠在 FaaS 平臺調用已有的 HSF 服務，返回領域內的模型，GAIA 平臺能夠對外發布爲 MTOP 接口，恰好知足需求。

前期的調研中，發現 GAIA 的平臺語言棧選擇了後端的王牌語言 Java，Function Runtime Framework 最先版本只支持Java，後期隨着前端棧的探索和閒魚團隊的 Flutter 探索，目前平臺已經支持 Dart Runtime, Node.js Runtime。

做爲一個 iOS Native 開發者，沒有本身熟悉的語言怎麼辦？Swift 於 2019年 WWDC 宣佈發佈 5.x 版本，Swift5.x 版本 ABI 穩定，標誌着 Swift 正式進入成熟語言行列，加上 Swift 誕生之初就是一門跨平臺的語言，而且也有開源的 Server side workgroup推動着 Swift 在後端領域的探索，也涌現出一些知名的庫 Kitura Vapor Perfect Zewo。

因而咱們嘗試用 Swift 構建一套 Function Runtime Framework，先來了解下 Runtime Framework 是爲了完成什麼？

Swift Runtime Framework 須要完成以下操做

Swift 運行時初始化。
日誌監控
通訊協議
集團已有中間件調用
Function 調度
發佈系統構建

在後端部署的服務都是可彈性的，GAIA 也不例外，Swift Function Runtime， Swift Function 交付都是製做成 Docker Image 統一交付。簡化如圖所示。

Swift 運行時構建

Swift 語言是跨平臺的，包括 Apple‘s OS， Linux Windows Android，RespibarryPi，可是官方放出的 ToolChain 只有 Ubuntu，其餘都須要從源碼手動構建，集團提供的雲 Server 是 CentOS，須要手動構建並製做 Docker Image。

日誌監控

做爲一個後端系統，不可能像移動端程序次次經過斷點調試，排查線上問題時，日誌規範很是重要，這裏按照 GAIA 的 Function 規範實現便可。

通訊協議

因爲業務 Function 都是經過容器交付，業務方實現的部分都是一個簡單的函數，這個函數被調用時是經過 SideCar 進程經過 RPC 調用而來的，所以須要實現GRPC 通訊，這裏使用的是 Google 開源的 Protobuffer 和 GRPC 的 Swift 版本實現。

因爲 Swift 語言一般的開發者都是 Apple 平臺的開發者，使用的開發工具都是 Xcode，可是爲了交付到後端，只能使用 Swift Package Manager 交付，開發使用 Xcode 或者 Visual Studio Code Remote 開發。

集團已有服務通訊

任何新平臺，新架構的出現都須要一個漸進式遷移舊技術的能力，GAIA 也不例外，GAIA 背後屏蔽了不少集團已有中間件的能力和生態，在阿里的語言棧是 Java ，可是對於一個新的語言棧則是困擾，由於原有的的語言棧並非語言中立，平臺中立的，如 HSF Tair EagleEye 等。

但幸虧的是目前這些中間件生態還有一套 CPP 版本的 SDK 維護，Swift 自然就是和 C 混編的，C 能夠調用 CPP，目前調用其餘中間件服務經過 Swift 和 CPP 混編實現。

一個典型的業務交互時序圖以下：

正式上線

Funtion Runtime Framework 完成後，就能夠經過 GAIA 的發佈平臺建立函數，編寫本身的業務代碼裏，這裏就不分享如何操做了，直接上示例代碼和效果圖。

//  File.swift
//
//
//  Created by nero on 2019/9/12.
//

import GAIA
import HSF
import Foundation

struct EventResult: GAIA.EventResult {

    var isSuccess: Bool  = true

    var code: String = "200"

    var message: String = "SOT Test"

    var payLoad: TestContent
    init(payLoad: String) {
        self.payLoad = TestContent(content: payLoad)
    }
}

struct MtopUserQuery: Codable {
    let pageNo: String 
    let pageSize: String
    let appName: String
}

struct PageQuery: HSFModel {
    let javaClassName = "com.xx.PageQuery"
    let request: PageQueryRequest
    let pageNo: Int
    let pageSize: Int
    init(pageNo: Int, pageSize: Int, appName: String) {
        self.pageNo = pageNo
        self.pageSize = pageSize
        self.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: ConsumerService
    func 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 在雲端一體化的探索一期圓滿結束，一個 iOSer 也能夠同時開發先後端程序，這對研發模式也創造了一些新的可能，最近也屢次聽大佬們的一些分享，如閒魚團隊使用 Dart+flutter 在雲端一體化研發模式的探索，有一些不成熟的視角，暫且記錄一下。

技術棧平常研發調試的困難？

在研發模式交流和一些實際探索的體驗中發現，端上的研發風格和後端的研發風格差別較大，端上的同窗傾向於打斷調試，實時預覽效果，背後的原力是由於端上要更快的交付，端上的環境更容易構建，可是後端的同窗更傾向於日誌系統，鏈路追蹤。但其實不管是斷點調試仍是日誌系統，本質上須要一個有效排查問題的系統，否則在實際開發中，因爲跨技術棧會讓調試的成本變大，系統一旦複雜起來反而會拖慢效率。

工程結構的升級

在 Swift On GAIA 的實際體驗中，使用的開發工具，應用交付方式，都不統一，各個語言棧都有本身的研發風格，工具鏈支撐，研發模式和工具鏈體系也須要對應的升級，避免鏈路過長，工具鏈割裂。

領域的邊界是什麼？

目前閒魚的大佬在 GAIA 完成了 Dart Function 環境的支持，可讓客戶端同窗向前更進一步，本身完成後端的能力，實現無上下游依賴的業務閉環，而且屏蔽後端的細節。

不過在一些細節上的分析，發現不一樣的業務場景遇見的挑戰仍是不一樣，若是一個 Function 只使用已有的基礎設施，如接口聚合，簡單的邏輯處理是比較合適的，但若是這個業務連數據的生產者也由客戶端的同窗來寫複雜度就變大了，由於跨端的思惟方式不一樣，大前端同窗可能不會思考更多存儲的設計，將來在業務擴大時就可能不容易擴展。

那麼在實現業務的的時候，如何界定一些領域的邊界是一個值得思考的點，須要一些方法論或者指導原則，來幫助 Function 同窗決策這款技術選型的可擴展性。

人員組織架構升級

若是研發模式大升級，傳統的後端 API 發佈，各端接入的人員上下游關係勢必會發聲比較大的變化，如何找到人員組織的方式也是須要從新定義和調整的。往小了說乾的活分配不同了，往大了說組織架構也須要適應時代調整。

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

目先後端大部分的語言棧都是 Java ，其中集團部分團隊使用 CPP，涌現了多個 CPP 版本的 SDK 用來調用 Java 的生態框架，如 HSF CPP 版本 Tail CPP 版本，隨着 GAIA 平臺接入語言棧的變多，加上富客戶端 Swift/Kotlin/Java/Javascript，要不要作一些相似 Protobuffer 這種經過中立的 DSL 定義解決語言差別性。

這裏做者是不太承認一套語言解決全部環境的，一是目前手淘的生態分爲 Native+Weex+H5+小程序，自己就難以聚合，二是單拿 iOS 端，在蘋果限制下的跨平臺老是有部分取捨的，不能解決所有問題。

領域特定/通用

將來 Swift 在 FaaS 平臺上是朝着解決通用能力去前進仍是構建領域模型，構建領域特徵能夠構建領域生態的 API，定義業務的模式，相似星環的風格，若是構建的是通用能力，解法多是另一種。

One More Thing

淘寶基礎平臺團隊正在進行社招招聘，崗位有 iOS Android 客戶端開發工程師、Java 研發工程師、C/C++ 研發工程師、前端開發工程師、算法工程師。

歡迎投遞簡歷至：junzhan.yzw@taobao.com

點此觀看團隊介紹視頻。

參考
一、當咱們聊Serverless時你應該知道這些

二、歷時五天用 SwiftUI 作了一款 APP，阿里工程師如何作的？

三、What is Azure

四、基礎設施即服務wiki百科

五、IaaS，PaaS，SaaS 的區別