Rpc分布式网络通信框架(1)

理论准备

单机聊天服务器的缺点 :

• 受限于硬件资源, 并发量有限制 -> 集群服务器解决
• 任意模块的修改都会导致整体的编译部署 -> 分布式解决
• 有些模块是CPU密集型, 有些是IO密集型, 对硬件资源不一样 -> 分布式解决

集群与分布式 :

• 集群 : 每个里面都运行了一个独立系统, 有全套的服务.
• 分布式 : 将不同服务搭载在不同的服务器上, 还可以对单个分布式节点集群.

分布式面临问题 :

• 模块如何划分?
• 各模块之间如何访问? -> 涉及网络传输

RPC(remote procedure call 远程过程调用)通信原理

• 将请求序列化, 经由服务发现将请求通过网络发送到目标服务器, 对端接收并反序列化, 调用目标函数并返回, 返回也要经历上述过程.

RPC分布式网络通信框架

这只是一个框架, 可以帮助我们将自己的服务发布为rpc节点, 或帮助我们调用其他发布者发布的rpc节点中的方法, 接下来让我们深入了解.

服务与方法

这只是一个标准的概念, 服务包含方法, 一个服务可以有很多方法, 一个方法就对应一个函数, 其实服务就是起到一个分类的作用, 在rpc中通常以此作为分类标准.

具体框架

• 假如我们要调用一个远程服务, 也就是调用一个远程服务器上的函数并将参数传入, 获取该函数返回的内容, 在这之中函数发布者和函数调用者都会有一些特定的操作.

• Provider(发布者)

  将自己想发布的方法包装进服务中, 发布该服务, 意味着自己作为服务器持续接收远端通过网络发送来的调用请求, 接收请求的处理逻辑如下 :

  • 利用muduo库进行网络消息的接收 -> 反序列化取出请求的服务/方法/参数 -> 调用对应函数并产生返回值 -> 将返回值序列化 -> 通过muduo库将返回值发送回去

• Consumer(调用者)

  只要知道了发布rpc服务节点的地址, 就可以通过接近普通方法的调用方式调用到远程方法.

  • 直接获知目标rpc的地址或通过服务发现获取地址 -> 将服务/方法/参数序列化发送给目标地址 -> 等待接收返回值并反序列化.

这其中我们有两大工具必不可少 :

• Protobuf

  类似于json用于网络通信的序列化和反序列化的工具, 不过其支持对rpc服务的序列化和反序列化, 可以使框架的构建更加简便.

• Zookeeper

  服务发现工具, 帮助客户端找到目标服务方法的地址.

Zookeeper分布式协调服务

服务发现 / 分布式锁

一个注册中心, 保存了所有可获得的服务和其对应的URL(ip / port).

znode节点

zookeeper服务专属的数据存储节点, 类似一个树, 用来存储服务, 一个节点最多存储1兆数据

Watcher

在节点变化时使用Watcher的客户端会得到通知.