ioGame25 will see a qualitative leap in performance. 性能将迎来质的飞跃。

[iohao]

ioGame 由 [网络通信框架] 和 [业务框架] 组成

• 网络通信框架: 职责是各服务器之间的网络通信。
• 业务框架: 职责是业务逻辑的处理方式和编写方式。

ioGame25 将移除基于 Netty 的网络通信框架 bolt，由 Aeron 代替。

---

内部网络通信框架-介绍

Aeron 将用于内部服务器之间的网络通信交互，可靠 UDP，无锁、独特的 IPC 机制，多进程可使用内存共享的方式交互。

特点:

• 可靠 UDP。
• 极低延迟，通过无锁设计和零 GC 策略，Aeron 能够实现亚微秒甚至纳秒级别的端到端延迟，特别是在进程内或跨进程通信时。它的性能几乎可以达到底层硬件的极限。
• 高吞吐量，Aeron 的吞吐量非常高，通过批处理和高效的网络协议，能够以极高的速率处理大量消息。
• 无锁、高稳定性，避免了 GC 暂停和锁竞争，使得延迟抖动非常小，这对于对延迟敏感的系统至关重要。
• 高效的资源利用，减少了不必要的内存分配和数据复制，使得 CPU 和内存资源得到更有效的利用。
• 真.零拷贝：与 Netty 零拷贝不同的是，Aeron 的“零拷贝”则是一种更为激进和底层的实现，在进程间或线程间通信时，通过共享内存来完全避免数据拷贝。利用共享内存，将数据源和目的地直接映射到同一个物理内存区域，从而完全消除了跨进程（或跨线程）的数据拷贝。这是一种更高维度的零拷贝。

---

消息格式-介绍

内部交互消息格式使用 SBE，SBE 是一种为性能而生的编码标准。它通过将消息结构与内存布局直接绑定，彻底消除了编解码开销，特别适用于对延迟有极高要求的金融、物联网和高性能计算等领域。

特点：

• 消息大小非常小，只包含原始数据和必要的元数据。
• 编解码开销几乎为零，直接内存映射。
• 性能最高，为低延迟优化。
• 固定内存布局，无运行时解析。
• 内存开销极小，无临时对象，零 GC，完全避免在编解码过程中产生新的 Java 对象。
• 亚微秒，接近原生硬件速度。

SBE 性能极快，极致的低延迟，性能通常是 Google Protobuf 的 10 倍到 100 倍以上，单核每秒可处理 1~2 千万条，多核可以轻松达到数亿条消息每秒。

---

减少请求链与跳转链-介绍

由于 Aeron 独特的 IPC 机制，基于共享内存（Shared Memory）和无锁（Lock-Free）设计，这从根本上消除了数据在不同进程间传输时产生的拷贝和上下文切换开销。

Aeron IPC 的核心是利用内存映射文件（Memory-Mapped Files）来在不同的进程间共享一个物理内存区域。

得益于这种 IPC 机制，ioGame25 可以将请求链减少到 0 次，或至多一次。可以简单的想象成即使启动了多个进程，在交互上等同于在一个进程中的效率，因为各进程之间直接在内存中交互数据的。

ioGame25 的优势随着服务器之间的调用链变长而更加明显。例如，在由四个逻辑服务器 A -> B -> C -> D 组成的调用链中，许多传统框架会涉及多个网络传输周期、消息序列化以及请求和响应的反序列化。

示例：

A->B
A 请求 B: ---- 序列化消息、请求网络传输
B 接收 A 的网络请求: ---- 反序列化消息、序列化消息、响应网络传输
A 接收 B 的响应: ---- 反序列化消息

B->C
B 请求 C: ---- 序列化消息、请求网络传输
C 接收 B 的网络请求: ---- 反序列化消息、序列化消息、响应网络传输
B 接收 C 的响应: ---- 反序列化消息

C->D
C 请求 D: ---- 序列化消息、请求网络传输
D 接收 C 的网络请求: ---- 反序列化消息、序列化消息、响应网络传输
C 接收 D 的响应: ---- 反序列化消息

总计：
网络请求 3 次。
网络响应 3 次。
序列化消息 6 次。
反序列化消息 6 次。

而在 ioGame25 中，则没有这些。网络传输 0 次、序列化消息 0 次、反序列化消息 0 次。

[iohao]

ioGame is composed of a Network Communication Framework and a Business Framework.

• Network Communication Framework: Responsible for network communication between various servers.
• Business Framework: Responsible for the handling and implementation of business logic.

ioGame25 will remove the Netty-based network communication framework, bolt, and replace it with Aeron.

---

Internal Network Communication Framework - Introduction

Aeron will be used for network communication between internal servers. It features Reliable UDP, a lock-free design, a unique IPC mechanism, and allows multiple processes to interact via shared memory.

Key Features:

