【发布时间】：2016-07-26 09:47:32
【问题描述】：
我是 Azure Service Fabric 的新手，我遇到的最大问题是
- 什么时候应该使用可靠的演员？请给我一些实际的例子。
- 什么时候应该使用可靠的服务？请给我一些实际的例子。
【问题讨论】：
【发布时间】：2016-07-26 09:47:32
【问题描述】：
看看差异：
- 状态类比：Actor 作用于对象图的单个实例。 服务通常具有多个调用者的状态。
- Scope ：Actor 不能单独工作，因为它们的大小（更像对象）。
- 生命周期 ：Actor 仅在使用时才处于活动状态，因此 更多将适合您的可用服务器资源
- 并发：参与者 强制单线程访问
- State : Actors 只是修改 聚合，服务在集合上工作，所以经常在集合上使用事务 对于酸性行为。
- Communication ：Actor 通过 平台提供的渠道。服务可以选择其他方式。
- Access : 集群中的 Actor 无法从外部访问 默认。您可能需要一个提供访问权限的服务。
何时使用演员的示例：
- 对于您的移动应用程序的每个用户，您可以拥有一个演员。
- 对于每个向您的应用程序发送信息的恒温器，您可以有一个参与者。
- 对于您电子商务网站的每位客户，您可以拥有一个购物篮参与者。
在您可能习惯的情况下创建服务。创建可同时为多个用户提供服务的可靠服务。例如气象服务。
【讨论】：
-
谢谢，假设我正在开发一个简单的图书目录在线应用程序，服务是什么，演员是什么？
-
如果没有更多上下文，很难说。最终用户可以租用或购买书籍吗？什么是商业案例？当您拥有面向最终用户的功能时，您可以为每个最终用户拥有一个参与者。甚至可能是每本书，但这取决于。
-
关于比例的注释不是真的。 Reliable Actors 是 Reliable Services 之上的框架，因此它们的扩展方式完全相同。 Actor 与服务一样受到服务器资源的限制。
-
关于您提供的示例，是的，您可以通过这种方式对这些问题进行建模。但是，如果您想回答有关您的数据的问题，您将需要一个单独的存储机制来查询，例如：“告诉我所有来自西雅图的移动用户”或“让我将所有恒温器设置为 25 度或更高”
-
感谢 Vaclac，我已经更正了有关比例的概述。关于 Actor 样本。是的，当您选择使用表示单个对象（例如恒温器）的 Actor 来解决问题时，会对涵盖多个 Actor 的数据产生影响。
我并不是要使用一个词来定义它自己，而是仅在您确定您的问题符合 Actor 设计模式时才使用 Reliable Actors。 Actors 是一种设计模式，与许多四人组设计模式非常相似。如果您的问题符合其中一种模式，请使用它。如果没有，最好不要试图将你的问题硬塞进错误的模式中。
在 Service Fabric 中，Reliable Actors 是 Virtual Actor 模式的一种实现。它有一定的操作规则和相应的注意事项。这是一个很好的文档，可以了解 Reliable Actor 框架的工作原理以及它是否满足您的要求：https://azure.microsoft.com/en-us/documentation/articles/service-fabric-reliable-actors-platform/
Reliable Actors 实际上只是一个建立在 Reliable Services 之上的框架，因此所有相同的缩放、分区和分发规则都适用。
【讨论】：
-
有哪些问题适合 Actor 设计模式？
-
这很有趣，互联网上没有人能给出一个清晰、简洁、真实的例子来说明为什么你会使用服务而不是演员。我已经阅读了有关演员的文档和维基百科文章，但我仍然非常困惑。
-
我相信这会对你有很大的帮助stackoverflow.com/questions/4493001/good-use-case-for-akka TL;DR 当你需要高并发加上状态隔离时，你需要演员。此外，如果您的服务正在管理一个经历复杂状态机转换的实体，其中每个分支都需要隔离，那么 Actor 非常适合