Fork me on GitHub

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 

 

posted @ 2021-03-13 22:09  张善友  阅读(392)  评论(0编辑  收藏