【项目】C++实现JsonRpc框架——功能分析与模块划分

文章目录

一、项目功能分析
二、模块划分
- [1. 服务端模块划分](#1. 服务端模块划分)
- - [1.1 Network](#1.1 Network)
  - [1.2 Protocol](#1.2 Protocol)
  - [1.3 Dispatcher](#1.3 Dispatcher)
  - [1.4 RpcRouter](#1.4 RpcRouter)
  - [1.5 Publish-Subscribe](#1.5 Publish-Subscribe)
  - [1.6 Registry-Discovery](#1.6 Registry-Discovery)
  - [1.7 Server](#1.7 Server)
- [2. 客户端模块划分](#2. 客户端模块划分)
- - [2.1 Network](#2.1 Network)
  - [2.2 Protocol](#2.2 Protocol)
  - [2.3 Dispatcher](#2.3 Dispatcher)
  - [2.4 Requestor](#2.4 Requestor)
  - [2.5 RpcCaller](#2.5 RpcCaller)
  - [2.6 Publish-Subscribe](#2.6 Publish-Subscribe)
  - [2.7 Registry-Discovery](#2.7 Registry-Discovery)
  - [2.8 Client](#2.8 Client)
三、框架设计
- [1. 抽象层](#1. 抽象层)
- [2. 具象层](#2. 具象层)
- [3. 业务层](#3. 业务层)

一、项目功能分析

本质上来讲，我们要实现的rpc（远端调用）思想上并不复杂，其实就是客户端想要完成某个任务的处理，但是这个处理的过程并不自己来完成，而是将请求发送到服务器上，让服务器来帮其完成处理过程，并返回结果，客户端拿到结果后返回。

然而上图的模型中，是一种多对一或一对一的关系。一旦服务端掉线，则客户端无法进行远端调用，且其服务端的负载也会较高。因此在rpc实现中，我们不仅要实现其基本功能，还要再进一步，实现分布式架构的rpc。

分布式架构：简单理解就是由多个节点组成的一个系统，这些节点通常指的是服务器，将不同的业务或者同一个业务拆分分布在不同的节点上，通过协同工作解决高并发的问题，提高系统扩展性和可用性。

其思想也并不复杂，也就是在原来的模型基础上，增加一个注册中心，基于注册中心，不同的服务提供服务器向注册中心进行服务注册，相当于告诉注册中心自己能够提供什么服务，而客户端在进行远端调用前，先通过注册中心进行服务发现，找到能够提供服务的服务器，然后发起调用。

而其次，发布订阅功能，则是依托于多个客户端围绕服务端进行消息的转发。单纯的消息转发功能，并不能满足于大部分场景的需要，因此在其基础上实现基于主题订阅的转发。

在上图的结构中，我们可以让每一个Server作为备用注册中心形成分布式架构，一旦一个注册中心下线，可以向备用中心进行注册以及请求，且在此基础上客户端在请求Rpc服务的时候，因为可以有多个rpc-provider可选，因此可以实现简单的负载均衡策略，且基于注册中心可以更简便实现发布订阅的功能。

总结一下，这个项目的三个主要功能：

RPC远程调用功能
服务的注册与发现以及服务的下线/上线通知
消息主题的发布与订阅

二、模块划分

1. 服务端模块划分

服务端的功能需求：

基于网络通信接收客户端的请求，提供rpc服务
基于网络通信接收客户端的请求，提供服务注册与发现，上线&下线通知服务
基于网络通信接收客户端的请求，提供主题操作（创建/删除/订阅/取消订阅），消息发布

在服务端的模块划分中，基于以上理解的功能，可以划分出这么几个模块：

Network：网络通信模块
Protocol：应用层通信协议模块
Dispatcher：消息分发处理模块
RpcRouter：远端调用路由功能模块
Publish-Subscribe：主题发布订阅功能模块
Registry-Discovery：服务注册/发现/上线/下线功能模块
Server：基于以上模块整合而出的服务端模块

1.1 Network

该模块为网络通信模块，实现底层的网络通信功能，该模块我们将使用陈硕的Muduo库来进行搭建。

1.2 Protocol

应用层通信协议模块的存在意义：解析数据，解决通信中有可能存在的粘包问题，能够获取到一条完整的消息。

在前边的muduo库基本使用中，我们能够知道想要让一个服务端/客户端对消息处理，就要设置一个onMessage的回调函数，在这个函数中对收到的数据进行应用层协议处理。

而Protocol模块就是是网络通信协议模块的设计，也就是在网络通信中，我们必须设计一个应用层的网络通信协议出来，以解决网络通信中可能存在的粘包问题，通常解决粘包有三种方式：特殊字符间隔、定长、LV格式。

使用特殊字符间隔方法，则如果正文中也出现特殊字符，还需要转义处理；

使用报文定长方法，则消息之间长度差距大，定长则系统开销高；

所以，我们项目中将使用LV格式来定义应用层的通信协议格式。

简单来说，LV格式是一种将数据表示为正文长度（Length）+ 正文（Value）的编码方式。

Length：该字段固定4字节长度，用于表示后续的本条消息数据长度。

MType：该字段为Value中的固定字段，固定4字节长度，用于表示该条消息的类型。

Rpc调用请求/响应类型消息
主题发布/订阅/取消订阅/消息推送类型消息
主题创建/删除类型消息
服务注册/发现/上线/下线类型消息

IDLength：为消息中的固定字段，该字段固定4字节长度，用于描述后续ID字段的实际长度。

MID：在每条消息中都会有一个固定字段为ID字段，用于唯一标识消息，ID字段长度不固定。

Body：消息主题正文数据字段，为请求或响应的实际内容字段。

1.3 Dispatcher

这个模块存在的意义：区分消息类型，根据不同的类型，调用不同的业务处理函数进行消息处理。

当muduo库底层通信收到数据后，在onMessage回调函数中对数据进行应用层协议解析，得到一条实际消息载荷后，我们就该判断这条消息代表这客户端的什么请求，以及应该如何处理。

因此，我们需要Dispatcher模块，作为一个分发模块，这个模块内部会保存一个hash_map<消息类型, 回调函数>，以此由使用者来决定哪条消息用哪个业务函数进行处理，当收到消息后，在该模块找到其对应的处理回调函数进行调用即可。

rpc请求&响应类型
服务注册/发现/上线/下线请求&响应类型
主题创建/删除/订阅/取消订阅请求&响应，消息发布的请求&响应

1.4 RpcRouter

RpcRouter模块存在的意义：提供rpc请求的处理回调函数。内部所要实现的功能，是分辨出客户端请求的服务进行处理得到结果进行响应。

rpc请求中，最关键的两个点：

请求方法（函数）名称
请求对应要处理的参数信息

在Rpc远端调用中，首先将客户端到服务端的通信链路打通，然后将自己所需要调用的服务名称，以及参数信息传递给服务端，由服务端进行接收处理，并返回结果。

而不管是客户端要传递给服务端的服务名称以及参数信息，或者服务端返回的结果，都是在上边Protocol中定义的Body字段中，因此Body字段中就存在了另一层的正文序列化/反序列化过程。

序列化方式有很多种，鉴于当前我们是json-rpc，因此这个序列化过程我们就初步使用json序列化来进行，所定义格式如下:

json 复制代码

//RPC-request
{
	"method" : "Add",
	"parameters" : 
	{
		"num1" : 11,
		"num2" : 22
	}
}
//RPC-response
{
	"rcode" : OK,
	"result": 33
}
{
	"rcode" : ERROR_INVALID_PARAMETERS
}

要注意的是，在服务端，当接收到这么一条消息后，Dispatcher模块会找到该Rpc请求类型的回调处理函数进行业务处理，但是在进行业务处理的时候，也是只会将 parameters 参数字段传入回调函数中进行处理。

然而，对服务端来说，应该从传入的Json::Value对象中，有什么样的参数，以及参数信息是否符合自己所提供的服务的要求，都应该先检测是否符合要求，符合要求了再取出指定字段的数据进行处理。

因此，对服务端来说，在进行服务注册的时候，必须有一个服务描述，以代码段中的Add请求为例，该服务描述中就应该描述：

服务名称： Add，
参数名称： num1，是一个整形，
参数名称： num2，是一个整形，
返回值类型：整形

有了这个描述，在回调函数中就可以先对传入的参数进行校验，没问题了则取出指定字段数据进行处理并返回结果。

基于以上理解，在实现该模块时，应该有以下设计：

该模块必须具备一个Rpc路由管理，其中包含对于每个服务的参数校验功能
该模块必须具备一个方法名称和方法业务回调的映射
该模块必须向外提供Rpc请求的业务处理函数。

Publish-Subscribe模块存在的意义：针对主题的发布订阅请求进行处理，提供一个回调函数设置给Dispatcher模块。

发布订阅所包含的请求操作：

主题的创建
主题的删除
主题的订阅
主题的取消订阅
主题消息的发布

在当前的项目中，我们实现一个简单的发布订阅功能，该功能是围绕多个客户端与一个服务端来展开的。

即，任意一个客户端在发布或订阅之前先创建一个主题，比如在新闻发布中我们创建一个音乐新闻主题，哪些客户端希望能够收到音乐新闻相关的消息，则就订阅这个主题，服务端会建立起该主题与客户端之间的联系。

当某个客户端向服务端发布消息，且发布消息的目标主题是音乐新闻主题，则服务端会找出订阅了该主题的其他客户端，将消息推送给这些客户端。

既然涉及到网络通信，那就先将通信消息的正文格式定义出来：

json 复制代码

//Topic-request
{
	"key" : "music", //主题名称
	// 主题操作类型
	"optype" : TOPIC_CRAETE/TOPIC_REMOVE/TOPIC_SUBSCRIBE/TOPIC_CANCEL/TOPIC_PUBLISH,
	//TOPIC_PUBLISH请求才会包含有message字段
	"message" : "Hello World"
}

//Topic-response
{
	"rcode" : OK/ERROR_INVALID_PARAMETERS,
}

主题和订阅者的关系是"多对多"，一个主题可能有多个客户端订阅，一个客户端可以订阅多个主题。因此：

该模块必须具备一个主题管理，且主题中需要保存订阅了该主题的客户端连接（hash_map<Topic, vector<Connection>>）。主题收到一条消息，需要将这条消息推送给订阅了该主题的所有客户端。
该模块必须具备一个订阅者管理，且每个订阅者描述中都必须保存自己所订阅的主题名称（hash_map<Connection, vector<Topic>>）。目的是为了当一个订阅客户端断开连接时，能够找到订阅信息的关联关系，进行删除。
该模块必须向外提供主题创建/删除，主题订阅/取消订阅，消息发布处理的业务处理函数

1.6 Registry-Discovery

Registry-Discovery模块存在的意义：就是针对服务注册与发现请求的处理。

服务注册/发现类型请求中的详细划分:

服务注册：服务provider告诉中转中心，自己能提供哪些服务
服务发现：服务caller询问中转中心，谁能提供指定服务
服务上线：在一个provider上线了指定服务后，通知发现过该服务的客户端有个provider可以提供该服务
服务下线：在一个provider断开连接，通知发现过该服务的caller，谁下线了哪个服务

服务注册模块，该模块主要是为了实现分布式架构而存在，让每一个rpc客户端能够从不同的节点主机上获取自己所需的服务，让业务更具扩展性，系统更具健壮性。

而为了能够让rpc-caller知道有哪些rpc-provider能提供自己所需服务，那么就需要有一个注册中心让这些rpc-provider去注册登记自己的服务，让rpc-caller来发现这些服务。

因此，在我们的服务端功能中，需实现服务的注册/发现，以及服务的上线/下线功能。

json 复制代码

//RD-request
{
	//SERVICE_REGISTRY-Rpc-provider进行服务注册
	//SERVICE_DISCOVERY - Rpc-caller进行服务发现
	//SERVICE_ONLINE/SERVICE_OFFLINE 在provider下线后对caller进行服务上下线通知
	"optype" : SERVICE_REGISTRY/SERVICE_DISCOVERY/SERVICE_ONLINE/SERVICE_OFFLINE,
	"method" : "Add",
	//服务注册/上线/下线有host字段，发现则无host字段(因为发现请求的目的本就是寻找能提供服务的host)
	"host" : 
	{
		"ip" : "127.0.0.1",
		"port" : 9090
	}
}

//RD-response
{
	"rcode" : OK/ERROR_INVALID_PARAMETERS
}

//如果是发现请求，则应答中需要添加以下发现结果字段
{
	"method" : "Add",
	"host" : 
	[
		{"ip" : "127.0.0.1","port" : 9090},
		{"ip" : "127.0.0.2","port" : 8080}
	]
}

该模块的设计如下：

必须具备一个服务发现者的管理（hash_map<method, vector<Discoverer>>）：
- 方法与发现者：当一个客户端进行服务发现的时候，进行记录谁发现过该服务，当有一个新的提供者上线的时候，可以通知该发现者。
- 连接与发现者：当一个发现者断开连接了，删除关联关系，往后就不需要通知它了。
必须具备一个服务提供者的管理（hash_map<method, vector<Provider>>）：
- 连接与提供者：当一个提供者断开连接的时候，能够通知该提供者提供的服务对应的发现者，该主机的该服务下线了
- 方法与提供者：能够知道谁的哪些方法下线了，然后通知发现过该方法的客户端
必须向Dispatcher模块提供一个服务注册/发现的业务处理回调函数
- 这样，当一个rpc-provider登记了服务，则将其管理起来，当rpc-caller进行服务发现时，则将保存的对应服务所对应的主机信息，响应给rpc-caller。
- 而当中途一个rpc-provider2上线登记服务时，则可以给进行了对应服务发现的rpc-caller进行服务上线通知，通知rpc-caller当前多了一个对应服务的rpc-provider2。同时，当一个rpc-provider2下线时，则可以找到进行了该服务发现的rpc-caller进行服务的下线通知。

1.7 Server

当以上的所有功能模块都完成后，我们就可以将所有功能整合到一起来实现服务端程序了。

RpcServer：rpc功能模块与网络通信部分结合。
RegistryServer：服务发现注册功能模块与网络通信部分结合
TopicServer：发布订阅功能模块与网络通信部分结合。

2. 客户端模块划分

在客户端的模块划分中，基于以上理解的功能，可以划分出这么几个模块

Protocol：应用层通信协议模块
Network：网络通信模块
Dispatcher：消息分发处理模块
Requestor：请求管理模块
RpcCaller：远端调用功能模块
Publish-Subscribe：发布订阅功能模块
Registry-Discovery：服务注册/发现/上线/下线功能模块
Client：基于以上模块整合而出的客户端模块

其中，前三层与服务端几乎相同

2.1 Network

网络通信基于muduo库实现网络通信客户端

2.2 Protocol

应用层通信协议处理，与服务端保持一致。

2.3 Dispatcher

IO数据分发处理，逻辑与服务端一致

2.4 Requestor

Requestor模块存在的意义：针对客户端的每一条请求进行管理，以便于对请求对应的响应做出合适的操作。

首先，对于客户端来说，不同的地方在于，更多时候客户端是请求方，是主动发起请求服务的一方。而在多线程的网络通信中，多线程下，针对多个请求进行响应可能会存在时序的问题，则我们无法保证一个线程发送一个请求后，接下来接收到的响应就是针对自己这条请求的响应。

其次，类似于Muduo库这种异步IO网络通信库，通常IO操作都是异步操作，即发送数据就是把数据放入发送缓冲区，但是什么时候会发送由底层的网络库来进行协调，并且也并不会提供recv接口，而是在连接触发可读事件后，IO读取数据完成后调用处理回调进行数据处理，因此也无法直接在发送请求后去等待该条请求的响应。

针对以上问题，我们创建出当前的请求管理模块来解决，它的思想也非常简单，就是给每一个请求都设定一个请求ID，服务端进行响应的时候标识响应针对的是哪个请求（也就是响应信息中会包含请求ID），因此客户端这边我们不管收到哪条请求的响应，将数据存储入一个hash_map中，以请求ID作为映射，并向外提供获取指定请求ID响应的阻塞接口，这样只要在发送请求的时候知道自己的请求ID，那么就能获取到自己想要的响应，而不会出现异常。

针对这个思想，我们再进一步，可以将每个请求进一步封装描述，添加入异步future控制，或者设置回调函数的方式。不仅可以阻塞获取响应，也可以实现异步获取响应以及回调处理响应。

2.5 RpcCaller

RpcCaller模块存在的意义：向用户提供进行rpc调用的模块。

Rpc服务调用模块，这个模块相对简单，只需要向外提供几个rpc调用的接口，内部实现向服务端发送请求，等待获取结果即可，稍微麻烦一些的是Rpc调用我们需要提供多种不同方式的调用：

同步调用：发起调用后，等收到响应结果后返回
异步调用：发起调用后立即返回，在想获取结果的时候进行获取
回调调用：发起调用的同时设置结果的处理回调，收到响应后自动对结果进行回调处理

Publish-Subscribe模块存在的意义：向用户提供发布订阅所需的接口，针对推送过来的消息进行处理。

发布订阅稍微能复杂一丢丢，因为在发布订阅中有两种角色，一个客户端可能是消息的发布者，也可能是消息的订阅者。

而且不管是哪个角色都是对主题进行操作，因此其中也包含了主题的相关操作，比如，要发布一条消息需要先创建主题。

且一个订阅者可能会订阅多个主题，每个主题的消息可能都会有不同的处理方式，因此需要有订阅者主题回调的管理。

2.7 Registry-Discovery

服务注册和发现模块需要实现的功能会稍微复杂一些，因为分为两个角色来完成其功能：

注册者：作为Rpc服务的提供者，需要向注册中心注册服务，因此需要实现向服务器注册服务的功能
发现者：作为Rpc服务的调用者，需要先进行服务发现，也就是向服务器发送请求获取能够提供指定服务的主机地址，获取地址后需要管理起来留用，且作为发现者，需要关注注册中心发送过来的服务上线/下线消息，以及时对已经下线的服务和主机进行管理。