单机聊天服务器

聊天系统做了模块化设计，每一个模块都包含很多特定的业务

缺点：

1. 单机聊天服务器极大程度的受限于硬件资源，服务器所能承受的用户并发量是有限的，即使我们通过改变最大连接量等参数，但是受到单机本身物理性质的限制，并发量是存在上限的；

2. 在项目中，客户需求发生改变的时候，我们对任意模块进行修改，即使很小的模块，很小的修改，都会导致整个项目代码重新编译、部署，对于大型项目来说，十分耗时，如果修改有误，再次修改就会导致重新编译；

3. 系统中，有些模块是CPU密集型，有些是IO密集型，造成各模块对硬件资源的需求是不一样的，我们对此的部署也应该是不同的，否则会导致CPU性能利用率低等现象。

集群聊天服务器

每一台服务器都是一套独立的聊天系统

优点

用户并发量得到了提升，集群部署简单！

缺点

1. 修改模块项目代码还是需要重新编译，并且不同的服务器都需要进行再次编译，从而要进行多次编译，相比于单机聊天服务器，编译更加费时费力

2. 有些模块是CPU密集型，有些是IO密集型，造成各模块对硬件资源的需求是不一样的，比如后台管理不需要高并发，所以不需要每台机器都部署相同的聊天系统。

分布式聊天服务器

一个项目拆分成多个模块，每一个模块独立部署在一个服务器上，所有服务器协同工作共同完成项目需要，对客户提供所需服务。对此，每一台服务器称作分布式的一个节点，根据节点的并发要求，对一个节点可以再做节点模块集群部署，比如下图分布式节点1可以再集群部署出分布式节点1-1，分布式节点1-2，…针对不同的需求，可以按需部署相应的资源。

分布式聊天系统存在的问题

1. 对于系统中的各类软件模块，如果合理的进行划分？各个模块之间的耦合问题会造成各模块可能会实现大量重复的代码，如何去避免这样的事件的发生。

2. 各模块都运行在不同的进程里（如docker虚拟化环境中），各模块之间如何通信呢？例如机器1上的模块怎么调用机器2上的模块的一个业务方法？机器1上的一个模块进程1怎么调用机器1上的模块进程2里面的一个业务方法呢？

这也是我们这个项目要解决的问题，接下来我们将会一步一步的解决这些问题。