【.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、以上就是本文章的全部内容。欢迎大佬们留言、点赞或转发推广~~


目录
相关文章
|
1月前
|
缓存 JavaScript Serverless
一些可能被忽视的 Vue3 API 附带案例
一些可能被忽视的 Vue3 API 附带案例
103 0
|
20天前
|
API
GEE案例分析——利用sentinel-3数据计算空气污染指数(Air Pollution Index,简称API)
GEE案例分析——利用sentinel-3数据计算空气污染指数(Air Pollution Index,简称API)
27 0
|
1月前
|
缓存 供应链 安全
淘宝API接口调用:案例分析与最佳实践(续)
淘宝API接口是连接商家与淘宝平台强大功能的重要桥梁。通过案例分析和最佳实践的分享,我们希望商家能够更深入地理解如何有效地使用这些API来优化电商业务。随着技术的不断进步,淘宝API的功能将会越来越丰富,而商家面临的挑战也会越来越大。因此,商家需要不断地学习新技术、探索新方法,并且不断完善自己的API使用策略,以便更好地适应市场的变化,赢得竞争的优势。
|
1月前
|
供应链 搜索推荐 API
淘宝API接口调用:案例分析与最佳实践
在电子商务迅猛发展的今天,淘宝作为中国最大的在线购物平台之一,为商家们提供了强大的数据分析和市场洞察工具——淘宝API。有效的API调用不仅可以提升商家的运营效率,还可以帮助商家更好地理解消费者需求、优化商品布局、提高用户满意度等。本文将通过案例分析和最佳实践探讨如何高效利用淘宝API接口。
|
1月前
|
机器学习/深度学习 安全 数据挖掘
电商API接口的最佳实践与案例分析
随着电商行业的快速发展,越来越多的企业开始将业务拓展到线上。为了提高用户体验和运营效率,电商平台提供了丰富的API接口,方便商家进行商品管理、订单处理、营销活动等操作。本文将介绍电商API接口的最佳实践和案例分析。
|
2月前
|
存储 安全 Devops
DevOps 中 API 治理的工程问题和落地实践案例
API 的全生命周期管理与 Devops 是紧密相关的,Devops 中的各个环节都会对 API 治理有一定的业务诉求,很多时候企业需要一体化的 API 管理平台来提供相应的业务能力。 在 Devops 工作流中进行 API 全生命周期管理时,成功交付的核心其实就是为企业提供工程问题的解决能力。那么所谓工程问题都有哪些呢?
54 0
DevOps 中 API 治理的工程问题和落地实践案例
|
2月前
|
定位技术 API
百度地图API的使用教程以及案例(二)
百度地图API的使用教程以及案例
|
2月前
|
定位技术 API 容器
百度地图API的使用教程以及案例(一)
百度地图API的使用教程以及案例
|
3月前
|
前端开发 fastjson API
实用API设计案例
实用API设计案例
19 0
实用API设计案例
|
3月前
|
API 开发工具 开发者
在钉钉中,服务端API 如何获取OA审批评论中的附件下载链接?
在钉钉中,服务端API 如何获取OA审批评论中的附件下载链接?
222 1

相关产品

  • 云迁移中心