Lattice 项目全景：我把它做成什么样了
我做 Lattice，不是为了做个“看起来高级”的项目。
很简单，就是服务器里老出问题：异常发现慢，排查靠猜，执行动作又不太敢下手。
这篇我不讲套话，就讲我现在这套系统到底怎么跑，以及我为什么这么做。
起因：我最怕三件事
- 事件上不来，后端一片“风平浪静”。
- 告警满天飞，但没人敢信。
- 配置改了半天，不知道到底生没生效。
Lattice 的设计基本都围着这三件事打。
现在的结构：三块，谁都别越界
我把项目拆成三部分：
lattice-mod：在游戏里采集事件、执行命令。lattice-backend：接收事件、做规则判断、存储和告警。lattice-desktop：给我一个能直接操作的控制台。
我没有做成一个大仓库里的“大一统服务”，因为这三块的节奏完全不同。
mod 跟着游戏版本走，backend 更看重稳定，desktop 则是高频改交互和排障体验。
事件链路：我先解决“别丢”，再解决“多快”
这条链路里最重要的是 mod 端的 EventQueue。
我给它设了几个硬规则：
- 缓冲最多
50,000条，超过就开始丢并打日志。 - flush 间隔有下限，最短
200ms，避免过度打爆连接。 - 上报默认走 gzip。
- 后端失败时先落到本地 spool，后面再回放（每轮最多捞 5 个文件）。
我宁愿偶尔重复，不接受静默丢失。
因为重复还能在后面做去重和容错，丢了就真的没了。
backend 入口也做得比较硬：鉴权、schema 校验、无效事件过滤（比如 minecraft:air、count <= 0）都在最前面做。
这是我踩坑后的结论，脏数据拖到后面再处理，成本会指数上升。
检测这块：不是单条 if/else，而是带时间窗口
我现在的规则不是“来一条算一条”，而是维护多种窗口状态：
- 转移链缓存
- 同物品短时窗口
- 严格模式下的大额窗口
- 审计增长窗口
所以它能回答的不是“这条像不像异常”，而是“这条放在上下文里像不像异常”。
规则 ID 现在是 R0-R12 这一套。
其中我只把 R4 / R10 / R12 这类高价值规则直接推外部告警，其他留在查询面给人工判读。
这个决定救过我很多次。
以前全推告警，值班两天就麻了；现在信噪比高很多。
扫描这块是最容易出事故的地方
扫描不是只扫在线容器，我把来源拆成四类：
- 离线世界
- SB 离线数据
- RS2 离线数据
- 在线运行时
每次扫描都会明确阶段和状态，不是一个“running=true/false”就完事。
我还保留了详细失败原因，比如队列溢出、离线任务提交失败、结果收集失败、健康守卫阻断等。
为什么这么麻烦？因为线上真正难排查的问题都是这种：
- “失败了”不重要，重要的是“卡在哪一层失败了”。
- “慢”不重要，重要的是“吞吐到底掉在哪一段”。
我还加了健康守卫：在线人数太高或者平均 tick 时间超阈值，就先别扫。
结论很现实：晚扫一点比扫崩服强太多。
权限这块：我不再接受口头授权
高危命令我做了 OP token 门禁，核心流程是：
- token 当天有效。
- 首次 apply 会绑定玩家 UUID。
- 同一个 token 被别的号复用，直接撤销并上报 misuse。
另外保留必要豁免：
控制台和特定自动化来源可以走白名单路径，不会被玩家门禁误伤。
这块做完之后，最大的变化是“争议变少了”。
以前是“你是不是乱用了命令”，现在是“日志里有完整链路”。
配置发布：我终于不再靠“应该好了”
我现在最满意的一点，是配置发布变成了有版本、有回执的流程：
- desktop 发配置。
- backend 存
revision和checksum。 - mod 收到后应用。
- mod 回传
APPLIED / PARTIAL / REJECTED。 - desktop 直接展示最后 ack。
这件事看起来普通，但在日常运维里非常值钱。
它直接把“猜测”变成了“可验证”。
desktop 在我这边不是展示页，是操作台
我每天在 desktop 里做的都是实操：
- 看 live/ready/alert 状态。
- 看任务进度和告警投递记录。
- 改配置并盯回执。
- 直接发 RCON 命令。
另外 desktop 会嵌入启动 backend。
本地排障时不用手动起一堆进程，这一点节省了我很多时间。
现在的判断
Lattice 还没到“完成态”，但已经过了最难的一关：
它不再是几个脚本拼一起，而是一套能持续跑、能排障、能迭代的系统。
我接下来主要盯两件事：
- 继续压误报，让告警更像“可执行结论”。
- 继续补自动化回归，减少跨端改动带来的连锁问题。
如果你问我这个项目的标准是什么，我现在就一句话：
别炫，先稳；别玄学，先能解释。