阿里 Midway 正式发布 Serverless v1.0，研发提效 50%。

[czy88840616]

Github: https://github.com/midwayjs/midway， 开源为了前端和 Node.js 的发展，请到 Github 点 Star ！

去年阿里提出 Serverless 架构，并利用其新一代研发架构，减少了大量研发人员对基础设施和运维的关注。对前端开发者而言，他们只需写几个函数即可实现后端业务逻辑，推动业务快速上线，让整个前端研发效能提升 50%。

在过去的半年里，Midway FaaS 收获了很多同学的关注，也有不少大企业已经直接开始使用，在此感谢你们。今天，Midway FaaS 将演进为 Midway Serverless，并正式成为 Midway 体系的核心场景，同时正式发布 v1.0 版本。

v1.0 版本代表着一个正式的版本，可以放心的使用。通过整个 Midway Serverless 新体系，我们将阿里的 Serverless 能力逐步开放，前端将进入一个崭新的时代。就像两年前说的一样，开源只是开始，终态远没有到来。

如今的 Serverless，是云厂商各自开疆拓土的黄金时代，也是各位尝试的最好年代，如今 Node.js 在这个时候成为了最佳选择，Midway 体系也当仁不让地站在这十字路口，去朝着引领的方向去行。

什么是 Midway Serverless

就像前面提到的一样，Midway Serverless 是套面向 Serverless 的解决方案，它包括框架，运行时，工具链，配置规范几个部分，这几部分的组合之后，提供了一些面向 Serverless 体系的特有能力：

1. 平台间迁移更容易
   • 通过提供统一的配置规范以及入口抹平机制，让代码在每个平台基本相同；
   • 扩展不同云平台的运行时 API，不仅能加载通用的平台间扩展，也能接入公司内部的私有化部署方案；
2. 让应用更易维护和扩展
   • 提供了标准的云平台函数出入参事件定义；
   • 提供了多套和社区前端 React 、Vue 等融合一体化开发的方案；
   • 使用了 TypeScript 作为基础语言，方便应用扩展和定义；
   • 提供了完善的 Midway 体系标志性的依赖注入解决方案；
3. 生态更轻量和自由
   • 函数体系复用 koa 的生态和 Web 中间件能力，在处理传统 Web 时更加得心应手；
   • 提供 egg 组件复用 egg 插件的生态链，企业级开发链路更简单顺畅；
   • Midway 体系的装饰器能力统一，让传统 Web 迁移到 Serverless 体系更快更好；

上面提到的全部能力，都已经在 Midway Serverless 仓库开源，欢迎 Star。
Github: https://github.com/midwayjs/midway

Serverless 和 FaaS

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

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

弹性容器，能够满足当前的对资源利用全部憧憬，也是云平台不断追求的目标之一，而对于开发者，不管是弹性的容器，还是弹性的函数，只要有一套代码能都运行其中，满足业务的需求即可。Midway Serverless 的目标由此而来，从原来的 FaaS 场景开拓到了其他领域，不管是函数还是新的架构，我们都将一一满足，并落地业务、反哺社区。

防平台锁定

Vendor Lock-in 是每个使用云平台的的人都会拷问灵魂的问题，Midway Serverless 一开始的初衷就是让一套代码能够运行在不同的平台和运行时之上，我们不建议在不了解全貌时去自定义运行时，那非常的危险。事实上，官方的运行时是运行最稳定，也一定是性能最好的，所有的基准跑分都是基于此。

我们了解的大多数企业在面对 Serverless 的第一个问题就是，我的代码是不是一定得绑死到阿里云，或者腾讯云，aws 等等。

面对这个问题，Midway Serverless 提供了一套 “隐藏式” 入口加上通用化定义来解决这个问题。

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




除此之外，Midway Serverless 提供了一套 Spec 定义，来抹平多个平台的差异，同时也能方便的在多个平台间复用相同的工具链和函数逻辑。



这样，不管是 API Gateway，还是普通的 HTTP 触发器，都能在统一的编程平面中提供 API，让编写代码变的简单。

TS 与装饰器

函数的写法是十分灵活的，灵活带来了简便，同时也带来了维护成本。由此在函数中引入了 TS，引入了标准和扩展性。

下面的代码，看起来似乎是 koa 的标准语法，其实是函数中面向 HTTP 触发器的 API，为了和 Web 栈语法保持一致，通过一些转变，使得参数的获取，调用都尽可能无缝衔接，也减少了学习的成本，原有的代码也能更好的迁移过来。



另一边，通过装饰器修饰的方法都将变为函数入口，让整个函数的结构变得自由。通过构建的方式，让真实的入口隐藏起来，不仅让函数跨多个平台调用，也可以适配到不同的路由。如上面的示例，在一个文件中入口有多个，可以共享同一份代码，但是实际上每个函数的调用又是独立的，在管理和后期维护上都提供了便利。

