一、背景介绍
前端应用生命周期分为开发、部署、运维以及监控四个阶段。
开发层面的工具有比如构建方面的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仓库不一致。
