网站进一步的升级工作

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

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

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

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

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

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

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

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

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

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

感谢 @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 不恰好就是解决这个需求的存在吗？所以就有了以上的修改。

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

hsxfjames
PHP 可以说是天然地 ssr 了（逃
目前 Flarum 官方实现了针对搜索引擎的简单的HTML输出，SEO 方面可以满足。
考虑更多的是加载速度方面，考虑到复杂的网络环境，目前我更倾向于抽出一个轻量通用的 App Shell，先保证第一屏的到达，所以对体积这块比较敏感一些