一、背景介绍
前端应用生命周期分为开发、部署、运维以及监控四个阶段。
开发层面的工具有比如构建方面的Webpack ,代理方面的Proxy以及mock工具等。部署方面更多的是开源工具,比如 Github Action、travis CI、SQL CI。运维系统一般需自行搭建。监控方面的工具有比如阿里云的ARMS监控、Sentry以及DataDog 等。
前端主要偏向应用和交互,对资源的探索相对较少。
在一个现代化的GitOps前端应用平台中,CICD 是架构的灵魂。 CICD 层面有很多方案,但无论是开源还是商业化版本,前端开发者的诉求大多可以总结为以下三个:
l 免运维:无需关心资源的预留或容量的规划,无需关注底座资源不足导致构建失败。
l 前端友好:整体架构基于Javascript语言开发,轻量简单。
l 被集成:前端团队往往有自己内部的开发运维平台,希望该平台能够很好地进行二次封装,从而快速开发内部的前端 PaaS平台。
二、Serverless(FaaS)架构CICD的实践
CICD业务流程如下:在Github Repo发布一条 commit 代码,push之后执行install、build、test以及depoly步骤,整个流程具有以下三个特点:
l 事件驱动:所有触发流程都通过事件驱动。
l 长时间运行:因为网络问题或每个任务的脚本不一,执行时间可长达数小时,运行时长不确定。
l 流量波峰波谷::一般夜里流量较低,上班时间会提交代码,存在流量高峰。
FC 异步函数具有以下几个特点:
l 免运维:无需做容量规划以及资源调度,无需维护调度集群,按调用次数收费,如果没有产生调用则不收费。
l 对比K8s:它已经具备完整的可观测能力,而k8s可能需要安装可观测相关插件;弹性方面,FC的异步函数具有毫秒级别伸缩速度,而k8s为分钟级; FC 每秒能够处理数万条任务,而k8s仅数百条。
l 高阶能力:包括任务去重、任务流控(任务失败自动重试)以及任务执行结果回调(所有执行结果均可进行投递以供后续处理)。
上图展示了简单的系统流程。开发者 push 一段代码到Git Repo,再由系统配Webhook触发 FaaS 函数。FaaS函数会接收到一个traffic请求,traffic不一定是 webhook ,也可能是其他请求类型。Trigger和worker两个函数很重要的特点为,其中所有业务逻辑或与任务处理相关的逻辑都属于nodeJS 生态。
一个通用的产品必须具有相关规范,这里的规范主要有Trigger规范和触发器规范。
Trigger规范分为三种类型:
第一,事件类型:事件类型包括很多事件,通过插件化的方式实现。所有事件都需要经过两个流程:
l 鉴权。并非所有人都可以调用HTTP接口,因此需要有鉴权的逻辑。
l Filter。Github上可能每天会触发上千条 webhook请求,因此需要通过filter筛选感兴趣的 webhook。
第二,手动触发。比如失败后需要手动触发,或者希望将整体的能力集成到自建系统,需要 RustAPI进行直接调用。
第三,定时触发。比如定时的巡检、定时端到端的测试。
Task 规范最大的优点在于自定义step,提供了shell、npm模块以及goggle/zx。其中goggle/zx指用Javascript书写脚本的能力。
其次,支持模板语法。比如要判断当前步骤是执行或暂停、当前的任务是否影响其他任务的调用等。以上所有能力都基于 npm 包实现。
事件到达后,Trigger函数会调用 npm 包 trigger 里的一些能力。然后执行worker函数,调用上面的 task 方法,同时会产生日志信息。日志信息是 interface 接口,可以存储到 OSS 、NAS 或SLS,最终实现 Consul 后对日志信息进行处理。
此处还有持久化的存储能力,即Ots,它是 Serverless DB,按调用次数收费。
函数能力是设计的核心。
Trigger函数是一个 API server ,也是一个暴露出来的HTTP请求,还是 controller 函数,负责控制整体的流程运转。它主要负责以下几项工作:
① 鉴权:负责权限的拦截。比如验证不通过则会提示失败,可以在 WebHook 里面查看失败的 WebHook 信息。
② 流量过滤:比如只接收Push流量,将issue等流量过滤掉。
③ 网关能力:做路由的分发。
同时,Trigger是单实例、多并发的函数。在一分钟内会触发成千上百的请求,如果每一个请求都拉齐函数实例,会造成极大的资源浪费。而单实例多并发,则意味着在一个 POD里可以处理多个请求查看,能够极大地节省资源。此外,Trigger函数只做简单的鉴权以及流量过滤,不存在过多计算,也无需与数据库交互,因此非常轻量。
Worker 函数的特点为需要长时间运行,因此需要支持比如暂停、取消等高阶能力,同时它还能实现流量的过滤。
从函数的特性来看,首先它是事件函数,即无法通过 HTTP 接口在外部调用它;第二,它是异步函数;第三,它是Custom Runtime函数,能够一键切换语言以及版本,无需多余的维护。此外,Worker函数天然拥有镜像加速能力,保证了拉起速度。
核心的 Npm 组件有以下三个:
① Trigger:负责parse Trigger spec。
② Engine:负责parse Task spec。
③ Core:提供了一系列方法,比如日志方法、解析yaml、环境变量以及 secret 等能力。
三、总结展望
后续将实现Pipeline能力。比如多个task编排,其中编排能力包括串行执行和并行执行,串行执行和并行执行的特点为无法暂停。任务的暂停和恢复等能力需要通过第三方机制,比如通过 Redis 消息队列或 MQ 消息队列来实现。同时还会支持cache缓存来减少网络开销。
多region部署切换的能力可以根据灵活的配置规则将worker函数切换到不同region,解决了国内访问GitHub时经常出现的网络不通导致任务失败的问题。
日志支持几种存储方式:
第一,基于文件存储 NAS方案。优点为能够展示实时日志,能够不断地实时追加,可以很好地支持实时滚动、实时的刷新等场景。缺点为文件没有生命周期,需要新建辅助函数清理日志;此外,QPS 并发较高时,会存在写入性能瓶颈。
第二,基于日志系统SLS方案。SLS 和函数计算结合非常紧密,因此使用极其方便,支持从 stdout流中读取流日志,日志也具备完整的生命周期。缺点为价格比较昂贵。
第三,基于 OSS 对象存储方案。优点为价格便宜,使用简单,因为 OSS 是 rest接口,具备完整的生命周期;缺点为无法像文件一样进行追加,因此无法支持实时日志,执行完task之后才能获取当前的完整日志。
Q&A:
Q:通过CICD将前端代码部署到server,是否还需要后端?
A:需要。CICD整个系统的server部署在FC,因此肯定需要后端。此处可理解为前端完成了后端的工作。业务逻辑(应用)维护在各种仓库里,对yaml进行定义即可触发函数。
Q:Demo里存在版本之间的切换,从v1切换到v2再切换到v1。那么版本驻在哪里?
A:不存在版本的概念。所有版本都来自于 git ,可以回退到任何一个 commit,只有git commit 的概念
Q:开发了新特性,更新到git仓库。发现有bug需要回退,git仓库是否也需要回退?
A:Git仓库不需要回退,git记录了所有历史行为,因此通过git fetch获取commit即可。另外,如果是生产流程,则建议通过tag部署,以避免部署状态与git仓库不一致。