BizTalk:如何限制到wcf服务的连接数？

我开发了一个BizTalk应用程序，它接收一个包含大量消息的文件作为输入。我使用BizTalk XML反汇编程序组件在单独的创建消息中对文件进行“解包”。这些消息中的每一条都由转换消息并调用wcf服务的业务流程从MessageBox中提取

我现在遇到的问题是，每个批处理包含1000条消息，而这1000条消息似乎都同时调用wcf服务。wcf服务被这些消息“轰炸”，并被配置为仅并行处理10条消息（每个调用必须处理数据并将数据放入数据库），并将大量“太忙”异常返回BizTalk。我将wcf适配器配置为在1分钟后重试连接

最终的结果是，BizTalk首先解除消息的争用，然后用所有1000条消息轰炸wcf服务，得到一堆“太忙”异常，然后在不执行任何操作的情况下等待，直到1分钟过去，然后再次轰炸，依此类推

如果我可以将BizTalk配置为最多打开10个到该特定wcf服务的连接，那么处理将更加高效，但据我所知，这是不可能的。（wcf服务配置为使用net.tcp。）

我已经用几种不同的方法尝试了主机的节流设置，但不是没有帮助，就是让应用程序速度慢得无法忍受。此外，BizTalk中的节流似乎是以这样一种方式实现的：它首先轰炸一个服务，然后注意到它正在轰炸，然后等待一段时间，什么也不做，然后解除节流，再次开始轰炸。将请求/消息慢慢地传递出去似乎更好，以便它们在时间上更均匀地分布。例如，我想将WCF适配器配置为每秒最多接收4条消息。现在可能的限制是这样的：在5秒钟的滑动窗口内，如果有超过20条消息，我希望激活限制。但这是不一样的，因为它允许“突发”效应

---

您知道如何提高吞吐量吗？

使用。这太难看了。但是，当优雅的建筑与现实世界相遇时，就会产生丑陋

BizTalk中的主机限制状态是BizTalk本身可用性的自我保护机制-我不会轻易更改这些状态

与Igal的单例思想一样，您可以对BizTalk执行一些不干净的操作，以防止它使用WS-calls使您的应用程序过载，但这样做最终可能会损害BizTalk server的可伸缩性。似乎对应用程序的同步调用可能是问题所在-是否可以考虑更改为使用MSMQ异步执行此操作

但是，如果您保持同步wcf，您还可以在发送主机上查找wcf适配器（我认为如果还没有，您需要转到wcf自定义适配器）

我已经多次使用该模式，它似乎工作得很好。其思想是将真正的消息包装在编排的有效负载中。当需要调用您的服务时，您可以将其传递给一个业务流程，如果运行的业务流程太多，该业务流程就会脱水。这是一个简单的概念，效果很好

---

我会说这个博客非常过时。。但是这个想法是可行的。

这个问题已经有一年多的历史了，但我只想补充一个答案，以防有人有同样的问题

我尝试使用BizTalk主机的节流配置。这没有帮助。我实际上没有尝试使用单例模式，因为这是我不想要的：我们创建了一个强大的面向服务的体系结构，可以轻松地并行处理多条消息，我不想通过引入单例模式来完全撤销这一点

那我最后做了什么？首先，我再次考虑了实际需要什么：我们需要处理一组文件，每个文件包含1000条消息。文件中消息的处理顺序并不重要。处理文件的顺序很重要。通常，我们应该先处理文件1，然后处理文件2，然后处理文件3，依此类推。然而，这并不严格，顺序仅限于文件的范围，例如，必须先处理范围1-5，然后处理范围6-8，但在一定范围内，文件的顺序并不重要。这就是要求

我改变的第一件事，不是一次处理一条消息，而是将服务更改为接受一组消息，以便一次可以处理一个文件。通过一次处理一个文件，只有一个对WCF服务的调用，这样做的优点是BizTalk和WCF服务之间的聊天要少得多。但是请注意，这使得WCF服务端的代码更加复杂，因为每个消息仍然必须独立于其他消息进行处理（使得错误处理更加复杂）。如果我们一次处理有限数量的文件，我们还可以避免太忙错误

除了消息的实际处理之外，WCF服务还提供“注册”文件处理的调用。这是服务器端的代码，用于检查此时是否可以处理文件：它考虑了文件的顺序，并确保只有在已处理上一个文件（范围）时才能注册文件（范围）。这些register调用尝试在循环中注册一个文件（范围），其中包含一个wait。调用尝试注册文件，如果不接受，则等待，然后重试。我真的不喜欢这个解决方案，但它是有效的

最后，我有了一个解决方案，它考虑了文件范围的顺序，接下来是关于可以并行处理多少文件的配置。这意味着我不再收到任何太忙错误。我对我的解决方案并不完全满意，但它确实有效并且非常稳定。它一直在毫无问题地运行