Web服务版本控制：是ESB矫枉过正？

我们在生产环境中有多个版本的Web服务（包括REST和SOAP），并且每个版本的编号都越来越大。Web服务版本控制：是ESB矫枉过正？

在版本之间，可能会对请求和响应进行较小的更改（通常是添加新字段）。

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

可能的解决方案的一个方面涉及创建“虚拟端点”，以将对先前版本的请求路由到相同服务的新版本。因此，/ v1/customer/1的请求映射到/ v2/customer/1。我们正在使用Mashery，通过它可以很容易地完成。

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

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

来源

2011-03-29 Nate Reed

如果刀具适合...

如果你正在寻找它要给满足您的版本控制和改造需求，然后继续使用它的ESB。

你不想要的是“哦，这里是我们的ESB在为我们的一个Web服务倾听我们的一个端点”。这简直是疯了。

对我来说，ESB很适合你的需求。你不必检查所有的框。事实上，你需要核对的唯一一个框是“这个工具是值得的资源和时间来学习，利用，支持和部署在我们的环境与我们更舒适的东西”工作箱。

因为像ESB这样的软件存在的一个问题是它们可能带有很多东西，因此很多文档对于平台中的新手来说很难做到，并且选择合适的东西，以及如何配置它。

我会抓住一个ESB并做一个飞行员，然后做一些性能测试。如果你不会在飞行员身上耗费大量时间，而且它看起来似乎运作良好，然后随它一起滚动。

来源

2011-03-29 23:49:44

我喜欢做飞行员的想法。如果运行太困难，那么我可以排除使用该特定框架。应该有足够轻量级来支持我们的用例，但不会阻碍。 – 2011-04-16 13:49:19

有一些像IBM这样的公司专门为您的用例构建软件。他们基本上有一个服务注册服务器。服务注册表充当您所有服务的别名。更重要的是，大多数服务注册表服务器都有一个工作流程，人们可以使用该工作流程来提升，降级，日落，版本，并通知服务的用户某些事情已发生变化。大多数人称之为工作流...治理。

来源

2011-04-14 19:55:42

谢谢。这个答案使我能够实现服务注册的开源ESB。 Apache Synapse带有一个与我上面描述的完全一致的例子。正如另一个人所建议的那样，我可以用它来做一个飞行员。 – 2011-04-16 13:48:26

尝试UltraESB [http://adroitlogic.org]，其中显示了许多关于如何执行路由和转换的示例。您还可以使用基准测试http://esbperformance.org加载测试任何ESB，以了解它们在路由，转换等方面的表现有多快。它是一个小的（〜35MB）ESB，不需要更改代码或具有陡峭的学习曲线 - 在编写时你的路由规则是一些Java行，甚至是Javascript，Ruby，Groovy等 - 无论你知道哪种JSR 223脚本语言。

来源

2011-05-13 05:56:26

对于这个解决方案，ESB可能是矫枉过正的。尽管我们可能会弃用旧版本，并且有新版本，但仍会尝试使用旧版本服务的客户端程序会发生什么情况。

如果我们在新版本的服务中更改了请求/响应格式，那么尝试发送旧请求格式并期望旧响应格式的客户端将会失败。所以我们不能也不应该将旧的服务版本突然离线，但是将其逐步淘汰。为此，我们需要并行运行新旧服务，至少需要一段时间。

因此，引入ESB并不能解决问题。当我们真正退休的旧服务，经过一段时间，允许客户使用旧的迁移到新的，然后我们可以重新指引旧的URL到新的。但是，我们不需要ESB来做到这一点，因为像httpd mod_proxy或nginx这样的简单解决方案可以完成这项工作。

ESB对于在客户端和实际端点之间添加消息中介的增值功能非常有用。因此，无论在哪里有so many performing ESBs，都应该保持它适合这种情况的简单而智能的解决方案。

来源

2013-02-20 15:41:11 Samisa

Web服务版本控制：是ESB矫枉过正？

回答

相关问题