问题标签 [esb]

很抱歉这个非常复杂的问题，但这是我已经研究了一段时间的东西，这真的让我很沮丧。我觉得在当今时代，我们拥有一百万零一种实现服务的方法，即跨平台 (SOAP) 且易于构建（感谢 .NET、java 和其他框架）。然而，这些技术已经在社区中存在了 5-10 年，但我们（或者至少我是）不断地困扰着同样的问题：

1. 识别（跟踪服务）——UDDI；例如，本月不得不提醒同事 3 次服务所在的位置，尽管事实上有一个讨论该服务的 wiki 和一个相同文档的 PDF 版本，该文档位于我们保存服务文档的存储库中.
2. 可扩展性——开箱即用的集群；作为组织，我们花很多钱来支付我们的管理员，只是为了观察我们服务的使用情况并做出决策，比如，这个服务是否需要更多的 RAM、更多的 CPU、更多的接口？我如何对此进行负载平衡？
3. 监控 - 错误记录等；我数不清有多少次我必须在服务上设置跟踪才能了解为什么会发生似乎只影响一个客户的错误，或者必须将逻辑编码到服务中以序列化异常，将异常记录到 dbs，优雅地失败等等。
4. 部署——易于部署；这些都没有将 DLL 部署到 5 个负载平衡服务器

这些问题中的每一个都需要组织实施某种类型的定制解决方案。#1 的文档和 UDDI。#2 的虚拟化和负载平衡硬件/软件。#3 的跟踪、向数据库/日志等写入异常。＃4的自定义部署软件。我为一个中型组织工作。我什至无法想象像 Sun、Google 或 Microsoft 这样规模的公司会如何解决这些困境。

也许我的愿景是不切实际的，但我梦想拥有一个框架本身，它位于管理上述所有内容的服务器集群之上。读到微软的 AppFabric 让我欣喜若狂，因为它似乎真的将 BizTalk 的一些功能扩展到了 WCF 服务实现者：缓存、托管、监控等。但是，从我所见，我仍然觉得它不存在实现我对一体化解决方案的梦想，该解决方案可帮助开发人员和组织编写可轻松跨集群扩展、轻松部署到集群中、可识别、甚至可能版本化的服务。

所以，我并不是说这篇文章是关于我的梦想的。我确实有一个问题。首先，我的梦想/想要完全不切实际吗？此外，有哪些可用的解决方案试图解决这些问题，而不将我们限制在开发服务的新的和更专有的方式（BizTalk）上？最后，关于完整的 SOA/ESB 解决方案，我们现在或未来在哪里看到了市场上的最大潜力？

.Net 是否有良好的免费服务总线允许 Java 客户端订阅？我正在使用 NServiceBus，我喜欢流畅的 API 和简单性，但它不支持 Java 客户端或基于 Web 服务的连接的 WCF 集成。

谢谢！

我开始设计我公司的一种电信产品的新版本，并提供负载平衡和可扩展性，我正在考虑某种（.NET 开源）ESB。我希望通过避免使用关系数据库并使用（可能）非事务性队列馈入分布式内存缓存（例如 Velocity 或 memcached）来提高系统的吞吐量。

我从来没有在实时系统中使用过这样的架构，而且我担心我在日常开发的简单性中获得的收益会在吞吐量上有所损失（这对于这个应用程序来说是非常关键的）。

我只玩过 NServiceBus，所以我不知道它（或其兄弟）是否适合作为实时 no-sql 应用程序的基础。你怎么看？

我该如何判断这些产品？我应该购买商业应用程序，避免像瘟疫一样的 ESB，还是使用其他方法？

寻找一些想法/模式来解决我将很快开始工作的系统的设计问题。毫无疑问，我需要使用某种消息传递（可能是 MSMQ）在系统的某些区域之间进行通信。我不想重新发明轮子，但同时我想确保我使用正确的工具来完成这项工作。我一直在修改和阅读 NServiceBus，它的功能给我留下了深刻的印象——但我不确定它是否适用于我想要实现的目标。

这是系统需要做什么的（希望）非常简单和概念性的描述：

我有一个客户可以向其发送消息的服务。该服务是“Fire and Forget”——客户得到的最多可能是成功或失败（成功是收到消息）。

每条消息的处理/处理都非常重要，并且可能会占用大量系统资源。因此，只能同时处理 X 条消息，其中 X 是可配置的值（基于系统规范等）。传入的消息将存储在队列中，直到“轮到他们”处理。

对于每个客户端，消息必须按顺序处理（FIFO）。但是，某些客户端可能会连续发送许多消息（数千条或更多），例如，如果它们在一段时间内失去连接。出于这个原因，必须在客户端之间以循环方式处理消息——不允许客户端吃饱，也不允许客户端饿死。因此，系统要么必须能够查询特定客户端的队列，要么为每个客户端创建单独的队列（自动，因为客户端在编译时不为人所知）并轮流从中提取。

我目前的想法是，我真的只需要使用 vanilla MSMQ，创建一个服务来接受消息并将它们写入一个或多个队列，然后创建一个进程来从队列中读取消息并处理/处理它们。但是，使用 NServicebus 之类的东西获得的可靠性、审计、可扩展性和易于配置看起来非常吸引人。

ESB 是不是适合这项工作的工具？还有其他一些我应该研究的技术或模式吗？

更新

一些澄清。

