本项目 Github: https://github.com/midwayjs/midway， 开源是为了给前端和 的发展献一份力，还请到 Github 体验一下，并且帮忙点个 Star~ ‍♂️ 感谢~

上一篇大家对 50% 的数字有疑问，这一次作为后续，我们做一个回答和总结。

去年开始，阿里前端及集团多个团队联合开始了一项“秘密”任务，使用 Serverless 这一新一代研发架构，希望能大量减少研发人员使用基础设施和运维的成本。

为什么是 Midway Serverless？

Midway 之前是传统的 Web 栈框架，和业界现有的 EggJS，NestJS 等解决的是类似的问题，从中后台到移动端应用，前端都广泛采用了这些框架来构建自己的业务系统。阿里集团也不例外， 应用非常之多，但是这些系统有一个共性，大多数服务器的 CPU 使用率非常低，这无疑是一种资源的巨大浪费。

这种资源浪费的常态以及应用的规模化几何倍数的增产，让应用治理的人员头疼不已。伴随着去年集团 Serverless 架构在实际应用的诉求，让我们前端看到了希望。正因为如此，集团 Midway 体系的演进势在必行。

Serverless 和 FaaS

FaaS 是 Serverless 架构的其中一种形态，也是这一次 Midway 希望解决的场景，在 之前，我们在 FaaS 上投入了许多，但是事实上 Serverless 架构非常庞大，FaaS 只是其中的一小部分，基于事件驱动的模型，从微服务（MicroService）这种专注于单一职责与功能的小型功能块演进而来。如今这种更加“代码碎片化”的软件架构范式，相比微服务更加细小的程序单元，给业务代码提供了无与伦比的灵活性。

今天按照《福布斯》杂志的统计，在商业和企业数据中心的典型服务器仅提供 5%～15% 的平均最大处理能力的输出，这无疑是一种资源的巨大浪费。而随着 Serverless 架构的出现，让服务提供商提供我们的计算能力最大限度满足实时需求，这将使我们能更有效地利用计算资源。

今天阿里使用了 FaaS 来作为业务的落地容器，希望能进一步减少容器的规格，降低成本。集团机器的成本当前是按 CPU Core 算的，以 4C8G（4核8G）的机器为例，一个中后台应用最少需要 2 台机器，而上了 FaaS，能减少到 1C，乃至 ，这个成本下降的非常可观。

为什么是前端？

在集团大中台小前台的趋势下，前端是最接近用户且活力迸发的团队。前端一直希望能够有机会摆脱”资源“的困境，对整体工种的职能、边界有更广泛而清晰的拓展需求，造就了如今前端的范围不断衍生，从端侧到智能化，无一不是职能扩大的体现。

对前端开发者而言， 赋予了开疆拓土的能力，自前后端分离开始，从端到全栈， 已经成为前端学习的标配，而 DevOPS 的提出，也让前端逐步走向开发自治，运维自驱的路子。而在实际实践中发现，大部分前端的确在朝着那个方向走，但是更多的是在业务和自治之间产生了一些迷惘，这两者的关系其实很不容易平衡，时间一久也会对业务的规模化产生一些影响。

而 Serverless 的出现，正好让前端有机会减少整个 OPS 环节，更加聚焦于业务本身，同时，由于整体的代码量减少以及轻量化开发理念、部署平台能力的增强，让整个业务的规模化成本越来越低。

之前有人把 Serverless 比作前端的 ，这不无道理。 的轻量，快速已经得到了广泛的认可，在 Serverless 时代，容器的快速调度，代码的快速启动，都是非常重要的指标，而 在这一方面的优势非常大，另一方面，前端的不断快速试错，业务的支持，以及整个阿里的前端委员会的落实，让阿里前端在 Serverless时代大放异彩。

为什么是 50%?

这个数值在我们看来，Serverless 带来的效能变化的数值可能更大。其中分为规模化成本和交付速度两个方面。

降低规模化成本

首先是 服务器成本。

从容器本身的角度来看，前面已经简单演算过，从传统容器到函数，整个容器资源从固定规格到更加细粒度的规格去逐步演进，这将更加符合场景的诉求。经过我们一年的跟踪，中后台应用的机器成本能降低 70% 以上，而实际移动端业务，也达到了 30% 左右。

第二块是 治理成本。

越是大的公司，历史包袱越是严重，今年的阿里集团内部，还存留着 V6 乃至 V4 的代码。每年的 版本升级，框架升级，库升级都要至少长达几个月，多则几年。

而如今，函数运行时（Runtime）是前端自己编写的，我们可以将需要治理的 版本，框架，乃至中间件都埋入其中，这就需要定制整个运行时及其通用化的能力。

集团的内的函数服务有多种，提供了不一样的基建，网关服务。今天淘系前端能够使用一套代码部署在不同的平台之上，得益于 Midway Sererless 底层的多平台适配能力。同时这套代码的防腐层能力也正好能抹平社区的平台差异性。