• Reliable UDP.
• Extremely Low Latency: Through its lock-free design and zero-GC strategy, Aeron can achieve sub-microsecond or even nanosecond end-to-end latency, especially for intra-process or inter-process communication. Its performance can nearly reach the limits of the underlying hardware.
• High Throughput: Aeron's throughput is very high. By using batching and an efficient network protocol, it can process a large volume of messages at an extremely high rate.
• Lock-Free, High Stability: By avoiding GC pauses and lock contention, latency jitter is very low, which is crucial for latency-sensitive systems.
• Efficient Resource Utilization: It reduces unnecessary memory allocation and data copying, leading to more effective use of CPU and memory resources.
• True Zero-Copy: Unlike Netty's zero-copy, Aeron's "zero-copy" is a more aggressive and low-level implementation. For inter-process or inter-thread communication, it completely avoids data copying by using shared memory. By leveraging shared memory, data sources and destinations are directly mapped to the same physical memory region, which completely eliminates data copying across processes (or threads). This is a higher-dimensional form of zero-copy.

---

Message Format - Introduction

The internal communication message format uses SBE (Simple Binary Encoding), an encoding standard born for performance. By directly binding message structures to their memory layout, it completely eliminates encoding and decoding overhead, making it particularly suitable for fields with extremely high latency requirements, such as finance, IoT, and high-performance computing.

Key Features:

• Very small message size, containing only raw data and necessary metadata.
• Near-zero encoding/decoding overhead due to direct memory mapping.
• Highest performance, optimized for low latency.
• Fixed memory layout, no runtime parsing.
• Minimal memory overhead, no temporary objects, zero GC. It completely avoids generating new Java objects during encoding and decoding.
• Sub-microsecond performance, close to native hardware speed.

SBE is extremely fast, with ultra-low latency. Its performance is typically 10 to over 100 times faster than Google Protobuf. A single core can process 10 to 20 million messages per second, and multiple cores can easily achieve hundreds of millions of messages per second.

---

Reducing Request and Call Chains - Introduction

Due to Aeron's unique IPC mechanism, which is based on a shared memory and lock-free design, it fundamentally eliminates data copying and context-switching overhead that occurs during data transfer between different processes.

The core of Aeron IPC is to use Memory-Mapped Files to share a physical memory region between different processes.

Thanks to this IPC mechanism, ioGame25 can reduce the request chain to zero or at most one step. You can simply imagine that even if multiple processes are running, their interaction is as efficient as if they were within a single process, because the processes interact with data directly in memory.

The advantages of ioGame25 become more pronounced as the call chain between servers gets longer. For instance, in a chain of four logic servers, A -> B -> C -> D, many conventional frameworks would involve multiple cycles of network transmission, message serialization, and deserialization for requests and responses.

Example:

A -> B
A requests B: ---- Message serialization, network request transmission
B receives A's network request: ---- Message deserialization, message serialization, network response transmission
A receives B's response: ---- Message deserialization

B -> C
B requests C: ---- Message serialization, network request transmission
C receives B's network request: ---- Message deserialization, message serialization, network response transmission
B receives C's response: ---- Message deserialization

C -> D
C requests D: ---- Message serialization, network request transmission
D receives C's network request: ---- Message deserialization, message serialization, network response transmission
C receives D's response: ---- Message deserialization

Totals:
Network requests: 3 times
Network responses: 3 times
Message serialization: 6 times
Message deserialization: 6 times

In contrast, ioGame25 eliminates all these steps. With it, there are 0 network transmissions, 0 message serializations, and 0 message deserializations.

[cnrainbing]

ioGame25 预计多久可以发布 Aeron + SBE 版本

[iohao]

至少需要等到 java25 出来之后。

[cnrainbing]

至少需要等到 java25 出来之后。

Java25 已发布

[iohao]

通讯模型相关的工作已经完成，已进入内测与优化阶段。

[iohao]

游戏对外服相关的优化

下面是 ioGame21 与 ioGame25 从对外服处理用户请求的对比，性能有巨大的提升。

---

ioGame21

ioGame21 从对外服处理用户请求，通信使用的 bolt RPC。

1. netty 接收 byte[] ，反序列化成 ExternalMessage。（反序列化 1 次，创建对象 1 次）
2. 将 ExternalMessage 对象转为 RequestMessage 对象，而 RequestMessage 中包含了 HeadMetadata 对象。（创建对象 2 次）
3. 将请求转发到 Broker 时，通信使用的 bolt RPC 通信。（网络请求 1 次）
4. 将 RequestMessage 对象放到 bolt RPC Request 对象中时，会将 RequestMessage 序列化成 byte[]，由于涉及通信，那么 bolt RPC
   Request 对象也会序列化成 byte[]。(创建对象 1 次，序列化至少 3 次)
5. Broker 接收到请求后，需要将 bolt RPC Request byte[] 反序列化成 bolt RPC Request，从中获取 RequestMessage byte[] 数据，并将
   RequestMessage byte[] 反序列化成 RequestMessage 对象。（创建对象 3 次，反序列化 3 次）
6. 将请求从 Broker 转发到游戏逻辑服时，通信使用的 bolt RPC 通信。（网络请求 1 次）
7. 将 RequestMessage 对象放到 bolt RPC Request 对象中时，会将 RequestMessage 序列化成 byte[]，由于涉及通信，那么 bolt RPC
   Request 对象也会序列化成 byte[]。(创建对象 1 次，序列化至少 3 次)
