Serverless 奇点已来，下一个十年将驶向何方？

2023-01-13
浙江
本文字数：5096 字
阅读完需：约 17 分钟

引言：
以前构建应用，需要买 ECS 实例，搭建开源软件体系然后维护它，流量大了扩容，流量小了缩容，整个过程非常复杂繁琐。
用了 Serverless 服务以后，这些问题都简化了，从半托管到全托管，所有服务 API 化，无限容量充分弹性，可以组装使用，生产力大幅改变。同时推动软件研发模式升级，组装式研发将成为主流。
基于阿里云全面 Serverless 化的经历，阿里巴巴研究员、阿里云智能云原生应用平台总经理丁宇（叔同）阐述了企业应用架构的演进历程，以及 Serverless 兴起带来的行业变化。
本文整理自 QCon 上海站 2022 丁宇（叔同）的演讲内容。

过去十年，上云成为确定性的趋势。

在上云阶段，企业关注点在于如何实现平滑上云，因此云厂商将云托管（Cloud-Hosting）作为核心策略。云的主要形态是资源型服务，以虚拟机的形式为企业提供海量的算力。

对开发者而言，虚拟机的功能和使用方式和 IDC 中的物理服务器没有区别。原有的应用、技术栈不需要改变就可以平滑上云。云托管的策略很好地满足了企业在上云阶段的核心诉求，因此取得了成功。

随着越来越多的企业上云，甚至很多企业系统第一天就是在云上构建，企业的核心关注点转变为如何更好地利用云的能力，将产品快速推向市场，从而实现业务成功。

这促使云在下一阶段发展的主要目标转变为利用云自身的优势，解决大规模复杂应用的开发和运维挑战。但是，如果算力的呈现形式仍然是服务器这样的资源形态，它的使用门槛依然很高。算力和业务相隔太远，企业需要有一整套支撑应用的基础设施来用好算力。

如何让算力像电力一样的普及，云计算需要新的形态。

云服务的角色将发生巨大的变化，不再是单纯的提供资源，而是要成为企业构建应用的新平台，要帮助企业尽可能减小机器运维等低价值重复工作，聚焦于业务的创新。

下一个十年，是云演进自身能力，帮助企业用好云的阶段，而云厂商的核心能力就是 Serverless 云服务。

1.png

为什么选择 Serverless

Serverless 服务是全托管的。

云厂商可以通过存储计算分离，软硬协同优化等底层技术，大规模提高服务的资源效率和性能。以阿里云存储服务为例，自 2018 年开始大规模使用 RDMA 技术，自研了 Solar-RDMA 协议，以及 HPCC 流控和端网融合技术。

通过网络和存储的协同设计，结合 FPGA 硬件加速压缩算法等能力，实现了稳定的微秒级的读写性能。企业只需要调用服务 API，就能使用云厂商在相关领域的专业能力，享受到技术红利。

Serverless 服务具备自适应弹性， 让企业的应用更平稳的应对业务负载不可预测或者突然爆发的情况。

一个典型的业务系统可划分为应用层、接入层、资源层。资源型的云服务只提供了资源层面的弹性能力，企业还需要实现接入层和应用层的弹性能力，才能做到业务的全链路弹性。

架构设计阶段，根据各个组件的依赖关系，制定弹性伸缩和限流降级方案。对于关系型数据库等几乎没有弹性能力的服务，一般需要预测未来 3 年对数据库的写入和读取规模，进行分库分表。
资源规划阶段，权衡各个组件的扩缩容难易度、伸缩速度、业务负载变化速度等因素，通过冗余资源实现相应的弹性能力。接入层资源占比在整个系统不高，维持较高冗余资源成本不高，也比较容易扩容。应用层的资源规划最具挑战。应用层是资源消耗大头，一般不允许通过很高的冗余资源来扛住负载峰值，此外应用层的扩缩容牵扯上下游链路，复杂度很高。最后，应用层不同服务的流量规模不同，需要梳理清楚，重点做好热点链路的冗余资源规划。
线上运行阶段，通过完整的可观测能力，建立量化链路的流量，检测热点，进行动态扩缩容，再量化热点链路流量，再判断是否进行动态扩缩容的闭环。此外，完整、及时的监控报警也是十分必要的，为不同组件设定不同的热度阈值，检测到热度流量后，系统要及时的广播给关联组件的开发、运维人员，根据预定方案进行处理。

2.png

可见，在资源层的弹性能力上构建整个业务的弹性能力复杂度非常高。Serverless 服务的自适应弹性目标就是为了简化复杂度，帮助企业更容易实现业务弹性。

