MediatRPC - 基于MediatR和Quic通讯实现的RPC框架，比GRPC更简洁更低耦合，开源发布第一版

时间：2022-11-17 17:08:39

大家好，我是失业在家，正在找工作的博主Jerry。作为一个.Net架构师，就要研究编程艺术，例如SOLID原则和各种设计模式。根据这些原则和实践，实现了一个更简洁更低耦合的RPC（Remote Procedure Calls）框架，名叫MediatRPC。

一、MediatR 编程思想

SOLID的总原则是开闭原则(Open Closed Principle)： 一个软件实体,如类、模块和函数应该对扩展开放,对修改关闭。其它原则和设计模式都是为了实现和体现这个总原则。例如我们熟悉的工厂模式就很好的实现了开闭原则(Open Closed Principle)。

但是我认为，MediatR对这个总原则的实现更完美。在MediatR中，任何新增功能都可以通过新增Resquest消息和Handler处理器的方式实现，甚至可以在不改变原有Notification消息的基础上，新增Handler处理来实现功能扩展。新版本还增加了对StreamRequest的支持，使其可以通过相同的方式对请求数据流进行处理，实现和GRPC类似的流式数据处理。

MediatR对这个总原则的实现之所以更好，是因为它没有让程序员采用传统的面向接口的编程方式来对功能进行抽象，也就是通过接口方法来代表功能。而是另辟蹊径，采用消息来代表功能，把功能抽象为对消息的处理过程。很巧妙的避免了接口类粒度难以定义和接口方法签名耦合的问题。 MediatR让程序员从面向接口编程转变为面向消息编程。化繁为简，我认为这是一个很大的编程思想的进步。

二、MediatR 和 Grpc对比

MediatR还提供各种自定义AOP功能和异常处理功能，是个很优秀的过程/功能调用（Procedure Calls）框架。从过程/功能调用的角度来讲，它比GRPC更简洁，更低耦合。因为GRPC本质上还是传统的对服务器端功能的接口抽象，也就是Proto文件的作用。这导致了客户端不但要知道服务端方法的接口参数，也要知道方法所在接口和方法名称才能调用该功能。此外，如果客户端只想调用服务端的一个方法，也必须要引用整个Proto文件，或者对Proto文件进行删减（增加风险）。

而这些高耦合的问题在MediatR中都不存在，因为在MediatR中，消息就代表功能，服务端只要接收到消息就执行对应处理过程来实现功能。客户端想调用那个功能只要发送相应的消息即可。除了MediatR不能远程（Remote）以外。

三、如何实现MediatRPC

那么，我们就给MediatR加上远程通讯的功能。这就涉及到远程通讯的问题，目前最先进最时髦的远程通讯协议莫过于QUIC了。它是HTTP3的通讯实现基础，基于UDP协议，比TCP协议减少了握手次数，提高了传输效率，提高了传输安全性等，总之就是两个字：先进。

而.Net 中的System.Net.Quic，是微软实现的跨平台QUIC的.Net封装程序集。微软其实是用C++实现的QUIC，据说其性能受到了业界好评。本文就使用System.Net.Quic为MediatR增加远程发送和接收消息的功能。从而实现真正的RPC，起名叫MediatRPC。

四、MediatRPC实现效果

 我们先来看一下实现结果，首先启动服务端：

MediatRPC - 基于MediatR和Quic通讯实现的RPC框架，比GRPC更简洁更低耦合，开源发布第一版

客户端远程调用代码如下：

Console.WriteLine("MediatRPC Client Running...");
Console.WriteLine();

MediatRpcClient mediatRpcClient = await MediatRpcClient.Build();

var responseMessage1 = await mediatRpcClient.Send(new TestRequestMessage() { Message = "Hello MediatRPC 1" });
Console.WriteLine(JsonSerializer.Serialize(responseMessage1));

Console.WriteLine();

var responseMessage2 = await mediatRpcClient.Publish(new TestNotificationMessage() { Message = "Hello MediatRPC 2" });
Console.WriteLine(responseMessage2);


Console.ReadKey();

MediatRpcClient是我实现的客户端对象，它分别向服务端发送了两个消息，一个是用Send发送了IRequest消息，并打印返回消息。另一个是用Publish发送了INotification消息，打印是否执行成功。消息发送和接收方式和MediatR一摸一样, 因为方法签名直接抄袭了MediatR。宗旨就是，怎么使用MediatR就怎么使用MediatRPC。

服务端处理Request消息的Handler代码如下：

 public class TestRequestMessageHandler : IRequestHandler<TestRequestMessage, TestResponseMessage>
    {

        public TestRequestMessageHandler()
        {
        }

        public async Task<TestResponseMessage> Handle(TestRequestMessage request, CancellationToken cancellationToken)
        {
            TestResponseMessage testResponseMessage = new TestResponseMessage();
            testResponseMessage.Message = $"ACK:{request.Message},{DateTime.Now.ToString("HH:mm:ss")}";
            return testResponseMessage;
        }
    }

启动客户端：

MediatRPC - 基于MediatR和Quic通讯实现的RPC框架，比GRPC更简洁更低耦合，开源发布第一版

Request 和 Response Package是我封装的消息包，参考了Http包的实现，也分为Headers和Body。Request 包将原来Http包的请求路径改为MediaRMethod，让服务端知道如何处理这个消息。调用日志每一步都打印的很清楚，不再赘述。

因篇幅关系，具体的服务端和客户端通讯实现方式将在下一篇展开，明天就会发布，也会发布源代码。

五、找工作

▪ 博主有15年以上的软件技术实施经验（Technical Leader），专注于微服务（Dapr）和云原生（K8s）软件架构设计、.Net Core、Java开发和Devops构建发布。
▪ 博主10年以上的软件交付管理经验（Project Manager & Product Ower），致力于敏捷（Scrum）项目管理、软件产品业务需求分析和原型设计。
▪ 博主熟练配置和使用 Microsoft Azure云。
▪ 博主为人诚恳，积极乐观，工作认真负责。 

我家在广州，也可以去深圳工作。做架构师、产品经理、项目经理都可以。有工作机会推荐的朋友可以加我微信 15920128707，微信名字叫Jerry。

标签：

相关文章