Dapr是一个很优秀的分布式应用运行时，在本篇里我们来说一下Dapr的几个特色功能。
为了方便介绍，我简单画了个思维导图，如下所示：

众所周知，新技术的产生是为了解决现存的问题。从上面的思维图中我们可以了解下Dapr这几大特色功能是为了解决微服务架构中现存的什么问题。具体的Dapr技术代码示例或者说明大家可以访问这个链接来查看。

Publish And Subscribe

发布与订阅 微服务之间一些对实时性要求不高的场景，可以采用发布与订阅的方式来实现微服务之间的异步通信。Dapr初始化安装的Redis很容易就能实现简单的队列功能，不过我个人觉得小型项目用用还可以，如果是大吞吐量的高并发系统还是选用更专业的Rabbit或者Kafka来做消息队列。

Service Invocation

服务调用 微服务之间实时调用的场景Dapr提供了Service Invocation功能来满足。 Dapr支持使用HTTP或者gRPC来调用，我们一起来看看当ServiceA通过Service Invocation来调用ServiceB会发生哪些事情？

1. Service A makes an HTTP or gRPC call targeting Service B. The call goes to the local Dapr sidecar.
   ServiceA发起调用，调用将转向到Dapr的本地边车进程。
2. Dapr discovers Service B’s location using the name resolution component which is running on the given hosting platform. Dapr
   通过命名解析组件来获取ServiceB的地址。
3. Dapr forwards the message to Service B’s Dapr sidecar.
   Note: All calls between Dapr sidecars go over gRPC for performance. Only calls between services and Dapr sidecars can be either HTTP or gRPC.
   Dapr将消息转发至B的边车进程。
4. Service B’s Dapr sidecar forwards the request to the specified endpoint (or method) on Service B. Service B then runs its business logic code.
   B的边车进程转发消息至特定方法，然后B执行业务逻辑代码。
5. Service B sends a response to Service A. The response goes to Service B’s sidecar.
   B回复响应至B的边车。
6. Dapr forwards the response to Service A’s Dapr sidecar.
   Dapr转发响应至A。
7. Service A receives the response.
   A获取响应。

State Management

状态管理 在分布式微服务框架中共享一致的数据是很重要的功能。Dapt通过State Management提供了对一致数据的读写功能。比如一些实际案例中的购物车信息，用户状态会话信息等。

Bindings

绑定 使用这个功能Dapr允许微服务接受第三方系统的消息以及主动与第三方系统交互。官方给的Demo是微服务接收一个Cron表达式来驱动任务按照表达式来定时执行。

Actors

计算单元 计算单元理解起来优点困难，我们先来看看官方给的解释。

The actor pattern describes actors as the lowest-level “unit of computation”. In other words, you write your code in a self-contained unit (called an actor) that receives messages and processes them one at a time, without any kind of concurrency or threading.
While your code processes a message, it can send one or more messages to other actors, or create new actors. An underlying runtime manages how, when and where each actor runs, and also routes messages between actors.
A large number of actors can execute simultaneously, and actors execute independently from each other.
参与者模式将参与者描述为最低级别的“计算单元”。换句话说，您在一个独立的单元（称为参与者）中编写代码，该单元接收消息并一次处理一条消息，而无需任何类型的并发或线程。
当您的代码处理一条消息时，它可以向其他参与者发送一条或多条消息，或创建新的参与者。底层运行时管理每个参与者的运行方式、时间和地点，并在参与者之间路由消息。
大量参与者可以同时执行，并且参与者彼此独立执行。

哪一些场景适合应用计算单元呢？

• 功能涉及大量（数千或更多）小型、独立且孤立的状态和逻辑单元，比如聊天室?
• 希望使用不需要外部组件进行大量交互的单线程对象，包括跨一组参与者查询状态。
• 参与者实例不会通过发出 I/O 操作来阻止具有不可预测延迟的调用者。