Service Fabric 可靠服务管道设计

Posted 2023-03-08

【中文标题】Service Fabric 可靠服务管道设计

【英文标题】：Service Fabric Reliable Services Pipeline design

【发布时间】：2016-02-17 00:52:18

【问题描述】：

如果 Service Fabric 的可靠服务，我需要实施管道，并且我需要一些指导方针，从可靠性简单性和简单良好设计的角度来看，这些方法中的哪一种更可取：

【参考方案1】：

我也一直在研究这个话题（将应用于我为NServiceBus 和MessageHandler 所做的工作），并想就此事发表我的看法。但是我还没有确定最好的模型是什么。

如果您忽略 ServiceFabric 的实际实施，我会在可靠性方面按以下顺序对建议的方法进行分类：

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

如果您从简单的角度来看，我会按照以下方式对其进行分类

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

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

存储基础架构仅适用于 Statefull 服务，因此无状态服务（如 Rest API 或其他协议终止网关）不能成为管道的一部分（通常您希望将其中之一作为入口点） 只有1个线程可以同时访问一个可靠队列，所以不可能同时从同一个队列中读写。这严重限制了队列的吞吐量。 访问可靠队列需要本地事务，但这些事务仅限于单个分区。因此，也无法扩展有状态的服务来创建竞争消费者模式。

鉴于这些缺点，我仍然倾向于为 SF 服务使用另一种类型的队列基础架构，而不是 SF 的持久性模型，例如 Azure 服务总线或 Azure 存储队列（NserviceBus 也允许）。

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

【讨论】：

伊夫，我从来没有见过这么详细的答案，你帮了很多忙！现在我肯定在考虑 C（存储和转发）模型。毕竟这是一种关注点分离。我仍然不喜欢使用其他 Azure PaaS 服务。我将通过新的这些新指南深入研究 SF。谢谢！

顺便说一句IReliableQueue 正是我的想法。现在我发现它有缺点。

我希望开发团队能解决这些缺点，对于某些/许多场景来说，本地传输将非常有吸引力。

这一个读写器的东西，这会扩展到整个事务吗？如果是这样，天哪。

如果 Azure ServiceFabric 团队中的某个人能在此处插话，那就太好了。我不得不想象竞争消费者模式将成为使用 ServiceFabric 进行扩展的最常见用例之一。真的是 IReliableQueue 的实现不支持它，最好使用类似 Azure ServiceBus 的东西吗？