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!