1. EBS 架构
ESB（企业服务总线）是一种模式，可让集中式软件组件执行后端系统集成（以及数据模型转换、深度连接、路由和请求），并将这些集成和转换作为服务接口提供，以供新应用程序复用。 通常使用专用的集成运行时和工具集来实施 ESB 模式，以确保最佳的生产力。
简单来说 ESB 就是一根管道，用来连接各个服务节点。ESB的存在是为了集成基于不同协议的不同服务，ESB 做了消息的转化、解释以及路由的工作，以此来让不同的服务互联互通。从名称就能知道，它的概念借鉴了计算机组成原理中的通信模型——总线，所有需要和外部系统通信的系统，统统接入ESB，岂不是完美地兼容了现有的互相隔离的异构系统，可以利用现有的系统构建一个全新的松耦合的异构的分布式系统。ESB做了消息的转换解释与路由等工作，让不同的服务互联互通。
传统的ESB的服务调用方式是，每一次服务的调用者要向服务提供者进行服务交互请求时都必须通过中心的ESB来进行路由。 每一次服务交互的路线是：
服务调用者-->ESB（接收服务请求）-->服务提供者（服务处理）-->ESB（服务提供返回结果）-->服务调用者（服务返回）经过服务总线路由过的服务交互，共出现4次网络会话创建和数据传输。传统企业服务总线的架构就暴露出“硬伤”，例如，10台ESB服务器有一台实例出现了问题，无法正常提供服务路由的能力，服务路由压力就落在了剩下的9台ESB服务器上，原本由出问题的那台服务器提供的服务路由职能就分摊到了剩下的9台上，每台的负载水位就超过88%，个别服务器可能更高，在服务器处于高水位运行的时候，出现问题的概率会大增。导致其他服务器也不堪重负而“罢工”。
“雪崩”事故后，故障恢复的时间和成本非常高昂，因为传统的一台一台重启服务器已经不能进行故障的恢复，因为一旦服务启动起来，前端的访问洪流会立即再次压垮启动后的服务器，唯一正确的方式是先切断前端应用对企业服务总线的服务请求，让这10台服务器全部启动后，在开放服务请求，这样才能恢复系统的运行。
1.1. ESB 优点
从理论上讲，集中式 ESB 有可能标准化和大幅简化整个企业中服务的通信及集成。 硬件和软件成本可以共享，只需供应服务器一次，还可以指派单支专家团队（必要时进行培训）来开发和维护集成。
开发人员可使用单个协议与 ESB“对话”，并发出命令来指导服务间的交互，然后交给 ESB 转换这些命令、路由消息并根据需要变换数据以便顺利执行这些命令。 这样，开发人员就不需要将大量时间用于集成，而是将更多的时间用于配置和改进应用程序。 由于能够在不同项目之间复用这些集成，因此可以提高生产力并节省下游成本。
虽然有不少组织成功部署了 ESB，但在许多其他组织中，ESB 被视为 SOA 部署的瓶颈。 更改或增强某个集成通常会干扰到其他集成。 ESB 中间件更新通常会影响现有集成。 由于 ESB 是集中管理的，因此应用程序团队很快就发现需要排队等待集成。 随着集成量的增长，ESB 服务器实现高可用性和灾难恢复的成本变得更高。 作为跨企业项目，ESB 筹集资金较为困难，因而加大了相关技术难题的解决难度。
最终，维护、更新和扩展集中式 ESB 变得十分复杂且代价昂贵，以至于 ESB 经常会造成自身和 SOA 预期可得到的生产力效益迟迟无法实现，从而使期待锐意创新的业务团队感到挫败。
1.2. ESB 与微服务
微服务架构可将单个应用程序的内部结构分解为若干个可独立更改、扩展和管理的小板块。 伴随虚拟化、云计算、敏捷开发实践和 DevOps 的兴起，微服务如雨后春笋般涌现和发展。 在这种背景下，微服务具有以下优势：
- 提高开发人员敏捷性和生产力，具体方法是让开发人员将新技术整合到应用程序中，而无需接触或“追赶”应用程序的其余部分。
- 更简单、更具性价比的可扩展性，具体方法是使任一组件可独立于其他组件进行扩展，以最快的速度响应工作负载需求并以最高效率使用计算资源。
- 更强的灾备能力，因为一个组件的故障并不会影响其他组件，并且每个微服务只需达到自己的可用性要求，而无需让其他组件达到 “最大共同可用性”要求。
微服务带给应用程序设计的同等细分程度也会被带到集成中，并且具有相似的优点。 这就是敏捷集成背后的理念，将 ESB 细分为若干个去中心化的集成组件，这些组件不存在相互依赖关系，并且单个应用程序团队可以拥有并自主管理此类组件。
1.3. ESB 和 SOA
ESB 是 SOA（面向服务的架构）的基本组件，它是二十世纪九十年代后期出现的架构。 SOA 定义了通过服务接口来复用软件组件的方法。 此类接口会使用通用的通信标准，这些标准能够快速合并到新应用程序中，而不必每次都执行深度集成。
SOA 中的每个服务都包含执行整个独立业务功能 （如检查客户信用、计算每月贷款还款额或处理抵押贷款申请）所需的代码和数据集成。 这些服务接口提供松散耦合，这意味着，即使基本或根本不知道如何在底层实施集成，也可以调用这些接口。 将使用 SOAP（简单对象访问协议）/HTTP 或 JSON/HTTP 等标准网络协议公开这些服务，以便发送数据读取或更改请求。 服务的发布方式可以让开发人员快速找到并复用这些服务以组装新应用程序。
此类服务可从头开始构建，但通常是通过将原有记录系统的功能公开为服务接口来创建。 此时便需要使用 ESB。 原有系统和记录系统通常采用旧的协议和专有数据格式，因此需要进行转换和集成才能使用 SOA 网络协议。 ESB 将动态执行这些转换和集成。 可以在不使用 ESB 的情况下实施 SOA，但应用程序所有者必须采用自己独有的方式来公开服务接口，这就需要完成大量的工作（即使接口最终可复用也是如此），并且在将来需要完成大量的维护工作。