游戏服务端开发的逻辑解耦思路

基本 CS 框架时期

最开始的代码库中，主循环收到协议后，通过手写的路由关系转交给对应的业务逻辑类实现。

通过依赖倒置解耦注册单点

更进一步的模式是将业务逻辑明确地拆分为 n 个 logic 类，路由关系通过依赖倒置转交给 logic 类自己注册，把部分协议注册到自己名下。主循环通过注册表查找 logic 进行分发。这样可以更方便地从切入层做一些校验和统计的工作，整体给框架的信息更多，更可控。

这种模式减少了大量重复代码，可以倒置的不仅是协议依赖，还有其他内部协议，db 请求等。最终将一组玩法归类到一个 logic 中实现。

常见的问题

再往前进一步，logic 也会变得越来越臃肿，例如经典的道具，任务等。这类语义在经过拓展，变体之后，实际已经是多个不同的实现逻辑，放到单个 logic 承载导致非常臃肿。

另外，部分逻辑需要多个不同的进程配合。如果一个 logic 承载了 A 进程的数据 a，在 B 进程中就无法直接用，这里很多开发者很容易开始复制代码到 B 中。例如校验是否过期的逻辑，很多同事直接在业务中写运算，后来过期逻辑调整了，如果没有封装，这里就需要人工 review 代码去改逻辑，而且非常容易遗漏。道具有道具的过期逻辑，任务有任务的过期逻辑，支付有支付的过期逻辑。如果不通过封装分清楚，代码的可读性将非常差。

这种 logic 的模式代码膨胀之后还存在依赖混乱的问题，例如 logicA 中有简单逻辑 a1，复杂逻辑 aaa1，aaa1 依赖 logicB 中的数据，logicB 中的接口又依赖 a1 提取 A 中的数据，就出现了依赖圈。很多情况下，是由于 a1 根本和 logicA 没关系，可以拆分出来而没有拆分导致的。这里很多人都会开始复制代码快速跑通，然后就不管了，因为这种情况出现的大量复制简直是万恶之源。

如果要解决这些问题需要重构代码，我坚持小步重构的思想，随着需求迭代，触及到改动的地方，准备好测试之后，一定要把能优化的都尽量优化干净。如果因为能 work 而应该调整的不改，后面一定一定会有坑的。

通过 System 拆分逻辑

后来我们拆分出了更细的逻辑系统，这里借鉴了 ECS 中 System 的设计，传统的 logic 由于需要维护一些内存的东西，都是一个单例对象。但是新的 System 由于没有 logic “承载一个玩法” 这样的包袱，足够简单到可以严格只用静态函数描述逻辑。

在有了 System 拆分逻辑之后，logic 就只作为接入层。我们还做了一件事简化这个接入层，通过使用函数对象，把 logic 的注册直接调整为消息到函数的注册，在 logic 和 base 之间加入了一个 svrbase，用来做进一步的校验协议，校验 svr 的数据如 Player 对象等，这样在最终的 logic 中完全省略了逻辑之外的代码，可读性极大地提升了。同时从这个 svrbase 层起，所有接口只接收引用，指针参数容易造成很多指针参数归属权不明确，代码中出现大量浪费的指针判空逻辑等。使用引用意味着直接操作数据，在哪里校验，在哪里加工，每一层的语义更加清晰。

System 的主要设计思想是精确。例如任务的 System 叫做 BaseTaskSystem，这里是最简化的任务，只有任务配置，任务进度这两个属性。再上一层根据不同的任务类型，任务玩法分为 ATaskSystem，BTaskSystem，分别处理不同 Task 的逻辑。对于任务配置的获取，任务数据的校验，进度迭代，统一调用 BaseTaskSystem。这样 A B 中只需要处理 Base 不知道的信息。精确的好处就是下层可靠了，上层效率就高了。最后到 logic 层基本就是纯语义的转述，没有代码复制，开发效率变高了。这里对于没有特殊逻辑的任务，我们没有创建代理而是直接默认用 BaseTaskSystem，可以减少工作量。

这里只使用 ECS 中 S 的部分，其实在数据层面由于我们大部分数据是协议数据转译，都是 POD Type，在 S 中只操作数据和引用的话，C 的部分是天然实现的。E 的部分由于我们是 CS 模式，还没有很强的循环更新需求，因此暂时没有用上。

总结

整理一下，System 的特点是：

• 全静态函数，只有逻辑。
• 只接收引用或传值，只操作直接安全的数据。每个 System 只操作自己的数据
• （由于 optional 还没有实装，可以返回指针用于部分场景）
• 没有继承，没有多态。对其他 System 有合理依赖直接调用，必要时通过重构来优化依赖关系。

这样抽象下来，很多 System 由于自身的简洁性，可以移动到无业务相关的公共库中。而有业务依赖的 System 则保留在对应的 svr 中。logic 之间和不同进程的逻辑之间可以复用公共库的逻辑，跨进程的依赖关系也变得清晰。整体代码质量可以得到提升。在铺功能的过程中可以享受业务拆分复用的红利，开发效率可以大幅提升。