关于腾讯云:如何优雅地部署一个-Serverless-Nextjs-应用

23次阅读

共计 7343 个字符，预计需要花费 19 分钟才能阅读完成。

上一篇 前端福音：Serverless 和 SSR 的天作之合，具体介绍了 SSR 相干常识，同时也提到了 Serverless 给 SSR 计划带来的福利。但它只是将 Next.js 利用部署到 Serverless 服务上而已，并不适宜理论生产业务。为此本篇专门针对 Next.js 的 SSR 计划进行了摸索和优化，一步一步带大家理解，如何基于 Serverless 架构部署一个理论的线上业务。

领先体验：serverless-cnode

本文次要内容：

  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 服务上。

咱们先疾速初始化一个 Serverless Next.js 我的项目：

$ 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/ 就能够看到首页了。

Next.js 组件，会默认帮忙咱们创立一个 云函数 和 API 网关 ，并且将它们关联，理论咱们拜访的 是 API 网关，而后触发云函数，来取得申请返回后果，流程图如下：

解释 ：咱们在执行部署命令时，因为一个简略的 Next.js 利用除了业务代码，还包含宏大的 node_modules 文件夹，这就导致打包压缩的代码体积大略 20M 左右，所以大部分工夫耗费在代码上传上。这里的速度也跟开发环境的网络环境无关，而实际上咱们云端部署是很快的，这也是为什么须要 30s 左右的部署工夫，而且网络差时会更久，当然前面也会提到如何进步部署速度。

置信你曾经领会到，借助 Serverless Components 解决方案的便当，它的确能够帮忙咱们的利用高效的部署到云端。而且这里应用的 Next.js 组件，针对代码上传也做了很多优化工作，来保障疾速的部署效率。

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

如何自定义 API 网关域名

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

然而这个手动配置还是不够不便，为此 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 证书控制台 查看。腾讯云曾经提供了申请收费证书的性能，当然你也能够上传本人的证书进行托管。

之后咱们再次执行部署命令，会失去如下输入后果：

这里因为自定义域名时通过 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

浏览器拜访，关上调试控制台，能够看到拜访的动态资源申请门路如下：

上图能够看出，动态资源均通过拜访 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 进行性能测试，来验证下咱们的播种。测试后果如下：

优化前：

优化后：

前后比照，能够显著看出优化成果，当然这里次要是针对动态资源进行了优化解决，缩小了冷启动。为了更好地游湖体验，咱们还能够做的更多，这里就不展开讨论了。

基于 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.tenc…

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

传送门：

  • GitHub: github.com/serverless
  • 官网：serverless.com

欢送拜访：Serverless 中文网，您能够在 最佳实际 里体验更多对于 Serverless 利用的开发！

举荐浏览：《Serverless 架构：从原理、设计到我的项目实战》

正文完
腾讯云
发表至： 腾讯云
2020-07-23
 0
关于腾讯云:腾讯云-Serverless-支撑新东方核心业务算力资源
关于腾讯云:TKE-qGPU-通过-CRD-管理集群-GPU-卡资源
关于腾讯云:腾讯云tca云运维考试答案内容真题介绍
大数据平台是否更应该容器化