.net中调用esb_微服务架构的应用集成：服务网格并不是 ESB

本文要点

• 在企业级软件开发中，API、服务、数据和系统集成是最具挑战性，同时也是最重要的需求；
• 过去，我们曾经将这些独立的应用以点对点的风格集成在一起，随后这种方式被 ESB(企业服务总线，Enterprise Service Bus)风格所代替，与之同时出现的还有面向服务架构(Service Oriented Architecture，SOA)；
• 随着微服务和“云原生”架构的普及，出现了“服务网格”的概念。服务网格的核心思想是将所有业务逻辑的代码作为服务的一部分，同时将网络通信相关的逻辑放到到服务间通信基础设施之中。
• 因为服务网格提供了一些 ESB 的功能，所以有人将其误解为分布式 ESB，让它也负责应用集成。这是不正确的。
• 服务网格只是用来在服务间进行通信的基础设施，开发人员不应该在服务网格中构建任何业务逻辑。有一些其他的框架和库可以用来实现云原生企业应用的集成模式。

在企业级软件应用开发中，长期以来，API、服务、数据以及系统的集成都是最具挑战性同时也是最基本的需求。

在过去，我们会将这些独立的应用以点对点的方式进行集成，这种方式随后被企业服务总线(enterprise service bus，ESB)和面向服务架构(service-oriented architecture，SOA)所替代。

但是，在现代微服务和云原生架构中，我们很少再去讨论应用集成了。但这并不意味着这种现代架构已经解决了企业应用集成的所有挑战。

应用集成的挑战几乎没有什么变化，但是我们解决它们的方式却发生了变化。

从 ESB 到智能端点和哑管道

大多数采用 SOA 的企业都会使用 ESB 作为中心总线，以连接和集成所有独立的 API、服务、数据和系统。

如果给定的业务场景需要与组织中不同的实体进行通信的话，ESB 的职责就是探测所有的实体并创建组合功能。

因此，通常来讲，ESB 解决方案是所有内置集成功能的动力源，例如到不同系统和 API 的连接器、消息路由、转换、弹性通信、持久性和事务。

图 1：使用 USB 进行集成

但是ÿ