从 ioGame 迁移

介绍

与 ioGame 的比较

标题	描述
性能大幅提升	框架内部消息传输层采用了 Aeron + SBE 组合 ，真.零拷贝、零回环、零反射、零GC、零运行时解析、编解码开销几乎为零。 通过无锁 (Lock-Free) 设计和零 GC (Zero-GC) 策略， 能够实现亚微秒甚至纳秒级别的端到端延迟，特别是在进程间通信 (IPC) 时，它的性能几乎可以达到底层硬件的极限。
对外服自定义协议更简单	ExternalMessage 结合 CommunicationMessage 接口，将一些不需要序列化的逻辑属性平铺到其父类中，这样在整个对外服的处理中只需要创建一次对象。 新的方案内存开销极小，无临时对象，零 GC，完全避免在编解码过程中产生新的 Java 对象。
简化内部协议	内部协议采用平铺的方式，减少对象的创建。
网络请求与总体序列化次数	从序列化对象总数、反序列化对象总数、创建对象总数、网络请求总数几个方面进行分析。 在相同的通信模型下，请求链与跳转链大幅减少，总体序列化次数也得到大幅减少。
内部网络跳转次数的减少	得益于 IPC 机制，跨进程的数据交互只会在内存中进行，不会产生网络请求。
简化线程模型	简化线程模型，无业务线程上下文切换。 开发者只需要关注业务线程模型，自定义编排更简单。
更好的扩展性	在扩展通信模型和获取对外服数据时更简单。
示例	提供了更多的使用示例。

---

与 ioGame 架构的不同

ioGame 使用 ExternalServer、Broker、LogicServer 架构。

由于时间关系与精力的原因，目前 ionet 使用 ExternalServer、LogicServer 架构，外加一个内置的注册中心。 后续有时间及精力充沛时会支持 Broker，这种后续的支持不会对现有架构产生影响，是一种无感知的支持。

由于 ionet 具备 IPC 特性，即使各服务器在不同的进程中，也不会产生网络请求。

为什么要新开一个产品

为什么要新开一个产品，而不是在 ioGame 上继续迭代，有以下几点原因：

1. 内部网络传输层由 Bolt 更换为 Aeron，考虑到并不是所有开发都能接受新事物。
2. 因为内部网络传输的变更，导致 api 的变更，如果要兼容老的 api，会有一定的工作量。 新开一个产品可以忽略这些兼容工作，第二个可以无束缚的进行重构与优化。
3. 应一些企业用户的要求，期望在功能上与非企业用户有一定的区别。

如何迁移

大多时候，当前框架是可以兼容 ioGame 相关代码的，下面特别指出不同的部分。

标题	描述
逻辑服	简化逻辑服的创建。
通信模型	内部通信模型 api 做了统一规范命名，使其更符合直觉。
访问对外服	更容易扩展，并且对未登录的用户有更好的支持。
线程编排	简化线程模型，开发者只需要关注业务线程模型。
Room	简化 Room 扩展模块，减少概念。
Spring 集成	Spring 相关的迁移到扩展模块中，开发者可按需选择。
双版本策略	采用双版本策略（开源版/企业版） 开源版: 精简了分布式相关的功能，大幅降低了上手门槛和减少了学习成本。 致力于提供一个高性能、单机部署的解决方案。 单机支持启动多进程，其能力足以满足绝大多数项目的需求。 企业版: 提供水平扩展能力，通过多机多节点分布式部署，突破单台机器的物理上限，支持亿级连接和超高并发场景。 此外，企业版针对分布式场景进行了全面功能增强和性能优化，提供了无缝的水平扩展能力。

提示

建议配合文档示例做迁移修改。 其他注意点：

• 包名做了修改。
• 扩展模块命名做了统一，以 extension 打头。

最后

建议开发者能迁移的尽量迁移，因为之后的主要精力都将放在当前开源库上。