【第1844期】利用jsDelivr与TravisCI搭建高速CDN

前言

这服务挺好的。今日早读文章由腾讯音乐@boxizen投稿分享。

正文从这开始～～

本文适用于有如下需求的用户：

• 想要搭建属于自己的图床或CDN

• 力求流程简单且服务稳定高效

• 不想花钱

背景

相信很多人使用过 Github Pages 来搭建静态页面，这的确是个很好的网页寄存服务，但由于国外网络原因，访问起来速度慢，甚至经常抽风。

针对这问题网上有过一些解决方案，常见的是使用国内 CDN 加速，好办法但缺点是域名需要备案，不论你买的是国内还是国外的域名(腾讯云是如此，求证实)，而备案的正常流程需要走 21 个工作日；其次也有人提到用 coding (国内版github) 的 Pages 服务再部署一套，由于 coding 的机房在国内，访问起来速度也会有所提升，缺点是需要额外再部署一套代码。

那有没有不需要备案，访问起来快而且还免费的CDN可用呢？jsDelivr就是其中之一，事实上也有很多人通过把业务代码中的资源链接替换成 jsDelivr 链接来解决这个问题，但在很多经验贴中这里还需要一些人为的操作成本。

jsDelivr

简而言之 jsDelivr 就是一个为开发者提供免费公共CDN 加速服务，由于是国外的CDN服务，好处是可以免备案，同时由于在中国也有 ICP，所以国内访问起来速度也杠杠的。如今 jsDelivr 已与 npm 和 github 完成深度集成，可以直接通过 jsDelivr 来访问 github 上的资源。

下图为 jsDelivr 节点分布图(注意关键词 works in China)，从地图上来看中国地区也分布了多个节点。

jsDelivr节点分布

jsDelivr 链接格式为：https://cdn.jsdelivr.net/gh/用户名/仓库名@发布版本号/文件路径，这里可以看出 git 仓库需要走 release 发布才能被 jsDelivr 所引用，这也是比较麻烦的一点，比较自动化的方式是在仓库提交时触发 CI 构建部署，提交打 tag 和 release 发布，而在实际操作过程中也会有些坑。

构建发布

以 Github Pages 为例，如果想要页面上线后引用的静态资源链接替换成 jsDelivr 链接，正常流程如下：

github cdn资源

而本地的构建和替换可以通过加入 CI 来减少人为操作成本，这里需要增加开发分支，gh-pages 只作为发布分支，由 CI 完成推送部署，那么流程可以演变为：

github cdn资源

本文使用了 Travis-CI 作为静态资源构建发布的 CI，关于 Travis-CI 不做过多的介绍，作为 github 近乎标配的 CI 工具，其完整的生命周期如下所示，根据钩子的名称容易理解其含义。

• [OPTIONAL] Install apt addons

• [OPTIONAL] Install cache components

• before_install

• install

• before_script

• script

• aftersuccess or afterfailure

• [OPTIONAL] before_deploy

• [OPTIONAL] deploy

• [OPTIONAL] after_deploy

• after_script

并在在项目根目录下添加如下配置：

1. language: node_js

2. node_js:

3. - "v8.12.0"

4. branches:

5. only:

6. - dev

7. cache:

8. directories:

9. - node_modules

10. before_install:

11. - export TZ='Asia/Shanghai'

12. install:

13. - yarn

14. script:

15. - yarn build

16. deploy:

17. provider: pages

18. skip-cleanup: true

19. github-token: $GITHUB_TOKEN

20. local-dir: dist

21. target-branch: gh-pages

22. verbose: true

23. on:

24. branch: dev

但这里我们会发现还是免不了本地打 tag 和 github 上点 release 发布这个步骤，仔细查看文档发现 Travis-CI 在 deploy 周期里还提供了 releases 的 provider 来解决手动发布的问题，并且支持设置多个 provider 来完成复杂部署的问题。因此我们是可以通过在 before_deplopy 钩子中完成 commit 打 tag， 并在 deploy 中执行 releases 的 provider 来实现自动化打 tag 与 release 发布。不过这种方式却不适用于本案例，原因在于 Travis-CI 触发的提交来自开发分支，而打 tag 和 release 是针对部署后的 gh-pages 分支。

deploy 中的多 provider 方式无法满足跨分支的部署发布操作，但别忘了还有 after_deploy 的钩子，几经尝试, 本人把切换分支，fetch拉取，commig 打 tag 和 release 发布的相关操作封装成后置脚本，并在 after_deploy 中声明调用，配置如下：

1. deploy:

2. provider: pages

3. skip-cleanup: true

4. github-token: $GITHUB_TOKEN

5. local-dir: dist

6. target-branch: gh-pages

7. verbose: true

8. on:

9. branch: dev

10. # provider: releases

11. # api_key: $GITHUB_TOKEN

12. # file: dist/*

13. # skip_cleanup: true

14. # on:

15. # tags: false

16. after_deploy:

17. - node ./scripts/release.js $GITHUB_TOKEN

优化后的流程如下：

github cdn资源

如此以来只要本地完成提交推送后，线上的 Github Pages 页面的静态资源将会被全量替换为 jsDelivr 链接，对于纯静态资源的提交发布流程也是类似如此。

当然在部署后置脚本中还可能会遇到一些小问题，如 Travis-CI 每次触发构建时基于节省资源和构建速度的考量，仅仅会 clone 提交所在分支的仓库，这在 checkout gh-pages 分支的时候会有问题，因为根本找不到该分支的，这可以通过添加远程分支源来解决。

速度对比

github自带cdn速度：

github cdn资源

jsDelivr加速后：

github cdn资源

而你需要做的仅仅是把本地资源推到 github上，真香！

关于本文 作者：@boxizen 原文：https://www.zybuluo.com/boxizen/note/1547108

为你推荐