• 站务
  • 网站进一步的升级工作

转眼一年过去,从 0xffff.cf 到 0xffff.one,也正是有大家一直以来的关注、讨论与沉淀的支持之下,网站才坚持至今。过去由于我个人一直处于大学中最为忙碌(各种琐事缠身)且迷茫的阶段,未能有足够的时间与精力完善本站。一年多来,在我们一点一滴的讨论的积淀之下,渐渐带来了一定的影响,对于打破身边同学对于计算机学科的迷茫也产生了一点儿效果。作为站长,我最近的许多事情渐渐安顿下来,未来也主要投身于 Web 相关技术的研究,所以也可以说是能集中精力于本站的维护与优化上了。

网站到目前为止仍然有许多问题,主要集中在这几方面:

  1. 网站的框架问题,本站基于的 Flarum 从发起至今已经五年,仍然处于 beta 版的不稳定状态,目前已经发布了 beta.9 版本,相比于本站目前用的 beta.7 版本,其中插件 API 经历了较大的改动,需要重新基于新的版本改进与部署。而且,目前这个项目主要的发起人选择了离开,发了个 farewell,投身了新的项目的开发中,社区维护的力量明显地不足。
  2. 功能上,我们缺少的功能还很多,比如说暗色主题数学公式,比较友好的附件、剪切板贴图上传、大图显示等等。
  3. 基础设施,访问速度的问题,由于域名的原因,暂无法实现使用大陆的服务器,过去网站是用 CloudFlare 的免费 CDN 与我个人的一个位于美国的 VPS 跑起来的,在大陆的访问速度还是比较慢,虽然说在魔改了许多东西之后速度有了一些改善,但还不够稳定。特别是针对移动端的环境,仍然有许多不足。
  4. 开发部署流程比较原始,还是通过 SFTP 上传的方式部署到网站中的,即使有版本控制,对于一些修改也难以跟踪和完善,而且环境的搭建也纯手动(比如说现在我已经忘记了当时部署网站时安装和配置过什么)。

经过一段时间的思考,目前打算对本站做出如下一些改进:

