如何优雅地部署一个 Serverless Next.js 应用

时间  2020-07-26
标签 如何 优雅 部署 一个 serverless next.js 应用 栏目 JavaScript 繁體版
原文   原文链接

上一篇 前端福音：Serverless 和 SSR 的天做之合，详细介绍了 SSR 相关知识，同时也提到了 Serverless 给 SSR 方案带来的福利。但它只是将 Next.js 应用部署到 Serverless 服务上而已，并不适合实际生产业务。为此本篇专门针对 Next.js 的 SSR 方案进行了探索和优化，一步一步带你们了解，如何基于 Serverless 架构部署一个实际的线上业务。css

抢先体验：serverless-cnodehtml

本文主要内容：前端

  1. 如何快速部署 Serverless Next.js
  2. 如何自定义 API 网关域名
  3. 如何经过 COS 托管静态资源
  4. 静态资源配置 CDN
  5. 基于 Layer 部署 node_modules

如何快速部署 Serverless Next.js

因为本人对 Serverless Framework 开发工具比较熟悉，而且长期参与相关开源工做，因此本文均使用 Serverless Components 方案进行部署，请在开始阅读本文以前，保证当前开发环境已经全局安装 serverless 命令行工具。
本文依然上一篇中介绍的 Next.js 组件 来帮助快速部署 Next.js 应用到腾讯云的 Serverless 服务上。node

咱们先快速初始化一个 Serverless Next.js 项目：git

$ serverless create -u https://github.com/serverless-components/tencent-nextjs/tree/master/example -p serverless-nextjs
$ cd serverless-nextjs

该项目模板已经默认配置好 serverless.yml，能够直接执行部署命令：程序员

$ serverless deploy

大概 30s 左右就能够部署成功了，以后访问生成的 apigw.url 连接 https://service-xxx-xxx.gz.apigw.tencentcs.com/release/ 就能够看到首页了。github

Next.js 组件，会默认帮助咱们建立一个 云函数 和 API 网关，而且将它们关联，实际咱们访问的 是 API 网关，而后触发云函数，来得到请求返回结果，流程图以下：express

Serverless Requst Flow

解释：咱们在执行部署命令时，因为一个简单的 Next.js 应用除了业务代码，还包括庞大的 node_modules 文件夹，这就致使打包压缩的代码体积大概 20M 左右，因此大部分时间消耗在代码上传上。这里的速度也跟开发环境的网络环境有关，而实际上咱们云端部署是很快的，这也是为何须要 30s 左右的部署时间，并且网络差时会更久，固然后面也会提到如何提升部署速度。npm

相信你已经体会到，借助 Serverless Components 解决方案的便利，它确实能够帮助咱们的应用高效的部署到云端。并且这里使用的 Next.js 组件，针对代码上传也作了不少优化工做，来保证快速的部署效率。api

接下来将介绍如何基于 Next.js 组件，进一步优化咱们的部署体验。

如何自定义 API 网关域名

使用过 API 网关的小伙伴，应该都知道它能够配置自定义域名，以下图所示：

Manual Config Custom Domain

可是这个手动配置仍是不够方便，为此 Next.js 组件也提供了 customDomains 来帮助开发者快速配置自定义域名，因而咱们能够在项目的 serverless.yml 中新增以下配置：

org: orgDemo
app: appDemo
stage: dev
component: nextjs
name: nextjsDemo

inputs:
  src:
    dist: ./
    hook: npm run build
    exclude:
      - .env
  region: ap-guangzhou
  runtime: Nodejs10.15
  apigatewayConf:
    protocols:
      - https
    environment: release
    enableCORS: true
    # 自定义域名相关配置
    customDomains:
      - domain: test.yuga.chat
        certificateId: abcdefg # 证书 ID
        # 这里将 API 网关的 release 环境映射到根路径
        pathMappingSet:
          - path: /
            environment: release
        protocols:
          - https

因为这里使用的是 https 协议，因此须要配置托管在腾讯云服务的证书 ID，能够到 SSL 证书控制台 查看。腾讯云已经提供了申请免费证书的功能，固然你也能够上传本身的证书进行托管。

以后咱们再次执行部署命令，会获得以下输出结果：

Custom Domain Outputs

这里因为自定义域名时经过 CNAME 映射到 API 网关服务，因此还须要手动添加输出结果中红框部分的 CNAME 解析记录。等待自定义域名解析成功，就能够正常访问了。

如何经过 COS 托管静态资源

Next.js 应用，有两种静态资源：

  1. 项目中经过资源引入的方式使用，这种会通过 Webpack 打包处理输出到 .next/static 目录，好比 .next/static/css 样式文件目录。
  2. 直接放到项目根目录的 public 文件夹，经过静态文件服务返回，而后项目中能够直接经过 url 的方式引入（官方介绍）。

第一种的资源很好处理，Next.js 框架直接支持在 next.config.js 中配置 assetPrefix 来帮助咱们在构建项目时，将提供静态资源托管服务的访问 url 添加到静态资源引入前缀中。以下：

