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

　　demo运行环境：Windows10，Docker(dapr_zipkin，dapr_redid，dapr_placement)

 

---

　　安装：dapr init
　　卸载：dapr uninstall，然后删除 C:\Users\当前用户\.dapr

---

 

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

dapr ru n --app-id app1 --app-port 5000 --dapr-http-port 3500

　　这种完全的分离，对应用来说是无侵入的，即使把旧应用管理起来也是无缝的。

　　dapr的服务是通过下面这样的url调用的的：

　　http://localhost:3500/v1.0/invoke/app1/method/test

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

 　　

　　dpar的服务调用就这么简单，带来一个问题是，既然dapr可以通过appid做到服务发现，那么同一服务的多副本怎么实现？

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

　　于是我就用nginx搭建了个负载均衡，指向两个相同的服务。5000是nginx对外的端口，appid为app1；两个服务端口和appid分别是5001和app1-1，5002和app1-2，后然分别给这三个服务加上sidecar（当然，只对于服务调用来说，可以只给nginx加sidecar，但dapr的sidecar不只服务调用，还有别用，后续说明）

　　调用示意图如下，如果从浏览器调用到服务的话，是经过nginx的saidecar和nginx两层反向代理完成的。

 

　　经过两个反向代理，性能会差吗？为了了解调用的性能，下面进行了一个测试，1、直接调用服务Invock方法；2、经过sidecar代理调用服务SidecarInvoke;3、经过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是分布式开发运行时！！！

　　

　　想要更快更方便的了解相关知识，可以关注微信公众号