基于微服务架构的云原生ESB解决方案

对于任何希望提高业务价值、探索新机会并在市场上领先于竞争对手的组织而言，数字化转型变得至关重要。 有几种不同的集成方法，遵循不同的架构模式。

面向服务的架构 (SOA) 出现在行业已有十多年了。 由 SOA 支持的企业服务总线 (ESB) 成为最流行的中间件模式，用于解决传统单体应用程序的大部分问题。 然而，当基于云的技术、自动化和基础设施随着越来越多的功能不断发展以构建更具可扩展性、更可靠的应用程序时，ESB 无法保持其作为领先中间件实现的地位。 微服务架构已成为集成的下一个战略举措，它利用云基础设施的全部优势来构建弹性、自动修复、可扩展的解决方案。

如果组织即将开始数字化转型，首要问题之一将是选择实施和架构：它是基于 ESB、基于微服务、混合解决方案还是另一种完全不同的方法。 当您的新集成解决方案有很多可用选项时，值得看看您选择一个特定选项而不是所有其他选项的原因是什么。 上面讨论的每个选项都有优点也有缺点。 让我们看看 ESB 和微服务的主要区别是什么，这将帮助任何人就他们未来的解决方案做出决定。

​

基于 SOA 的 ESB（企业服务总线）

ESB 是一种基于 SOA 的中间件架构，基于服务提供者、服务消费者和事件流。 服务提供者生成事件并发布到称为企业服务总线的事件总线。 服务消费者消费他们感兴趣的事件。ESB 支持同步和异步事件流。

ESB 带有许多不同的特性，当消息通过它时。它包括消息转换、协议转换、服务编排和负载丰富。这些特性在来自不同供应商的所有 ESB 实现中都很容易获得。它有助于解决方案与企业内不同类型的系统集成。

企业在构建集成解决方案时，仅使用 ESB 并不能满足需求范围内的所有中间件需求。通常还需要引入以下中间件功能：

• API 管理——以适当的安全性和 QoS 将内部资源暴露给外部世界
• 消息队列——建立与外部系统的异步通信。
• 业务流程管理——在某些验证中让人员或设备参与消息流。
• 身份和访问管理 - 管理解决方案内的访问。
• 监控和警报——识别运行时问题并迅速采取行动。

下图显示了如何通过 ESB 连接不同的系统。

​

SOA 架构的优点

ESB 在服务集成方面有几个好处。

• 技术独立性：ESB支持HTTP/S、AMQP、MQTT等不同类型的传输协议，使得对外服务的技术不再是问题。任何基于任何技术构建的服务都可以集成，只要它可以使用 ESB 支持的上述协议之一进行通信。
• 服务可重用性：一旦服务通过 ESB 作为虚拟服务公开，这些服务就可以被任何其他服务使用，而不受网络和技术的限制。新的集成需要最少的努力才能添加到解决方案中。
• 集中治理和监控：ESB 具有所有服务的可追溯性，因此它可以成为治理服务使用和监控统计数据的中心点。如果服务通过点对点连接进行连接，则应在每个连接处进行监控。
• 可维护性：端服务之间不存在紧耦合，可以独立更新，不影响其他服务。此外，可以在 ESB 层应用不同类型的控制，而不是更新实际服务。
• 容错：服务故障和恢复过程可以在ESB处理，终端服务不受影响。例如，如果服务失败，ESB 可以将消息路由到其故障转移服务端点，直到原始服务恢复运行。
• 部署并不复杂：ESB 有一个简单的部署方法，它将包含所有内置的服务路由和编排功能。不同的供应商可能有不同类型的部署模式，但最终不会太复杂而无法处理。

​

SOA 架构的缺点

• 添加往返延迟：ESB 层将在服务流中添加额外的步骤并对响应时间添加轻微的延迟。因此，性能可能与通过点对点连接直接访问单个服务不同。然而，这是在增加的轻微延迟与

  ESB 提供的许多其他优势之间的折衷。

• 连接要求：所有服务都需要连接到 ESB 以促进服务调用，这将产生额外的成本来设置 VPN 和其他基础设施。

