Dapr Actor 的微服务架构

Dapr中的Actor模型，和Orleans的Virtual Actor一脉相传， 圣杰写过一篇文章Orleans 知多少 | .NET Core 分布式框架介绍过。简单来讲：Actor模型 = 状态 + 行为 + 消息。一个应用/服务由多个Actor组成，每个Actor都是一个独立的运行单元，拥有隔离的运行空间，在隔离的空间内，其有独立的状态和行为，不被外界干预，Actor之间通过消息进行交互，而同一时刻，每个Actor只能被单个线程执行，这样既有效避免了数据共享和并发问题，又确保了应用的伸缩性。

Actor模型大大简化了并发编程的复杂度，Dapr在Actor运行时中提供了许多功能，包括并发控制，状态管理，生命周期管理如Actor的激活/停用以及用于唤醒Actor的Timer(计时器)和Reminder(提醒)。这些功能同样也是通过API的方式予以提供。

• 调用Actor 方法：POST/GET/PUT/DELETE http://localhost:3500/v1.0/actors/<actorType>/<actorId>/method/<method>
• 创建 Timer：POST/PUT http://localhost:3500/v1.0/actors/<actorType>/<actorId>/timers/<name>
• 创建 Reminder：POST/PUT http://localhost:3500/v1.0/actors/<actorType>/<actorId>/reminders/<name>

Dapr Actor 对于使用者，我们可以根据任意名称去获取一个Actor（无论它是否存在），然后就可以发送消息给这个Actor（无论它在哪里）。

作为对比我们可以看看传统微服务架构：

1、通信模型上是节点与节点之间通信（采用RPC形式）

2、同一种服务的多个节点是等价的（因为它们大多数是无状态）（也就是我们的请求发送给其中任何一个节点都是没区别的）。

所以在目前的微服务架构里我们基本需要：

1、服务发现（某个服务部署在哪些节点）

2、负载均衡

因此也出现了各种 service mesh框架（比如Istio），来简化微服务开发，帮我们做这些重复的事情，应用开发者只关心业务。

但即便如此，service mesh跟Dapr Actor 还是有一个显著区别：Dapr Actor （从编码来看）开发模型类似OOP，开发者关注的是对象之间的（RPC）通信/交互。 而service mesh仍然是将一个大系统拆分成多个小系统，交互方式仍然是系统与系统之间（服务与服务之间）(可以看做是面向过程，因为服务就类似一组函数)。

不过Erlang同属Actor模型，跟Dapr Actor 就比较像，但也有一个差别：Erlang是显式创建Actor，Dapr Actor 是隐式创建（用户不需要主动创建，你调用它，它就必然存在）；所以从编码上来看，Dapr Actor 无疑是更便捷的。（当然Erlang的某些特性，Dapr Actor 也是没有的）：https://channel9.msdn.com/Shows/Azure-Friday/Learn-all-about-Distributed-Application-Runtime-Dapr-Part-2