java netty 网络游戏服务器架构对比，与传统架构对比，N*N 问题，架构演进 ioGame

渔民小镇

已于 2023-07-07 13:47:06 修改

阅读量1k

点赞数

分类专栏： ioGame 文章标签： java 服务器架构

于 2023-07-07 13:04:35 首次发布

本文链接：https://blog.csdn.net/qq_16111009/article/details/131594555

版权

ioGame 专栏收录该内容

1 篇文章 2 订阅

订阅专栏

文章对比了传统架构和ioGame架构在连接数、心跳消耗、依赖中间件、管理使用和开发成本等方面的特点。传统架构因N*N问题导致大量内部连接和心跳消耗，依赖第三方中间件，管理复杂，成本高。而ioGame架构通过Broker解决这些问题，提供更少的内部连接、低心跳消耗，不依赖额外中间件，简化管理和降低成本，且具有更好的灵活性和适应性。

摘要由CSDN通过智能技术生成

简介

这篇，我们讨论一下传统架构与 ioGame 架构的对比，会选择性的抽出几点来做对比，但不涵盖全部，因为对比得越多，传统架构暴露的缺点也会越多。

传统架构

前置说明：

在传统架构设计中，游戏对外服部分称为网关（或称为玩家网关）。为了方便理解，这里沿用了 ioGame 游戏对外服的叫法。

传统架构设计通常都是相互直连，从图中可以看出，每个游戏逻辑服都需要与其他的逻辑服建立连接。与其他游戏逻辑服建立连接是为了能够相互通信。

由于笔墨有限，上图中只画出了三个游戏逻辑服和一个游戏对外服，此时的线条已经足够凌乱了。由于传统的架构服务器之间会相互连接，那么【实际连接数=N*(N-1)】；为了方便表达与计算，后续称这个术语称为【N*N 问题】。

N * N 问题

可以看出，传统架构会产生NN 问题，下面简单说说 NN 带来的其他问题。

在连接方面

假设我们有 1,000 个游戏逻辑服，那么光内部连接就有 1000*1000=1,000,000 个。你没有看错，是百万的内部连接。
假设我们有 10,000 个游戏逻辑服呢，此时大约有一亿个内部连接。

在心跳消耗方面

逻辑服之间的心跳：为了检测连接是否存活，就需要心跳，心跳有发送心跳与响应心跳。那么连接之间每次处理心跳的次数为：心跳次数=2NN。

先不说其他的，光心跳就占用了多少开销了。如果有 10,000 个游戏逻辑服，大约有一亿个内部连接，这样啥都没干，光每次心跳检测就消耗了 2 亿次（请求、响应）。

随着游戏对外服、游戏逻辑服的增加，内部连接总数会以恐怖的数字增加。

依赖中间件方面

此外，你还需要借助很多需要安装的第三方中间件，如：Redis、MQ、ZooKeeper …等，才能满足整体架构的运作。只要引入了需要安装的中间件，那么你的架构或者说框架，基本上与轻量级无缘了；

很多开发者无法正确分辨一个架构或框架是否是轻量级的，甚至还见过以代码量来划分是否轻量级的；spring 代码量比较多吧，这里可以明确的告诉你，spring 是轻量级的框架。

或许你会说，spring-data 系列需要安装 mysql、MongoDB、Redis 之类的，为什么还说 spring 是轻量级的；首先，spring-data 只是 spring 的一个子项目，其次，是你为了满足业务需要才引入的，而不是 spring 强行给你引入的。

一个架构、框架是不是真正的轻量级，取决于是否依赖了需要独立安装的中间件。

或许你会说，我不安装这些中间件不就是轻量级的架构或框架了。老哥，你这么说是没毛病的，但随着你的业务发展需要，安装中间件是必然的，因为传统架构就是这么设计的。

管理使用方面

你需要为每个游戏逻辑服都分配独立的端口，这里还是以 10,000 个游戏逻辑服为例，这样就需要管理着上万的端口。在这个数量的基础上，每次有新的游戏逻辑服上线，都需要从注册中心得到各游戏逻辑服的 ip:port，并与这些游戏逻辑服建立连接。

如果使用的是云服务器之类的，别忘了你还需要配置一下相关 port ，否则其他逻辑服连接不进来，别小看这一个环节，通常这些小地方最浪费开发者的时间。

开发成本

在分布式开发体验方面，大部分传统架构是不支持同进程启动多个游戏逻辑服的。这会让调试与排查问题变得非常困难，从而降低开发者的效率、增加工作量等；随着你的业务增加，你的开发成本将越来超高。

在业务开发成本，由于传统架构各自相互连接，越多越混乱，那么业务开发的复杂度无形之中又上升了。

成本方面

在使用传统架构时，在成本方面还需要关注，如：安装中间件的成本、维护中间件的成本、学习中间件的成本、部署中间件的成本。

稳定性方面的考虑，安装和使用的中间件越多，不稳定因素则越多；甚至你还得考虑团队其他成员乱用中间件的因素。

优点

由于各服务器之间是相互直连的，那么只需要一次传输就可以到达。

ioGame 架构

ioGame 架构除了具备传统架构的优点外，还能避免传统架构的所有缺点。

从图中可以看出，架构由三部分组成：1.游戏对外服、2.Broker（游戏网关）、3.游戏逻辑服；三者既可相互独立，又可相互融合。