// next.config.js
const isProd = process.env.NODE_ENV === "production";
const STATIC_URL =
  "https://serverless-nextjs-xxx.cos.ap-guangzhou.myqcloud.com";
module.exports = {
  assetPrefix: isProd ? STATIC_URL : "",
};

上面配置中的 STATIC_URL 就是静态资源托管服务提供的访问 url，示例中是腾讯云对应的 COS 访问 url。

那么针对第二种资源咱们如何处理呢？这里就须要对业务代码进行稍微改造了。

首先，须要在 next.config.js 中添加 env.STATIC_URL 环境变量:

const isProd = process.env.NODE_ENV === "production";
const STATIC_URL =
  "https://serverless-nextjs-xxx.cos.ap-guangzhou.myqcloud.com";
module.exports = {
  env: {
    // 3000 为本地开发时的端口，这里是为了本地开发时，也能够正常运行
    STATIC_URL: isProd ? STATIC_URL : "http://localhost:3000",
  },
  assetPrefix: isProd ? STATIC_URL : "",
};

而后，在项目中修改引入 public 中静态资源的路径，好比：

<!-- before -->
<head>
  <title>Create Next App</title>
  <link rel="icon" href="/favicon.ico" />
</head>

<!-- after -->
<head>
  <title>Create Next App</title>
  <link rel="icon" href={`${process.env.STATIC_URL}/favicon.ico`} />
</head>

最后，在 serverless.yml 中新增静态资源相关配置 staticConf，以下：

org: orgDemo
app: appDemo
stage: dev
component: nextjs
name: nextjsDemo

inputs:
  src:
    dist: ./
    hook: npm run build
    exclude:
      - .env
  region: ap-guangzhou
  runtime: Nodejs10.15
  apigatewayConf:
    # 此处省略....
  # 静态资源相关配置
  staticConf:
    cosConf:
      # 这里是建立的 COS 桶名称
      bucket: serverless-nextjs

经过配置 staticConf.cosConf 指定 COS 桶，执行部署时，会默认自动将编译生成的 .next 和 public 文件夹静态资源上传到指定的 COS。

修改好配置后，再次执行 serverless deploy 进行部署：

$ serverless deploy

serverless ⚡framework
Action: "deploy" - Stage: "dev" - App: "appDemo" - Instance: "nextjsDemo"

region:    ap-guangzhou
# 此处省略......
staticConf:
  cos:
    region:    ap-guangzhou
    cosOrigin: serverless-nextjs-xxx.cos.ap-guangzhou.myqcloud.com
    bucket:    serverless-nextjs-xxx

浏览器访问，打开调试控制台，能够看到访问的静态资源请求路径以下：

Static Asset Url

上图能够看出，静态资源均经过访问 COS 获取，如今云函数只须要渲染入口文件，而不须要像以前，静态资源所有经过云函数返回。

备注：以前因为都是将 .next 部署到了云函数，因此无法访问页面后，页面中的静态资源，如图片，都须要再次访问云函数，而后获取。因而看似咱们请求了一次云函数，而实际上云函数单位时间并发数，会根据页面静态资源请求数而增长，从而形成冷启动问题。

静态资源配置 CDN

上面咱们已经将静态资源都部署到 COS 了，页面访问也快了不少。可是对于生产环境，还须要给静态资源配置 CDN 的。经过 COS 控制台已经能够很方便的配置 CDN 加速域名了。可是仍是须要手动去配置，做为一名懒惰的程序员，我仍是不能接受的。 而 Next.js 组件正好提供了给静态资源配置 CDN 的能力，只须要在 serverless.yml 中新增 staticConf.cdnConf 配置便可，以下所示：

# 此处省略....
inputs:
  # 此处省略....

  # 静态资源相关配置
  staticConf:
    cosConf:
      # 这里是建立的 COS 桶名称
      bucket: serverless-nextjs
    cdnConf:
      domain: static.test.yuga.chat
      https:
        certId: abcdefg

这里使用 https 协议，因此也添加了 https 的 certId 证书 ID 配置。此外静态资源域名也须要修改成 CDN 域名，修改 next.config.js 以下：

const isProd = process.env.NODE_ENV === "production";
const STATIC_URL = "https://static.test.yuga.chat";
module.exports = {
  env: {
    STATIC_URL: isProd ? STATIC_URL : "http://localhost:3000",
  },
  assetPrefix: isProd ? STATIC_URL : "",
};

配置好后，再次执行部署，结果以下：

$ serverless deploy

serverless ⚡framework
Action: "deploy" - Stage: "dev" - App: "appDemo" - Instance: "nextjsDemo"

region:    ap-guangzhou
apigw:
  # 省略...
scf:
  # 省略...
staticConf:
  cos:
    region:    ap-guangzhou
    cosOrigin: serverless-nextjs-xxx.cos.ap-guangzhou.myqcloud.com
    bucket:    serverless-nextjs-xxx
  cdn:
    domain: static.test.yuga.chat
    url:    https://static.test.yuga.chat

注意：这里虽然添加了 CDN 域名，可是仍是须要手动配置 CNAME static.test.yuga.chat.cdn.dnsv1.com 解析记录。

