Web服务版本控制：ESB是否过度？

Question

我们的生产环境中有多个版本的Web服务（包括REST和SOAP），每次发布版本数量都会增加。

在不同版本之间，请求和响应可能会有一些细微的变化（通常是新字段的添加）。

如果我们要淘汰旧版本，如何继续为旧版本提供服务？

其中一个解决方案的方面涉及创建“虚拟端点”，将旧版本的请求路由到相同服务的新版本。因此，对于/v1/customer/1的请求映射到/v2/customer/1。我们使用Mashery可以轻松完成此操作。

我们还想对请求和响应应用转换规则，以生成符合旧合同的XML和JSON响应。

总之，我们需要将路由和转换规则应用于所有传入消息和响应。ESB是否过度？我们的标准不完全符合http://blogs.mulesoft.org/to-esb-or-not-to-esb/中概述的标准。是否有更简单的解决方案？不需要修改我们的代码来实现请求和响应的版本控制吗？

- Nate Reed

Answer 1

如果这个ESB可以满足您的版本管理和转换需求，那就请使用它。

但您不应该仅仅为了监听一个Web服务端点而使用ESB。那样做是不明智的。

ESB可能非常适合您的需求，您并不需要全部都符合。实际上，您只需要考虑一个问题：“这个工具是否值得我们花费资源和时间去学习、利用、支持和部署于我们的环境中，而不是使用我们更熟悉的工具。”

因为像ESB这样的软件可能会带来很多东西，因此对于平台新手来说可能需要浏览大量文档，以找到合适的内容并进行配置。

我的建议是先试用ESB，并进行一些性能测试。如果试用过程中不花费太多时间，而且看起来可以胜任，那么就可以继续使用它。

- Will Hartung

---

我喜欢做试点的想法。如果启动过程太困难，我可以排除使用特定的框架。应该有足够轻巧的东西来支持我们的用例而不会阻碍进展。 - Nate Reed

Answer 2

有一些像IBM这样的公司，专门为您的用例构建软件。他们基本上拥有一个服务注册服务器。服务注册表充当您所有服务的别名。更重要的是，大多数服务注册服务器都有人们用来推广、降级、停用、版本化以及通知用户服务发生变化的工作流程。大多数人称这个工作流程为治理。

- Albert T. Wong

---

谢谢。这个回答让我了解到开源ESB实现服务注册表的方法。Apache Synapse附带一个示例，正好能够满足我上面描述的需求。就像另一个人建议的那样，我可能会使用它来进行试点测试。 - Nate Reed

Answer 3

尝试使用UltraESB [http://adroitlogic.org]，它展示了许多关于如何执行路由和转换的示例。您还可以使用http://esbperformance.org上的基准测试来对任何ESB进行负载测试，以查看它们在路由、转换等方面的性能如何。这是一个小巧的（~35MB）ESB，不需要代码更改或具有陡峭的学习曲线 - 您可以将您的路由规则编写为几行Java代码，甚至是Javascript、Ruby、Groovy等任何JSR 223脚本语言。

- Asankha

Answer 4

ESB 可能对这个解决方案过度了。虽然我们可能会弃用旧版本并有新版本，但仍在寻求使用旧版本服务的客户端程序会发生什么。

如果我们在新版本的服务中更改了请求/响应格式，则试图发送旧请求格式并期望旧响应格式的客户端将失败。因此，我们不能突然下线旧服务版本，而是逐步淘汰它。为此，我们需要同时运行旧版和新版服务，至少一段时间。

因此，引入 ESB 将无法解决问题。当我们实际上退役旧服务，并允许使用旧服务的客户端迁移到新服务后，我们可以将旧 URL 重定向到新服务。但是，我们不需要 ESB 来完成这项工作，因为像 httpd mod_proxy 或 nginx 这样的简单解决方案可以胜任。

ESB 真正有用的是在客户端和实际终端点之间添加价值的消息转换。因此，无论有多少 性能出色的 ESB 存在，您都应该为此案例保持简单而智能的解决方案。

- Samisa