Serverless 在阿里云函数计算中的理论

作者：网站云原生
近日，阿里云 aPaaS&Serverless 前端技术专家袁坤在 网站 云原生 meetup 长沙站分享了 Serverless 在阿里云函数计算 FC 的理论。
互联网软件架构演进

我们先简单回忆下互联网软件架构的演进之路。
单机部署

在单机部署中，将所有的业务和数据库都部署在一台主机中。

此架构的优点是：开发、部署以及运维都非常简单。缺点是：一旦遇到流量过大或者机器故障，整个系统瘫痪，甚至丧失业务数据，形成宏大业务损失。
集群化部署

针对上述架构问题，常用的处置方案是采取水平扩容的方式停止集群化部署。引入 SLB 的流量网关路由，停止负载平衡。集群化部署实质上是单体架构，开发人员在项目开发的时候需要额外注意，比如要使用 cookie 停止鉴权，session 就不能存储在本地，需要引入 Redis 停止单独存储。集群化部署可以通过快速水平扩容处置流量突增或机器故障的问题。

微效劳拆分

随着业务的开展以及团队规模的扩张，单体架构这样紧耦合的方式会带来越来越多的问题，架构的灵敏性和可扩展性成为阻碍业务开展的严重挑战。微效劳架构应运而生。

对比单体架构，微效劳架构远比其复杂，也衍生了很多新技术，比如：API 网关、效劳注册、效劳发现、RPC 通信。
Serverless 架构

从单体架构到微效劳架构，从单机部署到集群化部署，互联网软件架构越来越复杂，公司需要投入大量精神和本钱停止底层技术的晋级和维护。下图是 Serverless 架构，和单体架构不同的是将对应的组件换成 Serverless 云产品。

技术演进的实质是更好效劳业务，传统开发方式使企业花费更多的精神打磨底层技术细节，而 Serverless 架构就是让开发者专注业务实现从而发明更大的业务价值。
Serverless 架构的优势很明显：

不关注底层根底设备，专注业务价值发明
自动弹性，冷静面对突增流量
按资源使用计费，防止资源闲置浪费

Serverless 架构讨论

先来看一下 FaaS 的执行过程。蓝色部分是用户手动管理，只需要交付代码，其他的启动、运行、运维等都是在 FaaS 平台停止。

但是此架构会产生一些问题：

代码碎片化，无法统一管理和部署
本地环境和线上环境不一致，无法处置依赖兼容性问题
停止本地 Debug 和线上调试困难
FaaS 厂商对代码包有限制，无法部署大代码包
没有统一的规范，导致厂商锁定问题

Serverless Devs

针对上述问题，Serverless Devs 可以协助开发者更好地开发管理 Serverless 应用，它具备以下几个特点：

无厂商锁定，Serverless Devs 协助开发者将应用部署在各个厂商上面
开源开放，代码逻辑无任何黑洞
功能可插拨，Serverless Devs 通过组件的形式提供，开发者完全可以根据需求，快速开发适宜自己的工具套件
项目全生命周期管理才干，Serverless Devs 是用户停止项目初始化创建、开发、调试、部署等全生命周期管理的工具，简化 Serverless 应用开发

假设说 Serverless 架构可以协助开发者开发应用，那么 Serverles Devs 就是协助 Serverless 开发者更好地开发 Serverless 应用！

Serverless 架构理论

Serverless Devs 官网理论

通过上面的介绍可以看出 Serverless Devs 开发者工具并没有提供业务，业务的实现由组件提供，而组件自身分散在不同的 GitHub 仓库中。
Serverless Devs 官网有下面几个诉求：

不同仓库下 GitHub 源中的文档聚集在一个界面停止展示
组件开发者专注组件文档编写，文档自动实时同步到官网
组件一旦有变动，官网可以自动部署和构建

整体方案如下：

开发者在 GitHub 更新文档，触发 webhook 钩子配置的 Http Serverless 函数。这里需要注意的是：由于组件的文档数目不定以及 GitHub 网络不稳定等问题，假设所有的工作都在 Http 函数中处置，非常容易导致超时，所以将所有的处置逻辑放在异步伐用中，执行完后将处置的结果投递到钉钉或者邮件等渠道。
阿里云函数计算控制台理论

阿里云函数计算 FC 控制台是用户使用函数计算产品的第一站，控制台的用户体验至关重要。在架构上面临几个问题：

后端采用中心化部署形式，用户在海外访问延时非常高
需要用户手动建立监控、日志、灰度等才干，导致运维本钱偏高
研发效率较低，开发过程中前后端需要协调沟通，协作本钱较大

整体处置方案如下：

左侧是阿里云通用的网关，负责统一鉴权和安全等逻辑，抽离出 BFF（Backend for Frontend）层，这部分的特点如下：

整体 BFF 部署在阿里云函数计算 FC 上，开发者无需手动运维
BFF 层由前端工程师负责，前端工程师更好地深化业务，提供优秀的用户体验
后端工程师专注于底层稳定性和原子才干的提供，通过 SDK 的方式停止交付给 BFF

通过 Serverless 实现的 BFF 不只给业务带来了极大的灵敏性，对于前端工程师这个群体也有质的改变：从之前的技术视角转变到更加关注业务价值和用户体验提升。
CD 构建理论

常规的自建 CD 构建集群方案通过 Jenkins 或 Tekton 框架实现业务逻辑的编排，资源层面使用 K8s 部署，实现弹性伸缩。假设需要实现简单的云端构建 CD 方案，采用上文的架构略显复杂。
CI/CD 的业务场景有以下几个特性：

通过事件触发执行
流量无法提早预估
需要长时间在后台运行，对延时不敏感
由于网络时延等问题，需要设计失败重试机制

这些特性完全是为 Serverless 量身打造的。实现方案还使用了异步函数，将构建的所有流程导到异步函数中处置，整个编排逻辑通过 Serverless Devs 停止，完美实现了一个性能稳定的 CD 构建集群。
阿里云函数计算应用中心这款产品的底层的 CD 才干完全基于上述的原理停止理论，大家可以自行体验。

异步函数

理论中有非常多使用到异步函数的场景，这里简单介绍下异步函数。

总结来看，异步函数有四个特点：
1、可长时间运行，两个小时到一天不等
2、可以设置自动终止，自由调节时间，节约资源
3、可把触发结果分发给各个事件兑现中心
4、有三次时机可在失败的情况下自动重试