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

Question

在构建遵循微服务体系结构(http://martinfowler.com/articles/microservices.html)的总体服务时，有什么理由反对(或反对)使用企业服务总线的功能？为什么我们应该使用哑巴管道和智能端点，而不是使用更智能的管道，并能够开发更简单的服务？

Answer 1

这是一个很大的问题，可能无法在SO的问答形式中得到有效的回答。

这取决于你在用它做什么。

如果你正在构建一个由许多可以被认为是独立的小功能片段组成的单一产品，那么微服务可能是可行的。

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

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

话虽如此，为了对操作人员有所帮助：

如果你查看Spotify和Netflix做微服务的方式，你会发现他们喜欢这种方法的许多方面，包括但不限于:单个服务的蓝/绿部署的简易性，解耦的团队结构，以及故障隔离。

ESB允许您集中管理和执行策略，如法律要求，在一个地方审计所有内容，而不是希望每个团队都能获得关于记录所有内容的备忘录，提供有关负载和正常运行时间的全局统计数据，以及许多其他内容。ESB从大型企业发展而来，这些企业的驱动因素不是网站上的客户响应时间和创新速度(以及其他因素)，而是服务水平协议、成本效益和法规(以及其他因素)。

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

Answer 2

ESB这个术语已经超载了，主要是在Java世界中，意思是一块庞大而复杂的基础设施，最终在一个中心位置托管了一堆实现不佳的逻辑。

像Apache Caml或NServiceBus这样的轻量级技术并不鼓励这种方法，实际上遵循的是从一开始就作为互联网骨干的“哑巴管道/智能端点”方法。

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

完全公开--我是NServiceBus的创始人。

Answer 3

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

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

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