传统架构的隐形炸弹
在讨论 ionet 的架构之前，我们先来看一个让无数资深架构师头疼的问题：N*N 连接问题。
传统的分布式游戏服务器架构中，各个逻辑服之间通常是相互直连的。逻辑服 A 需要和逻辑服 B 通信？建立连接。B 需要和 C 通信？再建立连接。每个逻辑服都需要知道其他所有逻辑服的 ip:port，并与它们保持长连接。
这看起来没什么问题——当你只有 5 个逻辑服的时候。
但当逻辑服数量增长时，事情就变得恐怖了：
| 逻辑服数量 | 内部连接数 (N × (N-1)) | 每次心跳消耗 (2 × N²) |
|---|---|---|
| 10 | 90 | 200 |
| 100 | 9,900 | 20,000 |
| 1,000 | 999,000 | 2,000,000 |
| 10,000 | 99,990,000 | 200,000,000 |
10,000 个逻辑服时，光内部连接就接近一亿。 什么都还没干，每次心跳检测就要消耗 2 亿次请求/响应。
这还不算完。传统架构还有这些连锁问题：
- 端口管理地狱：每个逻辑服需要独立端口。10,000 个逻辑服 = 管理 10,000 个端口。云服务器上还得一一开放——这些琐碎工作最浪费时间。
- 中间件依赖：为了让这套架构运转，你还需要 Redis（缓存/pub-sub）、MQ（消息队列）、ZooKeeper（服务发现）。每个中间件都是成本。
- 开发调试困难：大部分传统框架不支持在同一进程中启动多个逻辑服，调试时要开一堆进程，排查问题非常痛苦。
ionet 的解法：对外服 + 逻辑服
ionet 用一个简洁的分层设计，一次性解决了上述所有问题。
架构只有两层：
┌─────────────────────────────────────────────┐
│ 对外服 (External) │
│ 负责与用户建立长连接 (Netty) │
│ 支持 TCP / WebSocket / UDP │
└───────────────────┬─────────────────────────┘│ Aeron IPC (共享内存)
┌───────────────────┴─────────────────────────┐
│ 逻辑服 (Logic Server) │
│ 负责处理业务逻辑 (Action) │
│ 可以有多种类型，每种可启动多个实例 │
└─────────────────────────────────────────────┘
对外服的职责单一：接收用户连接，转发请求给逻辑服，把响应发回给用户。它基于 Netty 实现，一台机器支持几千个用户连接，不够就加一台对外服——用户无感知。
逻辑服负责所有业务逻辑。逻辑服之间通过 Aeron IPC（共享内存）通信，不需要建立长连接，不需要开放端口。
为什么没有 N*N 问题？
两个原因：
- 多个逻辑服可以在一个进程内启动。 同进程内的通信走内存，零网络开销。
- 跨进程通信使用 Aeron 可靠 UDP，无长连接。 不需要心跳，不需要连接池。
所以 ionet 的连接模型不是 N*N，而是 P*P（P = 进程数）。一个进程可以包含数十个逻辑服，实际进程数远小于逻辑服数。
| 对比维度 | 传统架构 | ionet |
|---|---|---|
| 连接模型 | N × (N-1) 长连接 | P × P 无长连接 |
| 心跳消耗 | 2 × N² | 几乎可忽略 |
| 端口管理 | 每个逻辑服独立端口 | 逻辑服无需端口 |
| 安全性 | 需防扫描攻击 | 天然免疫（不开端口） |
| 中间件 | Redis / MQ / ZK | 零依赖 |
多服单进程 ↔ 多服多进程：开发与生产的无缝切换
ionet 的架构有一个极其务实的特性：开发时用单进程，生产时用多进程，不改代码。
开发阶段：多服单进程
在日常开发中，你可以把对外服和所有逻辑服放在同一个 JVM 进程中启动：
new RunOne().setAeron(aeron).enableCenterServer().setExternalServer(externalServer).setLogicServerList(List.of(new UserLogicServer(), // 用户逻辑服new GameLogicServer(), // 游戏逻辑服new ChatLogicServer(), // 聊天逻辑服new MatchLogicServer() // 匹配逻辑服)).startup();
一个 main 方法，所有服务全部启动。调试时只需要一个断点，就能追踪整个请求链路。
生产阶段：多服多进程
当项目上线，你可以将每种逻辑服拆分到独立的进程（或独立的机器）中部署。代码不需要改变任何一行——只需要调整启动配置。
这个能力带来的好处不只是灵活性，更重要的是降低了开发团队的认知负担。你可以用单体思维开发，到了生产再按需拆分。
动态扩缩容与无感知更新
水平扩展
对外服和逻辑服都支持动态增加和减少。
以对外服为例：假设一台机器能承载 5,000 个用户连接，当用户达到 7,000 时，只需启动第二台对外服。用户会被自动分流到不同的对外服上，但在开发者的视角，只有"一个"对外服——框架会处理好广播、推送等跨对外服的消息分发。
以逻辑服为例：假设你有两个 A 类型的逻辑服（A-1、A-2），用户请求会通过负载均衡策略分配到不同的实例上。需要扩容？启动 A-3 即可。
无感知更新
分布式架构带来的另一个红利是用户无感知的热更新。
假设 A 类型的逻辑服需要新增功能：
- 启动已支持新功能的 A-3、A-4
- 逐步将 A-1、A-2 下线
- 用户请求自动转移到 A-3、A-4
整个过程中，用户不会感受到任何中断。
安全优势：逻辑服不开端口
在传统架构中，每个逻辑服都需要开放端口，这意味着：
- 端口暴露在网络中，存在被扫描和攻击的风险
- 云服务器需要配置安全组/防火墙规则
- 运维人员需要维护大量端口映射
ionet 中，所有逻辑服完全不需要开放端口。它们通过 Aeron 的共享内存或可靠 UDP 通信，外部网络根本无法触及。
这不只是安全性的提升，更是运维工作量的一次性消除。"没有端口"这件事，意味着"管理端口"这项工作直接不存在了。
逻辑服的负载均衡与动态绑定
默认情况下，用户对某类逻辑服的多次请求会通过随机负载策略分配到不同实例。
但在某些场景中，你需要让用户绑定到特定的逻辑服实例——比如 LOL 式的匹配系统：
- 匹配服找到 A、B 两个用户
- 查询哪个房间逻辑服最空闲
- 将 A、B 绑定到该逻辑服
- 之后 A、B 的所有房间操作都由这个逻辑服处理
ionet 提供了动态绑定逻辑服的能力，用几行代码就能实现类似 LOL、王者荣耀的匹配与资源调度。后续文章会专门详解这个特性。
小结
ionet 的架构设计可以用一句话概括：用最简单的分层，解决最复杂的分布式问题。
| 传统架构的痛点 | ionet 的解法 |
|---|---|
| N*N 连接爆炸 | 无长连接，P*P 进程模型 |
| 中间件依赖重 | 零依赖，纯 Java 运行 |
| 端口管理繁琐 | 逻辑服不开端口 |
| 开发调试困难 | 多服单进程，一个断点走天下 |
| 扩缩容复杂 | 动态增减，无缝切换 |
| 更新影响用户 | 无感知热更新 |
这套架构的"奢侈之处"在于：它既简单到 5 分钟就能理解，又强大到可以支撑百万级用户的分布式系统。
更多资源
- 📖 架构介绍
- 📖 与传统架构对比
- 📖 对外服介绍
- 📖 逻辑服介绍
- 📖 动态绑定逻辑服
下一篇预告：[纳秒级延迟的秘密 —— Aeron + SBE 突破性能极限]