前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Dapr Actor 的微服务架构

Dapr Actor 的微服务架构

作者头像
张善友
发布2021-03-15 21:14:34
1.1K0
发布2021-03-15 21:14:34
举报
文章被收录于专栏:张善友的专栏张善友的专栏

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

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2021-03-13 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
负载均衡
负载均衡(Cloud Load Balancer,CLB)提供安全快捷的流量分发服务,访问流量经由 CLB 可以自动分配到云中的多台后端服务器上,扩展系统的服务能力并消除单点故障。负载均衡支持亿级连接和千万级并发,可轻松应对大流量访问,满足业务需求。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档