Express APP
作为一个Node.js开发者，相信大家都可能会使用Express框架，无论是构建后端服务，或是搭建一个前端的开发态服务器，Express都是一个很流行的选择。构建Express是极为容易的，添加一些路由规则和对应的处理函数，再选择一些中间件，一个应用就诞生了。
一个使用传统托管方法的简单 Express.js App —— 响应单次请求的过程。
下列代码展示了一个最简单的 Express App：
'use strict'
const express = require('express')
const app = express()
app.get('/', (req, res) => res.send('Hello world!'))
module.exports = app
这就完成了一个 Express App。若使用浏览器访问http://localhost:3000，你便可以在打开的网页中看到“Hello world!” 信息。
应用部署
麻烦的问题来了：如何才能将你构建的 Express App 展示给你的朋友或者家人？如何才能让每个人都能访问到它？
应用部署是一个耗时且痛苦的过程，但现在我们就假定你已经很快、很好地完成了部署的工作。你的应用已经能被所有人访问了，并且之后也运转良好。就这样直到一天，突然有一大批用户涌入开始使用你的应用。你的服务器开始变得疲惫不堪，不过仍然还能工作。
一个使用传统托管方法的简单 Express.js App —— 处于较大负载下。
就这样持续了一段时间后，它终于宕机了。
一个使用传统托管方法的简单 Express.js App —— 因为过多用户访问导致应用挂掉
一大批用户因为应用无法访问而变得不开心（无论他们是否为此应用付费）。你对此感到绝望，并开始在 Google 上寻求解决方法。如果在云上部署可以改善现状吗？
在云上部署应该就可以解决应用规模伸缩的问题了，对吧？
此时你遇到了一个恼人的朋友，她又在给你谈论 Serverless（无服务器）技术的种种。
Try serverless
让你的 Express App Serverless 化
在过去的文章《5分钟serverless实践|构建无服务器图图片鉴黄Web应用》中，你已经知道了 Serverless API 是由 API Gateway 和 FunctionGraph 组成的。现在需要考虑的是如何让你的 Express App Serveless 化。就像 Matt Damon 出演的电影《缩小人生》中描绘的桥段，Serverless 在未来也具有无限的潜力和可能性。
如何才能让你的 Express App 无缝接入 FunctionGraph
让我们向它请教一番！在集成到FunctionGraph之前，你的代码需要稍微调整一下。你需要 export 你的 app，而不是调用 app.listen 去启动它。你的 app.js 内容应该类似下列代码：
'use strict'
const express = require('express')
const app = express()
app.get('/', (req, res) => res.send('Hello world!'))
module.exports = app
这样修改后你可能无法在本地启动 Express 服务器了，不过你可以通过额外添加 app.local.js 文件进行解决：
'use strict'
const app = require('./app')
const port = process.env.PORT || 3000
app.listen(port, () =>
console.log(`Server is listening on port ${port}.`)
)
之后像启动本地服务器执行下面的命令就可以了：
node app.local.js
为了让应用的API能更好地使用API网关进行管理，你还需要确保你的所有API拥有一个共同的root_path。现在，进入FunctionGraph页面创建一个函数，函数名为api的root_path，将本地Express工程打包上传，作为函数的代码。然后再为函数创建一个入口文件，可以点击在线编辑器上File -> New File Template -> Node.js Express Server快速创建，入口文件代码如下：
const fgsExpress= require('fgs-express');
const app = require('./app'); // Your Express app entry
const server = fgsExpress.createServer(app);
exports.handler = (event, context, callback) => {
fgsExpress.proxy(server, event, context, callback);
}
fgs-express三方件会包装你的app，转发apig和app之间的请求。至此，你的Serverless化的Express APP就上线了，在浏览器中打开响应信息中返回的链接，若网页展示出 “Hello world!” 那么证明应用已经成功部署起来了！
Serverless Express App
优势
将你的应用 Serverless 化后，你不再畏惧用户群体的进一步扩大，应用会始终保持为可用状态。这并不是言过其实，因为在默认情况下 FunctionGraph 可通过弹性伸缩最高支持100个 function 并发执行。当 API Gateway 接收到请求后，新的 function 会在短时间内处于可用状态。
在高负载下的 Serverless Express.js App
这并不是你接入 Serverless 后唯一的收益。在保证应用不会因为高负载宕机的前提下，你同样削减了不少应用的运行开销。使用 FunctionGraph，你仅需按你应用的实际访问量付费。同样，FunctionGraph的免费试用计划还将给予你每应用每月一百万的免费流量（按访问次数计算）。
你的 Serverless App 真是太替你省钱了
更炫酷的Demo
在真实的项目中，是否真的能够快速集成？下面我们来实际操作一波，在Github上找一个实际的Express项目，让它Serverless化，快速上线。
canfoo / react-taopiaopiao
这是一个基于Express和React构建的仿淘票票APP，其中包括对前、后端请求的处理，无需关注细节，我们将其Api的root_path设置为express-demo，然后将项目压缩成zip包，将其作为代码创建一个名为express-demo的函数。创建完成后为函数添加一个入口文件，并创建一个apig触发器，即完成构建了。Apig触发器中显示的url即为Express程序的Api访问地址根路径。
现在，让我们拭目以待吧，将此url生成一个二维码，掏出手机，让大家在世界各地访问你APP吧。
爱情需要磨合——缺陷
即使Servlerss Express APP听起来超赞，也会有一些缺陷。
下面是 Serverless Express App 一些最 “致命” 的短板：
1、Websockets 无法在 FunctionGraph 中使用。这是因为在 Functiongraph 中，若应用没有任何的访问，那么你的服务器在客观上也是不存在的。
2、上传文件到文件系统同样是无法工作的，除非你的上传目录是 /tmp 文件夹。这是因为 FunctionGraph 对文件系统是只读的，即使你将文件上传到了 /tmp 文件夹，它们也只会在 function 处于 “工作态” 时存在。为确保你应用中的上传功能运转正常，你应当把文件上传并保存到 OBS 上。
3、执行限制也将影响你的 Serverless Express App 功能。例如 FunctionGraph 最大执行时间不能超过 5 分钟等。
这仅仅算是你的应用与 FunctionGraph 之间关于 Serverless 爱情故事的一个序章，期待尽快涌现更多的爱情故事！
生活需要爱——感谢
本文Express介绍部分大量借鉴以下文章：
(英文原文) Express.js and AWS Lambda — a serverless love story（作者：Slobodan Stojanović）
(译文) Express.js 与 AWS Lambda——一场关于Serverless的浪漫爱情故事（译者：刘嘉一）
扫码免费体验函数工作流FunctionGraph~