架构介绍

名称	扩展方式	职责
ExternalServer，游戏对外服	分布式	与玩家连接、交互
GameLogicServer，游戏逻辑服	分布式	处理具体业务逻辑
BrokerCluster，Broker（游戏网关）	集群	调度和转发任务

介绍

从架构简图中，我们知道了整体架构由三部分组成，分别是 1.游戏对外服、2.游戏网关、3.游戏逻辑服，三者既可相互独立，又可相互融合。

• 游戏对外服、Broker（游戏网关）、游戏逻辑服这三部分，在一个进程中。(单体应用，在开发分布式时，调试更加方便)
• 游戏对外服、Broker（游戏网关）、游戏逻辑服这三部分，在多个进程中。(分布式)
• 游戏对外服、Broker（游戏网关）这两部分在一个进程中，而游戏逻辑服在多个进程中。(类似之前游戏的传统架构)
• 甚至可以不需要游戏对外服，只使用 Broker（游戏网关）和游戏逻辑服这两部分，用于其他系统业务。

因为 ioGame 遵循面向对象的设计原则（单一职责原则、开闭原则、里式替换原则、依赖倒置原则、接口隔离原则、迪米特法则）等， 所以使得架构的职责分明，可以灵活的进行组合。

开发人员几乎都遇见过这么一种情况，在项目初期阶段，通常是以单体项目的方式进行开发，随着需求不断的增加与迭代，会演变成一个臃肿的项目。 此时在对一个整体进行拆分是困难的，成本是极高的。甚至是不可完成的，最后导致完全的重新重构。

ioGame 提供了在结构组合上的部署多样性，通过组合的方式，在项目初期就可以避免这些拆分问题。 在开发阶段中，我们可以使用单体应用开发思维，降低了开发成本。 通过单体应用的开发方式，在开发分布式项目时，调试更加的方便。 这既能兼顾分布式开发、项目模块的拆分，又能降低团队的开发成本。

架构优点

架构有很高程度的抽象，可以让设计者更加关注于业务，而无需考虑底层的实现、通信参数等问题。

我们采用模块化、抽象化的架构，显著降低了各服务器间的耦合度。 逻辑服务器可以即时注册使用，这极大地提升了系统的伸缩性与可维护性，使得动态扩展变得简单高效。

由于逻辑服务器注册到 Broker（游戏网关）上，因此可以动态地增加、删除或修改。 此外，逻辑服务器之间较低的耦合度也使得调试和测试工作更易于管理。

架构比较清晰的就是，游戏对外服负责维护客户端的接入（用户、玩家的连接），游戏逻辑服专心负责业务逻辑， 他们之间的调度由 Broker（游戏网关）来负责。 因为架构拆分的合理，所以特别方便用 k8s 来自由伸缩部署这三种服，哪个服水位高就扩容哪个，水位过去了又可以缩容。

游戏网关集群

Broker （游戏网关）支持集群的方式部署，集群的使用是简单的，集群无中心节点、集群自动化、自带负载均衡。 ioGame 本身就包含服务注册，你不需要外接一个服务注册中心，如 Eureka，ZooKeeper 等（变相的节约服务器成本）。

通过 Broker （游戏网关） 的介入，之前非常复杂的负载均衡设计，如服务注册、健康度检查（后续版本提供）、到服务端的连接维护等这些问题， 在 ioGame 中都不需要了，结构也简单了很多。实际上单台 Broker （游戏网关） 性能已经能够满足了，因为游戏网关只做了转发。

支持的扩展数量

逻辑服通常说的是游戏对外服和游戏逻辑服。逻辑服的数量支持扩展，扩展数量的理论上限是 netty 的连接上限。