同进程亲和性
介绍
同进程内不同 Netty 实例通信时，是通过内存进行传输的，不需要经过网络传输，数据传输速度极快。 也就是说，如果我们将游戏对外服、Broker（游戏网关）、游戏逻辑服部署在同一个进程中（也就是单体应用），那么各服务器之间是在内存中通信的。 甚至可以简单的理解为在同一 JVM 中的 a 方法调用了 b 方法，b 方法调用了 c 方法。
同进程亲和性是框架的特性之一，可以让同一进程内的 Netty 实例拥有相互访问优先权。当有请求需要处理时
- 即使你启动了多个 Broker（游戏网关），游戏对外服会优先将请求交给同进程内的 Broker（游戏网关）来处理。
- 即使你启动了多个相同的游戏逻辑服，Broker（游戏网关）会优先将请求交给同进程的游戏逻辑服来处理。
- 同样的，游戏逻辑服处理完请求后，会优先将响应交给同进程内的 Broker（游戏网关）。
部署简图
- pid : 表示在同一个进程内。
- External : 是游戏对外服。
- Broker : 是游戏网关。
- GameLogic : 是游戏逻辑服。
- CommonGameLogic : 是一些公用的游戏逻辑服。
图中，我们启动了 3 个进程。
- pid:1111，启动了游戏对外服、Broker（游戏网关）、游戏逻辑服[A-1、B-1]。
- pid:2222，启动了游戏对外服、Broker（游戏网关）、游戏逻辑服[A-2、B-2]。
- pid:3333，启动了多个公共的游戏逻辑服。
由于在同一个进程中，当 pic:1111 有 action 请求需要处理时，会优先交给 A-1 处理。 而一些跨服的公共业务，则会将请求交给 pic:3333 来处理。
同一进程内，不同 Netty 实例之间的通信是通过内存进行传输的，不需要经过网络传输，数据传输速度极快。
合理利用同进程亲和性，可以让各服务器之间通过进程来做微隔离。
使用场景
开发者可以利用同进程亲和性的特点，按照上图中的部署方式，可以让各服务器之间通过进程来做微隔离。 此外，又能提供一些游戏逻辑服来处理公共业务。 如一些跨服活动、跨服战...等，各种跨服业务。
如下类型的游戏，可以考虑使用该部署方式
- 滚服类型的游戏
- RTS（Real Time Strategy）实时战略游戏，例如星际争霸、红色警戒。
- MOBA（Multiplayer Online Battle Arena）多人在线竞技场游戏，例如英雄联盟、DOTA2。
- ARPG（Action Role-playing Game）动作角色扮演游戏，例如暗黑破坏神、无尽之剑。
- FPS（First-person Shooter）一人称射击游戏，例如使命召唤、绝地求生。
- TPS（Third-person Shooter）第三人称射击游戏，例如疾速前进、战地。
- ...
最后
从架构简图中，我们知道了整体架构由三部分组成，分别是 1.游戏对外服、2.游戏网关、3.游戏逻辑服，三者既可相互独立，又可相互融合。
所以，使用 ioGame 几乎可以满足任意的部署方式， 可以根据你的需求来适应不同类型的游戏，并且在 ioGame 中做这些工作是简单的。
为了更简单的说明三者之间的灵活性，现在把三者用字母代替， A.游戏对外服、B.Broker（游戏网关）、C.游戏逻辑服。 我们可以得出如下组合
- ABC : 三者在一个进程中，他们之间使用内存通信，无需传输。
- AB + C : 游戏对外服和游戏网关在一个进程中，他们之间使用内存通信，传输一次。
- A + BC : 游戏网关和游戏逻辑服在一个进程中，他们之间使用内存通信，传输一次。
通过上面的组合，我们可以看出，ioGame 架构是支持类似传统架构那样只做一次跳转， 甚至可以做到零跳转，这完全取决于你们的部署方式。
上面三种组合方式，都具备同进程亲和性。同进程亲和性生效的要点只有一个，至少保证有两部分在一个进程内。