Serverless说来并不是一个新鲜的东西，早在当年App Engine就提供了一个基于特定代码运行环境配合云服务的代码托管思路，但因为其各种环境的限制与迁移成本使其并没有很广泛的推广开了。而如今容器化的大行其道，云生态的丰富与完善，则为云原生应用提供了更为丰富的可能性，云厂商也不予余力的包装出新的概念、产品。
Serverless应用场景很多，但绕不开的一个问题就是Web项目可以跑吗？用Serverless跑Web项目真的能节约成本吗？于是我就开始尝试使用阿里云的函数计算来看一看。
在函数计算里运行Nuxt.js项目
为什么是Nuxt.js项目？
Nuxt.js 是基于 Vue.js 的 SSR，SSR 满足作为内容性质的Web应用的SEO需求，同时首次返回页面之后，在页面上的所有操作就都在浏览器上完成了，可以很大程度上减少网络交互。（其实是手头目前最适合测试的项目用了Nuxt.js）
Nuxt.js项目如何跑在函数计算上？
在官方文档中会告诉你，只需要安装并设置好命令行工具，并在项目目录运行就好了。
究其本质是利用了官方提供的一个custom的机制，在容器中预置好了环境，不管你是什么项目，只要给出你的项目的启动命令，并且启动后通过HTTP 9000端口进行交互，就可以通过函数计算访问到你的项目。所以不管你是Nuxt还是Express还是Wordpress，只要你能监听9000端口提供Web服务，一切就都就绪了。
官方是这么说的，对于一般个人Web项目来说也够了，（毕竟对云厂商来说，个人就是凑人头的），但本着能省则省的原则，如何进行优化呢？
函数计算的费用是怎么算的？
（截止本文撰写的时间）阿里云的函数计算主要包括了以下几个部分的费用：
1. 调用次数费用 2. 执行时长费用 3. 流量费用 4. 其他费用
调用次数费用
调用次数费用，指的是每次成功的通过HTTP请求函数计算，都会被计算请求次数，并进行计费，如果我们通过函数计算提供的是API类的服务，那就是API接口被请求的次数，但如果我们提供的是Web服务呢，在前面我们提到了，我们将整个Web项目通过9000接口监听的方式提供HTTP服务，那么相当于并不仅限于我们的Web页面，CSS、JS以及图片等等的静态资源也都是在通过这种方式在提供服务，是的，用户打开一次页面，并不会只有一次请求，还会有连带有各种静态资源的请求。
执行时长费用
执行时长既包括了使用的计算资源也包括实际运行的时长，当然 Nuxt.js 本身的资源占用以及执行渲染的时长并不会太长。
流量费用
从函数计算中流出的费用，这个与前面提到的调用次数类似，不作任何调整的情况下，所有的静态资源也都会直接从函数计算中流出，并计算费用。
优化方案
UI库的按需加载
如果在使用诸如 ant-design-vue 或者 element-ui 之内的库的话，如果直接将整个库引用到项目中的话，会很大程度上增加编译后的文件大小。
使用 ant-design-vue 的情况可以参考：Nuxt.js 中按需加载 ant-design-vue
开启 extractCSS
Nuxt.js 默认未开启 extractCSS，在引入UI组件时，进行额外编译的情况，会导致页面中大量的 style 片段，增加页面大小，且不利用复用，通过 extractCSS 将样式都输出到独立文件中，这样就可以和其他静态资源一块儿优化了。
静态资源优化
前文中提到，默认情况下，所有的静态资源（CSS/JS/图片），通过Nuxt.js内的express，直接通过监听端口的方式提供访问，这些资源从函数计算流出，带来额外的请求数和流量，这部分如果和动态流量来计算显然是不划算的。因此可以考虑静态资源使用CDN。
使用CDN可以有两种方式：
1. 全站使用：通过CDN加速整个函数计算项目，webpack编译出来的前端资源默认都在 /_nuxt/ 路径，在CDN中配置对 /_nuxt/ 的缓存策略，减少回源，这种方式实行起来相对简单，但是不够彻底。
2. 使用对象存储：通过将webpack编译后的 .nuxt/dist/client 目录下的文件，上传到对象存储，并配置CDN。然后更改 nuxt.config.js 中的 publicPath 项目，将其改为CDN地址的方式，从而实现将全部静态资源直接通过CDN进行访问。通过这种方式，在部署函数计算时，因为前端静态文件已经全部转到对象存储上了，因此代码包可以通过不包括 .nuxt/dist/client 目录，以减少代码包大小，从而提高冷启动速度
优化 node_modules
除了前端静态文件外，对于node项目来说 node_modules 犹如文件地狱，当引入的依赖不断增加时，node_modules 也会日趋增加，打包时带上 node_modules 会大幅增大代码包大小，影响冷启动时间。因此在部署前，需要对 node_modules 进行优化（使用yarn会在更新依赖后自动进行优化）
此外，如果 node_modules 确实过大，则建议引入 NAS，将 node_modules 放入 NAS中，容器启动挂载NAS提供服务，以减少冷启动时间。
服务端请求接口优化
Nuxt.js 中使用 axios 发起请求，获取接口数据进行页面渲染，对于服务端渲染的请求来说，是由服务端向上游接口进行请求，前面也提到，关于执行时长和资源使用来说，服务端渲染其实占用的时间并不多，但不可忽视的就是请求上游接口。
在 nuxt.config.js 的 axios 设置中，baseURL 和 browserBaseURL 分别指定了服务端和浏览器请求上游接口时使用的地址。在可能的情况下 baseURL 指定为接口内网地址，而 browserBaseURL 使用接口外网服务的地址，也能在一定程度上减少延迟，缩短执行时长。
成本如何
相较于传统的Web托管，静态资源部分的CDN使用成本与使用函数计算相差无异，同时在优化过程中，也已经对静态资源进行了优化。那么使用函数计算的成本如何呢？
当然，托Nuxt的福，请求方面用户在不刷新页面的情况下，仅第一次加载时的请求落在函数计算服务进行 SSR，此后的请求都是在前端请求接口，同时，我们也将静态资源全都转移到了对象存储上，因此对于函数计算的请求量其实是远小于整个Web项目，相当于用函数计算做了一个 SSR 服务。
实际开销来说，目前迁移到函数计算上的一个项目大致情况如下：
函数实例内存规格：192M（平均内存使用月130M）
WEB统计PV：18w（含前端路由跳转的PV）
函数计算调用次数：16w
函数计算资源使用量：1.2w CU·s
以本文截稿时的价格，若无免费额度，成本约为1.5元。（实际并未超过当前的免费额度）
可以说，对于流量不大的个人Web项目来说，开支基本上就是流量费用，计算成本相对来说可以忽略不计，不过国内的云服务，流量费用依旧不便宜，要省钱还是一门学问啊。