- 为什么我们用 Orleans
- Dapr VS Orleans
- Actor 模型
- Orleans 的核心概念
为什么我们用 Orleans
- 分布式系统开发、测试的难度（服务发现、通信）
- 运维的复杂度（伸缩性与可靠性的保障）
- actor 拥有全局唯一身份
- 自动伸缩功能
Dapr VS Orleans
Dapr 文档：https://docs.dapr.io
Orleans 文档：https://learn.microsoft.com/zh-cn/dotnet/orleans
| Dapr | Orleans |
|---|---|
| runtime 运行时 | framework 框架 |
| actor 只是其中的一个组件 | actor + state |
| 无分布式事务方案 | 提供最终一致性保障 |
| 依赖于 dapr 运行时 | 无除了 .net 环境的依赖 |
| 比较难进行 debug | 调试开发无差别 |
| docker 与 k8s 支持 | 裸金属/docker/k8s 支持 |
| 多种语言 sdk 支持 | 仅 C# 语言 |
| 1.8 版本 | 3.6 版本，4.0 即将发布 |
Actor 模型
- 对同一个 actor 的调用按顺序执行
- one actor 可以创建其他的 actor
- 给一个 actor 发消息（调用它的执行方法）
- 不能自己去实例化和销毁
- 同一个 identity 的 grain 在系统内只存在一共激活的实例
- actor 没有共享数据
- actor 的数据不可用被外部直接修改
我们有个工作 jd001，就是一个 actor，它会有一个 internal state，状态里面会有一个 identity，它是唯一的，不可改变的
有一个浏览工作的消息，它把工作的 id，以及当前的浏览者信息传入进来，调用 jd001
jd001 会创建一个 activity actor ac001，然后调用 ac001 把浏览记录下来，有一个活动类型 view
Orleans 的核心概念
- 单线程执行模型
- 多路通信复用
- 其他优势
- Grain
- 集群
- 最佳实践
单线程执行模型
actor 在 Orlean 中叫作 grain 谷仓
运行时保证 grain 每次永远不会在多个线程上执行，通过结合与其他 grain 的隔离，程序员绝不会在 grain 级别面临并发情况，因此绝不会需要使用锁或者其他同步机制来控制对共享数据的访问，非专家级程序员只需此功能便可方便地控制分布式应用程序的开发
多路通信复用
Orlean 中的 grain 具有逻辑终结点，它们之间的消息传送跨一组固定的全交换物理连接（TCP 套接字）进行多路复用，这使得运行时能够托管数百万个可寻址实体，并且每个 grain 的操作系统开销很低，此外，在注册/取消注册物理终结点（例如 TCP 端口或 HTTP URL）甚至关闭 TCP 连接时，激活和取消激活 grain 都不会产生成本
其他优势
- 熟悉的面向对象的编程（OOP）范式（grain 即是 .net 类）
- 激活透明
- 位置透明
- 自动传播错误
- 自适应资源管理
高性能
- 显示异步
- 多路复用通信
- 高效计划：运行时在自定义线程池中计划大量单线程 grain 的执行（每个物理处理器核心一个线程），借助采用非阻塞基于延续的样式（Orleans 编程模型的一个要求）编写的 grain 代码，应用程序代码会以非常高效的“协作”多线程方式来运行，没有任何争用，这允许系统达到较高吞吐量，并以很高稳定性采用非常高的 CPU 使用率（高达 90% 以上）运行。
Grain
- 概念
- 模式
- 持久化
- 特点
- 计时器和提醒
概念
grain = identity + behavior [ + state ]
- identity : User/davidgri
- behavior : class User : Grain, Iuser
- state : in-memory, persisted, or stateless
模式
- silo 内模式（集群内）
- silo 外 client-server 模式（集群外：客户端、服务端不在同一个 host 里面）
持久化
激活 grain 时，会自动读取 grain 状态，但 grain 需要负责在必要时显示触发任何已更改的 grain 状态的写入
IPersistentState<TState>
Grain<TState>（已过时）
通过 MongoDB 持久化
Orleans.Providers.MongoDB: https://github.com/OrleansContrib/Orleans.Providers.MongoDB
特点
- Grain 类似于对象，但是，它们是分布式的，虚拟的并且异步的
- 它们是松散耦合、隔离并且基本上独立的
- 避免在 grain 之间进行琐碎通信
- 直接使用内存比传递消息的开销要小得多
- 将过于琐碎的 grain 组合成单个 grain 可能更好
- 需要考虑参数和序列化的复杂性/大小
- 反序列化两次可能比重新发送二进制消息的开销更大
- 避免瓶颈 grain
计时器和提醒
Timer && Reminder：https://learn.microsoft.com/zh-cn/dotnet/orleans/grains/timers-and-reminders
集群
Orleans silo 生命周期概述：https://learn.microsoft.com/zh-cn/dotnet/orleans/host/silo-lifecycle
Kubernetes 托管：https://learn.microsoft.com/zh-cn/dotnet/orleans/deployment/kubernetes
最佳实践
哪些应用适合采用 Orleans
- 有大量（数百、数百万、数十亿甚至数万亿）松散耦合的实体
- 实体足够小、可以是单线程实体
- 工作负载是交互式的
- 预期或可能需要多台服务器
- 不需要全局协调、或者每次只需在少量几个实体之间进行小规模协调
哪些不适合
- 必须在实体之间共享内存
- 少量的大实体可以是多线程实体
- 需要全局协调和/或一致性
- 长时间运行的操作
本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
欢迎转载、使用、重新发布，但务必保留文章署名 郑子铭 （包含链接： http://www.cnblogs.com/MingsonZheng/ ），不得用于商业目的，基于本文修改后的作品务必以相同的许可发布。
如有任何疑问，请与我联系 (MingsonZheng@outlook.com) 。