基础设施上:

  1. 搬迁到更好的服务器,提高响应速度(目前已经准备好一个位于 hk 的服务器
  2. 考虑到服务器的带宽不足,通过稳定的 CDN 实现静态资源加载。(买了阿里云的 CDN)

程序架构、开发流程上:

  1. 运行环境采用 Docker 部署,与代码分离。通过 docker compose 容器编排的方式,把 Nginx、PHP、MySQL 等需要的程序环境统一地配置起来,网站代码则存放在宿主机中,避免直接配置环境产生的副作用。
  2. 通过 Traefik 实现网站的反向代理,支持证书、http2、与 Docker 容器的对接等工作。
  3. 重建代码库,以新版的 Flarum 脚手架为起点,记录每一点的改动。
  4. 引入 CI (持续集成),在 git push 之后能自动化地完成代码同步,composer 依赖安装,网站的更新与构建等工作。

对于一些通用功能插件,预期是通过本站的不断完善的动力与产出,丰富插件生态,回馈 Flarum 社区。目前已经将一些待改进的插件 fork 到了我们的 Github 组织,在本站的改进中,一些通用的改进会同步到这里。

在代码与基础的开发流程明确下来以后,未来也将会进一步地优化各方面的体验、SEO、完善网站的 PWA,提升首屏加载的速度等等(特别是微信环境下的速度)。

若你对本站的维护或 Web 相关的技术有兴趣,欢迎交流,也可以加入我们的讨论群,或是通过其它的方式联系我~

大家对于网站的更新、功能的完善有没有什么想法呢?

24 天 后

2019年8月30日 更新
已迁移至最新版的代码,并且搬到了 hk 的服务器,接下来将会修复更新之后可能的BUG,还有进一步的优化

晚上继续优化了一波网站,主要有以下更新:

  1. 启用了HTTP/2
  2. 开了gzip压缩节约带宽
  3. 切换到了 PHP 7.3 的 Docker 镜像
  4. 启用了字节码缓存 Zend Opcache、Composer autoload 优化
  5. 还有附件 CDN 回源地址更新,反代与服务器之间网络通信方面的优化

接下来的目标:

  1. 默认的 CSS、JS资源、用户头像套上 CDN
  2. 去掉官方的URL路径拼接的函数
  3. 修复更新后缺失的 xunsearch 中文搜索支持
  4. RSS Feed 输出修复
  5. 尝试升级到 PHP 7.4,它有个更彻底的 opcode 缓存,感觉可以用上
  6. 样式和字体、翻译文案优化
  7. 完善 Service Worker,争取实现一个完整的 PWA 应用
  8. 做好本站的 SEO
0x0001 更改标题为「网站进一步的升级工作

截至2019年9月3日14点15分,已完成的优化:

  1. 升级 PHP 7.4 beta4
  2. CSS、JS资源、头像等套上 CDN
  3. 修复 URL 路径问题

依托于 Docker、Github、Travis CI 的便利,目前跑通了整个网站前后端开发环境与构建部署的流程,预计接下来可以实现在空余时间内持续迭代完善本站。
有空再总结一下部署的过程中遇到的问题和解决的历程~

目前在关注的目标:

  1. 修复更新后缺失的 xunsearch 中文搜索支持
  2. RSS Feed 输出修复
  3. 样式和字体、翻译文案优化
  4. 完善 Service Worker,争取实现一个完整的 PWA 应用
  5. SEO 优化

后续:这里的 PHP 7.4 容器没配好,GD 库的 jpeg 支持挂了,在折腾配置之前暂时回滚到 PHP 7.3

5 天 后

payne 嘿嘿!曲线救国😆
等我把反代和后端之间的通信换成 http2,应该就无敌了~

2019年9月8日 更新
ISCNU 强力支持下
加入了大陆版的 CDN (0xffff-cdn.iscnu.net),实现本站静态资源的极速加载


在这里必须得打个广告~
若你是 SCNU 的学生,且对 Web 应用开发、运维、教育网 PT,网站建设、新媒体运营、信息素养的普及、阅读推广等等等等等等一切网络和知识连接相关的事情感兴趣,ISCNU 网络协会一定不能错过。

网站:https://i.scnu.edu.cn/
微信公众号:

    7 天 后

    昨天修好了 manifest.json,用 Chrome 手机版的话应该可以添加到桌面了~下一步继续修复搜索的问题


    统计了一下,还是……不是特别快,但已经不错了。有时甚至比美国的CN2-GIA慢,不知道是否线路的问题。
    主要是maxcdn比较慢。

      token7
      线路的确是个问题,HK 的小机性能捉急,所以它只做反代,流量导到了我的一个在广州的腾讯云的学生机来跑,一个请求会在广州和香港之间走两个来回。之前我在源站输出做了 gzip 压缩的优化,单个请求传输到反代的大小可以到 40kb 左右。目前的瓶颈应该应该还是带宽和延迟方面,我已经全链路都上了 HTTP/2,反代和源站之间只有一个 TLS 连接,多路复用之下,减小握手的消耗。

      之前有留意到的表现是,它在公司内网直接访问非常迅速,但在移动端或者深圳电信的网则一般般。
      类似 iosmanthus 的情况。

      刚刚看你这么一说,突然想起,可能是拥塞控制的问题?
      然后刚刚试着给反代服务器启用了 Google 搞的 TCP BBR 算法,似乎出现了立竿见影的效果(???)

      PHP 这边接收请求到响应生成完毕需要 130-200ms 左右(有毒 Laravel),减下来这个延迟也许可以说是能实现秒开的!

      所以接下来目标是给源站也上 TCP BBR 试试,但 Ubuntu 版本还是 16.04,Linux 内核版本还是 4.4 的,得先升级一下。

      进一步优化的话,大概会考虑 QUIC 协议,还有就是从压缩传输数据大小的角度考虑吧,目前看首页加载的数据有很多冗余,这个过程涉及源码层面的改造,所以也是得有空的时候再搞搞。

        0xdeadbeef 看到网站能渐渐地让身边变得更好一些,心中有些莫名的动力,好像也就没什么辛苦了hhh

        5 天 后

        token7 的确,不过搬砖了之后还是可以接受的,未来或许可以考虑众筹一波

        感谢 @0x709394 也加入了修 BUG 研究插件的行列,一波鸡血注入,又有了优化开发流程的动力。

        所以今天重新梳理了站点的代码发布方案,各个自定义的插件从聚集在一个仓库分拆成独立的仓库,然后通过 git submodule 来组织各个仓库的代码更新。

        除了脚手架项目涉及敏感信息之外,把核心和语言包、还有各个插件的魔改都开源了,日后会把脚手架的公共部分也抽离出来,方便折腾。

        目前定制了包括核心在内的 3 个组件,都在 0xFFFF 组织的仓库下:
        https://github.com/0xffff-one/core
        https://github.com/0xffff-one/lang-simplified-chinese
        https://github.com/0xffff-one/user-bio

        更新架构之后,修复了中文语言下日期显示,语言包文案,重新加入了个性签名插件,未来 LaTeX 和中文搜索等插件也可在此加入。

        欢迎研究和折腾,若发现代码中潜在的安全问题,请联系我:zgq354@gmail.com

        背景

        Flarum 本身设计了一个灵活的架构:网站主体只是一个脚手架,负责各种配置和文件等,然后用依赖管理工具 composer 的机制,所有的核心功能和扩展在脚手架的角度都以第三方插件的形式加载。官方再开发和维护核心插件,开发者可根据自己的需要去定制插件扩展。其中,脚手架负责存储,数据库,文件系统等工作,插件只处理业务逻辑,两者之间是天然解耦的。

        以前的 0xFFFF 在装好依赖以后,直接抛弃了 composer 的存在,然后一股脑去修改依赖包的内容,再 SFTP 同步到生产环境,整体比较混乱,没有发挥出这种程序架构设计的优势。结果忙起来以后都忘记自己对它做过啥,就改不动了,被迫升级。

        迁移到 Docker 的环境,参考了 使用 Docker 和 Traefik 搭建 Flarum 轻论坛应用 - 苏洋博客 来操作。思想是,不需要定制的部分则引用开源的代码,定制部分则从 vendor 里面抽出来,专门用一个仓库跟踪。一开始对 git 的 submodule 不太熟悉,弄完才发现这个仓库还是作为网站主项目的 submodule 存在。

        今天在魔改一些插件和 i18n 文案的时候,只用一个仓库的弊端便显现出来,每次需要手动 copy 代码,很不方便。git submodules 不恰好就是解决这个需求的存在吗?所以就有了以上的修改。

        想来,架构的更新也不是一蹴而就的事,而是在实践中不断增加需求的背景下,持续重构的过程~

        © 2018-2025 0xFFFF