PROSAGA码农传奇-SO业务编排-为什么ESB在微服务架构中被认为是坏的

<div class =“post-text”itemprop =“text”>
  
    我见证了两个ESB在不同公司的推出，在这两种情况下都有相同的崇高目标，只是帮助进行一些监控和身份验证，提供对遗留系统的“更好”访问。在这两种情况下，仅仅1 - 2年，ESB就成为单点故障，变革的瓶颈，并且通常是所有项目的障碍。
  
  
    ESB也是如此
    
      方便
    
     不要使用它们。首先，您只需为要发送到某个系统的消息添加一些特殊路由，然后您就可以快速解决将某些xml消息转换为其他格式的问题，因为您可以。然后，您需要添加更多XSLT或其他任何内容，以便在客户端系统中修复太昂贵的版本更新。等等...
  
  
    不久，你
    
      将
    
     那里有业务逻辑。所有团队都必须与ESB团队协调所有部署，新消息甚至消息格式的更改。它
    的
      将杀死独立
    </强>
     （你的团队的低耦合）。
  
  
    正如您所指出的，微服务架构的目的是启用
    的
      自主运作
    </强>
     不只是为了服务，而是
    的
      对于它的团队也是如此
    </强>
    。这样可以快速更改。理想情况下，这意味着：
  
  <UL>
    <LI>
      避免与其他团队的任何同步点，无论是测试，推出，配置还是操作（即您必须跨职能并进行DevOps等）
    </LI>
    <LI>
      避免与其他服务同步运行时。这意味着无论技术如何都避免同步调用。您应该只进行即发即弃，永远不会请求响应，即使响应在稍后的时间点发生。
    </LI>
    <LI>
      避免与其他团队的依赖关系。这意味着避免代码共享（具有业务逻辑或业务相关对象的代码）
    </LI>
  </UL>
  
    基本上，你应该能够继续操作你的微服务（并推出新版本），即使公司的其他人关闭他们并去度假。
  
  
    当然这是一个“理想化”的场景，但ESB绝对违背了上述所有目标。它是一个同步点，一个运行时和组织上的集中依赖。
  
</DIV>