【.NET6】gRPC服务端和客户端开发案例，以及minimal API服务、gRPC服务和传统webapi服务的访问效率大对决

 前言：随着.Net6的发布，Minimal API成了当下受人追捧的角儿。而这之前，程序之间通信效率的王者也许可以算得上是gRPC了。那么以下咱们先通过开发一个gRPC服务的教程，然后顺势而为，再接着比拼一下minimal api服务和gRPC服务在通信上的效率。以下,Enjoy:

1、创建一个gRPC服务项目。开发模板选项如下图所示。

 

 

2、新建项目MyFirstGRPCService，用来开发gRPC服务端使用。

 

 

 

 

3、选择.Net6 LTS版本。

 

 

 

 

4、初始项目，自动引用了包 Grpc.AspNetCore，用于提供gRPC基础服务。以及Protos文件夹下有proto文件，services文件夹下有与之对应的类文件。

 

 

 

 

5、proto文件和对应的类文件的内容比对，以及它们之间的关系。

 

 

 

 

6、新增一个test.proto文件，定义服务名称和方法名称，以及参数和返回值属性。

 

 

 

 

7、项目文件，可以看到新增的proto文件被自动引入到项目里面。

 

 

 

 

8、添加完毕需要生成一下。此处更正个错误，proto文件里面,int类型需要指定为int32，否则会出问题。然后在项目目录下cmd，执行dotnet run一下。

 

 

 

 

9、执行dotnet run 以后。会在根目录的obj文件夹下，产生一个以Grpc结尾的中间类文件，该文件里面提供了服务有关的内容实现。

 

 

 

 

10、然后新增一个测试服务类，此时就可以引用自动生成的文件里面提供的Grpc类，该类和proto文件里面定义的保持一致。

 

 

 

 

11、在服务里面重写方法，以及提供参数。注意空参数也需要传一个Empty类型的参数进去。可以自行比对重写的服务与proto文件的一些关联点。

 

 

 

 

12、新增一个控制台项目TestConsole,当作客户端，用来做交互使用。并且引入所需要的包，包括Google.Protobuf、Grpc.Net.Client和Grpc.Tools。

 

 

 

 

13、把protos文件，直接复制到客户端项目目录下。Proto文件起到一个中间连接的作用，类似WCF服务的契约代理类。

 

 

 

 

14、GRPC服务端的program文件里面，对刚才新增的TestService服务进行注册(类似依赖注入的注册)。

 

 

 

 

15、打开服务端项目文件，拷贝里面的proto的引用地址。

 

 

 

 

16、客户端对应的proto内容在人品好的情况下，会在拷贝proto文件的时候自动生成。如果人品不好的情况下，就需要从服务端里面拷贝了。拷贝过来以后，需要把Server改为Client，用来指示该服务是面向客户端的。

 

 

 

 

17、按照服务端一样的方式，在项目目录下cmd，输入dotnet run，显示Hello,World的时候（控制台程序program里面默认有个输出的，没有删除，所以会显示），在obj路径下会生成中间类文件。服务端生成的是面向服务的的，客户端生成的是面向客户端的。

 

 

 

 

18、新建一个测试类，用来测试GRPC客户端调用的。客户端调用需要指定访问的GRPC地址，地址当前服务端没有指定，咱们可以在服务端的launchSettings.json文件里面获取到。

 

 

 

 

19、测试服务类需要静态引用我们在proto文件定义的服务，然后在测试方法里面进行远程过程调用。

 

 

 

 

20、启动GRPC服务端，然后客户端调用测试方法，并启动，获得到了GRPC服务端返回的结果内容，说明我们搭建的简单的gRPC服务端和客户端程序OK。

 

 

 

 

21、接下来进行一个对比测试。关于使用webapi和gRPC的访问性能测试。先新建一个minimal api项目：TestPerformanceApi。

 

 

 

 

22、新增一个POST请求方式的api接口Test，用于做测试使用。为了简单些，不带参数并且只返回两个写死的属性，一个name和一个age。（备注：如果不晓得minimal api的，可以查看我的另一篇关于minimal api的文章）。

 

 

 

 

23、新增一个控制台程序，用于测试访问minimal api服务使用。有关代码和引用的包，如下图所示。此处循环访问500次进行测试，访问方式使用HttpClientFactory。

 

 

 

24、访问gRPC的服务，也加个循环500次调用。

 

 

 

 

25、既然都写到这里了，那同时也新增一个传统的webapi项目好了，一起验证下。

 

 

 

 

26、新增一个测试传统webapi的项目TestTraditionalApi，然后新增一个Test2的api控制器，有关代码如图所示。为了保持和minimal api地址一致，减少其他可能性损耗，route路由也直接指定了action。

 

 

 

 

27、再新增一个控制台项目，用来测试访问传统webapi。代码同测试mini api的控制台程序，只是访问的URL地址不一样。

 

 

 

 

28、启动gRPC服务、minimal API服务、以及传统webapi服务。为了防止先启动的控制台占据资源优势，以及避免启动项的项目占据资源优势，新增一个无任何功能的项目当作启动项，然后服务全部从 调试-启动新实例 里面进行打开。

 

 

 

29、访问500次gRPC服务结果：

 

 

 

30、访问500次 minimal api服务结果：

 

 

 

 

31、访问500次传统webapi服务结果。

 

 

 

 

32、为了防止其他可能性干扰，我把控制台输出其他信息全部屏蔽掉，并且循环次数新增到2000次，并且均测试两次，降低首次访问创建实例期间的延迟。其他代码雷同，均增加至2000次*2,并取消控制台打印。

 

 

 

 

33、先测试gRPC服务的结果。第一个2000次访问，耗时4399ms，第二次耗时3140ms.

 

 

 

 

34、然后是minimal api。第一个2000次使用了53347ms,第二个2000次使用了52459ms.

 

 

 

 

35、访问传统的webapi,第一个2000次使用了92025ms，第二个2000次访问，使用了90627ms.

 

 

 

 

36、gRPC效率有点偏高，为了防止可能是网络震荡导致的问题，最后再重新测一次。第一个2000次使用了68709ms，第二个2000次使用了65987ms

 

 

 

 

37、结论：由此可见，在没有任何其他限制情况下，minimal api的访问效率最高，gRPC服务次之，传统webapi最慢。gRPC此处是传入了参数，所以也有可能增加了些许时差，有兴趣的小伙伴可以自行继续测试。

本轮测试使用的开发环境是VS2022企业版，运行环境全部都是.NET 6，本地机器配置(五年多的老古董了)，可以参考如下截图：

 

 

 

 

 

38、以上就是本文章的全部内容。欢迎大佬们留言、点赞或转发推广~~