目录
3. 客户端模块划分
3.1 Network模块
3.2 Protocol模块
3.3 Dispatcher模块
3.4 Requestor模块
3.5 RpcCaller模块
3.6 Publish-Subscribe模块
3.7 Registry-Discovery模块
3.8 Client模块
4. 框架设计
4.1 抽象层
4.2 具象层
4.3 业务层
⭕4.4 整体设计框架
5. common 类的实现
5.1 常用的零碎功能接口类实现
5.1.1 简单日志宏实现
5.1.2 Json序列化/反序列化的封装
5.1.3 UUID的生成
5.2 fields 消息类型定义
5.2.1 请求字段宏的定义:
5.2.2 消息类型定义:
5.2.3 响应码类型定义:
5.2.4 RPC请求类型定义:
5.2.5 主题操作类型定义:
5.2.6 服务操作类型定义:
⭕
前文:[实现Rpc] 项目设计 | 服务端模块划分 | rpc | topic | server
3. 客户端模块划分
在客户端的模块划分中,基于以上理解的功能,可以划分出这么级个模块:
- Protocol:应用层通信协议模块。
- Network:网络通信模块。
- Dispatcher:消息分发处理模块。
- Requestor:请求管理模块。
- RpcCaller:远端调用功能模块。
- Publish-Subscribe:发布订阅功能模块。
- Registry-Discovery:服务注册/发现/上线/下线功能模块。
- Client:基于以上模块整合⽽出的客户端模块。
3.1 Network模块
网络通信基于muduo库实现网络通信客户端。
3.2 Protocol模块
应用层通信协议处理,与服务端保持⼀致。
3.3 Dispatcher模块
IO数据分发处理,逻辑与服务端⼀致。
3.4 Requestor模块
Requestor模块存在的意义:针对客⼾端的每⼀条请求进⾏管理,以便于对请求对应的响应做出合适的操作。
- 首先,对于客户端来说,不同的地方在于更多时候客户端是请求方,是主动发起请求服务的⼀方
- 而在多线程的网络通信中,多线程下,针对 多个请求进行响应可能会存在时序的问题,这种情况下,我们则无法保证⼀个线程发送⼀个请求后,接下来接收到的响应就是针对自己这条请求的响应,这种情况是非常危险的⼀种情况。
- 其次,类似于Muduo库这种异步IO网络通信库,通常 IO操作都是异步操作,即发送数据就是把数据放入发送缓冲区,但是什么时候会发送由底层的网络库来进行协调,并且也并不会提供recv接口,而是在连接触发可读事件后,IO读取数据完成后调用处理回调进行数据处理,因此也无法直接在发送请求后去等待该条请求的响应。(对 于网络通信前文有提到~[Linux#61][UDP] port | netstat | udp缓冲区 | stm32)
针对以上问题,我们则创建出当前的请求管理模块来解决:
- 它的思想也非常简单,就是给每⼀个请求都设定⼀个请求ID,服务端进行响应的时候标识响应针对的是哪个请求(也就是 响应信息中会包含请求ID)
- 因此客户端这边我们不管收到哪条请求的响应,将数据存储入⼀则hash_map中,以请求ID作为映射,并向外提供获取指定 请求ID响应的阻塞接口,这样只要在发送请求的时候知道自己的请求ID,那么就能获取到自己想要的响应,而不会出现异常。
针对这个思想,我们再进⼀步,可以将每个请求进⼀步封装描述,添加⼊异步的future控制,或者设置回调函数的方式,在不仅可以阻塞获取响应,也可以实现 异步获取响应以及回调处理响应。
3.5 RpcCaller模块
(1)RpcCaller模块存在的意义:向用户提供进行rpc调⽤的模块。
Rpc服务调用模块,这个模块相对简单,只需要向外提供几个rpc调用的接口,内部实现向服务端发送请求,等待获取结果即可,稍微麻烦⼀些的是Rpc调用我们需要提供多种不同方式的调用:
- 同步调用:发起调用后,等收到响应结果后返回。
- 异步调用:发起调用后立即返回,在想获取结果的时候进行获取。
- 回调调用:发起调用的同时设置结果的处理回调,收到响应后⾃动对结果进行回调处理。
3.6 Publish-Subscribe模块
(1)Publish-Subscribe模块存在意义:向用户提供发布订阅所需的接口,针对推送过来的消息进行处理。
- 发布订阅稍微复杂⼀点,因为在发布订阅中有两种角色,⼀个客户端可能是消息的发布者,也可能是消息的订阅者。
- 而且不管是哪个角色都是 对主题进行操作,因此其中也包含了主题的相关操作,比如要发布⼀条消息需要先创建主题。
- 且⼀个订阅者可能会订阅多个主题,每个主题的消息可能都会有不同的处理方式,因此需要有订阅者主题回调的管理。
3.7 Registry-Discovery模块
(1)服务注册和发现模块需要实现的功能会复杂⼀些,因为分为两个角色来完成其功能:
- 注册者:作为Rpc服务的提供者,需要向注册中心注册服务,因此需要实现向服务器注册服务的功能。
- 发现者:作为Rpc服务的调用者,需要先进行服务发现,也就是向服务器发送请求获取能够提供指定服务的主机地址,获取地址后需要管理起来留用,且作为发现者,需要关注注册中心发送过来的服务上线/下线消息,以及时对已经下线的服务和主机进行管理。
3.8 Client模块
将以上模块进行整合就可以实现各个功能的客户端了。
- RegistryClient:服务注册功能模块与⽹络通信客户端结合。
- DiscoveryClient:服务发现功能模块与⽹络通信客户端结合。
- RpcClient:DiscoveryClient & RPC功能模块与网络通信客户端结合。
- TopicClient:发布订阅功能模块与⽹络通信客户端结合。
4. 框架设计
在当前项目的实现中,我们将整个项目的实现划分为三层来进行实现:
- 抽象层:将底层的网络通信以及应用层通信协议以及请求响应进行抽象,使项目更具扩展性和灵活性。
- 具象层:针对抽象的功能进行具体的实现。
- 业务层:基于抽象的框架在上层实现项目所需功能。
4.1 抽象层
在本项目的实现当中,网络通信部分采用了第三方库Muduo库,以及通信协议使用了LV格式的通信协议解决粘包问题,数据正文中采用了Json格式进行序列化和反序列化,而这几方面我们都可能会存在继续优化的可能,甚至在序列化⽅方面不⼀定非要采用Json
因此在设计项目框架的时候,我们对于底层通信部分相关功能先进行抽象,形成⼀层抽象层
而上层业务部分根据抽象层来完成功能,这样的好处是在具体的底层功能实现部分,我们可以实现插拔式的模块化替换,以此来提高项目的灵活性和扩展性。
4.2 具象层
具象层就是针对抽象的具体实现。
而具体的实现也比较简单,从抽象类派生出具体功能的派生类,然后在内部实现各个接口功能即可。
- 基于Muduo库实现网络通信部分抽象。
- 基于LV通信协议实现Protocol部分抽象。
不过这⼀层中比较特殊的是,我们需要 针对不同的请求,从BaseMessage中派生出不同的请求和响应类型,以便于在针对指定消息处理时,能够更加轻松的获取或设置请求及响应中的各项数据元素。
4.3 业务层
业务层就是基于底层的通信框架,针对项目中具体的业务功能的实现了,比如Rpc请求的处理,发布订阅请求的处理以及服务注册与发现的处理等等。
(1)Rpc:
(2)发布订阅:
(3)服务注册&发现:
⭕4.4 整体设计框架
项目当中会有server和client共同使用的类,也有单独使用的类,所以我们分别实现对应的功能
5. common 类的实现
5.1 常用的零碎功能接口类实现
5.1.1 简单日志宏实现
日志宏意义:快速定位程序运行逻辑出错的位置。
参考前文:简单日志宏实现(C++)
项目在运行中可能会出现各种问题,出问题不可怕,关键的是要能找到问题,并解决问题。解决问题的方式:
- gdb调试:逐步调试过于繁琐,缓慢。主要⽤于程序崩溃后的定位。
- 系统运行日志分析:在任何程序运行有可能逻辑错误的位置进行输出提示,快速定位逻辑问题的位置。
#pragma once
#include <cstdio>
#include <ctime>#define LDBG 0
#define LINF 1
#define LERR 2#define LDEFAULT LDBG#define LOG(level, format, ...) \{ \if (level >= LDEFAULT) \{ \time_t t = time(NULL); \struct tm *lt = localtime(&t); \char time_tmp[32] = {0}; \strftime(time_tmp, 31, "%m-%d %T", lt); \fprintf(stdout, "[%s][%s:%d] " format "\n", time_tmp, __FILE__, __LINE__, ##__VA_ARGS__); \} \}#define DLOG(format, ...) LOG(LDBG, format, ##__VA_ARGS__);
#define ILOG(format, ...) LOG(LINF, format, ##__VA_ARGS__);
#define ELOG(format, ...) LOG(LERR, format, ##__VA_ARGS__);
5.1.2 Json序列化/反序列化的封装
#include <iostream>
#include <sstream>
#include <string>
#include <memory>
#include <jsoncpp/json/json.h>class JSON
{
public:static bool serialize(const Json::Value &val, std::string &body){std::stringstream ss;// 先实例化一个工厂类对象Json::StreamWriterBuilder swb;// 通过工厂类对象来生产派生类对象std::unique_ptr<Json::StreamWriter> w(swb.newStreamWriter());bool ret = w->write(val, &ss);if (ret != 0){ELOG("json serialize failed!");return false;}body = ss.str();return true;}static bool deserialize(const std::string &body, Json::Value &val){Json::CharReaderBuilder crb;std::unique_ptr<Json::CharReader> r(crb.newCharReader());std::string errs;bool ret = r->parse(body.c_str(), body.c_str() + body.size(), &val, &errs);if (ret == false){ELOG("json deserialize failed : %s", errs.c_str());return false;}return true;}
};
5.1.3 UUID的生成
UUID(Universally Unique Identifier),也叫通用唯⼀识别码,通常由32位16进制数字字符组成。
- UUID的标准型式包含32个16进制数字字符,以连字号分为五段,形式为8-4-4-4-12的32个字符
- 如:550e8400-e29b-41d4-a716-446655440000。
- 在这里,uuid生成,我们采用生成8个随机数字,加上8字节序号,共16字节数组生成32位16进制字符的组合形式来 确保全局唯⼀的同时能够根据序号来分辨数据(随机数肉眼分辨起来真是太难了…)。
#include <iostream>
#include <chrono>
#include <random>
#include <string>
#include <sstream>
#include <atomic>
#include <iomanip>class UUID
{
public:static std::string uuid(){std::stringstream ss;//1. 构造一个机器随机数对象std::random_device rd;//2. 以机器随机数为种子构造伪随机数对象std::mt19937 generator (rd());//3. 构造限定数据范围的对象std::uniform_int_distribution<int> distribution(0, 255);// 4. 生成8个随机数,按照特定格式组织成为16进制数字字符的字符串for (int i = 0; i < 8; i++){if (i == 4 || i == 6){ss << "-";}ss << std::setw(2) << std::setfill('0') << std::hex << distribution(generator);}ss << "-";//5. 定义一个8字节序号,逐字节组织成为16进制数字字符的字符串static std::atomic<size_t> seq(1);size_t cur = seq.fetch_add(1);for (int i = 7; i >= 0; i--){if (i == 5){ss << "-";}ss << std::setw(2) << std::setfill('0') << std::hex << ((cur >> (i * 8)) & 0xFF);}return ss.str();}
};
定义一个生成 UUID(通用唯一标识符) 的工具类 UUID
,其核心功能是通过结合随机数和计数器生成一个类似于标准 UUID 格式的字符串。
- 使用硬件随机数生成器和梅森旋转算法生成随机数。
- 将生成的随机数按十六进制格式组织,并在特定位置插入
"-"
。 - 使用静态原子计数器确保 UUID 的唯一性,并将计数器值按字节格式化为十六进制。
- 最终,返回一个形如
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
的字符串,表示一个生成的 UUID。
这种方式生成的 UUID 包含了随机性和递增序列,确保了其在大多数情况下的唯一性。
5.2 fields 消息类型定义
5.2.1 请求字段宏的定义:
定义如下:
#define KEY_METHOD "method"
#define KEY_PARAMS "parameters"
#define KEY_TOPIC_KEY "topic_key"
#define KEY_TOPIC_MSG "topic_msg"
#define KEY_OPTYPE "optype"
#define KEY_HOST "host"
#define KEY_HOST_IP "ip"
#define KEY_HOST_PORT "port"
#define KEY_RCODE "rcode"
#define KEY_RESULT "result"
提高代码的可读性:通过给常量字符串定义宏名称,可以使代码更加易读和易于理解。例如,
KEY_METHOD
比直接使用"method"
更直观地表达了该字符串在代码中的作用。
5.2.2 消息类型定义:
(1)主要功能:
- Rpc请求 & 响应。
- 主题操作请求 & 响应。
- 消息发布请求 & 响应。
- 服务操作请求 & 响应。
(2)具体定义如下:
enum class MType
{
/*
Request
Response
*/REQ_RPC = 0,
RSP_RPC,
REQ_TOPIC,
RSP_TOPIC,
REQ_SERVICE,
RSP_SERVICE
};
5.2.3 响应码类型定义:
(1)主要功能:
- 成功处理。
- 解析失败。
- 消息中字段缺失或错误导致无效消息。
- 连接断开。
- 无效的Rpc调用参数。
- Rpc服务不存在。
- 无效的Topic操作类型。
- 主题不存在。
- 无效的服务操作类型。
(2)具体定义如下:
enum class RCode
{RCODE_OK = 0,RCODE_PARSE_FAILED,RCODE_ERROR_MSGTYPE,RCODE_INVALID_MSG,RCODE_DISCONNECTED,RCODE_INVALID_PARAMS,RCODE_NOT_FOUND_SERVICE,RCODE_INVALID_OPTYPE,RCODE_NOT_FOUND_TOPIC,RCODE_INTERNAL_ERROR
};static std::string errReason(RCode code)
{std::unordered_map<RCode, std::string> err_map = {{RCode::RCODE_OK, "成功处理!"},{RCode::RCODE_PARSE_FAILED, "消息解析失败!"},{RCode::RCODE_ERROR_MSGTYPE, "消息类型错误!"},{RCode::RCODE_INVALID_MSG, "无效消息"},{RCode::RCODE_DISCONNECTED, "连接已断开!"},{RCode::RCODE_INVALID_PARAMS, "无效的Rpc参数!"},{RCode::RCODE_NOT_FOUND_SERVICE, "没有找到对应的服务!"},{RCode::RCODE_INVALID_OPTYPE, "无效的操作类型"},{RCode::RCODE_NOT_FOUND_TOPIC, "没有找到对应的主题!"},{RCode::RCODE_INTERNAL_ERROR, "内部错误!"}};auto iter = err_map.find(code);if (iter == err_map.end()){return "未知错误";}return iter->second;
}
5.2.4 RPC请求类型定义:
(1)主要功能:
- 同步请求:等待收到响应后返回。
- 异步请求:返回异步对象,在需要的时候通过异步对象获取响应结果(还未收到结果会阻塞)。
- 回调请求:设置回调函数,通过回调函数对响应进行处理。
(2)具体定义如下:
enum class RType
{REQ_ASYNC = 0,REQ_CALLBACK
};
5.2.5 主题操作类型定义:
(1)主要功能:
- 主题创建。
- 主题删除。
- 主题订阅。
- 主题取消订阅。
- 主题消息发布。
(2)具体定义如下:
enum class TopicOptype
{TOPIC_CREATE = 0,TOPIC_REMOVE,TOPIC_SUBSCRIBE,TOPIC_CANCEL,TOPIC_PUBLISH
};
5.2.6 服务操作类型定义:
(1)主要功能:
- 服务注册。
- 服务发现。
- 服务上线。
- 服务下线。
(2)具体定义如下:
enum class ServiceOptype
{SERVICE_REGISTRY = 0,SERVICE_DISCOVERY,SERVICE_ONLINE,SERVICE_OFFLINE,SERVICE_UNKNOW
};