用于外链的资源库构建

考虑到可访问性和访问速度,最终还是选择部署在 GitHub Pages 上面,然后再通过又拍云的 CDN 进行加速。

Background

在升级本博客的 hexo 和主题之前,是曾经搞过一个用 Aplayer 实现的外链播放器的,但因为当时播放过程会被在博客中的页面跳转而刷新页面,导致播放被打断而暂停,体验较差,所以在升级主题版本之后一直没有添加回来。在之后的某次逛 Github 的时候,偶然发现 PJAX 可以实现博客内页面跳转使用 AJAX 不刷新页面。于是又再次把 Aplayer 添加回来。

有了播放器,最重要的还是要有音乐,有歌曲。原本想着简单地从网上那些外链播放搜索网站,搜索抓取从各大音乐平台的外链,确实能找到,当时也能用,不过好像一般都会有有效期,过了一天就不能用了。为此,参考别人在 GitHub 开启 Repo 作为图床的想法,我也打算在 GitHub 开个 Repo 来存放图片或音频资源,提供外链。

虽然最后没有在博客上面放音乐了,但还是有些图片资源需要 host,尤其是现在博客同步发布于两个平台,如果图片还是放在博客里面一起发布,每次都要修改。

Methods

GtiHub Repo

想法比较简单,在 GitHub 上面开一个公共的 Repo,通过其单个文件下载的链接作为外链使用。

以创建的 yeung66/resources 仓库为例,我在 music 文件下面的音乐文件,其下载链接为 https://raw.githubusercontent.com/yeung66/resources/master/music/恋爱为何物.mp3,其映射关系还是很直接很简单的。当场生成放到博客测试一下,也能够正常使用,没有什么问题。

然而过了一会儿我在手机上访问时,就发现播放器出现异常,歌曲无法正常播放,在手机上直接访问了一下音乐的外链,无法访问。上网一看才发现,域名 raw.githubusercontent.com 被 DNS 污染了,没有梯子的话不能正常访问,而我在电脑上一直挂着梯子,而且这个网址也在我的 PAC 上面(好像还是我手动添加的),而手机非需要使用时都不会开代理工具。考虑到我的多数访客并不会挂着梯子进来,只能放弃这个方法。

Gitee Repo

既然 GitHub 的资源域名被墙了,那就考虑使用国内的替代品 Gitee 码云。思路也还是一样的,来一个公共 Repo,通过文件的下载链接作为外链使用,大概映射关系为 music 文件夹下的 a.mp3 的下载链接为 https://gitee.com/yeungyeah/resources/raw/master/music/a.mp3。放到博客的播放器中可用,似乎没有问题。

然而今天手机打开测试又再次播放失败了,在电脑上换了电脑测试访问,发现原因居然是访问的资源大小超过 1M 时需要登录,所以使用外链播放时,如果没有登录过的话,会不断重定向到登录链接,然后就一直失败,真的小气。(我专门到 GitHub 上面试了一下,不需要登录也可)。之前我在上去创建仓库的时候,登陆过,所以测试时一起正常。

GitHub / Coding Pages

突发奇想,虽然 GitHub 中 Repo 的文件直接下载链接被 DNS 污染了,但是它提供的 GitHub Pages 是可以正常访问的,而其中的静态文件也是能够直接访问的,那干脆就直接将他们当成 Pages 发布,这样就可以直接使用了,音乐文件甚至能够直接链接打开播放(直接通过 Github Repo 的文件下载链接是可以下载但是不能在线播放的)。在 GitHub 开启了 Pages 测试一下,能访问,但速度实在感人,播一秒卡两秒。

然后想到了现在博客正在托管的 Coding.net 平台(自换域名之后我将所有的解析到解到这里了,国内访问速度满分,但好像 Google AdSense 访问不到了),打开速度非常满意。 于是,我将我的资源 Repo 传到了 Coding.net 平台,开启 Pages 服务,提供资源外链使用。这两者还可以绑定域名,我就顺手绑了个二级域名,爽得直接起飞。 Coding 这个垃圾平台总是反复纵跳,相关的规则变来变去,现在又重新搭上了腾讯云,直接把之前所有部署的 Pages 给停了,而且没给任何的提醒。现在在 Coding 里面使用 Pages,需要使用腾讯云的 Severless 服务实现,而且还是给代金券的方式吸引你过去,之后估计还要收费,有点被恶心到了,果断弃用。

Gitee Pages

在 Coding Pages 挂了之后,只能重新回到 Gitee Pages 的怀抱,虽然 Gitee Pages 免费版不能自行绑定域名,但是它的访问速度和上传速度还是很香的。唯一的麻烦点是,免费版的 Gitee Pages 居然不能够自动更新 Pages 页面,每次 push 之后都需要上网页去手动点更新按钮,比较蠢。

然后找了一些自动化的方法,主要原理还是通过模拟登录 Gitee 来发送更新请求。一开始找了个用 puppeteer 的 js 脚本,直接是搞了个模拟浏览器登录之后发送模拟点击事件,但这个 package 怎么都下不完(需要下一个 chromium 的驱动,走镜像或者走代理都很慢)。然后又找了个使用 Github Actions 的方法,先提交到 Github repo,然后触发 action 在 Gitee 里把原 repo 拉过去,在更新 Pages。昨晚搞了一会儿,把 mirror 的部分用在本地 push 两个 remote 替代了,算是能够实现功能了。但是每次 push 到两个 remote 端,感觉有点浪费,尤其是上传到 Github 的速度属实不给力,走代理也不过百来 kb 每秒。

然后今天早上起来,突然醒悟过来,为啥要用 Github Actions 呢?我直接把他执行的脚本拿到本地,然后在部署的时候在 powershell 脚本里面调用一下不是更方便吗?这样就避免了向 Github 进行无谓的 push,而且账号密码还能存在本地,不需要传到 Github 的secrets 里面。最终的脚本读一个本地的 json 来获取数据,进行自动的更新 Gitee Pages。这样还避免了 Github Actions 登陆地为美国的异地登录的问题(当然我在本地跑的脚本也提示异地登录)。

暂时体验完美。(2020.10.18)

然而 Gitee 使用起来实在是过于不方便,有着太多的限制,最后还是废弃了。

GitHub Pages + 又拍云

网站备案之后,可以使用国内的 CDN 进行加速了,而又拍云可以为加入又拍云联盟的个人网站提供一定流量的 CDN 支持。于是选择使用 (白嫖) 又拍云的 CDN,对网站的资源文件进行 CDN 缓存。在博客的 repo 当中,所有资源都能通过 CDN 加速,比如图片和字体,效果杠杠的。而且对主站进行 CDN 加速之后,相同域名下的所有 GitHub Pages 都会默认就提供了 CDN 支持。在这种情况下,只需要新开一个 repo 存在资源,并开启 Pages 服务,就能够得到一个速度不错的外链图床或资源站服务。配合 PicGo,一键将图片上传到 repo 并获取相应的外链,体验完美。