共计 7343 个字符,预计需要花费 19 分钟才能阅读完成。
上一篇 前端福音:Serverless 和 SSR 的天作之合,具体介绍了 SSR 相干常识,同时也提到了 Serverless 给 SSR 计划带来的福利。但它只是将 Next.js 利用部署到 Serverless 服务上而已,并不适宜理论生产业务。为此本篇专门针对 Next.js 的 SSR 计划进行了摸索和优化,一步一步带大家理解,如何基于 Serverless 架构部署一个理论的线上业务。
领先体验:serverless-cnode
本文次要内容:
- 如何疾速部署 Serverless Next.js
- 如何自定义 API 网关域名
- 如何通过 COS 托管动态资源
- 动态资源配置 CDN
- 基于 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 利用,有两种动态资源:
- 我的项目中通过资源引入的形式应用,这种会通过
Webpack
打包解决输入到.next/static
目录,比方.next/static/css
款式文件目录。 - 间接放到我的项目根目录的
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 架构:从原理、设计到我的项目实战》