• 单点故障：将所有服务路由到一个地方，就会有单点故障的风险。这可以通过正确的故障转移（客户端或后端故障转移）和最新托管平台的自动修复功能来避免。许多 ESB 供应商支持复杂的高可用性部署模式来避免这些故障。

• 可扩展性的复杂性：即使只需要扩展单个服务，也没有这种方法可以独立增加该服务的容量。相反，它还需要使用所有其他服务来扩展整个 ESB。这将是一种资源和成本的浪费。

​

基于微服务架构的 ESB

微服务架构可将单个应用程序的内部结构分解为若干个可独立更改、扩展和管理的小板块。 伴随虚拟化、云计算、敏捷开发实践和 DevOps 的兴起，微服务如雨后春笋般涌现和发展。 在这种背景下，微服务具有以下优势：

• 提高开发人员敏捷性和生产力，具体方法是让开发人员将新技术整合到应用程序中，而无需接触或“追赶”应用程序的其余部分。
• 更简单、更具性价比的可扩展性，具体方法是使任一组件可独立于其他组件进行扩展，以最快的速度响应工作负载需求并以最高效率使用计算资源。
• 更强的灾备能力，因为一个组件的故障并不会影响其他组件，并且每个微服务只需达到自己的可用性要求，而无需让其他组件达到 “最大共同可用性”要求。

微服务带给应用程序设计的同等细分程度也会被带到集成中，并且具有相似的优点。 这就是敏捷集成背后的理念，将 ESB 细分为若干个去中心化的集成组件，这些组件不存在相互依赖关系，并且单个应用程序团队可以拥有并自主管理此类组件。

与面向服务（SOA）的架构相比，微服务架构 (MSA) 在今天更受欢迎。凭借最新的云技术和平台提供的许多迷人功能，可以说部署在高度可扩展、可靠的云平台中的微服务比 SOA 中的 ESB 提供更多价值。每个微服务都有自己的业务功能。因此，相比传统 ESB，微服务具有更细粒度的控制和更高的可扩展性。

以下特征在典型的微服务中可用。

• 它具有独特的业务功能范围。如果您需要获得整合的功能，那么可以选择集成少量微服务并构建一个复合微服务。
• 每个微服务都可以有自己的数据库。不鼓励使用集中式数据库，并且不会提供细粒度控制的价值。
• 微服务是非常松散耦合的。核心微服务中彼此之间没有直接通信。
• 每个微服务都有自己的运行时，主要运行在自己的容器上。
• 它具有非常短的启动时间，可在发生故障时提供高可用性以及扩展能力。
• 微服务可以在不影响整个系统的情况下独立开发、部署和扩展。
• 微服务部署会很复杂，周围有很多通信。因此，必须有 CI/CD 到位。
• 微服务部署的成功取决于微服务之间的通信，因此需要高度稳定的基础设施。

下图展示了微服务如何在一个解决方案中分层次放置，以方便管理和通信。

​

微服务的优势

• 高度可扩展：自包含服务可以根据业务功能的特定要求独立于其他服务进行扩展。
• 技术独立性：只要各个服务之间能够建立通信，就可以使用不同的技术构建微服务并部署在不同的平台上。因此，随着组织中可用的技能，开发将更加灵活。最重要的是，可以根据性能要求选择实现技术。例如，可以使用轻量级、性能友好的技术构建高性能实时应用程序，而可以使用具有缓存和数据流功能的技术构建批量数据处理服务。
• 服务弹性：微服务的设计原则是最早出现错误，有助于触发故障转移并在短时间内恢复。避免因单一业务故障导致整个回声系统故障。断路器和超时等架构模式将有助于实现这一要求。
• 支持跨团队敏捷开发：每个微服务可以由不同的团队开发和部署，因此业务不需要等到所有团队都完成工作才能在生产中看到结果。
• 更快上线：微服务开发将涉及全面的 CI/CD 实施，因此可以并行计划和执行发布，而无需相互依赖。它将为企业带来更快的上市战略。