【C++】从零实现Json-Rpc框架（3）

目录

项目设计

一、理解项目功能需求

 二、框架设计

2.1 - 服务端模块划分

Protocol

Dispatcher

 RpcRouter

Publish-Subscribe

 Registry-Discovery

Server

 2.2 - 客户端模块划分

Network

Protocol

Dispatcher

Requestor

RpcCaller

Publish-Subscribe

Registry-Discovery

Client

​编辑

2.3 框架设计 

抽象层

 具象层

业务层

整体设计框架

项目汇总：uyeonashi的博客-优快云博客

项目源码：https://gitee.com/uyeonashi/project

项目设计

一、理解项目功能需求

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

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

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

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

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

基于以上功能的合并，我们可以得到一个实现所有功能的结构图

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

项目的三个主要功能：
• rpc调用
• 服务的注册与发现以及服务的下线/上线通知
• 消息的发布订阅

 二、框架设计

2.1 - 服务端模块划分

服务端的功能需求：

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

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

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

---

该模块为网络通信模块，实现底层的网络通信功能，这个模块本质上也是一个比较复杂庞大的模块，因此鉴于项目的庞大，该模块我们将使用陈硕大佬的Muduo库来进行搭建。

Protocol

应用层通信协议模块的存在意义：解析数据，解决通信中有可能存在的粘包问题，能够获取到一条完整的消息。
在前边的muduo库基本使用中，我们能够知道想要让一个服务端/客户端对消息处理，就要设置一个onMessage的回调函数，在这个函数中对收到的数据进行应用层协议处理。
而Protocol模块就是是网络通信协议模块的设计，也就是在网络通信中，我们必须设计一个应用层的网络通信协议出来，以解决网络通信中可能存在的粘包问题，而解决粘包有三种方式：特殊字符间隔，定长，LV格式。

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

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

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

IDLength：为消息中的固定字段，该字段固定4字节长度，用于描述后续ID字段的实际长度。
MID：在每条消息中都会有一个固定字段为ID字段，用于唯一标识消息，ID字段长度不固定。
Body：消息主题正文数据字段，为请求或响应的实际内容字段。

Dispatcher

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

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

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

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

 RpcRouter

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

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

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

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

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

序列化方式有很多种，鉴于当前我们是json-rpc，因此这个序列化过程我们就初步使用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，是一个整形，
• 返回值类型：整形

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

基于以上理解，在实现该模块时，该有以下设计：
1. 该模块必须具备一个Rpc路由管理，其中包含对于每个服务的参数校验功能
2. 该模块必须具备一个方法名称和方法业务回调的映射
3. 该模块必须向外提供 Rpc请求的业务处理函数。

Publish-Subscribe

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

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

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

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

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

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

//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,
}

{
    "rcode" : ERROR_INVALID_PARAMETERS,
}

功能思想并不复杂，因此我们需要把更多的精力放到其实现设计上：

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

 Registry-Discovery

Registry-Discovery模块存在的意义：就是针对服务注册与发现请求的处理。
    服务注册/发现类型请求中的详细划分
        服务注册：服务provider告诉中转中心，自己能提供哪些服务
        服务发现：服务caller询问中转中心，谁能提供指定服务
        服务上线：在一个provider上线了指定服务后，通知发现过该服务的客户端有个provider可以提供该服务
        服务下线：在一个provider断开连接，通知发现过该服务的caller，谁下线了哪个服务

 服务注册模块，该模块主要是为了实现分布式架构而存在，让每一个rpc客户端能够从不同的节点主机上获取自己所需的服务，让业务更具扩展性，系统更具健壮性。
而为了能够让rpc-caller知道有哪些rpc-provider能提供自己所需服务，那么就需要有一个注册中心让这些rpc-provider去注册登记自己的服务，让rpc-caller来发现这些服务。
因此，在我们的服务端功能中，还需实现服务的注册/发现，以及服务的上线/下线功能。

//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" : {
    "ip" : "127.0.0.1",
    "port" : 9090
    }
}

//Registry/Online/Offline-response
{
    "rcode" : OK,
}
//error-response
{
    "rcode" : ERROR_INVALID_PARAMETERS,
}
//Discovery-response
{
    "method" : "Add",
    "host" : [
        {"ip" : "127.0.0.1","port" : 9090},
        {"ip" : "127.0.0.2","port" : 8080}
    ]
}

 该模块的设计如下：
1. 必须具备一个服务发现者的管理：
        a. 方法与发现者：当一个客户端进行服务发现的时候，进行记录谁发现过该服务，当有一个新的提供者上线的时候，可以通知该发现者
        b. 连接与发现者 ：当一个发现者断开连接了，删除关联关系，往后就不需要通知了
