今天也在 GitHub 搜 Koishi,搜到了这个,看起来也不是官方发的,但是感觉好好玩,就转载过来了。
然后我感觉这篇文章里讲的东西有很多其实是不合理或者难以实现的,所以只是图一乐。
今天也在 GitHub 搜 Koishi,搜到了这个,看起来也不是官方发的,但是感觉好好玩,就转载过来了。
然后我感觉这篇文章里讲的东西有很多其实是不合理或者难以实现的,所以只是图一乐。
如果你在 Koishi 开发群内看到群友激烈争论某些问题持续时间长达数个小时,请不要担心,这是 Koishi 群的风俗。观战的人们将此类行为总结为《Koishi 人》,这当然不是什么赞扬——
事实上,对于刚入群的新人,几乎难以理解这些人们在谈论什么。这是因为 Koishi 的开发者们自己对于插件开发有着一套独特的黑话哲学。而这其中的几乎每一条都是难以实现的。大家也不知道为什么要追求这些。
不过总之,让我们看看到底有哪些 Koishi 哲学吧。
目前暂定每层介绍一个,未来可能也会单独发帖以扩充内容。
(打问号的先不写了,希望未来有机会介绍吧。)
支持传播 Koishi 的制度自信
0dt 即 zero downtime,具体指 一个 Koishi 实例在持续运行的过程中发生可控的重启,重启期间 Koishi 可以保持工作。这里仅针对持续运行的 Koishi 展开讨论,不考虑云服务等情况(可前往「零状态」章节查看)。
其中「可控的重启」包括:
「Koishi 保持工作」包括:
可逆并未实现 0dt,但热更新最大限度地减少了用户在生产环境下的重启次数,客观上增加了 SLA。
零状态的 Koishi 自然实现了 0dt 所要求的「不会丢失任何插件的运行状态」。但后者也可以通过其他方式实现。
由于两个 Koishi 实例的生命周期存在重合,因此 0dt 本身也会对零占用有所需求。