适合个人网站的云服务组合

date
Dec 21, 2023
note
slug
cloud-for-personal-website
type
Post
status
Published
tags
Web
技术
summary
回想起来我折腾博客和各类网站已将近 10 年光阴,在维护 0xFFFF 的几年来,也尝试过各类不同的建站方案。当前用到的各类服务,综合速度和成本而言,感觉可能的选择方向差不多已经成型,可以做一个总结。若你也想低成本搭建属于自己的网站,且想拥有不俗的访问速度,这里的方案也许可以是你的一个参考。
old_url
回想起来我折腾博客和各类网站已将近 10 年光阴,在维护 0xFFFF 的几年来,也尝试过各类不同的建站方案。当前用到的各类服务,综合速度和成本而言,感觉可能的选择方向差不多已经成型,可以做一个总结。
若你也想低成本搭建属于自己的网站,且想拥有不俗的访问速度,这里的方案也许可以是你的一个参考。

基本结构

抽象地说,运行一个网站需要的能力主要分两大块,一是域名与 DNS 解析,二是负责处理浏览器请求的服务器端。从需求来看,域名和 DNS 的能力相对比较固定,而服务器端需要的能力就比较多样,按角色和常用的业务来区分,可以分为这几类:
  1. 接入层网关、反向代理:接收用户流量,转发到对应的服务
  1. 静态页面:HTML 网页 / Jamstack 应用的 Service-side Rendering
  1. JS / CSS 等:通常会通过第三方域名 CDN 分发,提高网页的打开速度,减小对主站的依赖
  1. 媒体类附件:网站流量消耗的大头,通常托管在对象存储,也可通过 CDN 分发
  1. 动态服务:当一个网站需要交互的能力,需要有服务承载相关的 API 接口
动态服务而言,大致可以按“无状态服务”和“有状态服务”去区分,无状态服务可以随时创建和销毁,有状态服务则需要持久化服务产生的数据。部分服务可能还需要数据库和缓存服务等的支持,类似 MySQL、PostgresSQL、Redis 等等。
当前云计算已经足够发达,基本你能想到的点,都有对应的云服务提供,因此也可以根据实际需要和网站的功能,来选择合适的服务去支撑。写这篇文章的主要目的,也是分享我当前在用的服务,以及选择 / 不选择它们背后的一些考虑点。

DNS 与接入层网关

