作者 | 杨皓然（不瞋）

对企业而言，Serverless 架构有着巨大的应用潜力。随着云产品的完善，产品的集成和被集成能力的加强，软件交付流程自动化能力的提高，我们相信在 Serverless 架构下，企业的敏捷性有 10 倍提升的潜力。本次分享我主要分为以下四个方面：

一、DevOps 的挑战以及如何降低 DevOps 实施代价？ 二、为什么 Serverless 是云发展的必然结果？ 三、Serverless + DevOps =？ 四、实战案例分享

DevOps 的挑战

1. DevOps 的挑战

对于应用交付的整个流程而言，通常会涉及三个环节，即开发、测试和运维，而在传统的组织架构中，他们对应的也往往是三个不同的团队。这三个环节各自有自己的侧重点，但是在实际上，想要让整个应用交付过程变得顺滑高效，并且让应用在上线后保持高可用的状态，往往需要三个团队将相互之间存在的墙打破掉。

这里的墙不只是组织架构隔阂所带来的障碍，还包括三个领域关注点的不同。比如开发需要关注可测试性和可运维性，这些东西将会深刻地影响应用的架构设计和开发实现，如果开发同学没有充分考虑到代码的可测试性，那么交给测试同学就会造成很大的问题，比如如何实现故障注入和精细流控，这都需要在开发时就考虑清楚。

对于运维而言也是一样的，开发的时候也需要考虑到可运维性，比如在开发的时候就需要考虑如何在服务实际上下线的时候做到平滑且不丢失数据，同时这样的设计也需要和运维系统进行深刻的对接，这样才能非常可靠、非常安全地连接起来，提升运维的效率。

阿里内部之前很多故障也都是因为开发和运维之间在设计上面存在信息不一致导致的，比如在开发设计时会做三副本的高可靠保证，但是在运维侧则可能会认为副本所在的机器没有提供服务因此被错误下线掉。

所以，DevOps 实际上包含了两层含义，首先是将开发、测试、运维变成一个团队；其次，还需要让整个团队的心智统一，这也是 DevOps 真正的挑战。

2. DevOps 的挑战 - 开发

快速回顾一下 DevOps 每个环节所需要考虑的东西。在开发阶段，首先需要梳理业务的需求和场景，并且将需求转换为系统设计，同时需要考虑数据模型如何设计，才能够让数据库不成为单点和瓶颈。因为在阿里巴巴这样的互联网企业中，应用承载了大量的用户访问，因此需要考虑复杂均衡、容错设计、流量控制等。

如果采用了微服务架构，应用将由多个服务组成，那么还需要考虑服务管理。以上全部考虑到之后，将其转化为系统设计，最后进行开发调试以及单元测试，完成了这些之后才可以将应用交给测试环节。

3. DevOps 的挑战 - 测试

在测试时需要考虑很多方面和维度，保证软件各方面的质量。测试包括了集成测试、端到端的 E2E 测试、性能测试、压力测试、容错测试、兼容测试、破坏测试等。

4. DevOps 的挑战 - 运维

当应用通过测试之后，就产出了一个交付物，这个交付物被认为具备了可以发布的能力，后续就需要进行运维工作了，比如应用灰度发布、升级回滚、服务器上下线、监控报警、安全补丁升级、网路配置、操作审计、生产环境引流等。

5. DevOps 的挑战 - 如何降低 DevOps 实施代价？

当我们深入地看 DevOps 中所包含的这些工作项之后，其实能够感受到如果想要做一个具有弹性的、高可靠的应用，需要考虑的点是非常多的，而这些在实施了 DevOps 之后就变成了同一个团队在整个应用生命周期中需要考虑的事情了。这对于团队心智和能力的要求是非常高的。

DevOps 应用交付流水线里面包含了很多环节，如何将这些环节非常流畅地串联起来，实现自动化也是非常重要的方面。

回顾了 DevOps 的挑战之后，通过阿里内部和整个业界的实践可以看到，需要通过平台和工具降低 DevOps 的复杂度。

Serverless 简介

1. 云的趋势

在介绍 Serverless 之前，首先回顾一下云的发展趋势，再来探讨为什么 Serverless 是云发展的必然结果。

在过去的十年间，云计算获得了很大的发展，其使得用户能够通过 API 的方式非常轻松地获得近乎无限的算力，而这些算力是通过虚拟机来呈现的，这样的模式存在很多的优点，它和应用原来的开发和运行环境是兼容的，这种模式能够使得传统遗留应用非常平滑地迁移到云上。

