服务调用和服务发现
这就是我们在微服务里面常说的服务治理,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 允许通过链接一系列中间件组件来定义自定义处理管道。 请求在路由到用户代码之前经过所有已定义的中间件组件,然后在返回到客户机之前,按相反顺序经过已定义的中间件,如下图中所示。