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

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

 

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


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


1995789-20211211232359932-380165609.png

 

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

1995789-20211211232409013-1629525311.png

 

3、选择.Net6 LTS版本。

 1995789-20211211232511687-105923074.png

 

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

1995789-20211211232537787-1826898048.png

 

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

1995789-20211211232546334-1925049203.png

 

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

1995789-20211211232556212-1453642770.png

 

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

1995789-20211211232603714-826828903.png

 

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

 1995789-20211211232613772-1136766573.png

 

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

 1995789-20211211232632352-939448093.png

 

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

 1995789-20211211232643354-2009526085.png

 

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

1995789-20211211232654347-1778097280.png

 

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

1995789-20211211232703115-1360815785.png

 

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

 1995789-20211211232713692-1482889647.png

 

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

1995789-20211211232723484-968105592.png

 

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

1995789-20211211232739976-1700450866.png

 

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

 1995789-20211211232755254-1163187862.png

 

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

1995789-20211211232803783-1940501367.png

 

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

 1995789-20211211232810950-1405456067.png

 

 

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

 1995789-20211211232818879-956729011.png


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

1995789-20211211232828350-1262245339.png

 

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

1995789-20211211232856147-2073466204.png

 

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

1995789-20211211232903124-290559741.png

 

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


1995789-20211211232913340-1327216350.png

 

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

1995789-20211211232921636-677487484.png

 

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

1995789-20211211232932132-1830283828.png

 

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

 1995789-20211211232940900-1309199048.png

 

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

 1995789-20211211232949288-1160474273.png

 

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

 1995789-20211211232958819-476598947.png

 

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


1995789-20211211233008782-973241859.png

 

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

 1995789-20211211233016055-1897512163.png

 

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

1995789-20211211233025254-322814219.png

 

 

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

1995789-20211211233034332-1700996272.png

 

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

 1995789-20211211233046258-168866443.png

 

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

 1995789-20211211233055240-823347146.png


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

1995789-20211211233103199-190689082.png

 

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

1995789-20211211233113930-1264407503.png

 

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

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

1995789-20211211233128461-1081102966.png

 

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


目录
相关文章
|
2月前
|
编解码 中间件 API
API实现跨平台访问的方式
【10月更文挑战第16天】API实现跨平台访问的方式
49 2
|
2月前
|
开发框架 .NET API
Windows Forms应用程序中集成一个ASP.NET API服务
Windows Forms应用程序中集成一个ASP.NET API服务
97 9
|
2月前
|
Kubernetes 安全 Cloud Native
云上攻防-云原生篇&K8s安全-Kubelet未授权访问、API Server未授权访问
本文介绍了云原生环境下Kubernetes集群的安全问题及攻击方法。首先概述了云环境下的新型攻击路径,如通过虚拟机攻击云管理平台、容器逃逸控制宿主机等。接着详细解释了Kubernetes集群架构,并列举了常见组件的默认端口及其安全隐患。文章通过具体案例演示了API Server 8080和6443端口未授权访问的攻击过程,以及Kubelet 10250端口未授权访问的利用方法,展示了如何通过这些漏洞实现权限提升和横向渗透。
183 0
云上攻防-云原生篇&K8s安全-Kubelet未授权访问、API Server未授权访问
|
3月前
|
人工智能 Serverless API
一键服务化:从魔搭开源模型到OpenAI API服务
在多样化大模型的背后,OpenAI得益于在领域的先发优势,其API接口今天也成为了业界的一个事实标准。
一键服务化:从魔搭开源模型到OpenAI API服务
|
3月前
|
API iOS开发 开发者
Snapchat API 访问:Objective-C 实现示例
Snapchat API 访问:Objective-C 实现示例
|
3月前
|
Go API 开发者
深入探讨:使用Go语言构建高性能RESTful API服务
在本文中,我们将探索Go语言在构建高效、可靠的RESTful API服务中的独特优势。通过实际案例分析,我们将展示Go如何通过其并发模型、简洁的语法和内置的http包,成为现代后端服务开发的有力工具。
|
3月前
|
负载均衡 API 数据安全/隐私保护
Zookeeper的客户端-原生的API
Zookeeper的客户端-原生的API
|
3月前
|
开发框架 前端开发 JavaScript
ASP.NET MVC 教程
ASP.NET 是一个使用 HTML、CSS、JavaScript 和服务器脚本创建网页和网站的开发框架。
44 7
|
3月前
|
存储 开发框架 前端开发
ASP.NET MVC 迅速集成 SignalR
ASP.NET MVC 迅速集成 SignalR
68 0
|
4月前
|
开发框架 前端开发 .NET
ASP.NET MVC WebApi 接口返回 JOSN 日期格式化 date format
ASP.NET MVC WebApi 接口返回 JOSN 日期格式化 date format
50 0