S1 阶段在使用 SwiftUI 编写集团内部使用的 SOT APP 时,有幸参与到 GAIA (FaaS)平台云端一体化的探索,从头至尾实现了一套基于 Swift 语言实现的遵照 GAIA Funtion 标准的 Runtime Framework,并完成了从客户端到后端使用统一的语言栈完成一体化链路的探索。前端
做为一个纯 iOS Native 端开发者,对于后端的技术体感,大部分还遗留在上学期间作的论坛管理系统,加之 FaaS Serverless 等都是一些后端领域较前沿的技术点,尤为是在后端还算是初生牛犊的 Swift 语言,期间走过无数的弯路,但也学到了不少新的知识。java
本文是对 Swift On GAIA 的阶段性总结和思考。因为这次技术探索有较多跨端知识,做为一个移动端工程师的视角理解可能很是片面和有误,如读者发现对概念有解释不对,欢迎你们留言区多多指正。因为在技术栈上前端生态已有较多探索, Native 端上的探索和技术储备落后与前端,有些实现会随着云端一体化得探索而改变,并非一个已经完备的解决方案,欢迎各位开发爱好者积极讨论,造福生态。算法
PS:文末附邮箱,感兴趣者可进行深刻交流。数据库
Serverlessjson
Serverless 起始是一个比较早的名词,早到 2012年,彼时的我才刚背起小书包走进大学里,可是早期的理论基础已经被提出。小程序
随着 2014年 AWS 的 Lambda 产品出现, Serverless 为云中的应用提供了一种全新的架构体系, Serverless 开始大火,以后各大云计算厂商的加入,Google Cloud Functions, Azure Funcions, IBM OpenWhisk Aliyun 以及其余国内的云计算厂商,如 华为云,腾讯云,百度云,短短数年时间 Serverless产品已遍地开花。swift
随着容器技术,IoT,5G,技术的快速发展, 技术上对去中心化,轻量虚拟化,细粒度计算等技术需求愈发强烈,而 Serverless 必将借势迅速发展,对未来的富客户端的研发模式的改变,则须要咱们这些技术人持续的去探索和创造了。后端
咱们在理解 Serverless 的过程当中先来看一看云服务的进化史,云计算经历了物理机房 -> IaaS -> PaaS -> SaaS -> FaaS/BaaS 。api
▐ 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解决的问题:
应用”承载多业务服务,并与基础设施依赖紧密耦合,“应用”负重前行。
应用的交付流程成本高。
以上的介绍考虑的是后端技术栈的问题,下面来看一下客户端的视角。
做为 iOS Native 开发者看到更有体感的切入点是所见即所得(What You See Is What You Get ),function版本化交付运行。
GAIA 平台大大缩短了后端的研发链路,提升了交付成本,屏蔽了运维细节,这对于一个跨栈的开发者也能简单理解。
GAIA容器架构
看过 GAIA 的概念,有必要简单的了解一下 GAIA 容器架构。
图中右侧部分,红色的 Function是真正的业务代码,能够以一个很是轻量,以函数级别交付,被 Function Framework 加载,并按照规范的生命周期管理函数的生命周期、健康检查、业务调用等,经过RPC 与 SideCar 通讯,SideCar Container 负责服务发现,流量管控,Function Event,这部分能够理解为规范,与语言无关,实现一套便可。
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 须要完成以下操做
在后端部署的服务都是可弹性的,GAIA 也不例外,Swift Function Runtime, Swift Function 交付都是制做成 Docker Image 统一交付。简化如图所示。
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 } }
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 的区别
六、平台即服务wiki百科
七、FaaS
八、Kitura
九、Vapor
十、Perfect
十一、Zewo
1四、阿里云小程序 Serverless 教你如何 30 分钟开发小程序!
1五、Knative:从新定义 serverless
本文做者:姜沂(倾寒)
本文为云栖社区原创内容,未经容许不得转载。