作者|姜沂（倾寒）
出品|阿里巴巴新零售淘系技术部

S1 阶段在使用 SwiftUI 编写集团内部使用的 SOT APP 时，有幸参与到 GAIA （FaaS）平台云端一体化的探索，从头到尾实现了一套基于 Swift 语言实现的遵守 GAIA Funtion 标准的 Runtime Framework，并完成了从客户端到后端使用统一的语言栈完成一体化链路的探索。

作为一个纯 iOS Native 端开发者，对于后端的技术体感，大部分还遗留在上学期间做的论坛管理系统，加之 FaaS Serverless 等都是一些后端领域较前沿的技术点，尤其是在后端还算是初生牛犊的 Swift 语言，期间走过无数的弯路，但也学到了很多新的知识。

本文是对 Swift On GAIA 的阶段性总结和思考。由于此次技术探索有较多跨端知识，作为一个移动端工程师的视角理解可能非常片面和有误，如读者发现对概念有解释不对，欢迎大家留言区多多指正。由于在技术栈上前端生态已有较多探索， Native 端上的探索和技术储备落后与前端，有些实现会随着云端一体化得探索而改变，并不是一个已经完备的解决方案，欢迎各位开发爱好者积极讨论，造福生态。

PS：文末附邮箱，感兴趣者可进行深入交流。

概念性介绍

Serverless

Serverless 起始是一个比较早的名词，早到 2012年，彼时的我才刚背起小书包走进大学里，但是早期的理论基础已经被提出。

随着 2014年 AWS 的 Lambda 产品出现， Serverless 为云中的应用提供了一种全新的架构体系， Serverless 开始大火，之后各大云计算厂商的加入，Google Cloud Functions, Azure Funcions, IBM OpenWhisk Aliyun 以及其他国内的云计算厂商，如 华为云，腾讯云，百度云，短短数年时间 Serverless产品已遍地开花。

随着容器技术，IoT，5G，技术的快速发展， 技术上对去中心化，轻量虚拟化，细粒度计算等技术需求愈发强烈，而 Serverless 必将借势迅速发展，对将来的富客户端的研发模式的改变，则需要我们这些技术人持续的去探索和创造了。

我们在理解 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 主要有以下的优点：

1. 低成本
2. 快速扩容
3. 更简单的管理
4. 绿色计算

目前国内外云计算厂家基本都支持了 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 需要完成如下操作

1. Swift 运行时初始化。
2. 日志监控
3. 通信协议
4. 集团已有中间件调用
5. Function 调度
6. 发布系统构建

在后端部署的服务都是可弹性的，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 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 在云端一体化的探索一期圆满结束，一个 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，定义业务的模式，类似星环的风格，如果构建的是通用能力，解法可能是另外一种。

原文链接
本文为云栖社区原创内容，未经允许不得转载。