作者 | 赵庆杰（卢令）

Serverless 规模化落地成果

2020 年，我们在 Serverless 底层基建上做了非常大的升级，比如计算升级到了第四代神龙架构，存储上升级到了盘古 2.0，网络上进入了百 G 洛神网络，整体升级之后性能提升两倍；BaaS 层面也进行了很大的拓展，比如支持了 Event Bridge、Serverless Workflow，进一步提升了系统能力。

除此以外，我们还与集团内十几个 BU 进行了合作共建，帮助业务方落地 Serverless 产品，其中包含 双11 核心的应用场景，帮助其顺利通过 双11 流量峰值大考，证明了 Serverless 在核心的应用场景下，依然表现得非常稳定。

 

两大背景，两大优势

1. Serverless 两大背景

为什么在集团内部能快速实现规模化的落地 Serverless？首先我们有两大前提背景：

第一个背景是 上云 ，集团上云是重要的前提，只有上云才能享受到云上的弹性红利，如果还是自己内部的一朵云，后续的起效降本其实非常难达成，所以 2019 年双十一阿里实现了核心系统 100% 上云，有了上云前提，Serverless 才有了发挥非常作用的空间。

第二个背景是 全面云原生化 ，打造了一个强大的云原生产品的云家族，对集团内部业务进行赋能，帮助业务达成了在上云基础上的两个主要目标：提高效能和降低成本， 2020 年天猫双十一核心系统全面云原生化，效率提升 100%，成本降低 80%。

2. Serverless 两大优势

  • 提高效能

 

一个标准的云原生应用，从研发到上线到运维，需要完成上图中所有标橙色的工作项，才能完成正式的微服务应用上线，首先是 CI/CD 代码构建，另外是系统运维的可视化工作项目，不仅要配置、对接，还需对整体数据链路进行流量评估、安全评估、流量管理等，这显然对人力门槛要求已经非常高。除此以外，为了提升资源利用率，我们还需要对各个业务进行混部，门槛会进一步地提高。

可以看出，整体的云原生传统应用，要实现微服务上线所需要完成的工作项，对于开发者来说非常艰难，需要由多个角色进行完成，但是如果到 Serverless 时***者只要完成上图中标蓝色的框 coding，后续剩下的所有工作项，Serverless 的研发平台可以直接帮助业务完成上线。

  • 降低成本

提高效能主要指的是人力成本的节省，而降低成本则针对的是应用的资源利用率。普通应用我们需要为峰值预留资源，但波谷就会造成极大浪费。在 Serverless 场景下，我们只需要按需付费，拒绝为峰值预留资源，这是 Serverless 降低成本的最大优势。

 

以上两大背景和两大优势，符合技术上云的趋势，所以集团内部的业务方一拍即合，一些大的 BU 已经把 Serverless 落地升级为战役层面，加速业务落地的 Serverless 场景。目前在集团落地的 Serverless 场景已经非常丰富，涉及到了核心的一些应用、个性化推荐、视频处理，还有 AI 推理、业务巡检等等。

Serverless 落地场景

目前，集团内前端场景是应用 Serverless 最快、最广的场景 ，包含淘系、高德、飞猪、优酷、闲鱼等 10+ 以上 BU。那为什么前端场景适合 Serverless 呢？

 

上图是全栈工程师的能力模型图，一般的微应用中需要有三个角色：前端工程师、后端开发工程师，运维工程师，三者共同完成应用的上线发布。为了提高效能，最近几年出现了全栈工程师的角色，作为全栈工程师，他要具备这三个角色的能力，不仅需要前端的应用开发技术，还需要后端系统层面的开发技能，并且要关注底层的内核、系统资源管理等，这对于前端工程师来说门槛显然非常高。

最近几年 Node.js 技术兴起，能够替代后端开发工程师角色，前端工程师只要具备前端开发能力，就可以充当两个角色，即前端工程师和后端开发工程师，但运维工程师仍然无法被取代。

而 Serverless 平台，解决的就是上图三角形结构中的底部三层，极大降低了前端工程师转变为全栈工程师的门槛，这对前端业务开发者来说非常有诱惑力。

 

另外一个原因是业务特性符合，大部分的前端应用具有流量洪峰的特性，需要业务评估前置，存在评估成本；同时前端场景更新迭代快，快上快下，运维成本高；且缺乏动态扩缩能力，存在资源碎片及资源浪费。而如果使用 Serverless，平台会自动帮你解决以上所有的后顾之忧，所以 Serverless 对前端场景的诱惑力非常大。

1. 前端落地场景

 

上图列举了前端落地的几个主要场景和技术点：

BFF 转换成 SFF 层： BFF 主要是 Backend For Frontend，前端工程师做主要运维，但到了 Serverless 时代，运维完全交于 Serverless 平台，前端工程师只需要写业务代码，就可以完成这项工作。

瘦身： 把前端的业务逻辑下沉到 SFF 层，由 SFF 层去做逻辑的复用，把运维的能力也交给 Serverless 平台，实现客户端轻量化，提效功能下沉。