针对每个平台，Midway Serverless 提供了不同的运行时启动器，用于抹平各个平台的差异，并且通过这些启动器，将各个平台的出入参，以及各个 event 结构，网关的返回格式进行规则化，让用户尽可能不感知底层容器以及协议的差异。

集团通过这套方案，将一套代码部署在不同的函数服务之上，提供出不同协议的服务。所以到社区，我们开源的方案也同样适用于多个平台，阿里云，腾讯云或者是未来的 aws lambda、azure 等。

经过这层防腐和定制，整个运行时的更新变的简单，将传统应用需要半年起的版本推平工作，在短短一周内就完成了。

举个例子，底层有个和平台的连接协议库有安全性漏洞，从接到安全报告开始，我们做了几件事，一是从平台数据拉取受影响的函数范围，给所有业务方进行了安全性邮件推送，并告知在一定时间之内不做主动申报的，将默认统一自动更新。二是在流量低谷期进行滚动更新，并以告知业务及时关注和测试。经过这样的流程，整个安全性更新在极短的时间内就统一处理完毕，这在以往的应用场景下，几乎是不可能的。

第三块是 安全生产成本 ，这块在集团内部诉求较大，但是中小型公司应该不多，这里就不再详述了。 通过这三块的管控和治理，使得在 Serverless 架构下，集团业务规模化成本极速降低。

交付速度

除了规模化成本外，另外一块就是业务交付的情况。前端面向的移动端和中后台两大场景都需要快速的交付，以现在的情况来看，前端依旧是研发的瓶颈，在使用了 Serverless 之后，原有的复杂流程已经无法满足现有的诉求。

去年我们在分享中说过，前端自建了一套研发流程和平台，用于满足在新的场景的测试，灰度和回滚。整个研发流程，节点比以往更少，更聚焦。

而另一边，整个研发的效率，也有了不小的提升。

前端开发的效率，得益于前后端的融合，一体化开发和交付的速度。

传统的前端研发，需要在前端仓库和 端仓库多处进行开发，发布流程也是分离的。而在 Serverless 场景下，Midway Serverless 设计了一体化开发和发布的方案，这让前端能将业务在同一个仓库开发，同一个流程发布。特别是那些维护多业务的同学，感触会更深。

除了一体化的开发、调试，部署之外，从代码角度看，原有的编码习惯被保留，无需再度学习新的编程 API 也是一个方面。Midway Serverless 除了提供基于 TypeScript 和装饰器的编码风格之外，也提供了一些传统应用 Egg 应用迁移的方案，在不同的 BU 中也进行了落地尝试，效果非常不错。

经过一年我们在平台测的统计和业务开发方的走访，新的研发模式对业务整体的交付效率有一定的提升，这个提升是普适性的。

以前端完成需求为例，传统完成业务需求需要后端的介入以及联调，而新的研发模式在代码层面会开发更快，虽然单人来看工作量增加了，但是整体的交付时间，投入人员以及联调成本都有明星的降低。

除了业务感性的交付数据外，我们还统计了整体的研发代码量，提交的代码频次以及需求的迭代周期和发布。经过一年业务跟踪和数据的测算，我们得出整体前端人效的提升约为 48%，整个核心的算法牵扯到很对内部的数据，抱歉无法提供，欢迎大家入职观摩。

Serverless 的弊端

任何事物都有两面性。Serverless 优势固然的大，但是毕竟是新东西，特别是在企业中落地的时候，难免会遇到一些问题。

一是基建的缺失，传统的各种客户端，日系投递，连路追踪等能力都非常的完善，而函数这些新的事物还需要时间逐步沉淀，加上弹性容器的影响，整个链路都还是新生事物，需要时间去验证稳定性和可靠性。

二是业务同学的整体理念还是停留在传统应用的层面，对函数的运作机制，事件触发的行为了解不深，加上框架做了很多屏蔽的工作，很容易出现某些代码编写错误或者前期需求评估不到位，能力无法实现的情况。

这些都需要慢慢的打磨，相信在不断的实践下，整体都会越变越好。

本项目 Github: https://github.com/midwayjs/midway， 开源是为了给前端和 的发展献一份力，还请到 Github 体验一下，并且帮忙点个 Star~ ‍♂️ 感谢~

最后

我们可以看到，50% 的计算方式是一个相对感性的数字，但是 Serverless 在其中实实在在的体现出了它的魅力和价值。

最后庆祝一下 Midway Serverless 发布。通过整个 Midway Serverless 新体系，我们将阿里的 Serverless 能力逐步开放，希望整个前端能有不同的思路去承担更大的业务职能，进入一个崭新的时代。

原作者姓名：陈仲寅
原出处：OSCHINA
原文链接：揭秘：Midway Serverless 如何让阿里前端提效 50%？