服务织物可靠的服务管道设计 [英] Service Fabric Reliable Services Pipeline design

问题描述

我需要实现管道，如果服务织物的可靠的服务，我需要了解这些方法是什么，从简单的可靠性和简单的设计，良好的观点来看，preferable的一些准则：

I need to implement pipeline if Service Fabric's Reliable Services, and I need some guidelines about what of these approaches is preferable from the viewpoint of reliability simplicity and simple good design:

推荐答案

我一直在研究这个话题很多，以及（被应用到我的工作，为的 NServiceBus 和的MessageHandler ），并愿意提供关于此事我的想法。不过，我还没有确定最佳的模式是什么呢。

I have been investigating this topic a lot as well (to be applied to my work for NServiceBus and MessageHandler) and would like to provide my thoughts on the matter. However I haven't determined what the best model is yet.

如果你忽略的实际执行与ServiceFabric当涉及到可靠性我会分类按以下顺序提出的方法：

If you disregard the practical implementation with ServiceFabric I would categorize the proposed approach in the following order when it comes to reliability:

• C）的存储和转发模式，可能是最好的3款机型的时候还可以相互通信，所有服务都可以相互独立工作，不以任何方式受网络中断（在增加延迟的缺点）

每个服务
• A）输入队列：从网络中断了它自己的工作的影响无每个服务。然而，当它希望将消息发送到另一个服务可能由网络故障受到影响，需要重试建，以适应这一点。

每个服务
• B）输出队列：可能是至少3款机型，因为每个服务的直接依赖于别人的资源，这导致在节点之间的网络可用性的依赖性太大
。

如果你从一个简单点看的话，我想将它们分类如下方式

If you look at it from a simplicity point of view, I would categorize them the following way

• A）每个服务输入队列：作为消息源需要主动将消息路由到一个给定的目标队列，这是相当simpel实现业务流程或工作流（我假设你的管道将重新present什么）使用路由模式（静态路由或动态FE使用传送名单模式


• C）存储和转发：同样的路由是你实现一个明确的部分，所以静态和动态路由模式是可能的，但是在实际的实行是更难，因为你需要建立和管理，从转移传送消息的messagepump队列（输出）到目的队列和关联的需要从消息源流上下文到消息泵。 （无耻插头：NServiceBus是可以带走的复杂性，为您和使这种情况为A的简单框架）

每个服务
• B）输出队列：每个服务需要设置从另一个队列明确的阅读，这种方法只允许静态路由的路由规则嵌入在你只读（这严重限制你从功能透视图）

如果我们把ServiceFabric的实现细节考虑在内，那么我想你想利用IReliableQueue实施？这种实现有一些缺点虽然，让我怀疑这些模式实际上可以在适当ServiceFabric的本地存储基础架构来实现。

If we take ServiceFabric's implementation details into account, then I assume you want to make use of the IReliableQueue implementation? This implementation has some shortcomings though, that make me wonder if these patterns can actually be implemented properly on ServiceFabric's native storage infrastructure.

1. 的存储基础设施仅在有状态的服务提供，因此无状态的服务（如REST API的或其他协议终止网关）不能管道（通常你想其中的一个作为切入点）
的一部分

2. 只有1线程可以在同一时间访问一个可靠队列，所以不可能写入，并在同一时间从同一队列中读取。这严重限制了吞吐量的队列。


3. 访问的可靠队列需要本地事务，但这些交易被限制为一个分区。因此，它也不可能向外扩展您的有状态的服务创造竞争消费者模式。

，我还是倾向于使用其他类型的排队SF服务，而不是SF的持久化模型的基础设施，比如Azure的Service Bus或Azure存储队列（其中NserviceBus允许为好）。

Given these shortcomings, I'm still inclined to use another type of queueing infrastructure for SF Services instead of SF's persistence model, for example Azure Service Bus or Azure Storage Queues (Which NserviceBus allows as well).

总之，我会支持A和C，有轻微的preference为C，但我不相信关于使用可靠的队列作为实施直到这些缺点已经得到解决。

In short, I'll support both A and C, with a slight preference for C, but I'm not convinced about using reliable queues as an implementation until these shortcomings have been resolved.

这篇关于服务织物可靠的服务管道设计的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！