Swift在GAIA平台云端一体化的探索是怎样的

这期内容当中小编将会给大家带来有关Swift在GAIA平台云端一体化的探索是怎样的，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。

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

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

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

概念性介绍

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 服务的一张图来直观感受下

GAIA 平台大大缩短了后端的研发链路，提高了交付成本，屏蔽了运维细节，这对于一个跨栈的开发者也能简单理解。

GAIA容器架构

看过 GAIA 的概念，有必要简单的了解一下 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 统一交付。简化如图所示。

正式上线

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，定义业务的模式，类似星环的风格，如果构建的是通用能力，解法可能是另外一种。

上述就是小编为大家分享的Swift在GAIA平台云端一体化的探索是怎样的了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注亿速云行业资讯频道。