【#3】项目设计-EW帮帮网

一、理解项目功能

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

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

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

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

而其次的发布订阅功能，则是依托于多个客户端围绕服务端进行消息的转发。

不过单纯的消息转发功能，并不能满足于大部分场景的需要，因此会在其基础上实现基于主题订阅的转发。

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

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

项目的三个主要功能:

rpc调用
服务的注册与发现以及服务的下线/上线通知
消息的发布订阅

二、服务端模块划分

服务端的功能需求:

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

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

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

1. Network

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

2. Protocol

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

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

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

① 特殊字符间隔

原理

在每条消息之间插入一个特殊的分隔符（例如换行符 \n 或其他不可见字符），用于标记消息的结束。
接收方通过解析分隔符来区分不同的消息。

优点

实现简单，适合文本协议（如 HTTP、SMTP 等）。
不需要额外的长度字段或复杂逻辑。

缺点

分隔符不能出现在消息内容中，否则会导致解析错误（需要转义机制）。
对二进制数据不友好，因为二进制数据可能包含与分隔符相同的字节。

② 定长数据

原理

每条消息固定为特定长度（例如 100 字节）。如果消息不足指定长度，则用填充字符（如空格或零字节）补齐。
接收方每次读取固定长度的数据即可。

优点

实现简单，接收方无需复杂的解析逻辑。
适合固定大小的消息场景。

缺点

浪费带宽：短消息需要填充字符。
消息长度受限于固定值，灵活性较差。
需要事先约定消息的最大长度。

③ LV（Length-Value）格式

原理

在每条消息前附加一个固定长度的字段（通常是 2 字节或 4 字节），表示消息体的长度。
接收方先读取长度字段，然后根据长度读取消息体。

优点

高效：没有多余的填充字符，节省带宽。
灵活：支持任意长度的消息。
适合二进制协议和复杂场景。

缺点

实现稍复杂：需要分别处理长度字段和消息体。
长度字段本身需要固定长度，可能会限制消息的最大长度。

三者区别

特殊字符间隔 ：适合简单的文本协议，但不适合二进制数据。
定长数据 ：实现简单，但浪费带宽且灵活性差。
LV 格式 ：高效且灵活，是解决粘包问题的最佳实践，尤其适合复杂场景。

在实际开发中，LV 格式 是最常用的方式，因为它既能高效传输数据，又能灵活适应不同长度的消息。

比如：当前的这个项目中将使用 LV格式 来定义应用层的通信协议格式

Length：该字段固定4字节长度，用于表示后续的本条消息数据长度。
MType：该字段为Value中的固定字段，固定4字节长度，用于表示该条消息的类型。
Rpc：调用请求/响应类型消息。
- 发布/订阅/取消订阅/消息推送类型消息0
- 主题创建/删除类型消息。
- 服务注册/发现/上线/下线类型消息。
IDLength：为消息中的固定字段，该字段固定4字节长度，用于描述后续ID字段的实际长度。
MID：在每条消息中都会有一个固定字段为ID字段，用于唯一标识消息，ID字段长度不固定。
Body：消息主题正文数据字段，为请求或响应的实际内容字段。

3. Dispatcher

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

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

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

消息类型:

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

4. RpcRoute

🎋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，是一个整形，。
返回值类型：整形。

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

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

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

5. Publish-Subcribe

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

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

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

6. 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}
    ]
}

该模块的设计如下

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

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

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

同时，当一个 rpc-provider 下线时，则可以找到进行了该服务发现的rpc-caller进行服务的下线通知。

7. Server

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

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

三、客户端模块划分

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

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

1. Network

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

2. Protocol

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

3. Dispatcher

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

4. Requestor

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

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

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

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

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

5. RpcCaller

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

Rpc服务调用模块，这个模块相对简单，只需要向外提供几个rpc调用的接口，内部实现向服务端发送请求，等待获取结果即可。

稍微麻烦一些的是Rpc调用我们需要提供多种不同方式的调用：

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

6. Publish-Subscribe

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

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

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

7. Registry-Discovery

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

注册者：作为Rpc服务的提供者，需要向注册中心注册服务，因此需要实现向服务器注册服务的功能
- 连接注册中心，发送服务注册请求，等待响应判断是否注册成功
发现者：作为Rpc服务的调用者，需要先进行服务发现，也就是向服务器发送请求获取能够 提供指定服务的主机地址，获取地址后需要管理起来留用，且作为发现者，需要 关注注册中心发送过来的服务（上线/下线消息），并且及时对 已经下线的服务和主机进行管理。
- 为什么要有上下线功能呢？
- 原因：对于服务发现来说，这个流程是个一锤子买卖，进行服务发现的时候，注册中心只能将当前注册了该服务的主机地址进行返回，但是如果后续又有其他的主机注册了该服务，之前进行过服务发现的主机是得不到这个新注册的主机信息

也就是说：要实现的客户端既能用于 provide 进行服务注册，也能用于 caller 进行服务发现

8. client

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

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

四、框架设计

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

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

1. 抽象层

在当前的项目实现中：

网络通信部分 采用了第三方库 Muduo 库.
通信协议 使用了 LV格式 的通信协议解决粘包问题.
数据正文中 采用了 Json 格式进行序列化和反序列化.

而这几方面我们都可能会存在继续优化的可能，甚至在序列化方面不一定非要采用 Json ，因此在设计项目框架的时候，我们对于底层通信部分相关功能先进行抽象，形成一层 抽象层，而上层业务部分根据 抽象层 来完成功能.

这样的好处是在具体的底层功能实现部分，我们可以实现插拔式的模块化替换，以此来提高项目的灵活性和扩展性

在软件设计中，插拔式的模块化替换 指的是通过 抽象接口 和 依赖注入 ，让不同模块可以灵活替换，而无需修改其他模块的代码。

抽象接口：定义通用接口（如基类或抽象类），模块通过接口交互，而非直接依赖具体实现。

依赖注入：模块的依赖关系通过外部注入（如构造函数或配置方法），而非硬编码。

2. 具象层

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

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

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

3. 业务层

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

Rpc 请求处理

发布订阅请求

服务注册&发现

【#3】项目设计

一、理解项目功能

二、服务端模块划分

1. Network

2. Protocol

3. Dispatcher

4. RpcRoute

5. Publish-Subcribe

6. Registry-Discovery

7. Server

三、客户端模块划分

1. Network

2. Protocol

3. Dispatcher

4. Requestor

5. RpcCaller

6. Publish-Subscribe

7. Registry-Discovery

8. client

四、框架设计

1. 抽象层

2. 具象层

3. 业务层

4. 整体框架设计

网站公告

今日签到

热门文章

最新发布

【#3】项目设计

一、 理解项目功能

二、服务端模块划分

1. Network

2. Protocol

3. Dispatcher

4. RpcRoute

5. Publish-Subcribe

6. Registry-Discovery

7. Server

三、客户端模块划分

1. Network

2. Protocol

3. Dispatcher

4. Requestor

5. RpcCaller

6. Publish-Subscribe

7. Registry-Discovery

8. client

四、框架设计

1. 抽象层

2. 具象层

3. 业务层

4. 整体框架设计

网站公告

今日签到

热门文章

最新发布

一、理解项目功能