为什么微服务架构不是基于企业服务总线？

Question

在构建符合微服务架构（http://martinfowler.com/articles/microservices.html）的整体服务时，有哪些理由反对（或使用）企业服务总线的功能？为什么我们应该使用哑管和智能端点，而不是使用更智能的管道，并能够开发更简单的服务？

Answer 1

这是一个很大的问题，可能无法用SO的Q＆amp; A格式有效地回答。

这取决于你在做什么。

如果您正在构建一个由许多小功能组成的单个产品，可以被认为是独立的，那么微服务可能就要走了。

如果您是一个大型企业组织，其中IT不是董事会作为竞争优势的主要考虑因素，而您在严格监管的行业中工作，其中新标准必须应用于具有其自己的IT部门的全球分布式项目有些来自新的收购，您可以集中控制组织内的所有端点和应用程序，那么您可能需要ESB。

我不想被指责试图列出所有这两种方法的优点，因为它们不会完整，可能很快就会过时。

话虽如此，为了对OP有用：

如果你查看Spotify和Netflix如何做微服务，你可以找到他们喜欢的方法，包括但不限于：简化蓝色/绿色部署单个服务，解耦团队结构和隔离故障。

ESB允许您集中管理和实施策略，例如法律要求，在一个地方审核所有内容，而不是希望每个团队都获得有关记录所有内容的备忘录，提供有关负载和正常运行时间的全局统计信息，以及许多其他内容。 ESB来自大型企业，其中驱动程序不是网站上的客户响应时间和创新速度（除其他外），而是服务水平协议，成本效益和法规（以及其他）。

这两种方法都有很多价值。微服务目前正在编写很多，就像10-15年前的ESB一样。也许这是一个进步，也许它只是一个变化，也许只是消费品公司需要自我推销，大企业喜欢将细节保密。我们可能会在另外10年内发现。目前，它在很大程度上取决于你在做什么。与编程中的大多数事情一样，我开始时很简单，只有在需要时才转向更复杂的解决方案。

Answer 2

术语ESB主要在Java世界中已经过载，意味着一个庞大而复杂的基础架构，最终在一个中心位置托管了一堆执行不良的逻辑。

像Apache Caml或NServiceBus这样的轻量级技术不鼓励采用这种方法，而且确实遵循“管道/智能终端”和＃34;从一开始就充当互联网骨干的方法。

NServiceBus专注于提供比大多数消息传递库更高级别的框架，通过更深入支持一次性消息处理，更容易构建更可靠的智能端点。

完全披露 - 我是NServiceBus的创始人。

Answer 3

因为服务是隔离的，管道可以重复使用。

微服务的核心思想是隔离 - 系统的任何部分都可以被替换，而不会影响其他服务。智能管道意味着它们具有配置，它们具有状态，它们具有复杂（通常意味着难以预测）的行为。因此，随着时间的推移，智能管道不太可能保持其准确的行为。

但是 - 管道更改将影响附加的每个服务，而服务更改仅影响使用它的其他服务。

Answer 4

如何使用ESB的问题在于它通过在ESB中内置一些业务逻辑来在ESB和服务之间创建耦合。这将使得单独部署单个服务变得更加困难，并且越来越多地使ESB变得更加复杂和难以维护。