Service Fabric 可靠服务管道设计

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 服务总线或 Azure 存储队列（NserviceBus 也允许）。

简而言之，我会同时支持 A 和 C，稍微偏爱 C，但在这些缺点得到解决之前，我不相信使用可靠队列作为实现。