近半年的 0xFFFF 看起来可能没啥动静，但其实内在基于 Flarum 做了不少天翻地覆的改造，这其中默默写代码居多。为让更多人能够参与进来，感觉有必要开个新楼，记录最近的变更。

最大的变化是代码改动、开发环境基本都统一收归 Flarum 0x 这个项目仓库中，另外还有一些功能的更新。

Flarum 0x

过去 0xFFFF 的开发运维，整体经历了几个阶段：

  1. 18年：VPS 手工部署和代码改动（beta.9 版本）
  2. 19下半年：从手工部署到 Docker 化部署，参考并抽提出单独的仓库维护环境、项目配置（beta.14）
  3. 21下半年：更新至 v1.0 stable 版本，功能改动趋于稳定
  4. 22年底：整体迁移至 fly.io ，结合 patch、Docker 形成新的打包部署方案

从过去的 0xffff-flarum 更名为 Flarum 0x 重新起航，意为 0xFFFF 定制的 Flarum，主要着力于以下几方面：

  1. 沉淀论坛需要的自定义改动
  2. 现代化的云上开发、部署流程
  3. 降低门槛，更多人参与 flarum 的维护，回馈社区

主要的改动：

  1. patch 机制完善，避免直接改动 composer 依赖文件导致难以追踪
  2. 基于微软 Dev containers 做了个专门的 devcontainer 配置，在有 docker 环境的机器、GitHub Codespaces 上可以一键跑起 flarum 开发环境，降低环境配置门槛

功能优化

  1. 附件、头像存储迁移到 Cloudflare R2 对象存储
  2. 图片加载优化：为帖子图片补充 image size 尺寸防止加载过程中发生漂移 #31；并增加 img-proxy，针对文件体积大的图片适当压缩尺寸
  3. 针对 JS / CSS 加载，可以支持配置通过 CDN 加载
  4. 在 config.php 的自定义 Head 支持 <script> 等标签
  5. 基于 jsdelivr 的 Emoji、静态资源等改为走 ByteDance 的 CDN，避免无法访问

欢迎参与

由于我个人工作和生活日渐忙碌，能投入社区开发的精力和时间都越来越少。因此也期待更多人能参与进来，逐渐能脱离我的依赖去运转就更好了。

Flarum 的开发主要侧重于小型 Full-stack Web App 的领域的经验积累（Laravel, Mithril.js, 思维模型类似于 Spring + React），同时其拥有相对完善的插件架构，干净简洁的代码；另外在这个过程还会涉及到 LEMP（Linux + Nginx + MySQL + PHP）、Docker、各类 DevOps 工具等，覆盖了一个相对广但完整的知识面。

GitHub：0xffff-one/flarum-0x

目前所有的开发动态都在 0xFFFF Discord 的 #dev 频道 更新，有兴趣的朋友或者有什么想法，都可以参与进开发讨论。

后续有啥功能改动，会在楼下继续持续更新

5 天 后

把注册人机验证从 Google 的 reCAPTCHA 换成了 Cloudflare 的 Turnstile，操作更加简便。

新注册用户可以不用再点红绿灯，被自动驾驶白嫖智力了～

6 个月 后

时隔半年再记录下，比较重大的更新：

0xFFFF 主站搬到 fly.io 之后，我也一直在想办法优化站点的访问速度，虽然静态文件走已备案域名的大陆 cdn，但主域名动态内容访问的延迟仍还是硬伤。之前论坛部署在 fly.io 的东京机房，大陆访问 fly.io 的 Anycast IP，路由上会走 NTT 线路和 PCCW 线路，或者从美国绕一圈再到东京，高峰期访问速度和丢包都很不理想。

这里的缓解方式也是，放一个在香港的反向代理来承接来自大陆的流量，其他流量可以直冲 fly.io，再考虑用 DNS 做按地域分流。目前看阿里云香港轻量的速度与性价比都还不错，DNSPod 的免费版也可以实现分地域解析的能力，专业版会更细致，价格还可接受（¥99/年）。

另一点速度瓶颈在于，网站依赖 Cloudflare（简称 CF）默认的 DNS 和 CDN 带来的额外延迟，CF 本身承载站点众多，存在一定的因滥用被屏蔽的风险，且在大陆访问也不算稳定。另外他们家对象存储 R2 有强依赖 CF 的基础的网络架构，因而也会受限于这里的延迟乃至不可达。

