【C++从零实现Json-Rpc框架】第五弹——理解项目功能_c++ 如何实现rpc调用转化为异步

一、前言

        从本弹开始，就将正式开始从零实现Json-Rpc框架之旅了。在编写代码之前，我们先需要理解项目的功能，才能根据设计出对应的框架，进而根据框架写出代码。

二、正文

在项目框架搭建之前，我们首先要做的是理解项目功能，只有明确了我们这个项目是做什么的，才能进行下一步的框架设计，项目的三个主要功能：

● rpc调用

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

● 消息的发布订阅

1. RPC远程调用

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

举个例子，客户端想要实现一个两数相加的Add，那么它只需要向服务器提供num1和num2两个参数，并告诉服务器用Add方法，服务器在收到来到客户端的请求后，计算出结果后再通过网络返回给客户端。在整个过程，客户端并没有由自己来实现num1和num2的相加，而是由服务器来实现的，这其实就是一次Rpc远端调用 

2. 注册中心

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

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

        为了实现这样的分布式架构，我们可以在原来的模型基础上，增加一个注册中心，基于注册中心，就可以有不同的服务提供服务器，向服务器进行服务注册，相当于告诉注册中心自己能够提供什么服务。而客户端在进行远端调用前，先通过注册中心进行服务发现，找到能够提供服务服务的服务器，然后发起调用。

        不过采取这样的分布式架构，虽然提供服务的服务器由原来的一个变成多个，但是也可能会有人担心我们的注册中心只有一个，万一注册中心挂掉了，客户端不就不能进行Rpc远程调用服务了。首先，我们要明确的是，注册中心的压力是小于提供服务的服务器的，因为它无需参与功能的具体实现，其次，我们还可以采取将服务器作为备用注册中心的方式，这样，即使注册中心挂掉以后，备用的注册中心也能够保证功能的正常使用

3. 消息的发布订阅

在讲完Rpc远程调用和服务注册后，紧接着这就是消息的发布订阅功能，它是依托多个客户端围绕服务端进行消息的转发。但是单纯的消息转发功能，并不能满足大部分场景的需要，消息转发通常只是将信息从一个平台或用户传递到另一个平台或用户，缺乏对消息内容的处理和分析能力。例如，在客户服务场景中，如果仅仅是将客户的问题从一个渠道转发到另一个渠道，而没有对问题进行分类、优先级排序或自动生成初步的解决方案，那么服务效率将大打折扣。因此我们在基础上实现了基于主题订阅的转发，即根据主题来进性消息的转发。

有了上面的分别的功能图，我们将其合并后，就可以得到一个实现所有功能的结构图

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

三、结语

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

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

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