参考之前写的***集群***聊天系统，做了模块化设计，每一个模块都包含很多特定的业务，如下几个缺点：
- 1.受限于硬件资源，聊天服务器所能承受的用户的并发量
- 2.任意模块的修改，都会导致整个项目代码重新编译、部署
- 3.系统中，有些模块属于CPU密集型的，有些模块属于I/O密集型的，造成各模块对于硬件资源的需求不一样的。
单机服务器
集群服务器
- 1.在水平方向扩建机器 ，每一台服务器都独立的运行了一台聊天服务器，解决了受限于硬件资源。
- 2.但重新编译、部署更加困难了。编译一套代码，在多个机器上部署。
- 3.问题3还是没有解决，模块还是没有单独的去机器部署。但我们可以发现后台管理这样的模块，权限太大，只需要一点点资源，不需要高并发。像后台管理这样的模块，只需要把他部署在一台服务器上就够了，不需要多次部署。
分布式里面还可以包含集群。甚至可以把用户管理放在server2里面。
- 因为分布式把模块从整体拆分出来，每一个模块编译成独立运行小的服务，如果后台管理出问题了，我们只需要把后台管理模块重新编译，其余模块不需要。而且后台模块在server3，我们只需要把server3机器上的模块重新更新就完事了。解决了第二个问题
- 第三个问题很明显，如果后台管理是CPU密境 我们给这个服务器安装好的CPU资源.
- 当然分布式服务器忽然挂掉，这样又要说到容灾这些问题，主备服务器，高可用。
集群：每一台服务器独立运行一个工程的所有模块。
分布式：一个工程拆分了很多模块，每一个模块独立部署运行在一个服务器主机上，所有服务器协同工作共同提供服务，每一台服务器称作分布式的一个节点，根据节点的并发要求，对一个节点可以再做节点模块集群部署。
- 1.大系统的软件模块该怎么划分
各个模块可能会实现大量重复的代码 - 2.各个模块之间该怎么访问？
各个模块都运行不同的进程里面
机器1上的模块怎么调用机器2上的模块的一个业务方法呢
机器1上的一个模块进程1怎么调用机器1的模块进程2里面的一个业务方法呢
RPC（Remote Procedure Call Protocol）远程过程调用协议。
黄色部分：设计rpc方法参数的打包和解析，也就是数据的序列化和反序列化，使用Protobuf。
绿色部分：网络部分，包括寻找rpc服务主机，发起rpc调用请求和响应rpc调用结果，使用muduo网络库和zookeeper服务配置中心（专门做服务发现）。
mprpc框架主要包含以上两个部分的内容。
