RPC分布式网络通信框架：集群与分布式理论

一、集群与分布式理论

集群：每一台服务器独立运行一个工程的所有模块。
分布式：一个工程拆分了很多模块，每一个模块独立部署运行在一个服务器主机上，所有服务器协同工作共同提供服务，每一台服务器称作分布式的一个节点，根据节点的并发要求，对一个节点可以再做节点模块集群部署。

为什么需要分布式？
单机聊天服务器在性能瓶颈上会遇到的问题：
问题1：受限于硬件资源，聊天服务器所能承受用户的并发量有限。
问题2：任意功能模块代码的修改，都会导致整个项目代码重新编译、部署，效率较差。
问题3：系统中有些模块属于CPU密集型，有些模块属于I/O密集型，造成各模块对于硬件资源的需求不一样。

针对于上述问题，我们可以将单台服务器扩充为服务器集群：
问题1：非常轻松的进行硬件资源扩充，聊天服务器所能承受用户的并发量提高，每一台服务器都是一套独立的聊天系统，问题得到解决。
问题2：任意功能模块代码的修改，所有服务器还是需要重新编译，而且需要进行多次部署，问题更加严重了。
问题3：集群只是水平的扩展了服务器，模块并未分开进行部署，问题依旧存在。

针对于上述问题，我们可以将服务器集群改为分布式的： 不同的模块依旧不同的需求部署在不同的分布式节点上，一个分布式节点可以根据需求再进行集群部署。
问题1：整体业务被拆分为多个模块，针对于经常使用的业务可以进行多次节点集群部署，用户并发量提高，问题得到解决。
问题2：每一个模块从整体业务拆分开来，可独立运行、独立部署，只需要针对于出问题的模块进行重新编译，问题得到解决。
问题3：针对于CPU密集型、I/O密集型等不同模块所在的分布式节点，根据不同需求分配或减少资源，问题得到解决。

 

二、RPC分布式网络通信框架原理

为什么需要RPC分布式网络通信框架？
虽然上述问题使用分布式完美得到解决，但也因此产生了一些问题：
问题1：大系统的软件模块如何划分，划分不清楚会产生各模块出现大量重复代码。
问题2：各个模块被拆分到多个机器的不同进程上，涉及网络传输，业务接口相互访问非常复杂。
此时就需要分布式网络通信框架了，使用该框架将远程方法调用的所有细节包装起来，用户在不同的分布式节点上访问远程机器上的接口就像调用进程内的方法一样简单。

RPC(Remote Procedure Call Protocol)远程过程调用协议：
黄色部分： 设计rpc方法参数的打包和解析，也就是数据的序列化和反序列化，使用Protobuf。
绿色部分： 网络部分，包括寻找rpc服务主机，发起rpc调用请求和响应rpc调用结果，使用muduo网络库和zookeeper服务配置中心(专门做服务发现)。
RPC通信流程： 调用者发起了远程方法调用，因为是远程RPC方法需要先去服务配置中心查找该方法在哪一台机器上，将调用方RPC方法名字及参数都进行打包序列化，序列化好后将请求通过网络(muduo网络库)发送出去；被调用者从网络上接收到RPC调用请求后，将字节流从网络底层上报上来，再进行数据反序列化为具体RPC调用标识、参数等具体信息，然后在服务器上执行该方法。执行完方法后返回相应结果，需要先将结果打包序列化后通过网络(muduo网络库)发送出去；调用者接收到数据后会将字节流从网络底层上报上来，再进行数据反序列后得到具体数据结果。