微服务体系结构的引入彻底改变了企业应用的查看方式。这些应用不再是提供解决特定领域问题的功能的大型整体或大型服务。相反，我们现在有了小型的微服务，每个微服务都提供一组特定的功能。
这些小型微服务通过网络相互通信，以提供与组织的业务需求相对应的特定输出。
当我们阅读本章时，我们将看到传统的企业应用集成（EAI）方法是如何随着微服务的使用而过时的，微服务引入了新的集成模式，包括，无状态消息代理，而不是大型复杂的企业服务总线。
客户端之间的通信现在已被 API 网关的使用所取代，API 网关在客户端和后端微服务之间提供联合。
作为本章的读者，您将了解以下内容：
- 微服务和 EAI 环境中的变化
- 企业服务总线的变革
- 从微服务体系结构的角度思考 EAI
本章以第 11 章、采用微服务方法和第 15 章、企业应用集成及其模式的内容为基础。因此，理解本章中介绍的内容不需要特殊的硬件或软件，但了解分布式消息代理和异步消息传递系统将有助于在阅读本章时提供更广泛的背景。
最近，组织已经开始转向开发其应用的新方法。当应用由多个小型服务组成时，这种方法侧重于应用的开发，这些服务擅长于提供单一功能，并且能够很好地提供单一功能。这些小型服务称为微服务。
这些微服务为企业域的一个子集的功能建模。例如，基础设施中可能有一项服务负责处理用户凭证和身份验证，另一项服务负责处理电子邮件的功能，还有一项服务负责处理员工的工资支票。
所有这些服务都通过传递消息的机制在网络上通信，或者通过使用服务公开的 API 从一个服务向另一个服务进行 API 调用，以实现特定的用例。
现在，与传统的大型应用不同，传统应用需要中间件来处理数据从一个应用支持的格式到另一个应用支持的格式的转换，然后安全地传输数据，微服务需要一个 API，通过该 API，一个服务可以直接与另一个服务通信，或者需要一个小型消息代理，通过该代理，数据可以以消息的形式从一个微服务传输到另一个微服务。
这改变了过去企业应用集成的方式，因为现在基础架构中没有复杂的中间件解决方案提供粘合层来连接基础架构中的不同应用。
因此，让我们来看看为什么传统的方法在微服务体系结构中不起作用，并试图理解新的替代方案，这些新的选择有助于企业中的应用集成。
在由现代实践开发的应用中，开发小型微服务，在企业基础设施上托管它们，然后将它们集成在一起以相互通信，我们不能再使用在运行和维护大型单片应用或服务时熟悉的传统方法。让我们先花点时间来理解为什么在微服务的情况下点对点集成可能不起作用。
在微服务的点对点集成方法中，我们通过微服务公开的 API 使微服务直接相互交互。要实现这一点，每个微服务都需要了解由另一个服务公开的端点。这很好，但是如果微服务必须执行一些依赖于与其他五个微服务交互的操作，会发生什么呢？
此时，我们必须将五个不同微服务的端点嵌入到我们的微服务中。作为一次性任务，这是一个完全可行的解决方案。但是，关于微服务的性质，它们会随着时间的推移不断发展。这使得我们不断地更新我们的微服务，以反映更新的 API。
这只是挑战之一。通常，基于微服务体系结构的应用会在一段时间内增长，在基础设施中运行的服务超过 100 个，这使得在不同的微服务之间实现点对点集成变得非常困难。
因此，我们现在有了一个想法，即如何通过使用点对点集成来集成微服务，我们可以使用好的旧企业服务总线吗？让我们看一看。
企业服务总线通常提供一个中间总线，通过该总线，两个应用可以通过消息传递机制相互通信。此 ESB 还有一种标准格式，在发送消息之前可以对消息进行编码。
现在，我们可以将微服务挂接到 ESB，然后这些服务可以通过传递消息相互通信。这种方法绝对是好的，而且有效。但随着基础设施中的微服务数量开始增长，真正的问题开始出现。一旦发生这种情况，由于 ESB 传输的消息数量巨大，因此 ESB 开始看到沉重的负载。
ESB 无法扩展的另一个原因。。。
在微服务体系结构中使用 API 网关为解决微服务集成问题提供了一种非常有趣的方法，同时还通过使用联邦网关遵循应用集成模式之一。那么，让我们看看 API 网关在微服务集成过程中是如何帮助我们的。
基于微服务的应用中的 API 网关充当中心点，通过该中心点，微服务可以与基础架构中的其他微服务交互。此 API 网关提供以下特性：
- **API 的受限公开：**API 网关提供只公开来自后端微服务的一组受限 API 的功能，因此限制了公开的功能。除此之外，API 网关还可以在基础设施中引入新的 API 端点，其中每个 API 端点都可以映射到后端微服务的多个 API 端点。
- **联邦访问：**API 网关实现了微服务集成的联邦访问。发生这种情况的原因是，如果任何两个服务想要彼此交互，则需要调用 API 网关，该网关确实会向另一个微服务发出请求，并提供来自微服务的结果。
- **请求转换：**如果两个微服务使用不同的数据表示机制，则 API 网关还负责在它们之间转换请求。为了实现这种转换，API 网关通常实现一种公共数据格式，每个服务都可以使用该格式处理与 API 网关的通信，这一概念通常由 ESB 实现。
对于通过使用 API 网关集成的微服务，不同微服务之间的通信过程如下所示：
- 假设有两个微服务，A和B
- 微服务A想要通知微服务B由于某个呼叫或任何其他外部事件而发生的某个事件
- 微服务A对 API 网关公开的微服务B的端点进行 API 调用
- API 网关接收请求，对请求进行任何形式的转换，并将调用转发给微服务B
- API 网关现在等待微服务B返回响应
- 返回响应后，API 网关将响应转换为 microserviceA支持的格式，并在完成循环后返回响应
其他服务也通常遵循这种过程。
与传统方法相比，使用 API 网关集成微服务具有许多优势，如以下示例所示：
- **提高了安全性：**由于 API 网关限制了暴露的后端 API，因此 API 网关在不同微服务之间提供了更好的安全性。通过在不同微服务和 API 网关之间发生的通信之间实现简单的端到端加密，也可以提高这种安全性。
- **更好的可伸缩性：**API 网关通过使用负载平衡器允许动态伸缩，从而比传统的基于中间件的方法提供更好的可伸缩性。多个 API 网关进程可以在负载平衡器后面运行，最终将请求分发给它们。
- **更容易维护：**与 API 网关集成的应用通常更容易维护，因为它们需要单独管理的 API 端点数量减少了。
这些都是一些巨大的好处，它似乎是集成基于微服务的应用的一种好方法。那么，我们不再需要 ESB 了吗？ESB 走了吗？
答案是否定的。相反，随着微服务的出现，它发生了变化。让我们来看看这个转变是如何看待的。
随着微服务革命的到来，企业服务总线也发生了变化，它现在已被一些类似的解决方案所取代，但具有更好的可扩展性和消除单点故障的优势。
应用集成中的 ESB 过去扮演中心总线的角色，它充当希望彼此通信的应用之间的中介。ESB 通过引入公共数据格式和提供应用可以通过其与 ESB 对话的适配器来促进这种通信。
但 ESB 仍然存在两大缺陷：
- **可伸缩性：**ESB 是一个沉重的中间件，需要专门化才能使用。。。
有了微服务，有了它们自己的工具集和不同的需求，我们现在必须重新思考企业基础架构中的 EAI 方法。因此，让我们看看在考虑基于微服务的基础设施中的应用集成时，我们需要注意的几个要点：
- **扩展规划：**微服务基础架构内的应用不断发展，需要以同样的方式规划它们的集成。在考虑集成策略时，我们需要确保它能够支持我们应用的未来规模和我们应用可能需要的通信类型。
- **定义 API：**微服务公开的 API 在不同应用的集成中起着重要作用。在开始开发微服务之前，应该对其 API 进行良好的规划和记录，以便与其他服务进行更平滑的集成。
- **保持数据格式标准化：**不同微服务管理其数据的数据格式应标准化，只有几组格式，以便于集成并降低基础设施的复杂性。
在本章的过程中，我们了解了微服务作为企业应用开发方法的引入如何彻底改变了企业内部应用集成的方式。
我们看了一下传统的企业应用集成方法在应用于微服务体系结构时是如何失败的，然后我们看了随着 API 网关和分布式消息路由器的引入，EAI 的转换是如何发生的。
在本章结束时，我们将了解随着我们转向基于微服务的方法，企业应用集成的规划是如何变化的。
从这里，我们现在有了关于不同方面的想法。。。
- 微服务应用中点对点集成的瓶颈是什么？
- 随着微服务的出现，企业服务总线发生了怎样的变化？
- 微服务体系结构中的消息代理如何提供高可用性？