网站进一步的升级工作
- 已编辑
2019年9月8日 更新
在 ISCNU 强力支持下
加入了大陆版的 CDN (0xffff-cdn.iscnu.net)，实现本站静态资源的极速加载
在这里必须得打个广告~
若你是 SCNU 的学生，且对 Web 应用开发、运维、教育网 PT，网站建设、新媒体运营、信息素养的普及、阅读推广等等等等等等一切网络和知识连接相关的事情感兴趣，ISCNU 网络协会一定不能错过。
网站：https://i.scnu.edu.cn/
微信公众号：
- 已编辑
昨天修好了 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
0x0001
刚参考 Ubuntu 16.04 开启 BBR - 零件's Blog 给源站开了 TCP BBR
结果似乎稳定在了 500ms 上下
若只请求静态资源，不算 PHP 的处理时间，60ms 不到。
这么说，TCP 的拥塞控制也很关键啊！
tql
- 已编辑
感谢 @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 不恰好就是解决这个需求的存在吗？所以就有了以上的修改。
想来，架构的更新也不是一蹴而就的事，而是在实践中不断增加需求的背景下，持续重构的过程～
目前给小站上了 Service Worker，算是一个完整的 PWA 应用 了，用 Chrome 的同学应该可以看到这帅气的 LOGO
可以说，网络方面的瓶颈基本解决了，然后发现更大的 boss 是渲染性能问题，短期内估计无解，也看官方如何处理。
考虑前端 ssr + redis 缓存？我看首页和帖子数据和 ui 结构都挺不复杂，完全可以做服务端渲染
hsxfjames
TTFB 也是我目前最蛋疼的地方了，这里的 HTML 全是 PHP 生成的，用的是重型框架 laravel 魔改出来的后台，类似一种 PHP 和 JS 混合的产物。PHP 内部处理差不多 150ms 的内耗，然后辣鸡网络一个请求 大陆→HK→广州→HK→大陆 两次穿墙差不多需要 100ms。
这里原本也有点服务端吐 App Shell 然后前端调接口渲染的机制。作者为了减少一个请求，第一屏的实现是，在 PHP 内部调用帖子数据接口的控制器拿到数据，然后用 json_encode(类似JSON.stringify) 硬编码到 script 标签里面。然后前端再解析这个JSON，渲染出具体的 DOM 节点。也就导致页面整体大小差不多 200KB，gzip 之后也有 30KB...
拿掉了这部分 JSON 输出之后首屏的 HTML 输出降低到了 30KB，gzip 之后 7KB 左右，代价是网页加载完成后得多请求一次接口才能获取到帖子。
然后是 SSR 的可行性。刚刚试了下直接保存渲染好的首页，HTML 部分 100KB左右，gzip 以后刚好是你说的神奇数字14KB。但需要渲染的不仅仅是帖子列表，还有标签节点之类的东西，这些在 Flarum 目前是完全靠前端实现的，前端用的 Mithril.js 这方面支持看起来不太完善，改造的话还扯到PHP的模板和各种插件扩展之类的东西，难度估计非常高。
所以现在觉得还是尽可能减少 HTML 部分首次加载的体积，让它能作为整个 SPA 应用的 App Shell，后台尽可能直接输出，前端用 service worker 缓存起来，整个 SPA 启动起来之后再另外调这个耗时有点长的接口来请求，白屏的时间也短一些
