专访阿里亚顿：Serverless 正在颠覆开发模式，包括对工种的定义

Serverless 是一种“无服务器架构”模式，它无需关心程序运行环境、资源及数量，只需要将精力聚焦到业务逻辑上的技术。目前很多公司已经实现 DevOps 化，正在向 Serverless 迈进。而前端工程师也要关注 Serverless，因为它可能会改变前后端联调方式，亦可大幅度降低 Node.js 服务器维护门槛。

在 7 月 12 日深圳 ArchSummit 全球架构师峰会上，来自阿里的高级前端专家亚顿将分享《BFF in Serverless》话题，在此之前，亚顿老师把他在实践 Serverless 过程中的一些技术解决思路分享给大家，以飨读者。

采用 Serverless 理念对 BFF 层进行改造

亚顿说，在传统基于 Node.js 的 BFF 层，其痛点主要在于存在较高的发布和运维成本，而引入 Serverless 的关键目标就是要解决这两个问题。因此，为了提高发布速度、降低运维成本，团队将 BFF 层的函数全部转换为可动态执行的脚本并保存到数据库中，同时提供统一入口用于函数的路由分发，这是阿里团队改造中最核心的功能。围绕这一核心，为了能提高用户体验以及开发效率，团队还打造了针对用户的统一入口和针对开发者的控制台。

在改造的过程中，至关重要的两个问题是：

1）存量应用如何平滑迁移？如果新方案和传统方式差异过大，那较高的迁移成本将会阻碍改造计划的全面推广落地。

2）稳定性如何保障？即如何确保函数运行的沙箱环境的隔离性和安全性，防止函数因自身影响整个平台或其它函数的运行。这是我们最应该关注的两个问题。

Serverless 架构分层设计实践

在架构分层中，主要包含运行与开发两种时态。在运行时阿里团队将其分为 FaaS 和 BaaS 这两大核心模块，即提供安全运行函数片段能力的 function sandbox runtime 和可以在函数中调用各种后端服务的 BaaS Service，其关注的重点是稳定和能力。而在开发时，主要提供了支持在线开发、配置、调试、发布、回滚、监控等能力的一站式开发者控制台及独立 CLI，使开发者可以轻松创建和管理函数，其注重的是开发者的体验。

也许有人会问，当前 BFF 有什么样的最佳实践，有哪些公司已经标准化这样的做法？亚顿回复说，首先，目前进行 BFF 实践的团队或公司，几乎无一例外都采用了 Node.js 来实现，其实这并不是偶然。BFF 就是 UI 的粘合层，而 UI 通常都由前端人员在开发和维护，所以 BFF 层也自然由前端人员采用了对其来说比较顺手的工具来实现。所以，这是最重要的实践理念：服务自治，即吃自己的狗食。其次，对于 BFF 层的价值，是将后端服务聚合和裁剪，为 UI 提供 API。故第二个实践理念：BFF 只处理 UI 逻辑，业务逻辑下沉至后端服务。在不同公司由于基础设施和场景不同，所以很难存在一种标准化的实践方案，但整体方案上只要不偏离上面两个理念，我们认为这就是当前场景下的最佳实践。

前端在使用 Serverless 服务时，亚顿认为最主要痛点在于基础设施的不完善。CNCF 针对 Serverless 给出了他们的定义：Serverless = FaaS + BaaS，然而目前大家主要还是聚焦在前者，对 BaaS 的关注度相对较少。虽然阿里有了一套完善的函数运行时，但真正的业务通常是无法通过一个纯函数的执行而中间不调用任何其它依赖（比如 RPC、DB、Cache、MQ 等）就能独立完成的。所以，亚顿团队花了大量的精力将相关依赖封装起来，形成一套统一的 BaaS SDK 供函数调用，使其能完成以往在 BFF 中能完成的所有工作。

Serverless & GraphQL

Serverless 是否应该与 GraphQL 结合？如果是的话是否会提升应用开发的复杂度，如何权衡？亚顿说，对于 UI 层来讲， 使用 GraphQL 提供 API 确实是一个不错的实践，可以真正的实现按需查询，但其也存在相应的问题。比如在有 BFF 的情况下，它增加了 BFF 层的工作量，需要将所有后端服务都封装一遍来支持 GraphQL 协议；另外也增加了 Android、iOS 的工作量，你也得写两份的查询语句。目前就大家遇到的场景来说，GraphQL 其所能够提供的价值，和增加的工作量相比优势不够显著。不过大家仍然认为它一个不错的实践，如果在有适当的场景将会继续进行尝试。

当前很少看到 Serverless 大规模使用的案例，究其原因，最大障碍在于配套依赖的不完善。对于使用各种云服务的公司来说，目前大多数云服务商提供的 FaaS 服务相对来说是独立存在的，没有完全和自己的后端服务打通，这给 FaaS 的大规模应用带来了极大的不便；而像 BAT 这样的公司，由于其各自内部中间件服务非常丰富，要将 FaaS 与这些中间件服务逐个打通，也是一个不小的挑战。

这就衍生出另外一个问题，传统模式向 Serverless 模式的转变存在哪些阻力，如何克服？亚顿认为：研发模式转变，需要考虑三个问题：

1）新方案能否提供足够的价值；

2）线上应用如何迁移；

3）新方案带来的新问题，我们能否接受。

第一点其优势想必已不必多谈。对于第二点，如果是一个历史包袱不多的新团队或公司，这并不是一个问题，但对于已有大量线上应用的团队或公司，应用的平滑迁移是需要重点考虑的。第三点，亚顿认为目前 Serverless 存在的最大问题是缺乏标准。由于团队将原来的 BFF 应用打散成了一个一个的函数，那么如何将这些函数有效的组织起来是需要思考的问题。不仅是在组织上缺乏标准，在实现上同样如此。目前各大云厂商都是基于自己的理念各自实现其框架，这导致以后几乎不可能完成云厂商的平滑切换。可喜的是已经看到 CNCF 发布了第一版 Serverless 白皮书，使我们离标准化更近了一步；同时也出现了 Serverless Framework 这样的框架，抹平了不用平台服务的差异，能一定程度上解决这个潜在风险。

Serverless 对人及技术管理的影响

Serverless 只是全面云服务大趋势下的一个缩影，基础设施最终都将由 Provider 提供，作为 Developer 只需关注在这种模式下如何有效的设计和组织业务架构。脱离 BFF 场景，当 BaaS 的能力逐渐增强之后，前端可以独立完成以往需要后端才能完成的那部分工作，这将使前端向全栈的方向进一步演化；而后端将进一步下沉，将原有的一部分业务组装逻辑交由前端完成，自身去实现更加底层的通用业务封装，也就是常说的“大中台，小前台”。

亚顿个人认为后续工种将不会再分为前端、后端，而是产品研发和中台研发：产品研发负责所有的上层业务逻辑组装（如下单支付），而其中要使用到的一系列底层业务平台（如用户中心、订单中心、支付中心、物流中心），由中台研发负责。

所以，亚顿认为，对业务流程的深入理解和全局把控，将是今后前端人员的一项新的挑战和方向。

如果你对 Serverless 这个方向感兴趣，可以到7月深圳 ArchSummit 架构师峰会现场来交流，互通有无。本周是 8 折售票最后一周，点击阅读原文了解详情，也可以联系票务经理灰灰进行购票 17326843116。