针对 CF DNS 和 CDN 的问题，这里的思路是用低成本的替代品来实现，DNS 走 DNSPod 可以满足需求，发现一个 Bunny CDN 也可以满足这方面需要，由于 R2 没法离开 CF 的 DNS，并且附件的域名是 static.0xffff.one，CNAME 接入需要企业版本负担不起，只好另外再找对象存储服务。调研了一波发现 Backblaze B2 ，配合 Bunny CDN 还挺合适，而且价格于 0xFFFF 的小众规模而言，属于是非常便宜。

这其中未注意到的细节是，MySQL 跑在 fly 的带 volume 实例上，可能存在风险。前段时间想把 MySQL 实例从东京挪到香港，因意外操作导致 数据丢失，还好在坛友给力帮助下救了回来。意识到在 fly 的分布式边缘服务器维护有状态服务的坑还是很大，通常情况下只能靠备份和第三方服务去兜底，所以综合来看，小型的有状态服务还是用传统 vps 来承载合适一些，无状态服务适合交给 fly。

综合以上以及其他细节考虑，也得到一个新的部署方案，对应服务的选择：

  • 接入层网关：阿里港区轻量 vps + fly.io，然后 DNSPod 分流
  • 业务逻辑 + DB：另一台港区轻量服务器
  • JS / CSS 静态文件：腾讯云 CDN + Bunny CDN
  • 图片附件：Backblaze B2 + Bunny CDN
  • 压图服务 img-proxy：fly.io + Bunny CDN
  • 备份方案：腾讯 COS 广州、香港两地同步（定期 rclone + duplicati 备份）

以此实现剥离开对 Cloudflare 的依赖，速度已不再是瓶颈；并且业务状态都集中在一台机器，可维护性得以加强。

后续进一步的方向：

  1. 完全干掉 Flarum 实例对单节点状态的依赖，实现灵活水平扩展
  2. 数据库交给专业的 DBA 服务维护，关注低成本的托管 DB 方案，目前看 TiDB Cloud 和 PlanetScale 的免费额度能覆盖到，但可能外网访问数据库延迟会对应提高。目前看亚太地区只有新加坡和东京机房，考虑把计算实例挪到新加坡区域，目前在尝试 TiDB + 新加坡 AWS 的 LightSail 实例。
    3 个月 后

    0x0001 港区 vps 与 fly.io 通过 DNS 分流同时使用有一个坑点，Caddy 服务器的 HTTPS 证书依赖 HTTP 访问方式做身份校验，在自动 Renew 证书的时候，会因为校验请求打到了 fly.io 导致无法通过校验。

    解决方案是在 fly.io 部署 Caddy 的 Caddyfile 配置加一行针对 HTTP 校验用的 .well-known 的转发：

    {$MAIN_HOST} {
  reverse_proxy {$ORIGIN_HOST}

  handle /.well-known/* {
    reverse_proxy {$CDN_EDGE_HOST}
  }
}

    三个环境变量：

    • MAIN_HOST: 即 http://0xffff.one
    • ORIGIN_HOST: 源站的地址，我这里是 http://[IP 地址]
    • CDN_EDGE_HOST: 港区 vps 的地址，格式一样
      13 天 后

      0x0001 所以其实现在只有网关和压图跑在 fly.io 上了吗？既然业务逻辑和 DB 都已经放在 阿里hk 了那么将其他服务部署在 fly.io 上是为了什么？ 阿里云挂了的话一样是全挂啊。

          M1saka10010 所以其实现在只有网关和压图跑在 fly.io 上了吗？

          是的，另外压图有单独的 cdn 缓存

          M1saka10010 将其他服务部署在 fly.io 上是为了什么？

          这里主要是响应速度的考虑，fly.io 的网关主要是用来承载海外流量 & 搜索引擎流量，借助 fly.io 节点之间的内网优化访问速度，我们有在英国的坛友；另一个在阿里 hk 的网关主要服务于大陆的坛友。

          可用性主要是日常的数据备份，挂了再单独起一个机器就可。

                0x0001 那其实海外直接白嫖 cf 不好吗 早期 cf 可以 cname 接入，现在也有方法不用ns接入的。

                    M1saka10010 不用 R2 和 CDN 的话，感觉白嫖的意义其实不太大了，b2 + bunny.net + fly.io 更快一些，成本几乎可以忽略不计 🤔

                      © 2018-2025 0xFFFF