首先云厂商会将大量中间件、数据库、大数据等 BaaS 化的服务 Serverless 化。以数据库为例，不但提供 NoSQL 等天然具备高弹性能力的数据库服务，也将传统的关系型数据库 Serverless 化。

其次， Serverless 计算服务通常具备百毫秒到秒级的实例启动速度，每秒钟启动数千甚至上万实例，以及高度自动化的弹性伸缩能力，配合 Serverless 化的 BaaS 服务，将实现全链路的业务弹性。

最后，Serverless 服务通常内置了限流降级的能力，让企业资源可控，更容易应对系统雪崩的问题。

如何高效的利用好资源，是企业面临的一个普遍的难题。业界数据中心的统计数据表明，企业整体平均资源利用率是不高的，一般小于 15%。要提高资源利用率，企业一般面临以下挑战：

各个业务部门资源使用相互独立，没有资源并池，没有统一调度。
出于对性能、负载峰值以及业务未来发展保障等因素的考虑，业务部门一般倾向于多申请资源，通常是实际使用资源的 3-5 倍。
非核心应用碎片化的资源消耗导致了大量资源浪费。大量非核心应用为了满足高可用的要求，至少需要 2-3 台机器，而这些应用很多时候是长尾、低频调用的，甚至业务下线但服务器忘了释放，造成资源浪费。在阿里巴巴集团，非核心应用消耗的资源甚至超过了核心应用。
不同性质的应用没有共享资源，没有削峰填谷，集群整体资源利用率不高。

容器化是提高资源利用率的有效手段，但实施的复杂度较高。阿里巴巴集团通过全栈容器化，统一调度和离在线混部来提升资源的整体利用率，涉及到容器性能的优化、租户隔离、底层服务器算力归一化、定制的资源统一调度和离在线混部等等。

Serverless 的目标让企业用更简单的方式提高资源利用率，降低成本。

以函数计算为例，企业不需要为闲置资源付费，而是根据实际使用的资源付费。这意味着大量测试、预发甚至生产环境，大量非核心应用碎片化资源的使用场景，使用 Serverless 后资源利用率会非常高。

如果从性能角度考虑，需要预留一些资源，函数计算的闲置资源费用也比服务器更低。函数计算内置了多 AZ 容灾能力，企业不需要为容灾准备冗余资源。函数计算支持百毫秒级别的弹性伸缩速度和丰富的伸缩规则，企业不需要为峰值负载预留资源。

当云服务演进为 Serverless 形态后，企业的使用门槛大大降低，Serverless 将让算力像电力一样普及。

Serverless 引领下一代应用架构驱动研发模式升级

应用架构和研发模式的演变主要是由企业的业务发展诉求推动的。企业总是期望能够更敏捷的应对业务规模和复杂度的增长，更快的将产品推向市场，加快业务创新的速度，这就要求技术能支持大规模、复杂软件的快速迭代。

传统的企业级应用架构，通常是单体的，所有模块都耦合在一起，同时发布。这种单体架构应用在一开始是易于管理的，但随着业务发展，会带来巨大的复杂度。这种强耦合的架构带来开发、测试和运维过程中大量的冲突，拖慢了整个迭代速度。

例如整个应用的开发要求所有模块采用统一的语言和框架技术栈，如果一个基础库被多个模块共享，其中一个模块想要升级到新版本，则需要说服所有人同时升级，即便其他人并不需要新版本。所有模块的发布节奏被强行拉齐，一个模块的问题会影响整个应用的发布。

想要快速修复某个模块的线上问题也变得非常困难，因为这需要和其他模块正在进行中的变更合并，解决冲突，重新发布整个应用，运行所有测试，才能重新发布上线。单体应用架构已经不能满足软件研发效率的要求，被以微服务为主要特征的互联网分布式架构取代。

3.png

采用微服务架构后，应用程序由独立的服务组成。这些服务是松耦合的，通过 API 调用、事件触发或者数据流的方式交互。每个服务都完成一个特定的功能，独立开发、运行和发布。

微服务解决了单体架构的研发效率瓶颈，但是对应用的基础设施提出了非常高的要求。

例如，为了确保独立开发的微服务能够按预期协调配合，需要进行详尽的集成和端对端测试。测试环境中的应用部署次数通常是生产环境的 10 倍。如果应用基础设施不能快速提供独立的测试环境，那么大量的测试时间将消耗在环境稳定性问题的解决上。

