我们有多个版本的 Web 服务（REST 和 SOAP）正在生产中，而且随着每个版本的发布，这个数字都会越来越大。
在版本之间，请求和响应可能会有细微的变化（通常是添加新字段）。
如果我们要淘汰旧版本，我们如何继续为旧版本的请求提供服务？
可能的解决方案的一个方面涉及创建“虚拟端点”以将先前版本的请求路由到相同服务的新版本。因此，对 /v1/customer/1 的请求映射到 /v2/customer/1。我们正在使用 Mashery，通过它可以轻松完成。
我们还希望对请求和响应应用转换规则，以生成符合旧合同的 XML 和 JSON 响应。
总而言之，我们需要将路由和转换规则应用于所有传入消息和响应。 ESB 是否过大？我们的标准不太符合http://blogs.mulesoft.org/to-esb-or-not-to-esb/ 中列出的标准。这个问题有更简单的解决方案吗？不需要修改我们的代码来实现请求和响应的版本控制？
【问题讨论】：
标签： service transformation esb
如果工具适合...
如果您正在研究的 ESB 能够满足您的版本控制和转换需求，那么请继续使用它。
您不想要的是“哦，这是我们的 ESB 为我们的一个 Web 服务监听我们的一个端点”。这简直是疯了。
在我看来，ESB 可能很适合您的需求。您不必勾选所有复选框。事实上，您需要勾选的唯一框是“这个工具是否值得在我们的环境中学习、利用、支持和部署这个工具，而不是使用我们更熟悉的东西”框。
因为像 ESB 这样的软件的一个问题是，它们可以附带很多东西，因此平台中的新手可能难以浏览并选择合适的内容以及如何配置的大量文档它。
我会使用 ESB 并进行试验，然后进行一些性能测试。如果您没有在飞行员身上花费大量时间，而且它似乎成功了，那就继续努力吧。
【讨论】：
有些公司（例如 IBM）专门为您的用例构建软件。他们基本上有一个服务注册服务器。服务注册表充当所有服务的别名。更重要的是，大多数服务注册服务器都有一个工作流，人们使用它来提升、降级、取消、版本、通知用户服务发生了变化。大多数人将工作流程称为...治理。
【讨论】：
试试 UltraESB [http://adroitlogic.org]，它展示了许多关于如何执行路由和转换的示例。您还可以使用http://esbperformance.org 的基准测试对任何 ESB 进行负载测试，以查看它们在路由、转换等方面的执行速度。它是一个小型 (~35MB) ESB，不需要更改代码或具有陡峭的学习曲线 - 如您将路由规则编写为几行 Java 行，甚至是 Javascript、Ruby、Groovy 等——无论您知道什么 JSR 223 脚本语言。
【讨论】：
对于这个解决方案，ESB 可能是多余的。尽管我们可能会弃用旧版本并拥有新版本，但仍寻求使用旧版本服务的客户端程序会发生什么。
如果我们在新版本的服务中更改了请求/响应格式，那么尝试发送旧请求格式并期望旧响应格式的客户端将会失败。所以我们不能也不应该让旧的服务版本突然下线，而是逐步淘汰。为此，我们需要至少在一段时间内并行运行新旧服务。
因此，引入 ESB 并不能解决问题。当我们真正停用旧服务时，在允许使用旧服务的客户端迁移到新服务一段时间后，我们可以将旧 URL 重定向到新服务。但是，我们不需要 ESB 来执行此操作，因为像 httpd mod_proxy 或 nginx 这样的简单解决方案可以完成这项工作。
ESB 对于客户端和实际端点之间的消息中介增值非常有用。因此，无论有没有so many performing ESBs，您都应该将其保留为针对这种情况的简单而智能的解决方案。
【讨论】：