服务调用和服务发现
这就是我们在微服务里面常说的服务治理，Dapr 作为一个分布式系统，多个Dapr app怎么知道彼此的存在，通过什么方式进行沟通，这就是Dapr的服务治理要解决的问题，Dapr的服务发现机制，按照架构的不同方式（k8s还是自托管）有不同的实现，官方文档（https://docs.dapr.io/zh-hans/developing-applications/building-blocks/service-invocation/service-invocation-overview/）里的这张图介绍了调用逻辑。
服务 A 对服务 B 发起HTTP/gRPC的调用。
Dapr 使用 name resolution component 发现 Service B’s 位置 取决于运行的环境 hosting platform.
Dapr 将消息转发至服务 B的 Dapr 边车
注: Dapr 边车之间的所有调用考虑到性能都优先使用 gRPC。 仅服务与 Dapr 边车之间的调用可以是 HTTP 或 gRPC
服务 B的 Dapr 边车将请求转发至服务 B 上的特定端点 (或方法) 。 服务 B 随后运行其业务逻辑代码。
服务 B 发送响应给服务 A。 响应将转至服务 B 的边车。
Dapr 将消息转发至服务 A 的 Dapr 边车。
服务 A 接收响应。
这里面有很多核心的概念：
Dapr 命名有Namespace 概念，基本格式为FQDN
Dapr 的Service Invocation 支持 gRPC / HTTP 两种方式，默认的 Service to Service 使用gRPC 通信。
Service to Service 使用mTLS 做传输层加密
支持 Service 的ACL，可以个别控制每个API 与Method 的操作
支持 Retry 机制
可以使用其他service discovery 实现
RR load balancing with mDNS
支持tracing 和 metric
Middleware
和ASP.NET Core 支持通过 middleware 处理 HTTP request / response 完成一些 Cross-Cutting (AoP) 的功能，Dapr 也支持 Middleware 的概念，如下图：
Dapr 允许通过链接一系列中间件组件来定义自定义处理管道。 请求在路由到用户代码之前经过所有已定义的中间件组件，然后在返回到客户机之前，按相反顺序经过已定义的中间件，如下图中所示。