8. 游戏逻辑服接收到请求后，需要将 bolt RPC Request byte[] 反序列化成 bolt RPC Request，从中获取 RequestMessage byte[]
   数据，并将 RequestMessage byte[] 反序列化成 RequestMessage 对象。（反序列化 2 次，创建对象 2 次）

Hessian 是 Bolt 默认的序列化库，RequestMessage 中包含了 HeadMetadata 对象，在使用 hessian 来序列化 BarMessage 对象时，会被 Hessian 各自序列化一次。

public class RequestMessage extends BarMessage implements Serializable {
    ...
    HeadMetadata headMetadata;   
}

public final class HeadMetadata implements Serializable {
    ...
}

总计

• 反序列化: 1 + 3 + 2 = 6 次
• 序列化: 3 + 3 = 6 次
• 创建对象: 1 + 2 + 1 + 3 + 1 + 2 = 10 次
• 网络请求: 1 + 1 = 2 次

ioGame21，涉及多次对象创建、多次 GC、多次序列化、多次网络请求 ，并存在编解码开销。上述问题将在 ioGame25 得到解决。

---

ioGame25 设计方案

1. ExternalMessage 结合 CommunicationMessage 接口，将一些不需要序列化的逻辑属性平铺到其父类中，这样在整个对外服的处理中只需要创建一次对象。
2. 使用 Aeron + SBE，Aeron 解决网络方面，而 SBE 则解决编解码相关方面。

ioGame25 从对外服处理用户请求，通信使用的 Aeron。

1. netty 接收 byte[] ，反序列化成 CommunicationMessage。（反序列化 1 次，创建对象 1 次）
2. 将请求转发到游戏逻辑服时，使用的 Aeron 通信。无需序列化成 byte[] (零GC、零运行时解析、编解码开销几乎为零)，将 RequestMessage 的数据直接写入到 DirectBuffer 中，之后数据通过内存直达游戏逻辑服。（网络请求 0 次）
3. 游戏逻辑服接收到请求时，直接从 DirectBuffer 中读取数据，并赋值到 RequestMessage 对象中。（反序列化 0 次，创建对象 1 次）

总计

• 反序列化 1 次 (Netty 的硬性次数)
• 序列化 0 次
• 创建对象 2 次 (其中包含 1 次 Netty 的硬性次数)
• 网络请求 0 次。

ioGame25，零网络请求、真.零拷贝、零回环、零反射、零GC、零运行时解析、编解码开销几乎为零。

小结

新的方案内存开销极小，无临时对象，零 GC，完全避免在编解码过程中产生新的 Java 对象。通信使用 Aeron IPC，不同进程间可直接在内存中交互，从而避免了网络请求。Aeron 能够实现亚微秒甚至纳秒级别的端到端延迟，特别是在进程内或跨进程通信时。它的性能几乎可以达到底层硬件的极限。

[iohao]

ioGam25 对外服自定义协议也更简单，比如定制一个只有两个字段的 ExternalMessage ，那么只需要下面几行代码。

1. 自定义协议 MyExternalMessage。
2. 创建对外服消息编解码 MyCommunicationMessageCodec，主要用于创建 MyExternalMessage 对象。
3. 替换默认的，使用自定义的 MyCommunicationMessageCodec。

@Getter
@Setter
@ProtobufClass
public final class MyExternalMessage extends AbstractCommunicationMessage {
    @Protobuf(fieldType = FieldType.INT32, order = 1)
    int cmdMerge;
    @Protobuf(fieldType = FieldType.BYTES, order = 2)
    byte[] data;
}

public final class MyCommunicationMessageCodec implements CommunicationMessageCodec {
    @Override
    public CommunicationMessage createCommunicationMessage() {
        return new MyExternalMessage();
    }

    @Override
    public CommunicationMessage decode(byte[] bytes) {
        return DataCodecKit.decode(bytes, MyExternalMessage.class);
    }
}

CommunicationMessageKit.communicationMessageCodec = new MyCommunicationMessageCodec();

[cnrainbing]

ioGam25 版本还得多久发版，最近好多公司都在使用[Aeron] 代替JRaft底层的Netty通信，Aeron 最近非常火爆

[iohao]

ioGam25 版本还得多久发版，最近好多公司都在使用[Aeron] 代替JRaft底层的Netty通信，Aeron 最近非常火爆

已经进入编写文档阶段

[iohao]

考虑到以下几点原因，放弃在 ioGame25 上做更改，并决定在新框架上做迭代。原因如下

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

---

https://iohao.github.io/ionet

纳秒级延迟的分布式网络通信框架 ionet 发布，基于 Aeron 的 java 分布式服务器框架。
无锁异步化、事件驱动的架构设计；轻量级，无需依赖任何第三方中间件就能支持纳秒级延迟的分布式网络通信。

适用场景

• 网络游戏服务器
• 物联网
• 高频行情推送
• 实时博弈：在线游戏引擎
• 电信：需要高性能数据处理的系统。
• 任何对延迟有极端要求的内部服务通信
• 实时流数据处理（如视频流、传感器数据）
• 高频金融交易、市场数据分发、订单处理。（低延迟要求极高）