关于阿里云:云原生-06使用-Vercel-NextjsMidway阿里云函数计算部署前端应用

8次阅读

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

系列专栏申明：比拟流水，次要是写一些踩坑的点，和实际中与文档差距较大的中央的思考。这个专栏的典型特色可能是 次佳实际，争取能在大量的最佳实际中生存。

一些概念参见部署架构设计。

对于 FC，没有选型 Custom Container，因为冷启动太显著了，耗时和罗唆 504 频率太高，除非维持一个长期的兜底热容器，否则天生无奈解决
对于 Midway，没有选型自带的 npm run deploy 模式，而是 npm run package 后将 serverless.zip 传到了 OSS 制品仓库，是因为在现阶段 git commit 和 build artifact 还能难做到一一对应，实际上还是要以 build 为准；典型的场景是事变回滚，重新部署一个 build 是比拟有信念的，而指定一个 git commit 再执行一次 build 是没有信念的

index.html 和 rsrc 是同一个 制品，体现在这个架构图上，即都被打包到了 serverless.zip 中，也即拜访 https://app.../index.html 和 https://app.../rsrc/ 可能拜访到相应的文件；然而咱们会应用一个名为 rsrc.cdn 的配置项，指定用户去拜访 https://cdn...

<!-- template -->
<html>
  <body>
    <div id="root"></div>
    <script src="{rsrc.cdn}/rsrc/dist/umi.js" />

<!-- profile=local -->
<html>
  <body>
    <div id="root"></div>
    <script src="http://127.0.0.1:3000/rsrc/dist/umi.js" />

<!-- profile=prd -->
<html>
  <body>
    <div id="root"></div>
    <script src="https://cdn.../rsrc/dist/umi.js" />

实践上，应该将制品中的 public 这个文件夹上传到 bucket-cdn，但这样就须要实现相应的受权 upload 流程，所以这里采纳了回源模式：
1. 北京用户拜访 https://cdn…/rsrc/dist/umi.js，北京城市节点没有，于是向 oss/bucket-cdn 回源
2. 对于第一次拜访，oss/bucket-cdn 也没有，于是向 http://app-vpc…/rsrc 回源；此时会启动一个 FC，oss/bucket-cdn 于是失去了这个文件，并顺申请的原路返回给北京用户
3. 上海用户拜访 https://cdn…/rsrc/dist/umi.js，上海城市节点没有，于是向 oss/bucket-cdn 回源，这次有了，所以不必持续向上回源，能够间接返回
4. 以上每个申请都会独立的唤起一次 FC（不思考云厂商智能复用的状况，作为开发者咱们须要把这里设计为无状态的），即 index.html / umi.js / umi.css 会唤起 3 次 FC
5. 当 CDN 热身实现后，只有每次申请 index.html 会唤起 1 次 FC

以上这个模型是齐备的，但还缺最初一公里。阿里云的 FC 目前没有 Edge（文档上仿佛有内测，但感觉还不能用），因而所有申请到 index.html 都必须由杭州的 FC 来承当。

对于其中 SSG 的局部，比方 index.html，咱们能够应用相似 cdn 回源的形式部署到阿里云各城市节点上，但这须要本人设计和实现。Vercel 是原生反对的。对于其中 SSR 的局部，比方 account.html，目前只能通过唤起杭州的 FC，Edge Script 离能用还有一段距离。而 Vercel 也是原生反对的。这就是云原生生态的力量，并不是实现了每个粒度的性能让开发本人去组合，而是间接依照开发应有的行为去提供一个整合的产品。这里确实损失了自由度，但这些自由度原本就是开发所不须要的，开发应该聚焦在交付业务性能上。

Vercel 十分激进的基于 GitOps，严格由 Git Commit 来触发公布，从而导致短少了制品这个概念。这会带来两个问题，一是因为 IaaC 很难残缺施行，Commit 对依赖的治理并不能齐全锁定，所以对同一 Commit 的再次 Build 并不能失去 Immutable 的后果，这样回滚还不如向后修复（当然，在麻利的开发文化里的确只有向后修复，兴许这在 Vercel 的生态里不是问题）。

第二个问题是，Vercel 上永远只有最新版的代码，这样如果客户端有缓存，那么去拜访上个版本的资源时就会生效。无论开发文化如许麻利，这样看待客户体验的形式是不对的。如果在现有的 Vercel 上要解决这个问题，就必须和 App 一样执行语义版本，将语义版本和 Build 版本对立，即应用 /index-1.0.html + /rsrc/dist-1.0/umi-1.0.js。这个实际对开发尚且有难度，对经营则是齐全不可能的，当链接地址投放进来当前，比方打印到了海报上，是物理上不可能降级的。Vercel 这种纯线上的格调，在落地时是行不通的。

解决的计划比拟毛糙，演示意义大于实际意义，从生态上看，应该是由 Vercel 和 FC 各自去欠缺本人的产品。

感觉就差一个可观测性，这个系列的文章就闭环了。

Vercel 真的是太快了