不同云平台的实际结构是不同，如果用户需要使用到传统的 event 、context 结构， 我们也给不同平台触发器提供了不同的定义，方便代码编写，如下图。

复用社区生态

上面提到，Midway Serverless 体系的设计的初衷就是复用现有 koa 生态，将多个平台的底层 event 规则化成统一的类 koa API 。API 相似的目的是为了整个 koa 的 web 生态，我们同时也希望整个 koa 的 middleware 生态都可以复用。如下图，引入了 @koa/cors 。



另一面，Midway 由于出色的 IoC 组件化能力，提供了上层的 egg 基础组建，同时也能复用现有的 egg 插件，让传统企业级开发的能力得以延续，比如下图就是使用 egg-mysql 插件的示例。

前端赋能

云 + 端的开发体验是 Midway Serverless 目标之一，传统应用的开发，前端和后端分离，多仓库开发，部署分离。就算使用了 Node.js 的胶水层，也无法避免人员开发体感上的割裂。而在 Serverless 体系下，这不是什么问题。

由于后端的大幅简化，再加上云服务的 BaaS 化，让数据聚合，页面渲染变的更容易，也能更快的让前端上手和开发。

一体化慢慢成为了这一块的前端诉求，所谓的一体化，不仅仅是传统仓库的融合，也是整个开发模式的演进，从工程体系加上代码，CI/CD 的整套体系重塑的机会。

如今的 Midway Serverless，提供了和前端一体的开发方案，囊括了社区现有的 React 、Vue 等生态，也对整个工具链（ Webpack，ice scrips，umi 等）做了定制化方案，对不同的场景，比如博客等也提供了开箱即用的解决方案。


至于详细的前后端一体化能力，我们后续将单独开一篇文章来介绍前端一体化的细节和思考。

应用和函数

Serverless 是未来一段时间的方向，也是前端迈向更高层次的铺路砖。

之前一直在思索，如今的函数式开发的终态和应用的关系到底是什么？

现阶段，我们的答案是趋于统一，在被无数次的灵魂拷问和用户需求的追问中，我们得出了这个答案，函数即是应用在当前业务中的最小体现，更简单的来说，是在最小规格容器中运行应用的部分代码。

之后的一段时间，我们将聚焦于更多平台的接入，以及传统应用的迁移方案上，让之前的用户也能享受到 Serverless 弹性的红利，让企业成本更低，业务上线更容易。

最后

在集团大中台、小前端业务架构日趋深化的背景下，借助集团云原生 /Serverless 的发展，去年 Node.js 在业务端到端交付场景上看到了未来。

新一代云 + 端的前台业务交付模式逐渐成为现实，这可以帮助技术团队塑造有业务整体交付能力的特种兵，帮助业务快赢。但其路漫漫仍诸多不完善，为了尽早达到这一步，需要高度聚焦在两个核心问题上：1. 规模化成本、2. 交付速度。

期望在未来透过我们对规模化成本、交付速度的持续投入，Node.js/Serverless 体系可以体现出全面的先进性。

Midway Serverless，Go!

[momocraft]

原来 serverless 是阿里提出的？不是腾讯？

[Rwing]

我来看看评论

[jadec0der]

我进来看到 “去年阿里提出 Serverless 架构” 我就懵了，我以为是 aws 先做的呢？原来是抄的阿里

[chihiro2014]

让我想起了 python 之父廖雪峰，serverless 之父阿里

[gzlock]

研究过 midway，跟 egg.js 在 ts 环境下有一样的问题，创建一个 sequelize-typescript model 太复杂了，看 demo 要先定义个 interface，个人觉得太繁杂了（开发阶段频繁更改 model 字段后还要改 interface 的字段），想想手上的项目有两位数的 model，顿时头都大了。
最终从 egg.js （之前的几个项目一直在用）转到了 nestjs，在 sequelize 的体验上要省心很多

[hantsy]

原来 AWS Lambda 一直不是 Serverless，我靠，全世界感觉被 AWS 骗了，比企鹅还冤枉。

[hantsy]

研发提效 50%，这样写这个估计没有程序员敢用啊。

一旦用上去，不是企业员工都要失业了。用了一个 Midway，让老板知道我是多余的。

[hantsy]

纯属于调侃，没别的意思。

[gzlock]

更正一下上一个回复，interface 不需要包含 model 的字段，但仍然比 nestjs 下使用 sequelize-ts 来的复杂
贴一下两个框架定义 sequelize model 的例子
https://github.com/midwayjs/midway-examples/blob/master/demo-sequelize-typescript/src/lib/model/post.ts