优化先后对比

到这里，Serverless Next.js 应用体验已经优化了不少，咱们可使用 Lighthouse 进行性能测试，来验证下咱们的收获。测试结果以下：

优化前：

Before Next.js Optimization

优化后：

After Next.js Optimization

先后对比，能够明显看出优化效果，固然这里主要是针对静态资源进行了优化处理，减小了冷启动。为了更好地游湖体验，咱们还能够作的更多，这里就不展开讨论了。

基于 Layer 部署 node_modules

随着咱们的业务变得复杂，项目体积会愈来愈大，node_modules 文件夹也会变得原来越大，而如今每次部署都须要将 node_modules 打包压缩，而后上传，跟业务代码一块儿部署到云函数。在实际开发中， node_modules 大部分时候是不怎么变化的，可是当前每次都须要上传，这必然会浪费不少部署时间，尤为在网络状态很差的状况下，代码上传就更慢了。

既然 node_modules 文件夹是不怎么变动的，那么咱们能不能只有在它变化时才上传更新呢？

借助 Layer 的能力是能够实现的。

在这以前，先简单介绍下 Layer:

借助 Layer，能够将项目依赖放在 Layer 中而无需部署到云函数代码中。函数在执行前，会先加载 Layer 中的文件到 /opt 目录下（云函数代码会挂载到 /var/user/ 目录下），同时会将 /opt 和 /opt/node_modules 添加到 NODE_PATH 中，这样即便云函数中没有 node_modules 文件夹，也能够经过 require('abc') 方式引入使用该模块。

正好 Layer 组件 能够帮助咱们自动建立 Layer。

使用时只须要在项目下添加 layer 文件夹，而且建立 layer/serverless.yml 配置以下：

org: orgDemo
app: appDemo
stage: dev
component: layer
name: nextjsDemo-layer

inputs:
  region: ap-guangzhou
  name: ${name}
  src: ../node_modules
  runtimes:
    - Nodejs10.15
    - Nodejs12.16

配置说明:

region：地区，须要跟云函数保持一致
name：Layer 名称，在云函数绑定指定 Layer 时须要指定
src：指定须要上传部署到 Layer 的目录
runtimes：支持的云函数运行环境

执行部署 Layer 命令:

$ serverless deploy --target=./layer

serverless ⚡framework
Action: "deploy" - Stage: "dev" - App: "appDemo" - Instance: "nextjsDemo-layer"

region:      ap-guangzhou
name:        nextjsDemo-layer
bucket:      sls-layer-ap-guangzhou-code
object:      nextjsDemo-layer-1594356915.zip
description: Layer created by serverless component
runtimes:
  - Nodejs10.15
  - Nodejs12.16
version:     1

从输出能够清晰看到 Layer 组件已经帮助咱们自动建立了一个名称为 nextjsDemo-layer，版本为 1 的 Layer。

接下来咱们如何自动和咱们的 Next.js 云函数绑定呢？

参考 serverless components outputs 说明文档 ，能够经过引用一个基于 Serverless Components 部署成功的实例的 outputs (这里就是控制台输出对象内容)，语法以下：

# Syntax
${output:[stage]:[app]:[instance].[output]}

那么咱们只须要在项目根目录的 serverless.yml 文件中，添加 layers 配置就能够了：

org: orgDemo
app: appDemo
stage: dev
component: nextjs
name: nextjsDemo

inputs:
  src:
    dist: ./
    hook: npm run build
    exclude:
      - .env
      - "node_modules/**"
  region: ap-guangzhou
  runtime: Nodejs10.15
  layers:
    - name: ${output:${stage}:${app}:${name}-layer.name}
      version: ${output:${stage}:${app}:${name}-layer.version}
  # 静态资源相关配置
  # 此处省略....

注意：不一样组件部署实例结果的依赖使用，须要保证 serverless.yml 中 org,app,stage 三个配置是一致的。

因为 node_modules 已经经过 Layer 部署，因此还须要在 src.exclude 中添加忽略部署该文件夹。

以后再次执行部署命令 serverless deploy 便可， 你会发现此次部署时间大大缩减了，由于咱们不在须要每次压缩上传 node_moduels 这个庞大的文件夹了 (▽)

最后

基于以上方案，我部署了一个完整的 Cnode 项目，serverless-cnode，欢迎感兴趣的小伙伴，提交宝贵的 ISSUE/PR。

关于 Serverless SSR 的方案，我也在不断尝试和探索中，若是你有更好的方案和建议，欢迎评论或者私信来撩~

One More Thing

3 秒你能作什么？喝一口水，看一封邮件，仍是 —— 部署一个完整的 Serverless 应用？

复制连接至 PC 浏览器访问：https://serverless.cloud.tencent.com/deploy/express

3 秒极速部署，当即体验史上最快的 Serverless HTTP 实战开发！

传送门：

欢迎访问：Serverless 中文网，您能够在 最佳实践 里体验更多关于 Serverless 应用的开发！

推荐阅读：《Serverless 架构：从原理、设计到项目实战》

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程