关于 CDN 前端该懂的一切

[rottenpen]

CDN

前言

这是最近技术分享整理出来的话题，内容大部分摘自阿里云，腾讯云官方文档。

CDN是什么

CDN 的全称是 Content Delivery Network，即内容分发网络。CDN 是构建在 现有网络基础之上的智能虚拟网络，依靠部署在各地的边缘服务器，通过中心平台的 负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞， 提高用户访问响应速度和命中率。CDN 的关键技术主要包括了节点调度、节点负载 均衡和内容存储、分发、管理技术。

为什么要用CDN

使用 CDN 加速前，用户侧发起的请求通过用户侧 DNS 递归到网站 DNS 解析 以后，最终用户侧直接请求网站服务器。这里可能会造成以下几种情况： 1. 中心服务器负载过高，因为所有客户端发起的请求都会请求到服务器上 2. 终端用户内容获取延时高，比如服务器在北京，而用户在广州 3. 服务稳定性差

详细说明如下：

1. 用户向 www.test.com 下的某图片资源（如：1.jpg）发起请求，会先向 Local DNS 发起域名解析请求。
2. 当 Local DNS 解析 www.test.com 时，会发现已经配置了 CNAME www.test.com.cdn.dnsv1.com，解析请求会发送至 Tencent DNS（GSLB），GSLB 为腾讯云自主研发的调度体系，会为请求分配最佳节点 IP。
3. Local DNS 获取 Tencent DNS 返回的解析 IP。
4. 用户获取解析 IP。
5. 用户向获取的 IP 发起对资源 1.jpg 的访问请求。
6. 若该 IP 对应的节点缓存有 1.jpg，则会将数据直接返回给用户（10），此时请求结束。若该节点未缓存 1.jpg，则节点会向业务源站发起对 1.jpg 的请求（6、7、8），获取资源后，结合用户自定义配置的缓存策略（可参考产品文档中的 缓存过期配置），将资源缓存至节点（9），并返回给用户（10），此时请求结束。

CDN的层级划分

• CDN系统中，直接面向用户，负责给用户提供内容服务的的Cache设备都部署在整个 CDN网络的边缘位置，所以将这一层称为边缘层。
• CDN系统中，中心层负责全局的管理和控制，同时也保存了最多的内容Cache。在边缘层设备未能命中Cache时，需要向中心层设备请求；而中心层未能命中时，则需要向源站请求。不同的CDN系统设计存在差异，中心层可能具备用户服务的能力，也可能只会向下一层提供服务。
• 如果CDN系统比较庞大，边缘层向中心层请求内容太多，会造成中心层负载压力太大。此时，需要在中心层和边缘层之间部署一个区域层，负责一个区域的管理和控制，也可以提供一些内容Cache供边缘层访问。

什么是边缘计算

边缘计算是一种分散式运算的架构，将应用程序、数据资料与服务的运算，由⽹络中⼼节点移往⽹络逻辑上的边缘节点来处理。将原本完全由中心节点处理⼤型服务加以分解，切割成更⼩与更容易管理的部分，分散到边缘节点去处理。边缘节点更接近于⽤户终端装置，可以加快资料的处理与传送速度，减少延迟。

阿里云 边缘云ENS / 腾讯云 边缘计算机器 ECM

https://www.aliyun.com/product/ens

https://cloud.tencent.com/product/ecm

下面摘自 ENS 的文档：

开通服务：您需要根据实际业务需求填写开通ENS服务的各项资料。

（可选）创建自定义镜像：阿里云ENS控制台支持通过镜像构建机方式创建自定义镜像，您可以将自定义镜像用于创建边缘服务或升级边缘服务镜像。

创建边缘服务：根据业务需求，您可以在控制台创建边缘服务，明确边缘算力配置、分布，ENS智能选择节点进行批量下发算力。

上线运营：业务测试通过后，正式上线运营。您可以通过ENS控制台管理边缘服务、启停边缘服务、更新镜像、查看用量、进行数据监控等。

工程化上的应用

通过 CDN 减少前端打包体积

防止将某些 import 的包(package)打包到 bundle 中，而是在运行时(runtime)再去从外部获取这些扩展依赖(external dependencies)。

https://www.webpackjs.com/configuration/externals/

module.exports = {
   externals: {
      react: 'react' // '包名':'全局变量' 
   },
	 plugins: [
	new HtmlWebpackPlugin(/** 手动植入cdn 地址 **/ 
		{
				cdn: {
					js: ['cdn地址']
				}
		}
	)
	]
}

CICD 的时候自动上传静态资源到 CDN

https://juejin.cn/post/6952702774644015141

预渲染的边缘计算

SSG：Static Site Generation，静态网站生成

这样做有很多好处：

1. 由于文章内容已经被静态化了，所以它是 SEO 友好的，能被搜索引擎轻松爬取；
2. 大大减轻了服务端渲染的资源负担，不需要额外做一套 Node.js 服务；
3. 用户始终通过 CDN 加载页面核心内容，CDN 的边缘节点有缓存，速度极快；
4. 通过 HTTP API + CSR，页面内次要的动态内容也可以被很好地渲染；
5. 数据有变化时，重新触发一次网站的异步渲染，然后推送新的内容到 CDN 即可。
6. 由于每次都是全站渲染，所以网站的版本可以很好的与 Git 的版本对应上，甚至可以做到原子化发布和回滚。

SSG 的模式比较适用于个人博客/技术文档这种页面数量有限，更新频率有限的网站。但不适用于网页较多，更新频繁的网站。

ISR：Incremental Site Rendering，增量式的网站渲染

既然全量预渲染整个网站是不现实的，那么我们可以做一个切分：

1、关键性的页面（如网站首页、热点数据等）预渲染为静态页面，缓存至 CDN，保证最佳的访问性能；

2、非关键性的页面（如流量很少的老旧内容）先响应 fallback 内容，然后浏览器渲染（CSR）为实际数据；同时对页面进行异步预渲染，之后缓存至 CDN，提升后续用户访问的性能。

页面的更新遵循 stale-while-revalidate 的逻辑，即始终返回 CDN 的缓存数据（无论是否过期）；如果数据已经过期，那么触发异步的预渲染，异步更新 CDN 的缓存。

Incremental Static Regeneration: Its Benefits and Its Flaws

[rottenpen]

补充一下 QA:

公司官网有没有放cdn？

• 看到 www.xxx.com 的 index.html 文件是从正常域名中请求到的，但其他像 js/css 文件，是通过典型的 cdn 域名中获取的。

简单来说就是 CDN 服务商会分配给用户一个CNAME ，需要在域名解析服务商处将加速域名的DNS解析记录指向CNAME域名，访问请求才能转发到CDN节点上，实现CDN加速。 所以说，我们访问 www.xxx.com DNS解析会指向 CDN 的 CNAME，而不是我们中心服务器。 而针对其他 api 请求，调度服务会自动分配最佳的回源路径供用户向源服务器获得想到的数据