Actors
Actor 模型 起源于Carl Hewitt 在 1973 年提出的作为并发计算的概念模型，这种形式的计算会同时执行多个计算。 当时并没有高度并行的计算机，但多核 Cpu 和分布式系统的最新进步使得Actor 模型 变得流行。在Actor 模型中，Actor 是一个计算和状态独立的单元。 Actors 完全彼此隔离，它们永远不会共享内存。 Actors 使用消息相互通信。 当一个Actor 收到消息时，它可以更改其内部状态，并将消息发送到其他 (可能是新的) Actors。
Actor模型使得编写并发系统变得更简单的，它提供了基于 turn-based 的 (或单线程) 访问模型。 多个Actors可以同时运行，但每个Actor 一次只处理一个接收的消息。 这意味着，在任何时候，都可以确保在Actors 中最多有一个线程处于活动状态。 这使得编写正确的并发系统和并行系统变得更加容易。
Dapr 的实现基于 项目 "Orleans" 中引入的虚拟Actor模式。 对于虚拟Actor模式，不需要显式的创建Actor。 第一次将消息发送到Actor时，Actor将被隐式激活并放置在群集中的节点上。 当不执行操作时，Actor 会以静默方式从内存中卸载。 如果某个节点出现故障，Dapr 会自动将激活的Actor 移到正常的节点。 除了在Actor之间发送消息以外，Dapr Actor模型还支持使用计时器和提醒调度将来的工作。
虽然Actor模型 提供了很大的优势，但必须仔细考虑Actor的设计。 例如，如果多个客户端调用相同的Actor，则会导致性能不佳，因为Actor 操作会按顺序执行。 下面的检查清单是是否适用于 Dapr Actor的一些标准：
问题空间涉及并发性。 如果没有Actor，则需要在代码中引入显式锁定机制。
可以将问题空间分区为小、独立和隔离的状态和逻辑单元。
不需要低延迟的读取Actor 状态。 因为Actor 操作是按顺序执行，不能保证低延迟读取。
不需要在一组Actor 之间查询状态。 跨Actor 的查询效率低下，因为每个Actor 的状态都需要单独读取，并且可能会导致不可预测的延迟。
满足这些条件的一种设计模式非常好，就是 基于业务流程的 saga 或 流程管理器 设计模式。 Saga 管理必须执行的一系列步骤才能达到某些结果。 Saga (或进程管理器) 维护序列的当前状态，并触发下一步。 如果一个步骤失败，saga 可以执行补偿操作。 利用Actor，可以轻松处理 saga 中的并发，并跟踪当前状态。 EShopOnDapr 参考应用程序使用 saga 模式和 Dapr Actor来实现排序过程。
为了提供可伸缩性和可靠性，将在Actor服务的所有实例中对actor进行分区。 Dapr placement 服务负责跟踪分区信息。 启动Actor 服务的新实例时，Sidecar 会将支持的Actor 类型注册到placement 服务。 placement 服务计算给定Actor 类型的更新分区信息，并将其广播给所有实例。
关于 Actor Pattern 的信息以及相关论文：
Actor pattern
Orleans: Distributed Virtual Actors for Programmability and Scalability
总结
分布式架构的门槛比较高，需要考虑的问题很多，通常我们都需要考虑如下问题。
服务治理：包含Service Invocation、Service Trusted and Authorization (服务的信任、认证与授权)、通信模式(HTTP / gRPC)、通信机制(Push / Pull)、状态管理(State Machine)
运维：高可用、扩展机制、Log 处理、分布式追踪、Metric
安全性：Data Encryption、Secret Management、KMS、Auth 集成
性能和可靠性：Rate Limit、降级、熔断…
可扩展的架构
如何提升开发团队的效能
上述的这些东西，通常是一个有经验的、资深的软件工程师，如何在资源有限的情况下，可以快速开发、容易测试，是很多技术人的痛点所在。
这些问题从个别来看，都有相当成熟的系统，如果个别看，有很多现成的实践可以参考。但是对于存在了几十年的祖传代码的系统架构而言，如果要进行微服务改造，往往都要伤筋动骨，让技术主管和架构师伤透脑筋，往往要面对新旧技术的整合，同时也要面对现实的团队需求的交互和对于新技术的学习门槛。对于开发应用程式的开发人员来讲，满足业务需求的开发已经够头痛了，还要考虑这么多系统架构层面的东西，这种事是无法靠热情填补的。Dapr 将一些经过验证的技术和最佳实践带到微服务开发中。它通过即插即用模型将90 年代的数据驱动的客户端/服务器应用程序的操作，应用于现代云原生应用程序所需的最常见服务，让我们集中于业务需求的开发，而不需要考虑系统架构层面的东西 。