2. 必须具备一个服务提供者的管理：
        a. 连接与提供者：当一个提供者断开连接的时候，能够通知该提供者提供的服务对应的发现者，该主机的该服务下线了
        b. 方法与提供者：能够知道谁的哪些方法下线了，然后通知发现过该方法的客户端
3. 必须向Dispatcher模块提供一个服务注册/发现的业务处理回调函数

这样，当一个rpc-provider登记了服务，则将其管理起来，当rpc-caller进行服务发现时，则将保存的对应服务所对应的主机信息，响应给rpc-caller。

当中途一个rpc-provider上线登记服务时，则可以给进行了对应服务发现的rpc-caller进行服务上线通知，通知rpc-caller当前多了一个对应服务的rpc-provider。
同时，当一个rpc-provider下线时，则可以找到进行了该服务发现的rpc-caller进行服务的下线通知。

Server

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

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

---

 2.2 - 客户端模块划分

在客户端的模块划分中，基于以上理解的功能，可以划分出这么几个模块
1. Protocol：应用层通信协议模块
2. Network：网络通信模块
3. Dispatcher：消息分发处理模块
4. Requestor：请求管理模块
5. RpcCaller：远端调用功能模块
6. Publish-Subscribe：发布订阅功能模块
7. Registry-Discovery：服务注册/发现/上线/下线功能模块
8. Client：基于以上模块整合而出的客户端模块

Network

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

Protocol

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

Dispatcher

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

Requestor

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

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

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

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

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

 

RpcCaller

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

Rpc服务调用模块，这个模块相对简单，只需要向外提供几个rpc调用的接口，内部实现向服务端发送请求，等待获取结果即可，稍微麻烦一些的是Rpc调用我们需要提供多种不同方式的调用：
1. 同步调用：发起调用后，等收到响应结果后返回
2. 异步调用：发起调用后立即返回，在想获取结果的时候进行获取
3. 回调调用：发起调用的同时设置结果的处理回调，收到响应后自动对结果进行回调处理

Publish-Subscribe

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

发布订阅稍微能复杂一丢丢，因为在发布订阅中有两种角色，一个客户端可能是消息的发布者，也可能是消息的订阅者。
而且不管是哪个角色都是对主题进行操作，因此其中也包含了主题的相关操作，比如，要发布一条消息需要先创建主题。
且一个订阅者可能会订阅多个主题，每个主题的消息可能都会有不同的处理方式，因此需要有订阅者主题回调的管理。

Registry-Discovery

服务注册和发现模块分为两个角色来完成其功能

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

Client

将以上模块进行整合就可以实现各个功能的客户端了。

• RegistryClient：服务注册功能模块与网络通信客户端结合
• DiscoveryClient：服务发现功能模块与网络通信客户端结合
• RpcClient：DiscoveryClient & RPC功能模块与网络通信客户端结合
• TopicClient：发布订阅功能模块与网络通信客户端结合

服务注册客户端的封装，对外只需要提供服务注册的功能接口即可

---

2.3 框架设计 

在当前项目的实现中，我们将整个项目的实现划分为三层来进行实现

1. 抽象层：将底层的网络通信以及应用层通信协议以及请求响应进行抽象，使项目更具扩展性和灵活性。
2. 具象层：针对抽象的功能进行具体的实现。
3. 业务层：基于抽象的框架在上层实现项目所需功能。

抽象层

在咱们的项目实现中，网络通信部分采用了第三方库Muduo库，以及通信协议使用了LV格式的通信协议解决粘包问题，数据正文中采用了Json格式进行序列化和反序列化，而这几方面我们都可能会存在继续优化的可能，甚至在序列化方面不一定非要采用Json，因此在设计项目框架的时候，我们对于底层通信部分相关功能先进行抽象，形成一层抽象层，而上层业务部分根据抽象层来完成功能，这样的好处是在具体的底层功能实现部分，我们可以实现插拔式的模块化替换，以此来提高项目的灵活性和扩展性。

---

 具象层

 具象层就是针对抽象的具体实现。
而具体的实现也比较简单，从抽象类派生出具体功能的派生类，然后在内部实现各个接口功能即可。

• 基于Muduo库实现网络通信部分抽象
• 基于LV通信协议实现Protocol部分抽象

不过这一层中比较特殊的是，我们需要针对不同的请求，从BaseMessage中派生出不同的请求和响应类型，以便于在针对指定消息处理时，能够更加轻松的获取或设置请求及响应中的各项数据元素。

---

业务层

业务层就是基于底层的通信框架，针对项目中具体的业务功能的实现了，比如Rpc请求的处理，发布订阅请求的处理以及服务注册与发现的处理等等。

Rpc

发布订阅

 服务注册&发现

整体设计框架

---

本篇完，下篇继续！