.net 用于实时消息传递的BizTalk

我的公司正在探索将BizTalk用于我们的消息传递基础架构，我只是好奇它是否是一个好的候选者

首先，我们是一家.NET商店，处理医疗交易。目前，我们所有的产品都是为实现其目的而编写的，实际上没有通用代码。大多数事务都是通过标准的TCP套接字进行的（以使用MLLP的HL7为模型）。然后，我们处理这些数据，并可能将它们发送给一个或多个第三方，以便通过套接字进行处理。最后，我们将事务响应发送回客户。我们有很多这样运行的应用程序，我们希望将它们放在一个统一的平台上

我们需要它运行得非常快（FWIW，我的想法：

Biztalk Strengths w.r.t.您的要求

• 消息映射非常简单，您可以选择可视化映射或xslt
• 开发的一致性——一旦开发团队克服了 学习曲线，它确实为大多数类型的EAI提供了一个集中的平台 工作（即，您可以不断向Biztalk Server添加新的应用程序，这可以利用现有的消息和进程）
• 事务可靠性-您几乎可以拔掉插头 BizTalk，它可以很好地恢复状态，而不会丢失数据 数据
• 协议不可知-内部所有内容都是Biztalk的XML。您可以使用各种现成的适配器处理“特殊需求”客户，而无需重新编写应用程序
• 低维护操作—一旦部署和调试了应用程序，调整了生产环境，并设置了SQL和监控（如SCOM）维护任务，BizTalk就可以像设备一样快速运行
• 可伸缩性（以一定的价格）-BizTalk有很多用于扩展的旋钮，可以添加多台服务器以进行扩展。但是，我们通常发现在大多数情况下，瓶颈是底层SQL Server

弱点

• 在保证延迟/最大值方面存在一些挑战 处理时间。例如，需要在 BizTalk处于极端负载下，以避免可能导致 导致积压的邮件排队
• 动态路由在某些协议/适配器上有点不完整-您可以 如果需要的话，通常需要混合一些您自己的代码 管理大量静态数据变得不方便的点 使用筛选器发送端口。例如，如果您有100个第三方目的地 [say funds]-和10000个客户-[say doctors/hospitals]，那么将来自资金的消息流路由到医生将不是一件有趣的事。如果您可以保持来自“多”端的消息流，并使用同步协议，您可以避免路由问题

---

FWIW我在医疗环境中使用了BizTalk（但在基金方面，不是交换机），没有太多的挑战（也就是说，我们只需要路由到3个不同的交换机）。我猜您在这里有很多优点。如果低延迟是一项要求，那么您需要从一开始就进行设计，并对系统的这一方面进行广泛测试。没有“低延迟”选项可供您稍后打开：-）