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

Question

在构建遵循微服务体系结构的整体服务（http://martinfowler.com/articles/microservices.html）时，针对（或要求）使用企业服务总线功能的原因是什么？为什么我们应该使用哑管道和智能端点，而不是使用更智能的管道，并且能够开发更简单的服务？

Answer 1

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

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

NServiceBus特别关注于提供比大多数消息传递库更高级别的框架，以便通过更深入地支持一次性和一次性消息处理来更轻松地构建更可靠的智能端点。

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

Answer 2

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

Answer 3

这是一个巨大的问题，可能无法在SO的Q &格式中有效回答。

这取决于你在做什么。

如果你正在构建一个单独的产品，它包含许多可以被认为是独立的小部分功能，那么微服务可能是一条可行的路。

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

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

说了这么多，在努力成为有用的OP：

如果你看到了Spotify和Netflix的怎么办微服务，你可以找到自己喜欢的方式很多事情，包括但不限于：缓解部署个别服务的蓝/绿部署，解耦团队结构以及隔离失败。

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

这两种方法都有很多价值。目前正在撰写微服务，就像10到15年前的ESB一样。也许这是一种进步，也许这只是一种改变，也许只是消费品公司需要推销自己，大型企业希望保持私密。我们可能会在10年后发现。目前，这很大程度上取决于你在做什么。与编程中的大多数事情一样，我会从简单的开始，如果需要的话，只会转向更复杂的解决方案。

Answer 4

由于服务被隔离并且管道被重新使用。

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

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