Azure service fabric 服务结构—可靠服务或参与者的业务案例

在商业贷款中，两个不同的申请人（个人或公司）可以使用相同的抵押品（房屋、汽车、企业……）申请贷款

在这种情况下，申请人可以是演员，看起来很自然

抵押品怎么样演员还是服务

我认为： 参与者是在SF中可靠服务之上完成的抽象。参与者模型有一些概念（提醒、计时器、重新进入、事件等）来帮助推理实现业务需求，但它有一个更大的学习曲线来理解这些概念并应用参与者模式：

在我看来，可靠服务是满足架构师需求的一种更原始的方法，我们只有一个runasync方法来钩住用于请求/应答模式的池、批处理和rpc调用的操作。 有状态的可靠服务伴随着分区思考的复杂性而来，分区思考的是根据业务需求创建分区密钥的适当算法，但我们可以控制自己的模式。我们可以收集热数据以进行读写（而不仅仅是缓存），以减少延迟（更好的性能）

你采取哪种方法

考虑到： -您必须快速交付，并且您的开发团队对服务结构和演员模型是新手。 -我们没有做反应式编程，也没有数据流

你能从有状态服务开始吗？。 我们以后能让这些有状态的服务成为有状态的参与者吗如果需要的话

我不喜欢指使这家公司与一个缺乏专业知识的演员合作

---

谢谢，

我想没有人能为你做决定。它们只是在同一运行时上运行的不同编程模型。参与者确实需要一些学习，但也提供了一些明显的好处（无并发性、易于划分和通信）。我们目前正在做一个类似的决定，由于我们的需要，它取决于actor或一个与存储在字典中的actor状态等价的类。演员感觉更合适，但有时我们需要根据x、y或z属性查询演员，虽然技术上可能，但不建议这样做。从细节上看，我们可以看到哪一个是自然适合的，但我们没有；大多数公司都没有这种奢侈，而处于高级职位的人通常没有这种奢侈“不要参与这些令人敬畏的细节对话。在热的地方演员可能会成为瓶颈，特别是如果操作缓慢。我们也可能陷入死锁，或者我们需要设置超时来处理参与者之间的双向通信。我正在寻找这些领域的行业经验，但我明白，对于某些情况，没有错误的答案，只有稍微好一点的方法。谢谢