在构建遵循微服务架构 ( http://martinfowler.com/articles/microservices.html ) 的整体服务时，有什么理由反对（或支持）使用企业服务总线的特性？为什么我们应该使用哑管道和智能端点而不是使用更智能的管道并能够开发更简单的服务？
问问题
2657 次
4 回答
7
这是一个很大的问题，可能无法以 SO 的问答形式有效回答。
这取决于你用它做什么。
如果您正在构建一个包含许多可以被认为是独立的小功能的单一产品，那么微服务可能是要走的路。
如果您是一个大型企业组织，其中 IT 不是董事会将其视为竞争优势的主要考虑因素，并且您在一个受到严格监管的行业中工作，在该行业中，必须在拥有自己的 IT 部门的全球分布式项目中应用新标准，其中一些来自新的收购，您无法集中控制组织内的所有端点和应用程序，那么您可能需要 ESB。
我不想被指责试图在这里列出这两种方法的所有优点，因为它们并不完整并且可能很快就过时了。
话虽如此，为了对 OP 有用：
如果你查看 Spotify 和 Netflix 如何做微服务，你会发现他们喜欢这种方法的许多地方，包括但不限于：易于蓝/绿部署单个服务、解耦的团队结构和隔离故障。
ESB 允许您集中管理和执行政策，例如法律要求，在一个地方审核所有内容，而不是希望每个团队都获得有关记录所有内容的备忘录，提供有关负载和正常运行时间的全局统计信息以及许多其他内容。ESB 源于大型企业，其驱动力不是网站上的客户响应时间和创新速度（除其他外），而是服务水平协议、成本效益和法规（除其他外）。
这两种方法都有很多价值。就像 10 到 15 年前的 ESB 一样，目前正在编写大量微服务。也许这是一种进步，也许只是一种变化，也许只是消费品公司需要推销自己，而大企业喜欢将细节保密。再过10年我们可能会发现。目前，这在很大程度上取决于您在做什么。与编程中的大多数事情一样，我会从简单开始，只有在需要时才转向更复杂的解决方案。
于 2015-06-30T15:41:46.180 回答
5
ESB 一词已经被过度使用，主要是在 Java 世界中，它意味着一个庞大而复杂的基础设施，它最终在一个中心位置托管了一堆实现不佳的逻辑。
像 Apache Caml 或 NServiceBus 这样的轻量级技术不鼓励这种方法，并且确实遵循从一开始就充当互联网骨干的“哑管道/智能端点”方法。
NServiceBus特别专注于提供比大多数消息传递库更高级别的框架，通过对一次性消息处理的更深入支持，更容易构建更可靠的智能端点。
全面披露——我是 NServiceBus 的创始人。
于 2014-12-04T14:21:14.437 回答
4
因为服务是隔离的，管道是重用的。
微服务的核心思想是隔离——系统的任何部分都可以被替换而不影响其他服务。智能管道意味着它们有配置、有状态、有复杂（这通常意味着难以预测）的行为。因此，随着时间的推移，智能管道不太可能保持其确切行为。
但是 - 管道更改将影响附加的每个服务，而服务更改仅影响使用它的其他服务。
于 2015-07-17T07:32:13.417 回答
3
如何使用 ESB 的问题在于，它通过将一些业务逻辑内置到 ESB 中来创建 ESB 和服务之间的耦合。这将使独立部署单个服务变得更加困难，并使 ESB 越来越复杂且难以维护。
于 2015-06-28T08:56:22.370 回答