与传统架构对比
介绍
这篇，我们讨论一下传统架构与 ionet 架构的对比，会选择性的抽出几点来做对比， 但不涵盖全部，因为对比得越多，传统架构暴露的缺点也会越多。
传统架构
在传统架构设计中，对外服部分称为网关（或称为玩家网关）。 为了方便理解，这里沿用了 ionet 对外服的叫法。
传统架构设计通常都是相互直连，从图中可以看出，每个逻辑服都需要与其他的逻辑服建立连接以便能够相互通信。
由于笔墨有限，上图中只画出了 4 个逻辑服和一个对外服，此时的线条已经足够凌乱了。 由于传统的架构服务器之间会相互连接，那么实际连接数 = N * (N-1)。 为了方便表达与计算，后续称这个术语称为 N*N 问题。
N * N 问题
可以看出，传统架构会产生 N*N 问题，下面简单说说 N*N 带来的其他问题。
在连接方面
假设我们有 1,000 个逻辑服，那么光内部连接就有 1000*1000=1,000,000 个。 你没有看错，是百万的内部连接。 那么 10,000 个逻辑服呢？此时的连接大约是一亿个内部连接。
在心跳消耗方面
为了检测连接是否存活，就需要心跳，心跳有发送心跳与响应心跳。 那么连接之间每次处理心跳的次数是 2*N*N。
先不说其他的，光心跳就占用了多少开销了。 如果有 10,000 个逻辑服，大约有一亿个内部连接，这样啥都没干，光每次心跳检测就消耗了 2 亿次（请求、响应）。
随着对外服、逻辑服的增加，内部连接总数会以恐怖的数字增加。
依赖中间件方面
此外，你还需要借助很多需要安装的第三方中间件，如：Redis、MQ、ZooKeeper ...等，才能满足整体架构的运作。 只要引入了需要安装的中间件，那么你的架构或者说框架，基本上与轻量级无缘了。
很多开发者无法正确分辨一个架构或框架是否是轻量级的，甚至还见过以代码量来划分是否轻量级的。 Spring 代码量比较多吧，这里可以明确的告诉你，Spring 是轻量级的框架。
或许你会问，Spring-Data 系列需要安装 Mysql、MongoDB、Redis 之类的，为什么还说 Spring 是轻量级的。 首先，Spring-Data 只是 Spring 的一个子项目， 其次，是你为了满足业务需要才引入的，而不是 Spring 强行给你引入的。
一个架构、框架是不是真正的轻量级，取决于是否依赖了需要独立安装的中间件。
或许你会说，我不安装这些中间件不就是轻量级的架构或框架了。 老哥，你这么说是没毛病的，但随着你的业务发展需要，安装中间件是必然的，因为传统架构就是这么设计的。
管理使用方面
你需要为每个逻辑服都分配独立的端口，这里还是以 10,000 个逻辑服为例，这样就需要管理着上万的端口。 在这个数量的基础上，每次有新的逻辑服上线，都需要从注册中心得到各逻辑服的 ip:port，并与这些逻辑服建立连接。
如果使用的是云服务器之类的，别忘了你还需要配置一下相关 port ，否则其他逻辑服连接不进来，别小看这一个环节，通常这些小地方最浪费开发者的时间。
开发成本
在分布式开发体验方面，大部分传统架构是不支持同进程启动多个逻辑服的。 这会让调试与排查问题变得非常困难，从而降低开发者的效率、增加工作量等。 随着你的业务增加，你的开发成本将越来超高。
在业务开发成本，由于传统架构各自相互连接，越多越混乱，那么业务开发的复杂度无形之中又上升了。
成本方面
在使用传统架构时，在成本方面还需要关注，如：安装中间件的成本、维护中间件的成本、学习中间件的成本、部署中间件的成本。
稳定性方面的考虑，安装和使用的中间件越多，不稳定因素则越多，甚至你还得考虑团队其他成员乱用中间件的因素。
优点
由于各服务器之间是相互直连的，那么只需要一次传输就可以到达。
ionet 架构
ionet 架构除了具备传统架构的优点外，还能避免传统架构的所有缺点。 重要的是，没有 N*N 问题。
无锁异步化、事件驱动的架构设计；真轻量级，无需依赖任何第三方中间件就能搭建出一个分布式的网络通信服务器。
自带负载均衡、分布式支持、可动态增减机器。
| 名称 | 扩展方式 | 职责 |
|---|---|---|
| ExternalServer | 分布式 | 对外服的职责是与用户连接、交互 |
| LogicServer | 分布式 | 逻辑服的职责是处理具体业务逻辑 |
从架构简图中，我们知道了整体架构由对外服和逻辑服组成，两者既可相互独立，又可相互融合。
P * P
这里的 P 指的是进程。
ionet 架构没有 N*N 问题，这主要是因为
- 多个对外服和逻辑服可以在一个进程内启动。
- 逻辑服之间使用可靠 UDP 通信，是无长连接的。
在连接方面
由于 ionet 内部通信使用可靠 UDP，是无长连接的。 无论你有 1,000 个逻辑服，还是 10,000 个逻辑服，他们之间都不会建立长连接。
在心跳消耗方面
一个进程可以包含多个对外服和逻辑服，那么进程之间每次处理心跳的次数是 2*P*P。 由于一个进程可以包含多个对外服和逻辑服，那么在心跳开销方面几乎可以忽略不计。
依赖中间件方面
在轻量级方面，框架不依赖任何第三方中间件就能支持分布式网络通信，只需要 java 环境就可以运行。 这意味着在使用上简单了，在部署上也为企业减少了部署成本、维护难度。 使用 ionet 时，只需一个依赖即可获得整个框架，而无需安装其他服务，如 Nginx、Redis、MQ、Mysql、ZooKeeper、Protobuf 协议编译工具 ...等。
管理使用方面
在安全方面，所有的逻辑服不需要开放端口，天然地避免了扫描攻击。
在 ionet 中，你不需要为每个对外服和逻辑服分配独立的端口。 由于不需要为每个逻辑服分配独立的端口，那么我们在使用诸如云服务器之类的服务时，就不需要担心端口开放权限的问题了。 别小看这一个环节，通常这些小细节最浪费开发者的时间。 由于我们不需要管理这些 IP:Port，这部分的工作量就自然地消失了。
更好的分布式开发体验
在分布式开发体验方面，通常在开发分布式应用时是需要启动多个进程的。 这会让调试与排查问题变得非常困难，从而降低开发者的效率、增加工作量等，这也是很多框架都解决不了的问题，但 ionet 做到了！ ionet 支持多服单进程的启动方式，这使得开发者在开发和调试分布式系统时更加简单。
成本方面
ionet 不依赖任何第三方中间件或数据库就能支持分布式，只需要 java 环境就可以运行。 从而避免了安装中间件的成本、维护中间件的成本、学习中间件的成本、部署中间件的成本
由于我们不需要打理和使用任何中间件，意味着这部分的工作量就自然的消亡了。
优点
逻辑服之间通过 IPC 通信，无任何网络请求。
see 为什么快
小结
本篇中，只是做了一些简单的对比。
- 从对比中我们可以看出，传统架构是重量级的，ionet 架构则是轻量级的。
- 传统架构需要借助很多第三方中间件才能正常的运作，而引入的中间件越多，则会造成不稳定性就会上。
- 引入需要安装的中间件，存在着安装中间件的成本、维护中间件的成本、学习中间件的成本、部署中间件的成本。
- 传统架构还存在 N*N 的问题，即使什么都不做，心跳就已经消耗了大部分的机器资源了。
- 传统的逻辑服需要给每台机器安排一个启动端口，如果使用的是云服务器之类的， 别忘了你还需要配置一下相关 Port，否则其他逻辑服连接不进来，别小看这一个环节，通常这些小地方最浪费开发者的时间。 而 ionet 中的逻辑服不需要做这些工作，意味着这部分的工作量自然的消亡了。
这里还没有对比通信方式，ionet 提供了多种通信方式，帮助开发者简化跨进程通信，并且这些通信方式是可扩展的，通过这些丰富的通信方式，几乎可以满足任何业务。