云端一体化： 一处代码多端应用，这是非常流行的开发框架，同样需要 SFF 作为支撑。

CSR/SSR： 通过 Serverless 满足服务端渲染、客户端渲染等，来实现前端首屏的快速展现，Serverless 结合 CDN 整体可以作为前端加速的解决方案。

NoCode： 相当于在 Serverless 平台上做了封装，只需拖拽几个组件，就可以搭建一个前端页面，每个组件都可以用 Serverless 进行包装、功能聚合等，达到 NoCode 的效果。

中后台场景： 主要是单体的富应用场景，单体应用可以完全用 Serverless 模式进行托管，完成中后台应用上线，这同样也可以节省运维能力、减少成本。

2. 前端 Coding 变化

在前端场景应用 Serverless 之后，coding 有哪些变化呢？

 

对前端有一定了解的都知道，前端一般分三层：State、View 和 Logic Engine，同时会把一些抽象的业务逻辑下沉到 FaaS 层云函数上，然后用云函数作为 FaaS API 来提供服务，在代码编写上可以抽象各类 Aaction，每个 Aaction 可以有 FaaS 函数 API 提供服务。

 

上图以一个简单的页面为例，页面左侧是一些渲染接口，可以获取商品详情、收货地址等，这是基于 Faas API 实现的；右侧的是一些交互逻辑，比如购买、添加等，这也是 Faas API 可以继续完成的任务。

页面设计中，所有的 Faas API 不是只能为一个页面所使用，它可以为多个页面复用。复用这些 API 或者进行拖拽之后，就可以完成前端页面的组装，这对于前端来说是非常方便的。

3. 前端轻应用研发提效：1-5-10

 

在前端应用 Serverless 之后，我们把 Serverless 对前端的研发效能的提效简单总结为 1-5-10，其含义是：

1 分钟的快速开始 ：我们把各类主要场景做一个总结，将其归类为应用模板，每个用户或者业务方新起一个业务时，只需要选择相应的应用启动模板，就会帮助用户快速生成业务代码，用户只需要写自己的业务函数代码就可以快速开始。

5 分钟上线应用 ：完全复用 Serverless 的运维平台，利用平台天然能力，帮助用户完成灰度发布等能力；并且配合前端网关、切流等完成金丝雀测试等功能。

10 分钟排查问题 ：基于上线之后的 Serverless 函数，提供业务指标或系统指标的展示，通过指标不仅可以设置报警，还可以在控制台上给用户推送错误日志等，帮助用户快速定位问题、分析问题，10 分钟内掌握整个 Serverless 函数的健康状态。

4. 前端落地 Serverless 效果

前端实现 Serverless 的场景后效果如何？我们将 3 款 APP 在传统应用研发模式下所需要的性能和工时与应用 Faas 场景之后进行对比，可以明显看到，在原有的云原生基础上， 效能还能提升 38.89% ，这对于 Serverless 应用对前端应用来说效果非常可观，目前 Serverless 场景已经几乎覆盖整个集团内部，帮助业务方实现 Serverless 化，实现 提高效能 和 降低成本两个主要目标。

技术输出，拓展新场景

在集团的 Serverless 落地过程中，我们发现了很多新的业务诉求，比如存量业务如何快速实现迁移并节省成本？执行时间是否可以调大或者调长？资源配置是否可以调高？等等，针对这些问题我们提出了一些解决方案，基于这些解决方案我们抽象出了产品的一些功能，接下来介绍几个比较重要的功能：

1. 自定义镜像

 

自定义镜像主要目的是实现存量业务的无缝迁移，帮助用户实现零代码改造，并且把业务代码完全迁移到 Serverless 平台上。

存量业务的迁移是非常大的痛点，在一个团队内，不可能长期存在两种研发模式，这会造成极大内耗。想让业务方迁移到 Serverless 研发体系下，必须推出彻底的改造方案，帮助用户实现 Serverless 体系改造，不仅需要支持新业务使用 Serverless，还要帮助存量业务实现零成本快速迁移，所以我们推出了自定义容器功能。

 

传统 Web 单体应用场景特性：

  • 应用现代化细粒度责任拆分、服务治理等运维负担；
  • 历史包袱不易 Serverless 化：云上云下业务代码，依赖、配置不统一；
  • 容量规划，自建运维、监控体系；
  • 资源利用率低 （低流量服务独占资源）。

函数计算 + 容器镜像优势：

  • 低成本迁移单体应用；
  • 免运维；
  • 无需容量规划，自动伸缩；
  • 100% 资源利用率，优化闲置成本。

自定义容器功能，可以让传统 Web 单体应用（比如 SpringBoot、Wordpress、Flask、Express、Rails 等框架）不需任何改造，就可以以镜像的方式迁移到函数计算上，避免低流量业务独占服务器造成资源浪费。同时也可以享受到无需为应用做容量规划、自动伸缩、免运费等效益。

2. 性能实例

 

高性能实例，减少使用限制，拓展更多场景。比如：代码包从原来的 50M 上升到 500M，执行时间从原来的 10 分钟提高到 2 小时，性能规格比原先提升 4 倍多，能够最大支持 16G 和 32G 的大规格实例，来帮助用户运行一些非常耗时的长任务等等。

 