DNS 方面我选择 DNSPod,考虑点在于它有中国大陆内的解析节点,并且在专业版可以支持全球服务器的解析,价格还可接受。最关键是它提供了精细化地在不同的地域去做分流解析的能力,这对于部署在海外的站点是非常有利的,可以针对大陆用户去专门部署优化的线路,相比于 Cloudflare、ClouDNS 等会更加灵活。
接入层网关方面,关注目标在于,地域上离用户越近越好,可以针对不同地域用户使用针对其最优的线路,以减少网络层面的不确定性,尽可能和用户维持稳定的连接。对应的服务选择,一是支持动态请求链路优化的 CDN 服务,二是网络条件较好的云服务器,三是现今一些支持边缘计算的网站服务商(如 VercelFly.io 等),通常它们的边缘节点之间的链路会做一些特殊优化,可以合理使用利用起来。
这里我选择二、三两种方案结合,以一个阿里云香港的轻量服务器来承接来自大陆的流量,其他地域的流量通过 fly.io 承接,用 DNSPod 实现按地域的分流。目前(2023年底)的阿里云 hk 轻量服务器的网络质量非常优秀,全大陆访问的延迟可以 控制在 50ms 内;Fly.io 的好处则在于,他们有一个连通全球的边缘计算网络,理论上我只需要在我想要的地域部署服务,其他地域可以直接通过边缘节点接收用户请求,然后再在内部转发到服务所在地域的计算实例,网络请求相对也会更加可控一些。两者结合下来,实现各自中国大陆内外优势的互补。
对于反向代理的程序,这里直接用 Caddy Server,无论在轻量服务器还是 fly.io,只需做一些简单配置,就能实现流量转发,并自动申请签发配置好 https 证书,非常简单方便。
:80 { redir https://0xffff.one } 0xffff.one { reverse_proxy http://123.123.123.123:80 { # 可以在 header 加个标记供下游服务器识别来源 header_up +From-HK "true" } }

静态页面

众所周知,大部分网站、Web App 等实质上由静态的 HTML 网页以及各种脚本、样式图片音频资源等组合,因此托管静态页面和资源,应该是建站最基本的需求。
这方面的托管,基本没什么障碍的点,无非就是维护成本方面的差异,无论 VercelFly.ioGitHub PagesCloudflare Pages,还是自己架 HTTP 服务器部署,都没有什么毛病。部分服务还提供了适应静态页面渲染的边缘节点。
当前我是用 Vercel 多一些,本博客和 0xFFFF Wiki 都放在这上面,主打一个简单直接方便,push 代码直接就能自动触发构建和部署,非常省心。

静态资源、CDN

浏览器下载 HTML 后,通常需要加载脚本、样式、图片等资源,这会带来一个额外的流量消耗。接入层网关本身的带宽成本相对要贵一些,且访问速度方面不太可控,通常会单独对 HTML 外的资源,去根据访问情况做分布式的缓存。这也是 CDN 的一大作用,CDN 以大带宽低成本的优势,分摊源站点的流量,提升用户的访问体验。
这里我主要选择了 Bunny CDN,以及腾讯云 CDN 做大陆的静态资源加速。前者在价格和速度方面非常有优势;后者结合已备案域名,在大陆的访问体验更佳。主要考虑的点还是在速度方面的提升。

媒体类附件

一个网站的静态资源通常分为两部分,一部分是网站本身业务逻辑的一部分,这部分可以提前处理好交给服务托管;还有一部分是用户操作过程中新增的上传、后台处理需要的图片等,这种类型的数据就很适合放在对象存储上。
适合个人站长的选择不是太多,这方面鼻祖自然是 Amazon S3,不过传闻贼贵,不是一般学生可以承担的那种;另外还有国内大厂的 COS / OSS,Cloudflare R2,Backblaze B2 等。
Cloudflare R2 是很好的选择,它流量费全免的机制非常适合新手上路研究,但 Cloudflare 要求绑定的域名的 NS 记录都指向他们的 DNS 服务器。也就是说会和 DNSpod 的分流策略所冲突,无奈忍痛放弃。
经过一番尝试,发现 Blackblaze B2,这一服务在成本方面极具优势,虽然没有 Cloudflare 的 CDN 免流量费香,配合 Bunny CDN 去处理,效果还挺不错,0xFFFF 主站重度使用半个月下来,流量也才 2G 左右,费用 0.04 美分。
注册时记得选择 US West,距离大陆近一些,注册成功后改不了。
注册时记得选择 US West,距离大陆近一些,注册成功后改不了。
Bunny CDN 和 Backblaze B2 有 合作,可以优化接入相关体验。B2 官方还会有一些教程和文章,做的还挺贴心细致的:AWS CloudFront vs. bunny.net: How Do the CDNs Compare

动态服务

对于功能更强大的网站,静态的网页文件不太能满足需求,这时候就需要有后端服务支持,通常这类后端服务可能会提供以下的能力:
  1. 动态生成 HTML
  1. 根据请求 API,动态生成响应,驱动业务逻辑
  1. 可能根据需要,生成其他资源(图片 / 待下载的文件等)
如开头所说,动态服务有无状态服务和有状态服务两种:
  • 无状态服务:fly.io 会更适合,它可以以 Firecracker 虚拟机的形势一键部署运行 Docker 镜像,并快速部署到合适的地域,减少网络延迟的影响
  • 有状态服务:用一个单独的 VPS 来处理比较合适,这里我继续用了阿里云香港的轻量服务器,业务规模不大的情况下,一台机器足矣。这里可选项有很多,腾讯云、AWS 的 LightSail、Vultr、Linode 等也是不错的选择,最重要是稳定和可靠
一个可行的方向是尽可能把服务做得无状态,可以部署到边缘节点的话速度会更具优势(但同时也需要考虑不同地域之间状态共享的问题)。

数据库

我原本比较倾向在本机去部署网站的数据库,但经历过一次误操作导致 论坛数据丢失 的事件,也让我心有余悸,一方面日常备份得加强,另一方面也在考虑把数据库维护的工作交给专业的 DBA 服务。
这类服务通常很贵很贵,但感谢互联网,低成本的 Serverless 托管 DB 方案还是有的,目前看 TiDB Cloud 和 PlanetScale 的免费额度能覆盖到,大概一点缺点是公网访问数据库,延迟会对应提高,需要做好 cache 的方案。目前亚太地区只有新加坡和东京机房,可能需要考虑把计算实例挪到新加坡区域(接入层可以不动)。
有的站点会依赖 Redis 做 cache 或者 DB,这时候也需要考虑备份和托管的方案,目前 Upstash Redis 应该还不错,看 fly.io 和他们合作搞了内部方案
如果业务涉及到大量 SQL 查询(博客 / 论坛等),还是需要单机部署数据库,那就需要从备份入手。这里的一点经验也是,在跑数据库的容器加入定时任务,然后定期 mysql dump 出最新的 sql,gzip 压缩作备份,再保存到备份专用的对象存储桶中,备份软件推荐 Deplicati,存储桶我用的腾讯云的 COS。

引荐链接

若本文对你有所帮助,有需要的话,可以通过下方的引荐链接注册对应服务,可以为我多增加一些账户余额:

参考

 

© zgq354 2014 - 2024 | CC BY-NC-SA 4.0 | RSS