陈仲寅策划
叶兰去年开始，阿里前端及阿里的多个团队联合开始了一项“秘密”任务，使用Serverless这一新一代研发架构，希望能大量减少研发人员使用基础设施和运维的成本。目前这一框架已经实现前端提效50%，且已在Github开源，开源地址见文末。 MidwayServerless
Midway之前是传统的Web栈框架，和业界现有的EggJS，NestJS等解决的是类似的问题，从中后台到移动端应用，前端都广泛采用了这些框架来构建自己的业务系统。阿里也不例外，Node.js应用非常多，但是这些系统有一个共性，大多数服务器的CPU使用率非常低，这无疑是一种资源的巨大浪费。
这种资源浪费的常态以及应用的规模化几何倍数的增产，让应用治理的人员头疼不已。于是，阿里把目光转向Serverless架构，他们开始去思考，如何有效去减少研发人员使用基础设施的效率和运维的成本。
Serverless和FaaSFaaS是Serverless架构的其中一种形态，也是这次Midway希望解决的场景。在MidwayServerless1.0之前，我们在FaaS上投入了许多，但是事实上，Serverless架构非常庞大，FaaS只是其中的一小部分，基于事件驱动的模型，从微服务（MicroService）这种专注于单一职责与功能的小型功能块演进而来。如今这种更加“代码碎片化”的软件架构范式，相比微服务更加细小的程序单元，给业务代码提供了无与伦比的灵活性。
按照《福布斯》杂志的统计，在商业和企业数据中心的典型服务器仅提供5%～15%的平均最大处理能力的输出，这无疑是一种资源的巨大浪费。而随着Serverless架构的出现，让服务提供商提供我们的计算能力最大限度满足实时需求，这将使我们能更有效地利用计算资源。
阿里目前使用了FaaS来作为业务的落地容器，希望能进一步减少容器的规格，降低成本。集团机器的成本当前是按CPUCore算的，以4C8G（4核8G）的机器为例，一个中后台应用最少需要2台机器，而上了FaaS，能减少到1C，乃至0.5C，这个成本下降的非常可观。
落地前端在阿里“大中台小前台”的趋势下，前端是最接近用户且活力迸发的团队。前端一直希望能够有机会摆脱“资源”的困境，对整体工种的职能、边界有更广泛而清晰的拓展需求，造就了如今前端的范围不断衍生，从端侧到智能化，无一不是职能扩大的体现。
对前端开发者而言，Node.js赋予了开疆拓土的能力，自前后端分离开始，从端到全栈，Node.js已经成为前端学习的标配，而DevOPS的提出，也让前端逐步走向开发自治，运维自驱的路子。而阿里在实际实践中发现，大部分前端的确在朝着那个方向走，但是更多的是在业务和自治之间产生了一些迷惘，这两者的关系其实很不容易平衡，时间一久也会对业务的规模化产生一些影响。
而Serverless的出现，正好让前端有机会减少整个OPS环节，更加聚焦于业务本身；同时，由于整体的代码量减少以及轻量化开发理念、部署平台能力的增强，让整个业务的规模化成本越来越低。
之前，有人把Serverless比作前端的3.0，这不无道理。Node.js的轻量、快速已经得到了业界技术人员的广泛认可，在Serverless时代，容器的快速调度、代码的快速启动，都是非常重要的指标，而Node.js在这方面的优势非常明显。
前端提效50%这个数值在我们看来，Serverless带来的效能变化的数值可能更大。其中分为规模化成本和交付速度两个方面。
降低规模化成本首先是服务器成本。
从容器本身的角度来看，上文已经简单演算过，从传统容器到函数，整个容器资源从固定规格到更加细粒度的规格去逐步演进，这将更加符合场景的诉求。经过我们一年的跟踪，中后台应用的机器成本能降低70%以上，而实际移动端业务，也达到了30%左右。
其次是治理成本。
越是大的公司，历史包袱越是严重，今年的阿里集团内部，还存留着Node.jsV6乃至V4的代码。每年的Node.js版本升级、框架升级、库升级都要至少长达几个月，甚至几年。
而如今，函数运行时（Runtime）是前端自己编写的，我们可以将需要治理的Node.js版本、框架，乃至中间件都埋入其中，这就需要定制整个运行时及其通用化的能力。
阿里的内的函数服务有多种，提供了不一样的基建和网关服务。今天淘系前端能够使用一套代码部署在不同的平台之上，就得益于MidwaySererless底层的多平台适配能力。同时，这套代码的防腐层能力也正好能抹平社区的平台差异性。
针对每个平台，MidwayServerless提供了不同的运行时启动器，用于抹平各个平台的差异，并且通过这些启动器，将各个平台的出入参，以及各个event结构，网关的返回格式进行规则化，让用户尽可能不感知底层容器以及协议的差异。
阿里通过这套方案，将一套代码部署在不同的函数服务之上，提供出不同协议的服务。所以到社区，阿里开源的方案也同样适用于多个平台，比如阿里云、腾讯云或者是未来的AWSLambda、Azure等。
经过这层防腐和定制，整个运行时的更新变的简单，将传统应用需要半年起的版本推平工作，在短短一周内就完成了。举个例子，底层有个和平台的连接协议库有安全性漏洞，从接到安全报告开始，我们就需要做以下两件事，一是从平台数据拉取受影响的函数范围，给所有业务方进行了安全性邮件推送，并告知在一定时间之内不做主动申报的，将默认统一自动更新。二是在流量低谷期进行滚动更新，并以告知业务及时