感觉被周六加班榨干了，累的不想写博客。非常佩服其他同事，996 还看不出来有啥异样的，太强了。。3 月 4 月连续加班后，5 月终于可以放松一下，不用加班了。五一假期陪老婆回了老家，过了愉快的 5 天，后面补班就非常累了。。。

上月月底请新同学帮忙做了一次压测，发现了一处内存泄漏。我们战斗部分的代码是仿照 ECS 的方式写的，按帧驱动系统更新，但是怪物死亡的时候没处理好，AI 停止后有可能又重新加上 tag，导致场景里只有几百个怪，实际却有几千个 AI 在跑。用 CPU 火焰图看就是 AI 部分占用的 CPU 过多，但是触发 AI 的根源都是正常代码，没发现问题，还是最后靠 Code Review 发现的

搞完这个问题后，我们将压测机器人的数量上调了一下，单独针对移动压测了一轮，结果又爆了。吸取了之前项目的经验，这次已经将 AOI 相关的逻辑都抽离出一个独立服务进行处理了，但是压测发现这个服务还是过载了，CPU 到 98%，下游的 cluster sender 之类的分发服务也是顶不住了。起初我觉得是临时消息太多，透过内存火焰图，发现了一处分配大量临时内存的代码，新同学做了池化处理，元表也改为只用一个了，但是性能还是不够。后面做了合包处理，原来的设计里，一个人进入 100 人的视野，会产生 100 条信息，现在将这一百条信息合成一个包，减少链路上的压力，到靠近客户端的终端再做分发处理，终于将性能消耗降下来了

最近还搞了一轮大改造，目标是绝大部分的业务代码都可以热更。战斗系统因为用 ECS 构建，所以更新起来还是很方便的，基本就是替换 table 里的函数就完事了，稍微有点复杂的是面向玩家的 agent 服务，需要改造下事件和计时器相关的逻辑。上次 内部月刊分享的那篇文章 对我们触动很大，我们自己用 skynet 开发了这么久，居然一直没搞开发期热更，实在是难以启齿的笨。。。

期间压测还测出了一些和中间件组磨合的问题，压测的时候日志级别忘记调整了，结果写满了磁盘后，中间件组提供的容器直接挂了，也没收到相关告警，囧 rz 我们团队还缺乏动态扩容的经验，不知道以后能不能给中间件组提供自定义策略，适时启动更多节点去缓解高峰期压力