云的第一个阶段就是基础设施云化，这里就是云托管模式。基于云上的存储、网络等基础设施来构建应用，这种模式的核心价值在于资源的弹性和成本。下一个阶段中，云的体系已经远远超越了基础设施，能够看到在各个领域都出现了很多的云服务。因此，在今天需要考虑如何利用云服务的能力，以搭积木的方式来更快速地构建应用，而不是重复造轮子，这就是云原生的模式。

2. 云的产品体系正在迅速 Serverless 化

目前，主流的云计算产商的产品体系也正在迅速地 Serverless 化，这并非是对于未来的预测，而是实际正在发生的事实。下图中的数据是基于对于 AWS、微软和阿里云的产品所发布的新功能或者新服务形式的统计，可以看到绝大多数的新服务都在呈现 Serverless 化。

3. 云编程模型

云计算产生了大量的服务，在效能的角度来看，这些云服务是在更高层次抽象的 Serverless 形态，这就变得非常有意义了。如果从云编程模型的角度重新来审视云产品体系，能够看到最底层是基础设施层，这一层包含两部分，分别是 IaaS 和容器。在基础设施之上就是云原生应用操作系统，K8s 是这一层的事实标准，它能够把底层 IaaS 基础设施很好地管理起来。在操作系统之上出现了非常丰富的 API，也就是全托管的云服务体系。如果看阿里云的产品体系，就会发现了阿里云提供了丰富的产品体系，包括数据库、大数据、中间件，这些都是以 Serverless 全托管模式提供服务的。

在这样具有大量云 API 的情况下，今天的问题是如何设计一个通用的计算框架能够与这些 Serverless 的云服务、云 API 产生非常紧密的连接来帮助客户快速构建弹性、高可用应用。因此在框架层就出现了 Serverless 计算，其产生的原因最主要是需要和云 API 发生紧密的化学反应，帮助用户提升应用构建和运维效率，帮助客户构建分布式、数据化、智能化的新一代的云原生应用。

4. 云托管和 Serverless 应用差异

这里对比一下采用云托管的应用和采用 Serverless 的应用最本质的差异在哪里。对于应用而言，可以将其构建模式拆分为三层，分别是底层基础设施管理、中间的外部服务集成和上层的应用逻辑。如果采用云托管模式，实际上是在基础设施层去构建应用，应用构建的抽象层次是比较低的，因此会带来大量工作，用户自己需要整合不同的组件和服务，需要进行大量的决策和实现，交付的速度会比较慢，需要考虑很多的事情，而且在运维方面有大量的重复工作。

如果用户采用 Serverless 的模式构建应用，也就是相当于在上层 API 的方式构建应用，粘合的逻辑和基础设施管理的工作都由云服务商来承担，用户所需要整合和决策的代价比较低，所需要考虑的主要就是如何将业务逻辑和需求与云服务进行适配来构建应用。基于非常高效的云 API 来构建应用的好处在于构建的成本很低，并且能够实现按天、按小时进行交付，并且大大降低未来运维的负担。

5. 什么是 Serverless 计算？

Serverless 计算具有四个特点：首先，不需要维护云计算基础设施，应用构建的抽象层次上升，变得更加高效；其次，能够实现实时的弹性伸缩，这样能够通过未来的数据驱动的负载感知算法能够实现既满足很低的延时，也能够实现很高的资源利用率；再次，计量模式提供了非常细粒度的按需的模式，可以实现按秒级计量，能够实现完全按需的付费模式，对于用户而言，资源利用率是 100%；最后，能够实现高可用，将这种能力内置在平台层。

6. 阿里云 Serverless 产品体系

这里做一个说明，Serverless 计算只是阿里云 Serverless 产品中的一部分，除此之外还包括存储、API、分析、中间件等。因此，从这个角度来看，Serverless 也不是一个非常新的概念，最早的 OSS 对象存储就是一个 Serverless 产品，可以看出云产品体系正在 Serverless 化，只不过最近几年出现了函数计算这样通用的 Serverless 计算平台，进而能够将 Serverless 体系产品连接起来，构建一个 Serverless 应用。

Serverless DevOps

当有了这些 Serverless 的能力，那么如何将这些能力与 DevOps 结合起来呢？

1. 简化基础设施的管理和运维

