02-22 服务迁移与性能计划

2 月 22 日的讨论把项目推进路径收敛到一个更实际的迁移顺序：先在接近真实的环境中验证当前系统，再在不破坏现有运行模式的前提下，逐个服务向 Lyquid 迁移。重点不是做一次大的架构重写，而是先建立基准、保留可比性，并在每一层适配过程中逐步降低不确定性。

在这个基础上，迁移路径被定义成一个阶段性过程，而不是完整推倒重来。计划是先部署更新后的 Java 实现，观察最新产品逻辑和性能改动带来的效果，然后把实现迁移到 Rust，最后再逐步演进到 Lyquid。也就是说，Lyquid 不是一个孤立的替换项目，而是要分阶段接入当前系统，让性能变化可以在迁移过程中持续被观察和比较。

这种分阶段思路也影响了服务层面的迁移计划。当前的判断是，先从 clear（账户清算服务）和 order（API 下单服务）这类单节点服务开始，把它们作为 Lyquid 迁移对象；之后再处理 match（撮合服务）这类要求更高的组件。在这个阶段，基于 Kafka 的通信仍然应该保留。这样做的意图是，在能降低迁移风险的地方继续使用熟悉的 Web 2.0 式架构，而不是一开始就强迫所有组件进入新的模型。

我们也进一步明确了代码适配 Lyquid 需要做什么。迁移工作被概括为三个核心步骤：定义状态、实现合适的入口函数，以及确保幂等性。如果 f_750 分支能够在保留幂等行为的同时完全移除 Kafka transaction，那么一部分适配成本会直接消失，剩下的工作会更集中在状态定义和执行入口上。与之相关的一个开放问题是 Lyquid 的共识机制，这仍然需要和 Lyquor 团队进一步对齐，才能最终确定实现路径。

除了工程机制本身，这次会议也明确了协作预期。要提前整理好给 Lyquor 团队的问题，假期结束后恢复定期对齐会议，并且每次周会后输出简洁的文字总结，让外部相关方不用参加每一次技术讨论，也能持续了解进展。

4 月初的产品目标被有意定义为能力展示，而不是精修版本。目标是展示一个基础交易功能能够以去中心化方式运行的版本。高质量前端和极限性能不是当前优先级。更重要的是先证明架构可以通过一个基础界面端到端跑通。

最后一个主题是实现策略。团队对同时推进 AI 辅助迁移和人工开发迁移保持开放态度，并计划在比较性能差距后再决定长期方向。会议中也有人建议把早期 C++ 撮合版本重新接入 Kafka 并尝试上链，同时先翻译 Rust 版本以保留功能完整性，再做后续优化。这些想法背后的共同信息很一致：正确性和迁移连续性应该先于激进调优。