【C++从零实现Json-Rpc框架】第七弹——客户端模块划分

_麦麦_

已于 2025-05-27 21:04:44 修改

阅读量1.9k

点赞数 162

文章标签： rpc 网络协议网络 json

于 2025-05-27 21:02:51 首次发布

本文链接：https://blog.csdn.net/m0_73953114/article/details/148264079

版权

8. Registry-Discovery模块

9. Client

三、结语

一、前言

在第六弹中我们对服务端的模块划分进行了讲解，接下来我们就客户端的角度，来设计对应模块，帮助客户端实现项目的三个功能：

● rpc调用

● 服务的注册与发现以及服务的下线/上线通知

● 消息的发布订阅

二、正文

1. 客户端模块划分

在客户端的模块划分中，与服务端功能相对，可以划分出下面几个模块

1. Protocol：应⽤层通信协议模块

2. Network：⽹络通信模块

3. Dispatcher：消息分发处理模块

4. Requestor：请求管理模块

5. RpcCaller：远端调⽤功能模块

6. Publish-Subscribe：发布订阅功能模块

7. Registry-Discovery：服务注册/发现/上线/下线功能模块

8. Client：基于以上模块整合⽽出的客⼾端模块

2. Network模块

在客户端的Network模块，我们的网络通信与服务端一样，是基于Muduo库来实现网络通信客户端

3. Protocol模块

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

4. Dispatcher模块

IO数据分发处理，逻辑与服务端一致，由使用者来决定哪条消息用哪个业务函数来进行处理，当收到消息后，在该模块找到对应的处理回调函数进行调用即可

5. Requestor模块

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

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

其次，既然这样的话可能有的小伙伴就想既然这样子，那我们的客户端在发送一个请求后，等待不就好了。如果这样的话，一方面是效率比较低，另一方便是由于我们在网络通信模块时采用的Muduo库这种异步IO网络通信库，通常IO操作都是异步操作，即发送数据就是把数据放入发送缓冲区，但是什么时候回发送由底层的网络库来进行协调，并且也并不会提供recv接口，而是在连接触发可读事件后，IO读取数据完成后调用处理回调进行数据处理，因此也无法直接在发送请求后去等待该条请求的响应

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

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

6. RpcCaller模块

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

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

● 同步调用：发起调用后，等收到响应结果后返回

● 异步调用：发起调用后立即返回，在想回去结果的时候进行获取

● 回调调用：发起调用的同时设置结果的处理回调，收到响应后自动对结果进行回调处理

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

发布订阅相比于Rpc调用模块，会稍微复杂一些，因为在发布订阅中会有两种角色，一个客户端可能是消息的发布者，也可能是消息的订阅者。

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

8. Registry-Discovery模块

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

1. 注册者：作为Rpc服务的提供者，需要向注册中心注册服务，因此需要实现向服务器注册服务的功能

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

服务注册

服务发现

9. Client

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

● RegistryClient：服务注册功能模块与网络通信客户端结合

● DiscoverClient：服务发现功能模块与网络通信客户端结合

● RpcClient：DiscoverClient & Rpc功能模块与网路通信客户端结合

● TopicClient：发布订阅功能模块与网络通信客户端结合

RegistryClient

DiscoverClient

RpcClient

TopicClient

三、结语

        到此为止，本文关于从零实现Json-RPC框架第七弹的内容到此结束了，如有不足之处，欢迎小伙伴们指出呀！

         关注我 _麦麦_分享更多干货：_麦麦_-CSDN博客

         大家的「关注❤️ + 点赞👍 + 收藏⭐」就是我创作的最大动力！谢谢大家的支持，我们下期见！！