下图更多地是从如何构建高可用应用的角度来展现。这里将应用的模块分为四个方面：包括基础设施、运行时、数据和应用。基础设施层就是需要处理与机器相关的操作，比如故障处理。运行时则需要做应用资源隔离、流控等。数据层主要需要和数据库、缓存相关，比如如何设计数据库表结构，如何设计缓存策略，如何实现负载均衡，如何保证不会出现横向扩展瓶颈。

在应用层，则需要处理与应用相关的操作，比如代码包的错误、配置错误、心跳异常的处理。下图中蓝色虚框中的部分可以完全由平台负责，用户可以无感知；蓝色实框则是平台帮助用户做了大量工作，但是还是需要用户感知和作出一定决策；红色框则代表还是需要用户自己管理的部分。可以看到，在容错方面，平台提供了非常强的能力，包括多 AZ 的容灾能力、快速的弹性能力、内置的流控能力以及多层次、多维度的监控报警能力。借助于这些能力，用户管理基础设施的复杂度就大大降低了。

2. 敏捷的应用角度流程

下图展示了应用交付的流程，代码通过统一管理的代码库存储和管理起来，再通过持续集成将其变成一个交付物，再将其存储到交付物仓库里面。交付物可以是容器镜像，也可以是代码包的模式。产出了交付物之后，可以自动地将其部署到测试、生产环境中去做版本部署，最后实现到生产环境的自动部署。因此这样应用交付流程的关键点在于实现高度自动化，而自动化的关键环节有两点：分别是基础设施即代码和环节间的自动化串联。

3. 自动化应用交付流水线

下图展现的是自动化应用交付流水线，可以看到在下面的每一个环节都需要实现很多的功能，而很多都是重复性工作，因此需要做到基础设施即代码。

4. 基础设施即代码

下图是基础设施即代码的展示。Serverless 应用模型通过声明来定义应用资源，能够实现标准化、自动化和可视化。 可以为模板传入不同参数，可以动态生成应用运行环境。

5. 服务版本和灰度发布

在函数计算里面，应用有版本的概念，版本是一个不可变实体，因此杜绝了版本因为非预期的修改造成线上应用受损，阿里云通过服务版本和灰度发布避免了这样的问题，客户端访问应用通过别名来访问。

6. Serverless 工作流

阿里云提供了 Serverless 工作流方便用户将 DevOps 串联起来，用户可以通过配套的服务能力、工具能力快速地创建工作流，并且以可视化的方式展现出来，能够清楚地看到工作流的效果。

7. 自动化应用交付流水线

回顾一下当有了这些能力之后，如何实现自动化应用交付流水线。在源码阶段，可以实现代码质量静态检查，保证 CheckIn 的代码质量。当 CheckIn 到代码库之后，会自动运行单元测试，并且产出交付物。在测试的环节，通过与阿里云 ROS 的无缝集成能够实现自动化部署到测试环境，并且运行测试用例。这些完成之后，通过 ReleaseManager 可以确认部署，通过工作流将这些任务串联起来，发布到预发布环境中，并且进一步部署到生产环境中，每一个步骤都实现了自动化，研发效能得到了极大提升。

8. 日志收集和查询

在 Serverless 计算平台之上，原生提供了很多的日志收集和 Metric 收集能力，比如简单日志查询以及高级日志查询，能够通过日志方式为用户提供高级数据分析能力。

9. 指标收集和可视化能力

Serverless 计算平台除了提供了基本的指标视图之外，还支持自定义指标视图，用户可以通过自定义的关键词指标搜索实现与业务相关的数据分析。 当 Serverless 和 DevOps 结合之后，能够大大提升研发效能，一方面大大降低了开发团队的心智负担；另外一方面，通过工具使得整个 DevOps 流水线能够实现高度自动化。

案例分享

最后分享一些比较成功的案例。阿里 Serverless 计算支撑了阿里经济体小程序平台，节省了 40% 研发资源。阿里云 Serverless 支撑语雀使用函数计算实现文档等计算密集型业务，大幅度地降低了运维成本，还为石墨文档降低了 58% 的运维成本，帮助微博提升了研发效能，使得功能上线时间从原本的 2 周变为几小时。

可以看到，2020 年业界对于 Serverless 的接受度有了极大提升，同时，Serverless 的能力也变得更加普适。

作者介绍：杨皓然（不瞋），Serverless 计算负责人，2010 年加入阿里云，深度参与了阿里云飞天分布式系统研发和产品迭代的全过程。对大规模分布式计算，大规模数据存储和处理有非常深入的理解。