我刚接触到Azure服务结构，我遇到的最大问题是

看看不同之处：

• 状态类比：参与者处理对象图的单个实例。服务通常具有多个呼叫者的状态。
• 范围：演员不能单独工作，因为他们的大小(更像物体)。
• 生命周期：演员只有在使用时才是活跃的，所以更多内容将适合您的可用服务器资源
• 并发：参与者强制单线程访问
• 状态：演员只需修改聚合，服务在集合上工作，因此经常在集合上使用事务对于酸性行为。
• 沟通：演员通过平台提供的渠道。服务可以选择其他方式。
• 访问：无法从外部联系群集中的参与者违约。您可能需要提供访问的服务。

示例何时使用参与者：

• 对于移动应用程序的每个用户，都可以有一个演员。
• 对于每个向应用程序发送信息的恒温器，都可以有一个参与者。
• 对于您的电子商务网站的每个客户，您可以有一个购物篮演员。

在您可能习惯的情况下创建服务。创建一个可同时为多个用户提供服务的可靠服务。例如天气服务。

我不想用一个词来定义它自己，但是只有当你确定你的问题符合演员设计模式时，才使用可靠的演员。演员是一种设计模式，很像"四人帮"中的许多设计模式。如果您的问题符合其中一种模式，那么就使用它。如果没有，最好不要把你的问题推错模式。

在服务结构中，可靠的参与者是虚拟参与者模式的实现。它有一定的操作规则和注意事项。这是一个很好的阅读文档，了解可靠的参与者框架是如何工作的，以及它是否满足您的要求：https://azure.microsoft.com/en-us/documentation/articles/service-fabric-reliable-actors-platform/

可靠的参与者实际上只是一个建立在可靠服务之上的框架，所以所有相同的扩展、分区和分布规则都适用。