函数计算服务了很多场景，在服务过程中我们收到了很多诉求，比如约束条件多、使用门槛高、计算场景资源不足等问题。所以针对这些场景，我们推出了性能实例功能，目标是减少函数计算应用场景的使用限制，降低使用门槛，并且在执行时长上、各种指标上，用户可以灵活配置、按需配置。

目前我们支持的 16 核 32G 完全具备不同规格 ECS 一模一样的计算能力，可以适用于高性能的业务场景如 AI 推理、音视频转码等。这个功能对后续拓展应用场景来说非常重要。

挑战：

  • 弹性实例约束条件多，有一定使用门槛，如执行时长、实例规格等；
  • 传统单体应用、音视频等重计算场景下，业务需要拆分改造，增加负担；
  • vCPU、内存、带宽等资源维度，弹性实例未给出明确承诺。

目标：

  • 减小函数计算的使用限制，降低企业使用门槛；
  • 兼容传统应用和重计算场景；
  • 给用户明确的资源承诺。

做法：

  • 推出更高规格、资源承诺更明确的性能实例；
  • 未来，性能实例将具备更高的稳定性 SLA、更丰富的功能配置。

主打场景：

计算型任务、long-running 任务、弹性伸缩不敏感任务。

  • 音视频转码处理；
  • AI 推理；
  • 其它需求高规格的计算场景。

优势：

性能实例除放宽限制外，仍保留当前函数计算产品所具备的所有能力：按量付费、预留模式、单实例多请求、多种事件源集成、多可用区容灾、自动伸缩、应用的构建部署及免运维等。

3. 链路追踪

 

链路追踪功能包括：链路还原、拓扑分析、问题定位。

一个正常的微服务，不是一个函数就能完成所有工作，需要依赖上下游服务。在上下游业务都是正常的情况下，一般不需要链路追踪，但是如果下游服务出现了异常，如何定位问题？这时就可以依赖链路追踪功能，迅速分析上下游的性能瓶颈或者定位问题的发生点等。

函数计算也调研了很多集团内外的开源技术方案，目前已经支持 X-trace 功能，并且兼容了开源方案，拥抱开源，提供了兼容 OpenTracing 的产品能力。

 

 

上图是链路追踪的 Demo 图，通过计算 tracing 可以可视化看到后端服务的数据库访问开销，避免大量服务间的复杂校验关系增加问题排查的难度等。函数计算还支持函数代码级的链路分析能力，帮助用户优化冷启动、关键代码实现等。

Serverless 产品在业务角度上带来了巨大收益，但是封装也带来了一个阶段性难题——黑盒问题。当我们向用户提供链路追踪技术，同时也把黑盒问题暴露给用户，用户也可以通过这些黑盒问题提升自身的业务能力。这也是 Serverless 未来提高用户体验的方向，后续我们会在这方面继续加大投入，降低用户使用 Serverless 的成本。

挑战：

  • Serverless 产品在业务角度有巨大收益，但封装带来黑盒问题；
  • Serverless 连接云生态，大量的云服务造成调用关系复杂；
  • Serverless 开发者依然有链路还原、拓扑分析、问题定位等需求。

FC + x-trace 主要优势：

  • 函数代码级链路分析，帮助优化冷启动等关键代码实现；
  • 服务调用级链路追踪，帮助串联云生态服务，分布式链路分析。

4. 异步配置

 

在 Serverless 场景下，我们提供了离线任务处理、消息对立消费等功能，在函数计算中这类功能的使用率占比 50% 左右。在大量消息消费中，存在很多异步配置问题经常被业务方挑战，比如，这些消息是从哪里来？又去到哪里？为什么服务消费？消费的时间？消费的成功率如何？等等。这些问题的可视化/可配置，是目前需要主要解决的重要课题。

 

上图为异步配置的工作原理，首先从用户指定的事件源开始触发异步调用，函数计算立即返回请求 ID，同时也可以调用执行函数，返回执行结果到函数计算或者消息队列 MNS 里面。然后通过事件源可配置触发器等等，这些效果或者主题消费，可以进行消息的再次消费。比如，如果一个消息处理失败了，可以配置一下进行二次处理。

 

典型的应用场景：

  • 一是 事件闭环 ，比如对投递结果（如收集监控指标、报警配置）进行结果分析；生产事件上客户不仅可以利用 FC 消费事件，也可以利用 FC 主动生产事件。
  • 二是 日常的异常处理 ，比如失败处理、重试策略等。
  • 三是 资源回收 ，用户可以自定义存货时间，及时丢弃无用消息，节省资源，这是异步场景非常大的优化。

原文链接：https://mp.weixin.qq.com/s?__biz=MzI4NzI5MDM1MQ==&mid=2247488944&idx=1&sn=267113bde5407386d09f9df3b4783da1

如果觉得本文对你有帮助，可以关注一下我公众号，回复关键字【面试】即可得到一份Java核心知识点整理与一份面试大礼包！另有更多技术干货文章以及相关资料共享，大家一起学习进步！