首先，dapr的概念：Dapr 是一个可移植的、事件驱动的运行时，它使任何开发人员能够轻松构建出弹性的、无状态和有状态的应用程序，并可运行在云平台或边缘计算中，它同时也支持多种编程语言和开发框架

    一个个拆开来理解：

     可移植: 可以运行在windows，docker环境中，主要目标应该还是k8s

     事件驱动：还没想明白怎么事件驱动，可以知道的是支持消息的通知和订阅。（如果是消息驱动的话就可以理解了，因为各sidecar之间都是通过消息来通知的）

     运行时： 说明其实是一个运行环境，应用程序运行在这个运行时之上，那么应用程序的启动同时也要启动dapr

     弹性的：应该是可以随着应用程序的容器一起扩充或减少的意思，主要还是在k8s上弹性增减了

     无状态和有状态：应该指的是dapr其中的状态管理组件，可以使用也可以不使用。

     云平台：支持在各家的云平台上运行吧，而云平台大概就是k8s吧。

     支持多种编程语言和开发框架：虽然是微软开发的，但是官方文档用例竟然不是C#语言。。。因为使用到了sidecar模式，而应用程序与sidecar的交互都是通过消息通知，所以可以做到不限语言和开发框架。微软也出

了不同语言的sdk做支持，python,php,node.js等等，貌似不用sdk的话直接通过http 或者grpc调用也是可以的。

     sidecar模式：目前使用下来的感觉sidecar跟一个网关差不多，应用程序跟外部应用的交互都由这个sidecar来处理。

 

 其次，dapr的功能：dapr集成了 rpc调用，状态调用(我的理解是缓存)，发布/订阅消息，绑定(还没测)，actor，可观测性(还没测)，密钥管理 模块，使得应用程序只需专注于业务代码，这些外部交互功能则交给dapr管理，

减少了外部组件的代码侵入，对组件的切换可以对应用程序透明(比如消息组件从rabbitmq切换成redis，应用程序不用改任何代码)。但是我觉得应用程序还是侵入了dapr的代码，这在本机调试的时候需要启动相关服务才能

完整把应用程序跑起来，还是有点麻烦。比如我现在虽然用的是 self-hosted mode(自托管模式？)，但是还是得启动docker才能完整跑起来，因为dapr需要用到 zipkin 容器的功能。

 

  dapr的使用：可以参考官方文档，我说说我在windows 自托管模式下使用的经验，因为还没上k8s环境，所以还没熟悉k8s下的部署和使用。

    关于调试应用程序和dapr的交互，官方运行程序与dapr的命令是这样

  

dapr run --app-id DaprCounter dotnet run

   这样子会同时启动一个 sidecar 和  应用程序，sidecar 默认的端口是3500，同时应用程序会自动配置好sidecar相关的信息(http、grpc端口)。缺点是不好调试，可以通过vs附加进程的方式进行调试。

  另一种方式是指定端口先把 sidecar启动起来，监听应用程序端口，则可以使用vs直接运行程序，不受 dapr命令的影响。

dapr run --app-id myapp1 --dapr-http-port 12302 --dapr-grpc-port 11288 --app-port 5103  

app-port是应用程序的运行端口

接着在应用程序中配置  上边 http-port 和grpc-port的端口

    services.AddControllersWithViews().AddDapr(cfg =>
            {
                cfg.UseHttpEndpoint("http://localhost:12302");
                cfg.UseGrpcEndpoint("http://localhost:11288");

            });

如果使用actor，actor里面的HttpEndpoint端口也需要配置，否则默认是3500

如此，便能照平常的方式使用vs开发dapr应用程序了。

 

一些思考：

  前面写了，dapr的sdk对应用程序的逻辑还是有侵入性的，那么，如何解耦呢？目前想到的是使用依赖注入的方式，通过注入接口的方式在service层隐藏服务之间的交互逻辑。服务调用，actor，状态调用都可以使用这个方式，事件驱动貌似还不行，因为mq的sdk是通过event，

dapr是通过 rpc调用来发送通知，这两个方式差别挺大，等再深入学习dapr后再思考如何封装不同的消息组件。