https://github.com/nestjs/nest/blob/master/sample/07-sequelize/src/users/user.model.ts

[hantsy]

@gzlock TypeORM 不好用？ TypeORM 一直感觉是 JPA/Hibernate 的翻版。

[dremy]

看评论不说话🙊

[moroumo]

厉害。那腾讯和阿里的那些猎头蹲守着 AWS Lambda 挖人干啥啊

[qW7bo2FbzbC0]

开个玩笑，提效 50%不是只要单位时间给程序猿多派 50%的活就可以吗

[zy445566]

@hjahgdthab750 提效 50%主要还是不用管环境问题，实际上也是一种运维外包吧

[onecode]

原来 AWS Lambda 、Azure Function 都不行啊

[shadeofgod]

研发提效 50% 这个 50% 怎么算出来的。。。

[onfuns]

因为以前的不良印象，导致现在大家对阿里开源太苛刻了。唉，翻车了。

[qW7bo2FbzbC0]

@zy445566 跟不上了，我的思维还停留在微服务的概念上什么 service mesh, function as service 概念太多，学不过来

[NPC666]

@chihiro2014 你还漏了 C 语言之父谭浩强

[ChicC]

kpi 项目?

[Foralrec]

害怕

[JB18CM]

这个东西比 鸿蒙 os 还厉害吗

[otakustay]

感觉现在很多混淆 serverless 和 faas 的

[yiyi11]

串个台，有没有 java 对标的解决方案？

[fhsan]

初创公司喜欢玩这套 serverless，一台电脑完成全球用户的服务。
按量使用，感觉有时候被平台黑，恶意刷流量。

[xuanbg]

@otakustay serverless 是一种理念，而 FaaS 是这种理念的具体实现。

FaaS 有点像力扣刷题，只不过你写的代码不是给你评个分，而是可以被外部调用罢了。

serverless 就是把原先是在自己本地项目上面写代码，写好要自己部署，变成让你在平台上写代码，写好后自动部署无需操心运维的事。但是，现在稍微懂点运维知识就能借助一堆的开源工具搞定运维了，而且搞好后就压根不用管了。所以，真的有必要要让 server less 吗？

[hantsy]

@xuanbg 你没了解 Serverless 本原。

Serverless 是相对传统的需要 Server 运行的应用来讲。比如我们用到 NodeJS，Apache，Tomcat 等等。ServerLess 出发点是不再占用端口，内存，，宽带，甚至硬盘等资源**长期**运行，而是和命令行，Shell 脚本文件一样，临时分配一些资源，按需要来运行，运行完毕立即释放资源。比如 Linux Shell 脚本语言编写的脚本一样。

这种方式总得使用一个容器（平台）来运行，不然怎么执行你这特有的命令？ Bash 文件也需要 Bash Shell 解析，这个就是 FAAS 的责任。

理论上节约了大量的资源，但是个人认为一些资源的初始化和 Shutdown 成本也高，比如如果这些 Serverless 要用数据库之类的。当然又是个人认为，这类应用不适合 Serverless 。目前场景来讲，我感觉一些事件驱动情况，定时任务等比较适合 Serverless 。

当然国内很多技术被搞得乌烟瘴气，如果了解最初的，应该看看 AwsLambda 的介绍。

[Hanggi]

先来一口老干妈压压惊

[DoctorCat]

研发提效 50% 为啥不是 80% or 20% ？

[reus]

果然是阿里价值观

[ryanlid]

真好，又可以开除 50% 的员工了

[czy88840616]

看来大家关注点走在第一句。。。本意其实是阿里在内部落地 serverless 架构，aws 还是 serverless 之父，我道歉。。。

从逻辑上来说，faas 和 serverless 的概念不同，serverless 更为广义，而今天阿里内部实施的是其中一种函数的方式，对于业务来说，从传统的 Web 应用，跳过了微服务的演进，直接上手函数，也是有很多的不解，怀疑，甚至反对。好在前端委员会以及集团云原生战略的影响下，这一方向是明确并落实了下来，使得我们的工作能够尽可能顺利的开展，一年下来，业务也肯定了使用了 FaaS 之后的效果和业务价值。

Midway 是技术引导的产品，为了更贴近云原生和集团战略，从传统的 Web 框架演进而来，如今是一个面向用户的 Serverless 框架，解决在使用各家云厂商的不一致的场景，我们支持阿里云，腾讯云，乃至未来的 aws，都是出于技术的考虑（不然阿里云就该打我们了）。

KPI 是正常的价值引导，以及我们做事的驱动方式，技术人员一直是有梦想的，宣传和运营固然是一部分，更多的是踏踏实实的做事方式，虽然 midway/pandora/sandbox 只开源了两年，我们也希望能一直走下去，乃至 102 年。