根据阿里巴巴集团的研发统计数据，1 人日的研发，通常对应 5-7 人日的测试。测试环境已经成为阿里巴巴集团研发提效的最大痛点。

微服务的松耦合，也对数据库使用、状态管理、问题诊断、应用交付流水线带来了很大的挑战。关于微服务的复杂度以及解决方案，业界已经有非常多的讨论，这里不再赘述。

以微服务为核心的互联网分布式架构，实施的复杂度较高，必须有很好的工具、平台的支撑，这是业界的共识。

4.png

除了微服务架构，企业也广泛使用反应式架构、事件驱动架构等模式，这些架构都带来了松耦合、敏捷开发等好处，但相应的落地复杂度也变高了。

事实上，业界在应用的构建、编排、运行、BaaS 服务、基础设施管理等每一方面，都提供了丰富的产品和解决方案，建立了庞大的生态。但企业要整合这些软件/服务，让它们弹性、稳定、相互集成良好，加速应用开发迭代，这绝非易事。

而在用好云的阶段，云的使命就是要消除这种复杂度，带来大规模复杂软件开发质的突破，助力企业打破技术鸿沟。

5.png

每一个 Serverless 服务都是厂商领域能力的输出，通过服务 API 透出功能，承诺可靠性、弹性、性能等能力指标，因此他们是高质量的应用构建块（building blocks）。

例如阿里云对象存储（OSS）服务，承载着 EB 级的海量数据，承诺 11 个 9 的数据可靠性，99.95% 的可用性，以及多样化的数据分级存储和处理能力。

阿里云消息队列 RocketMQ 历经双十一万亿级消息洪峰的锤炼，承诺 10 个 9 的数据可靠性，99.95% 的可用性。这些云服务和企业基于开源软件自建的系统相比，在弹性、可靠性等方面有明显的优势。

6.png

不只是云厂商，大量的开源商业产品也采用了 Serverless 模式，包括 Confluent Cloud、MongoDB Atlas、Snowflake、Databricks 等。

随着厂商在存储、计算、中间件、大数据等领域推出越来越多的 Serverless 服务，并且这些服务通过事件驱动等方式紧密集成，云逐渐变成了应用构建和运行的超级平台，应用的研发模式也升级为组装式研发。

7.png

Serverless 让云成为应用构建的最佳平台

随着阿里云提供越来越全面的 Serverless 产品以后，很多云产品都变成模块化、API 化、服务化，它可以进行组装，通过拖拉拽的方式就能够构建应用。

在 Serverless 架构下，研发方式升级为组装式研发，可以做到流程编排、事件驱动，甚至可以做成可视化，这就彻底颠覆了原有的软件研发方式，大幅提升研发效率，灵活应对业务挑战。根据权威机构调研统计，组装式研发相比传统模式，可为研发提效 50% 以上。

从新兴的互联网创业公司，到传统企业构建大型软件，都可以使用 Serverless 架构和组装式研发。

以高德为例，高德的投放业务和用户生活场景紧密相关，功能多变；推荐的下游业务品类快速增长，投放的业务策略多变；而且整个业务和用户出行紧密相关，有明显的峰谷属性。

随着业务的增长，投放平台原有的架构面临一些明显的痛点：

重客户端。卡片处理、导航规划、页面展示等逻辑都放在 Web 或者移动设备上，导致客户端发版缓慢、代码臃肿。
业务功能紧耦合，跟不上业务迭代要求。投放策略多变，每次发布影响面大。
负载有明显的峰谷，常驻实例，资源利用率低。

Serverless 架构能很好地解决上述痛点。首先为客户端瘦身，将端上的逻辑大量的移到 BFF 层（Backends for frontend）。

由于 Serverless 计算零运维，只需要开发业务逻辑，完全由客户端人员发布，避免了团队协作问题。借助平台内置的应用平滑发布的能力，客户端的人员可以快速迭代，安心发布。

8.png

投放策略等后端服务也解耦为函数的形式，包括规则过滤函数、疲劳提醒函数、内容组装函数等等。这些函数作为独立的后端服务开发迭代，每次发布影响面不大，控制了爆炸半径。

通过仔细梳理热点逻辑以及上下游依赖，实现了全链路弹性以及接口级流控能力。弹性伸缩不但快速，而且安全，资源用量和负载峰谷匹配，效率高。

目前基于 Serverless 架构的高德业务投放平台已经承载了 100% 的生产流量，业务规模达到百万 QPS，功能交付从原来的数天降低到数小时，整体成本降低了 38%。