关于“按顺序”处理消息——在单个客户端的上下文中，消息绝对需要按照接收到的顺序进行处理。解释确切的原因很复杂，但这是一个坚定的要求。我没有提到每个客户端只能同时处理一条消息。因此，即使有 10 个工作线程并且只有一个客户端有消息等待处理，一次也只会处理其中一条消息——不必担心竞争条件。

我相信这通常可以通过 vanilla MSMQ 实现——您可以在队列中拥有一个消息列表，并始终先获取最旧的消息。

我还想澄清一个循环排序的用例。在此示例中，我有两个发送消息的客户端（A 和 B），并且只有一个工作线程。所有队列都是空的。客户端 A 一夜之间失去了连接，因此在上午 8 点向服务发送了 1000 条消息。这些消息排队，工作线程获取最旧的消息并开始处理它。在处理第一条消息时，客户端 B 将消息发送到服务中，该服务排队（如前所述，可能在单独的队列中）。当客户端 A 的第一条消息完成处理后，逻辑应该检查客户端 B 是否有消息（它是客户端 B 的“轮到”），既然找到了，就下一步处理它。

如果客户端 B 在此期间没有发送消息，则工作人员将继续一次处理客户端 A 的消息，始终在处理后检查其他客户端队列是否包含等待消息，以确保没有客户端被饿死。

我仍然觉得 ESB 之间可能存在不匹配，这个问题是 ESB 旨在促进服务之间的通信；我想要实现的是消息/通信和选择性排队系统的组合。

问题 - 可以在同一服务器上部署不同版本的 Mule（比如 Mule 2.0 和 2.2.0）吗？

它们将用于不同的应用程序。

1. 会不会因此而产生冲突？
2. 在这样做之前是否应注意任何先决条件
3. 您是否预见到这方面的任何潜在风险？

谢谢 ：）

我正在使用 MULE ESB 进行项目。

我正在工作的应用程序中的当前场景是

从第一个应用程序中，我们可以直接将 xml 消息发送到 peoplesoft（它充当第二个应用程序），但不能保证在 peoplesoft 端接收到所有消息。

所以我们决定在第一个和第二个应用程序之间使用 MULE。这是一个不错的选择吗？

您能否帮助在架构方面做出更好的选择，以便 peoplesoft 接收所有发送的消息

期待帮助。

谢谢

我有以下问题：我有几个带有本地 ActiveMQ 代理的站点，该代理转发到远程代理（在数据中心中）。这种连接通常不稳定，每月会中断几次，每次几分钟或几小时。

因此，如果此时无法访问远程代理，则消息需要在本地代理上等待。

我有以下 ActiveMQ 配置：

这会将消息从本地代理（主题 MySpecialTopic）转发到远程代理。这在连接稳定时有效。

但是，我尝试暂时禁用 Internet 连接，以使本地代理失去与远程代理的连接。那时我发送了一条新消息，该消息已在本地代理上排队，但从未到达远程代理，即使在本地代理重新连接后也是如此！

我缺少 ActiveMQ 配置中的某些内容吗？

谢谢！

嘿，
如果我们有 Apache Camel，为什么还要使用 Apache ServiceMix 和 Mule 等其他解决方案？
与这些产品相比，Apache Camel 有什么不能做的吗？
何时使用 Mule/ServiceMix 以及何时使用 Camel？

我正处于我们新网站的规划阶段——它是我们构建的一些移动应用程序的扩展。我们希望为我们的用户提供一个交流的中心点，并为不想/不能使用移动应用程序的用户提供功能。我们正在考虑添加的功能之一是本质上类似于 SO 徽章系统的声誉系统。我们正在设计系统以使用 SOA。

我不想将所有这些逻辑编码到主应用程序中作为谨慎的块。我正在考虑创建一种方法来实现这一点，这将使我们能够定义新的阈值和规则来获得声誉并将它们注入某些服务中。到目前为止，我想到的两种方法是：

1. 要查找用户操作中的某些特征并做出响应，这意味着运行的服务可以通过“插入式”奖励定义运行并检查已达到的阈值并做出适当的响应。
2. 在用户执行操作时触发事件 - 监听这些事件并做出适当的响应。因为将执行这些操作的服务可能在不同的服务器上运行在不同的应用程序域中，所以我可以看到有一个中央消息总线来监听和响应这些事件的唯一方法是使用 MassTransit、nServiceBus 或 Rhino.Esb .

我知道使用服务总线很容易被不恰当地设计成根本不需要它的应用程序，而且大多数时候——除非你正在集成不同的异构系统——在设计新系统时你很可能不需要它但我有点迷失了最佳方式的选择。我不喜欢让服务一直在后台敲击 Db 的想法。但它听起来确实在早期可能会简单得多 - 后来 - 我不敢想！

这里有人设计过这样的系统吗？你是怎么做到的？我们正在设计高吞吐量，因为我们预计系统有时需要能够应对用户的激增。

我需要一些能够实现以下功能的软件：
1. 为客户端提供单个端点（从多个服务端点中抽象出来）
2. 保留传入请求的队列
3. 在多台机器上的多个服务端点之间平衡负载
4 . 控制这些端点的可用性
5. 当达到最大 CPS 或最大消息队列大小时，给客户端一些可读错误
6. 根据队列大小和已知服务端点性能给出一些消息处理时间预测

这个东西应该是基于 .NET 和 WCF 友好的。我认为这是负载平衡器和 ESB 的某种混合。能否请您说出此类现有的任何产品（OSS 项目）？