Json-Rpc框架（框架设计 —— 整体设计框架 | 抽象层 | 具象层 | 业务层）

引言

在上一篇关于Json-Rpc框架的文章中，我们详细探讨了服务端和客户端的功能。今天，我们将转换视角，概览Json-Rpc框架的整体设计框架。从抽象到具象，再到业务实现，我们将一步步揭开这个框架的层次结构，让您轻松理解其设计思路和运作机制。

一、框架设计

在当前项目的实现中，我们采用了三层架构来组织开发工作，以确保项目的扩展性、灵活性和可维护性。这三层分别是：

1. 抽象层：此层负责将网络通信的底层细节、应用层通信协议以及请求响应机制进行高度抽象。通过这种抽象，我们为项目构建了一个基础框架，使得后续的开发工作能够不直接依赖于具体的网络库或协议细节，从而大大增强了项目的扩展性和灵活性。

2. 具象层：在抽象层定义的基础上，具象层负责实现具体的功能。它将抽象层中的接口、协议等转化为可执行的代码和数据结构，为上层业务逻辑提供坚实的技术支撑。这一层的存在，使得我们可以根据不同的需求和场景，灵活地调整和优化实现细节，而不必担心影响到整个项目的架构。

3. 业务层：作为最上层，业务层基于抽象层提供的框架和具象层实现的具体功能，来构建和实现项目所需的各种业务逻辑。这一层直接面向用户需求和业务需求，通过调用抽象层和具象层提供的接口和服务，实现项目的核心价值和功能。

二、抽象层

在我们的项目实现中，网络通信部分选用了Muduo这一高性能的第三方库，并采用了LV格式的通信协议来有效解决网络传输中的粘包问题。同时，为了数据的灵活性和可读性，我们选择了Json格式作为数据正文的序列化和反序列化标准。然而，我们意识到这些选择在未来可能需要根据项目需求或技术发展趋势进行优化调整，特别是在序列化方面，不一定局限于Json格式。

因此，在项目框架设计阶段，我们特别注重了对底层通信相关功能的抽象化处理，构建了一层独立的抽象层。这一层抽象层不仅封装了网络通信的底层细节，还定义了与上层业务交互的接口规范。通过这样的设计，上层业务部分可以基于抽象层提供的接口来开发功能，而无需直接关心底层通信的具体实现。

这种设计带来的显著好处是，当底层通信部分需要进行优化、升级或替换时（比如更换网络通信库、调整通信协议或改变序列化格式），我们可以实现插拔式的模块化替换，而无需对上层业务代码进行大规模修改。这种高度的灵活性和扩展性，使得我们的项目能够更好地适应未来可能的变化和挑战。

三、具象层

具象层是抽象层概念的具体实现层，它负责将抽象层中定义的接口和协议转化为可执行的代码。具体实现过程相对直接，主要是通过从抽象类继承并派生出具体功能的子类，然后在这些子类中实现抽象层定义的各个接口功能。

在我们的项目中，具象层的实现特别针对了以下几个方面：

• 网络通信部分：基于Muduo库，我们实现了网络通信的抽象接口，将Muduo库的网络功能封装在具象层中，以便上层业务逻辑能够方便地通过抽象接口进行网络通信操作。
• Protocol协议处理：针对LV通信协议，我们在具象层中实现了协议解析和封装的逻辑，确保数据在网络传输中能够正确解决粘包问题，并按照协议规范进行序列化和反序列化。
• 消息类型派生：为了处理多样化的请求和响应，我们从一个基础的消息类（如BaseMessage）派生出多个具体的请求和响应类型。这种设计使得在处理特定消息时，可以轻松地获取或设置消息中的各项数据元素，提高了代码的可读性和可维护性。

通过这样的具象层设计，我们既保证了底层通信的灵活性和可扩展性，又为上层业务逻辑提供了清晰、易用的接口，使得整个项目结构更加清晰。

四、业务层

业务层是构建在底层通信框架之上的，它专注于实现项目中具体的业务功能。在这一层，开发者会根据项目的实际需求，利用底层框架提供的通信能力和接口，来实现诸如RPC请求处理、发布订阅机制、服务注册与发现等关键业务逻辑。业务层的设计和实现直接决定了项目的功能丰富度和用户体验，是项目成功的关键所在。

Rpc

发布订阅

服务注册&发现

五、整体设计框架

六、项目代码

💻代码传送门：⭕代码链接