图中每个部分各自使用了一个虚线框，并用一根长连接线条就能表示了，意思是虚线框内的每个实例都与另外的虚线框内的实例建立连接。请看下面这张图，类似把多条线捆扎在一起了。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-j55hH9PF-1688706010402)(https://oscimg.oschina.net/oscnet/up-3f98b18b5dee8da13e616a803534fb46762.png)]

N * B

这里的 N 指的是游戏对外服和游戏逻辑服，而 B 指的是 Broker（游戏网关）。

在连接方面

假设我们有 1,000 个游戏逻辑服，那么内部连接的数量是 1000*1=1,000 个。你没有看错，只有一千个内部连接。
假设我们有 10,000 个游戏逻辑服呢，此时的连接大约是一万个内部连接。

Broker（游戏网关）只负责转发请求，全是 cpu 密集型的处理；所以，我们需要 Broker（游戏网关）机器的数量并不会很多。

通过对比可以看出，无论我们如何计算，ioGame 架构的连接总数是远远少于传统架构的。

在心跳消耗方面

由于 ioGame 架构没有 N*N问题，所以在心跳开销方面几乎可以忽略不计。

依赖中间件方面

正如 ioGame 简单介绍中所说的。在轻量级方面，ioGame 不依赖任何第三方中间件或数据库就能支持集群、分布式，只需要 java 环境就可以运行。这意味着在使用上简单了，在部署上也为企业减少了部署成本、维护难度。使用 ioGame 时，只需一个依赖即可获得整个框架，而无需在安装其他服务，如： Nginx、Redis、MQ、Mysql、ZooKeeper、Protobuf协议编译工具 … …等。

管理使用方面

在 ioGame 中，你不需要为每个逻辑服（游戏对外服、游戏逻辑服）都分配独立的端口。因为逻辑服是以客户端的方式来连接 Broker（游戏网关）的，所以，我们只需要知道其中一个 Broker（游戏网关）的 ip:port 就够了。

即使是使用云服务器之类的，也不需要关心端口是否开放权限的问题了；别小看这一个环节，通常这些小地方最浪费开发者的时间。由于我们不需要管理这些 ip:port 了，意味着这部分的工作量就自然的消亡了。

更少的开发成本

在分布式开发体验方面，通常在开发分布式应用时是需要启动多个进程的。这会让调试与排查问题变得非常困难，从而降低开发者的效率、增加工作量等，这也是很多框架都解决不了的问题，但 ioGame 做到了！ioGame 支持多服单进程的启动方式，这使得开发者在开发和调试分步式系统时更加简单。

成本方面

ioGame 不依赖任何第三方中间件或数据库就能支持集群、分布式，只需要 java 环境就可以运行。从而避免了安装中间件的成本、维护中间件的成本、学习中间件的成本、部署中间件的成本

由于我们不需要打理和使用任何中间件，意味着这部分的工作量就自然的消亡了。

优点

在传统架构中，各服务器之间是相互直连的，那么只需要一次传输就可以到达。

初次接触 ioGame 的开发者在看完架构图后，会认为 ioGame 必须比传统架构多一次的跳转才能到达。这么理解是正确的，但也不完全正确，不完全正确是因为 ioGame 是具备架构多样性的，架构多样性使其具备了能够适应各种业务场景的可能性。

如果时间充裕可以先阅读 ioGame 架构多样性这篇文档，这里在简单的重复一下架构的灵活性。ioGame 的架构由三部分组成：1.游戏对外服、2.Broker（游戏网关）、3.游戏逻辑服；三者既可相互独立，又可相互融合。所以，使用 ioGame 几乎可以满足任意的部署方式，可以根据你的需求来适应不同类型的游戏，并且在 ioGame 中做这些工作是简单的。

为了更简单的说明三者之间的灵活性，现在把三者用字母代替，A.游戏对外服、B.Broker（游戏网关）、C.游戏逻辑服；我们可以得出如下组合

ABC ：三者在一个进程中，他们之间使用内存通信；（无需传输）

AB + C ：【游戏对外服和游戏网关】在一个进程中，他们之间使用内存通信；（传输一次）

A + BC ：【游戏网关和游戏逻辑服】在一个进程中，他们之间使用内存通信；（传输一次）

A + B + C : 三者在不同的进程中。（比传统多一次传输）

通过上面的组合，我们可以看出，ioGame 架构是支持类似传统架构那样只做一次跳转，甚至可以做到零跳转，这完全取决于你们的部署方式。

提示：ioGame 架构是可以做混合组合的，虽然上面只列出了 4 种，但这 4 种是可以混合使用的，不需要局限于某一种方式。ioGame 的架构由三部分组成，可以将其比作为乐高积木，想适配什么样的游戏，就组装成什么样的架构。无论如何组装，你的业务代码都不需要做任何改变。

通过不同的部署方式，可以适应各种类型的游戏。部署方式可以随意的进行切换、变更，并且部署方式的变更是不会对现有的业务造成破坏性影响的，这就是架构灵活性。

小结

本篇中，只是做了一些简单的对比。

从对比中我们可以看出，传统架构是重量级的，ioGame 架构则是轻量级的。
传统架构需要借助很多第三方中间件才能正常的运作，而引入的中间件越多，则会造成不稳定性就会上。
引入需要安装的中间件，存在着安装中间件的成本、维护中间件的成本、学习中间件的成本、部署中间件的成本。
传统架构还存在 N*N的问题，即使什么都不做，心跳就已经消耗了大部分的机器资源了。
传统的游戏逻辑服需要给每台机器安排一个启动端口，如果使用的是云服务器之类的，别忘了你还需要配置一下相关 port ，否则其他逻辑服连接不进来，别小看这一个环节，通常这些小地方最浪费开发者的时间。而 ioGame 中的逻辑服不需要做这些工作，意味着这部分的工作量自然的消亡了。

这里还没有对比通讯方式，ioGame 提供了多种通讯方式，帮助开发者简化跨进程通信，并且这些通讯方式是可扩展的，通过这些丰富的通讯方式，几乎可以满足任何业务。