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

10

在构建遵循微服务架构(http://martinfowler.com/articles/microservices.html)的整体服务时,使用企业服务总线功能有哪些反对(或支持)的原因?为什么我们应该使用愚笨的管道和智能端点,而不是使用更聪明的管道并能够开发更简单的服务?

4个回答

7
这是个很大的问题,可能无法在 SO 的问答格式中有效回答。
这取决于你要做什么。如果你正在构建一个由许多小的独立功能组成的单一产品,那么微服务可能是正确的选择。如果你是一个大型企业组织,IT 不是董事会考虑的主要竞争优势,在一个需要应用新标准的行业中工作(这些标准跨越全球分布的项目、拥有自己的 IT 部门,其中一些来自新收购),你不能集中控制组织内的所有端点和应用程序,那么可能需要 ESB。
我不想被指责试图在此列出两种方法的全部优点,因为它们可能不完整且很快就可能过时。
话虽如此,为了对提问者有所帮助:
如果你查阅 Spotify 和 Netflix 如何使用微服务,你会发现他们喜欢这种方法的许多方面,包括但不限于:单个服务的蓝/绿部署容易、解耦的团队结构和隔离故障。
ESB 允许你集中管理和执行策略,如法律要求,在一个地方审计所有内容,而不是希望每个团队都能关注日志记录所有事情,提供有关负载和运行时间的全局统计信息,以及许多其他功能。ESB 起源于大型企业,在那里驱动力不是网站上客户响应时间和创新速度(在其他方面),而是服务级别协议、成本效益和法规(在其他方面)。
两种方法都有很多价值。微服务目前正在被广泛讨论,就像 10-15 年前的 ESB 一样。也许这是一种进步,也许只是一种变化,也许是因为消费品公司需要市场营销,而大型企业喜欢保持细节私密。在接下来的 10 年中,我们可能会发现答案。现在,这主要取决于你要做什么。与编程中的大多数事情一样,我建议从简单的开始,只有在必要时才转向更复杂的解决方案。

5
术语ESB在Java世界中已经变得过于通用,主要指一个复杂庞大的基础设施,最终承载着一堆中心化、实现不佳的逻辑。像Apache Caml或NServiceBus这样轻量级的技术不鼓励这种方法,并且遵循“愚蠢的管道/智能的端点”方法,这一方法从互联网诞生之初就是其支撑骨干。 NServiceBus专注于提供比大多数消息传递库更高级的框架,以便更容易地构建智能端点,通过对消息处理的一次性和仅一次性的深入支持来使其更加可靠。
完全披露 - 我是NServiceBus的创始人。

4
因为服务被隔离,管道被重用。
微服务的核心思想是隔离——系统的任何部分都可以被替换,而不影响其他服务。智能管道意味着它们具有配置、状态和复杂行为(通常意味着难以预测)。因此,智能管道不太可能在时间上保持其精确行为。
但是,管道的更改将影响每个连接的服务,而服务的更改仅会影响使用它的其他服务。

3
ESB 的问题在于其使用方式会在 ESB 中嵌入一些业务逻辑,从而导致 ESB 和服务之间存在耦合。这会使得单个服务独立部署变得更加困难,并且增加了 ESB 的复杂性和维护难度。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接