服务面料可靠服务管道设计

Question

如果Service Fabric的可靠服务我需要实现管道,并且从可靠性简单和简单的良好设计的角度来看,我需要一些关于这些方法更适合的指导:

Answer 1

我也一直在研究这个主题(适用于我的NServiceBus和MessageHandler的工作),并想提出我对此事的看法.但是我还没有确定最好的型号是什么.

如果您忽略ServiceFabric的实际实现,我会在可靠性方面按以下顺序对提议的方法进行分类:

• C)存储和转发模型在服务间通信方面可能是3种模型中最好的,所有服务可以相互独立工作,不会受到网络中断的影响(增加延迟的缺点)
• A)每个服务的输入队列:每个服务都不受网络中断影响,因为它自己的工作.但是,当它希望向另一个服务发送消息时,它可能会受到网络中断的影响,并且需要重新构建才能适应这种情况.
• B)每个服务的输出队列:可能是3个模型中最少的,因为每个服务直接依赖于其他服务的资源,这导致很大程度上依赖于节点之间的网络可用性.

如果从简单的角度来看,我会按照以下方式对它们进行分类

• A)每个服务的输入队列:由于消息源需要主动将消息路由到给定的目标队列,因此使用路由模式实现业务流程或工作流(我假设您的管道将要表示)相当简单(静态)使用路由滑动模式路由或动态fe
• C)存储和转发:路由是实现的一个明确部分,因此静态和动态路由模式都是可能的,但是实际实现更难,因为您需要构建和管理从传输队列传输消息的消息泵(输出) )到目标队列和相关的需要将上下文从消息源流入消息泵.(无耻的插件:NServiceBus是一个框架,可以消除你的复杂性,使这个场景像A一样简单)
• B)每个服务的输出队列:每个服务都需要设置为从另一个队列中显式读取,这种方法只允许静态路由,因为路由规则嵌入在您只读取的位置(这从功能角度严格限制了您)

如果我们考虑ServiceFabric的实现细节,那么我假设您想要使用IReliableQueue实现？这个实现有一些缺点,这让我想知道这些模式是否真的可以在ServiceFabric的本机存储基础架构上正确实现.

1. 存储基础结构仅在Statefull服务上可用,因此无状态服务(如Rest API或其他协议终止网关)不能成为管道的一部分(通常您希望其中一个作为入口点)
2. 只有1个线程可以同时访问可靠队列,因此无法同时从同一队列中进行写入和读取.这严重限制了队列的吞吐量.
3. 访问可靠队列需要本地事务,但这些事务仅限于单个分区.因此,扩展您的有状态服务以创建竞争性消费模式也是不可能的.

鉴于这些缺点,我仍然倾向于使用另一种类型的SF服务排队基础设施而不是SF的持久性模型,例如Azure Service Bus或Azure存储队列(NserviceBus也允许).

简而言之,我将支持A和C,略微偏爱C,但我不相信使用可靠的队列作为实现,直到这些缺点得到解决.