Tuo*_*nen 15 architecture soa esb distributed-computing microservices
在微服务架构中,自治业务服务应该直接相互通信.通信可以是同步(编排)或基于事件(编排).API网关可以聚合客户端的API(前端的后端).通过微服务,我们正在寻求两个最终目标
这为更高复杂性的价格提供了持续部署,细粒度扩展,快速技术适应,可重用性,可审计性等等.
但是,强烈建议不要使用ESB(企业服务总线)或其他中间件.微服务和ESB通常被视为竞争对手的解决方案.为什么ESB看起来如此糟糕？只要它仅用作具有一些额外监视和认证层(没有业务逻辑)的冥想通道,在微服务架构中使用它有什么问题？
Rob*_*gam 22
我见证了两个ESB在不同公司的推出,在这两种情况下都有相同的崇高目标,只是帮助进行一些监控和身份验证,提供对遗留系统的"更好"访问.在这两种情况下,仅仅1 - 2年,ESB就成为单点故障,变革的瓶颈,并且通常是所有项目的障碍.
ESB太方便不使用它们.首先,您只需为要发送到某个系统的消息添加一些特殊路由,然后您就可以快速解决将某些xml消息转换为其他格式的问题,因为您可以.然后,您需要添加更多XSLT或其他任何内容,以便在客户端系统中修复太昂贵的版本更新.等等...
不久之后,您将拥有业务逻辑.所有团队都必须与ESB团队协调所有部署,新消息甚至消息格式的更改.它会扼杀你团队的独立性(低耦合).
正如您所指出的,微服务架构的关键是不仅要为服务启用自主操作,还要为其团队启用自主操作.这样可以快速更改.理想情况下,这意味着:
基本上,你应该能够继续操作你的微服务(并推出新版本),即使公司的其他人关闭他们并去度假.
当然这是一个"理想化"的场景,但ESB绝对违背了上述所有目标.它是一个同步点,一个运行时和组织上的集中依赖.