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