首先，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后再思考如何封裝不同的消息組件。
相關文章：
Dapr 文檔庫 dapr官方文檔
Dapr for .NET Developers .net 使用dapr的文檔