Dapr牵手.NET学习笔记:想入非非的服务调用

2021年09月16日 阅读数:6
这篇文章主要向大家介绍Dapr牵手.NET学习笔记:想入非非的服务调用,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

demo运行环境:Windows10,Docker(dapr_zipkin,dapr_redid,dapr_placement)nginx



安装:dapr init
卸载:dapr uninstall,而后删除 C:\Users\当前用户\.dapr


dapr在部署时是经过给服务挂载一个sidecar,来辅助应用服务来完成一些额外的分布式工做,能够作到无侵入,本例是本地部署,sidecar和应用服务都是独立进程。经过以下代命令启动sidecar,appid为app1,应用服务端口是5000,dapr的端口为3500。web

dapr ru n --app-id app1 --app-port 5000 --dapr-http-port 3500浏览器

这种彻底的分离,对应用来讲是无侵入的,即便把旧应用管理起来也是无缝的。微信

dapr的服务是经过下面这样的url调用的的:app

http://localhost:3500/v1.0/invoke/app1/method/test负载均衡

3500是dapr端口,其中appid是 app1,对应的接口是 /test ,其余部分就是相同的了,这样带来的好处是显而易见的,没有的IP或主机名,方便经过 XX应用的XX接口的方式调用其余服务。就像订单服务下单接口调用支付服务支付接口同样明确易用。async


dpar的服务调用就这么简单,带来一个问题是,既然dapr能够经过appid作到服务发现,那么同一服务的多副本怎么实现?
分布式

这个问题我没有从dapr中找到答案(若是您有方案,请告知,十分感谢),可能也没有答案,由于dapr说它是应用开发运行时,而不是分布式基础设施,像负载均衡这种提升可用性的部署,不属于dapr的范畴。
ide

因而我就用nginx搭建了个负载均衡,指向两个相同的服务。5000是nginx对外的端口,appid为app1;两个服务端口和appid分别是5001和app1-1,5002和app1-2,后然分别给这三个服务加上sidecar(固然,只对于服务调用来讲,能够只给nginx加sidecar,但dapr的sidecar不仅服务调用,还有别用,后续说明)
性能

调用示意图以下,若是从浏览器调用到服务的话,是通过nginx的saidecar和nginx两层反向代理完成的。

通过两个反向代理,性能会差吗?为了了解调用的性能,下面进行了一个测试,一、直接调用服务Invock方法;二、通过sidecar代理调用服务SidecarInvoke;三、通过nginx的sidecar到nginx,再调用服务。下面是调用的代码:

using BenchmarkDotNet.Attributes;using BenchmarkDotNet.Running;
BenchmarkRunner.Run<TestInvock>();
[MemoryDiagnoser]public class TestInvock{ readonly HttpClient _invockClient; readonly HttpClient _sidecarClient; public TestInvock() { _invockClient = new HttpClient(); _sidecarClient = new HttpClient(); }
[Benchmark] public async Task<string> Invoke() { var content = await _invockClient.GetStringAsync("http://localhost:5000/test"); return content; }
[Benchmark] public async Task<string> SidecarInvoke() { var content = await _sidecarClient.GetStringAsync("http://localhost:3500/v1.0/invoke/app1-1/method/test"); return content; }
[Benchmark] public async Task<string> LoadbalancingInvoke() { var content = await _sidecarClient.GetStringAsync("http://localhost:3500/v1.0/invoke/app1/method/test"); return content; }}


性能的测试结果:负载均衡后的调用还不错,没有想的那么性能差,为了提升性能,能够用gRPC。


所得:在学习过程当中,一直错觉dapr能完成服务治理,但实践下来的结果是:dapr就是分布式开发的运行时。

因此使用dpar时,默念10次:dapr是分布式开发运行时!!!



本文分享自微信公众号 - dotNET跨平台(opendotnet)。
若有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一块儿分享。