总纲

这一章主要来谈单机、集群和分布式。从单机->集群->分布式，会介绍一下为什么我们要使用分布式的结构，这样安排有什么合理之处。

下面解释都以聊天服务器为例来解释。

单机聊天服务器

当你只有一台机器时，你所有的聊天服务器的功能都需要部署到同一台机器上，如下图所示。

那么就会有以下的问题：

• 受限于硬件资源，聊天服务器所能承受的用户并发量不大。
• 由于所有的功能模块都部署在一起，当任意一个模块被修改时，都会导致整个项目代码重新编译、部署。
• 系统中，有些模块是属于CPU密集型的，有些模块属于I/O密集型的，造成各模块对于硬件资源的需求是不一样的。

为了解决第一个问题，可以使用多台机器作为聊天服务器，这就是集群的概念。

集群—使用多台服务器部署且每台服务器都是独立的聊天系统

如下图所示：

当我们增加服务器的台数后，可以将到来的请求使用负载均衡器进行分发，这样就能够承担起更多的用户访问，即用户并发量提高了。同时，这样做还比较简单。
但是他仍然有缺陷：

• 当某一模块的内容被修改时，项目代码还是需要整体进行编译，而且需要进行多次的部署（有几台服务器就要部署几次）。
• 某些服务功能，例如后台管理，这样的服务根本不需要高并发，没有必要部署到每一台服务器上，浪费了服务器资源。

为了解决上述的两个问题，就提出了分布式的概念。

分布式—将聊天服务器中不同模块放在不同的服务器上

分布式的方式将聊天服务器中的不同模块放在不同的服务器上，这样，如果某些服务承担的任务比较重，那么我们可以多用一些机器来部署这些任务较重的服务，比如图中的分布式节点1，我们可以多搞几个。各个服务器中的功能模块，彼此之间也是相互隔离的，运行在不同的进程中，不同服务器之间的就不说了，同一个服务器中的不同服务可以运行在不同的docker虚拟环境中。

这样一来，当我们某一个功能需要修改时，只需要重新编译部署相关的服务器即可，无需更改其它无关服务器的服务；同时，我们也可以根据不同任务强度的服务来调整该服务相关服务器的个数。

那么以上就是对单机、集群和分布式的解释和优缺点分析。现在有另一个问题：
大系统的软件模块需要怎么划分？各个模块之间可能会出现重复功能的代码，怎么解决？各个模块之间是怎么互相访问的？

第一个问题，大系统软件模块的划分往往是由经验丰富的coder来进行的。

第二个问题，各个模块之间可能出现重复功能的代码，这怎么解决。比如，我们都需要某一个函数的某个功能，就比如上面提到的聊天服务器，我在进行发消息的时候需要先查看我有哪些好友（好友管理在server2上），之后我再给对应的好友发消息（消息管理在server1上），这样我不可能再把对应功能的代码粘过来对吧？那不就相当于又把两个模块耦合到一起了。我们可以让两个server之间进行通信，使得server1可以使用server2上的功能。

最后一个问题，各模块之间的访问使用的是rpc，也就是这个项目要做的事，具体可以看下面。

下一章，我来讲讲RPC的通信原理、RPC需要做什么工作、该项目的技术选型！