API 网关在微服务中的应用

目录

一、什么是 API 网关/p>

二、微服务架构对 API 网关的需求

三、API 网关在微服务架构中的工作

四、API网关的实现——问题和解决方案

可扩展性和性能

反应式编程模型

服务调用

服务发现

处理部分故障

五、API 组合

六、服务网格（service mesh）和 API 网关

七、API 网关在安全中的作用：身份和访问

消息安全

威胁防护 

日志记录 

白名单和白名单允许的方法

输入验证 

八、API 网关对微服务的好处 

安全优势

监控和分析 

降低微服务复杂性

支持混合通信协议 

避免将内部问题暴露给外部客户

九、微服务 API 网关的缺点 

一、什么是 API 网关/strong>

API 代表应用程序接口，包含用于构建应用程序的工具集。API Gateway 是一个反向代理，它接受所有 API 调用，应用各种服务来完成调用，并返回适当的输出。简单来说，API网关就是一个集成应用程序内部系统架构的服务器。 

API 网关负责为应用程序客户端提供 API、执行请求路由、提供身份验证、负载平衡、监控、组合和协议转换。当客户端发出请求时，请求会传输到 API 网关，然后路由到适当的微服务。 

API网关处理客户端请求的方法共有两种：

• 它将客户端的请求路由到合适的服务。
• 它将客户的请求分散到多个服务。

二、微服务架构对 API 网关的需求

微服务架构可能总共有 10 到 100 个甚至更多的服务，API Gateway 帮助我们合并客户端的入口点，独立于内部微服务的数量。在微服务架构模式中我们需要 API 网关的原因有很多，如下所示：

• API 网关有助于停止将内部问题暴露给外部客户端
• API 网关有助于为您的微服务提供额外的安全性 
• API网关有助于合并通信协议
• API 网关有助于降低微服务的复杂性，最终提高应用程序的效率。
• API 网关帮助分离微服务 API 和其他外部 API，以虚拟化设计需求和测试。

三、API 网关在微服务架构中的工作

假设您正在为应用程序显示产品详细信息的客户构建电子商务移动应用程序。在使用单体架构制作此应用程序时，客户端使用对应用程序的单个 REST 调用来检索数据。当我们使用微服务架构开发相同的应用程序时，每个微服务都会显示针对细粒度端点的指令。 

让我们利用微服务架构。产品详情页面通过多个微服务显示数据，例如，订单服务、购物车服务、评论服务、运输服务等等。在这里，客户端直接调用每个微服务并在可用实例之间分发请求。但是当客户端直接调用微服务时，会面临很多问题，例如客户端调用与 API 不匹配或使用不适合 Web 的协议。API Gateway 可以有效解决这个问题。API 网关融合了应用程序的内部系统，并允许每个客户端适应的 API。 

下图解释了 API 网关如何管理 API 调用并与其他架构组件交互。

API 网关的可扩展性和性能通常是必不可少的。有多种技术用于实现 API 网关的可扩展性和性能。API网关负责路由、计费、监控、速率限制、身份验证、足够的安全性、警报和策略等功能。它有助于拦截来自客户端的传入请求并将它们传递给API管理系统以应用必要的功能并获得输出。  

四、API网关的实现——问题和解决方案

在简单了解了 API 网关的工作原理之后，接下来就是学习 API 网关在微服务中的实现了。下面我们讨论了在实现 API 网关时必须考虑的一些设计问题和解决方案：

• 可扩展性和性能

对于每个应用程序，API 网关的可扩展性和性能是最重要的。因此，在支持异步和非阻塞 I/O 的平台上构建 API 网关是高效的。可以使用不同的技术来实现可扩展的 API 网关。您可以考虑Netty、JBoss Undertow和许多此类基于 NIO 的 JVM 框架。如果您使用的是非 JVM 平台，Node.js是基于 chrome 的 javascript 引擎构建的最佳选择。 

• 反应式编程模型

API 网关通过将请求路由到适当的后端服务来处理请求。另一方面，它还通过调用多个后端服务并结合整体结果来解决一些请求。例如，考虑到电子商务平台，对于产品详细信息请求，对后端服务的请求是相互独立的。 

API 网关应该能够同时处理多个请求，以最小化响应时间。但有时，请求之间存在依赖关系。因此，API 网关通过调用身份验证服务来验证请求，然后将它们路由到后端服务。同样，假设您希望在应用程序中从客户的愿望清单中获取产品的详细信息。在这种情况下，API 网关必须检索客户的个人资料数据以检索产品信息。 

• 服务调用

基于微服务的应用程序是一个分布式系统，应该使用进程间通信方法——它有两种技术。第一种是使用基于异步消息传递的机制。一些通过使用JMS和AMQP等消息代理来实现这一点，而另一些则直接使用无代理和服务通信，就像Zeromq一样。另一种技术是同步机制，如 HTTP 或 Thrift。 

API 网关将支持基于微服务架构的各种通信机制。一个系统可以同时使用异步和同步技术或每种方法的多个实现。 

• 服务发现

API 网关必须知道与之通信的每个微服务的 IP 地址和端口（位置）。在传统架构中，您可能会硬连线位置，但在最新的基于云的微服务应用程序中，这是一个不小的问题。 

消息代理等基础设施服务将包含一个静态位置，可以通过操作系统环境变量指定。然而，识别应用服务的位置并不容易，因为它是动态分配位置的。此外，由于自动扩展和升级，服务实例会动态变化。 

因此，API Gateway 需要使用系统的服务发现机制，即Service-Side Discovery 或Client-Side Discovery，就像任何其他服务客户端系统一样。如果系统选择客户端发现服务，那么 API 网关应该查询服务注册中心，该注册中心包含所有微服务实例及其各自位置的数据库。 

• 处理部分故障

在实现 API Gateway 时您可能面临的另一个挑战是系统的部分故障。当一个服务调用另一个服务不可用或响应缓慢时，所有分布式系统都会出现此问题。API网关从不阻塞无限期等待下游服务。 

处理这个失败最终取决于哪个服务失败和给定的场景。例如，在考虑购物应用时，如果推荐服务在产品详情场景中没有响应，API 网关会将剩余的产品详情返回给用户，因为它们仍然有帮助，推荐可以为空，也可以为更换。另一方面，如果产品详情服务没有响应，API 网关必须向用户返回错误。 

另请注意，API 网关可以返回缓存数据（如果可用）。例如，购物应用程序的产品价格变化不大，因此如果定价服务不可用，API 网关可以返回缓存的价格。API Gateway 可以自己缓存数据，也可以将其存储在外部缓存中，例如Memcached。API 网关通过返回默认数据或缓存数据来确保系统故障不会影响用户体验。 

同样，Netflix Hystrix是编写有助于调用远程服务的代码的最有价值的库之一。Hystrix 实现了一个断路器模式来阻止客户端等待失败的服务响应。它使断路器跳闸，如果服务的错误率超过指定的阈值，最终会立即使所有请求失败。它有助于使超过阈值的调用超时。如果您使用 JVM，建议使用 Hystrix，如果您使用的是非 JVM 环境，则应使用等效库。  

五、API 组合

API 网关通常不仅仅做反向代理，比如在 API 组合的帮助下执行 API 操作。API 网关提供客户端使用 API 组合在应用程序中使用单个 API 请求检索数据。 

下图详细说明了 API 组合的工作原理。假设您创建了一个电子商务应用程序和具有各种服务的客户端，例如订单服务、购物车服务、评论服务、运输服务等等。在这里，客户端发出请求调用以获取订单详细信息，例如订单账单、订单交付、订购的产品信息。传统的 API 请求调用会创建许多 API 调用，用于从后端调用每个服务。 

但同时，使用 API 网关，客户端会进行一次 API 调用，同时 API 网关将使用多次调用的组合调用服务，以提高输出性能。因此，API 网关使移动客户端仅使用单个请求即可检索数据。 

六、服务网格（service mesh）和 API 网关

处理微服务时最常见的问题是服务网格和 API 网关之间的区别，因为 API 网关和服务网格模式之间存在重叠。 

API 网关是架构的核心组件，而服务网格将应用程序的功能划分为由基础设施层进一步处理的微服务。API 网关和服务网格功能包括处理请求路由、速率限制、监控、身份验证等。两者之间的区别在于 API 网关管理从客户端到服务的流量。相反，服务网格包含服务到服务通信的流量。

API网关一般侧重于外部组织资源来管理和控制网络内部的服务。因此，它位于网络和应用程序之间，用于管理从边缘级客户端到服务通信的流量。可以说 API 网关的主要功能是路由外部和内部的 API 调用。 

同时，服务网格专注于将服务暴露给 Web 的内部组织资源。因此，服务网格揭示了使特定业务功能能够管理内部流量服务到服务通信的服务或 API 调用。因此，您可以使用服务网格来升级内部架构系统或微服务的可移植性。 

API 网关彻底确保了安全要求，主要是在服务网格中使用时。尽管如此，服务网格仍然存在一些安全问题，因为它更侧重于加速微服务的交付。 

因此，我们可以说 API 网关是一种成熟的技术，可以在应用程序中构建微服务模式时使用。相比之下，服务网格是一种新兴技术，在当前场景中存在风险。 

七、API 网关在安全中的作用：身份和访问

对于 API 网关技术，访问控制是最好的安全驱动程序之一，它服务于各种组织来管理 API 并设置有关如何处理客户端数据请求的规则。 

API网关的访问控制一般从认证机制开始，识别API请求调用的来源。在当前情况下，您可以使用流行的网关 OAuth 作为 Web 资源的中介，而无需向服务透露密码。在使用基于密钥的身份验证网关时，公司可能会丢失数据，因为维护密钥的身份验证具有挑战性。 

消息安全

使用网关，您可以使用单个通道路由所有 API 事务，以评估和保护整个组织的消息。API 网关的内部服务之间引入了消息安全性，使它们更加安全，并使消息能够在加密的服务之间传递。

如果忽略正确的身份验证，则会在组织中引起严重的安全问题。例如，如果 API 请求是手机号码，您可以获得电子邮件地址和设备标识数据等个人详细信息。因此，强大的身份验证机制（如 OAuth）对于保护组织的行业标准至关重要。 

威胁防护 

如果没有威胁防护，API 网关和服务器本地服务中的 API 从根本上是不安全的。如您所知，API 是与世界进行数字连接的主要来源，但如果有任何恶意用户攻击后端系统，则系统很容易受到攻击。 

攻击者可以注入 SQL 命令，例如 drop、delete 甚至创建可供 API 使用的随机数据。SQL 注入使攻击者能够访问系统数据库、代码和系统目录。攻击者有可能会从数据库中复制所有客户的数据并为他们的利益而使用这些数据。除了这种 SQL 注入之外，还有许多其他形式的注入威胁，例如 RegExInjection 或 XML 注入。 

日志记录 

对于请求调用的不同情况，有一个特定的 HTTP 状态码。例如，大多数开发人员使用 200 表示请求调用成功，使用 404 表示请求调用失败。堆栈跟踪可以威胁恶意用户识别包名称、类名称、版本、服务器名称或 SQL 查询。 

我们可以返回带有 HTTP 状态代码和错误消息的平衡错误对象，以减少这种挑战。重新调整余额错误代码将有助于增强错误处理问题并保护 API 免受攻击者的攻击。 

白名单和白名单允许的方法

API 流量的 IP 地址级别应该有一个熟悉的设备、网络和客户端 IP 地址列表。此列表因网络的大小而异。如您所知，多种方法允许访问给定 URL 以对给定实体执行各种操作。例如，POST 方法将创建一个新实体，而 DELETE 方法将删除该实体。相反，GET 请求将读取实体，而 PUT 方法将更新给定实体。 

因此，服务需要限制动词的数量才能工作，所有其他的都会返回一个响应码。 

输入验证 

黑客发现系统中的漏洞并利用这种松散的输入验证来破坏系统。攻击者将使用现有输入来确定接受的内容并相应地推送请求，直到系统完整性崩溃。 

一些常见的输入验证是

• 消息大小

当您确定不会收到任何大于特定大小的邮件时，最好设置邮件大小限制。它将帮助您过滤掉消息并使系统更有效、更安全。

• JSON 威胁防护 

JSON（JavaScript Object Notation）是内容级攻击的威胁。这些攻击使用 JSON 文件使系统服务崩溃并压倒解析器。 

• SQL 注入

SQL 注入保护使您能够通过阻止可能导致 SQL 注入或任何类似威胁的请求来保护系统。 

• XML 威胁防护

对 XML 应用程序的恶意攻击包括 SQL 注入、XSLT 或递归有效负载以使系统服务崩溃。 

• 速率限制

所有 API 用户的身份验证和所有 API 调用的日志记录使 API 供应商能够限制所有客户端的消耗。API 网关上限允许您检测单个 API 资源进行的 API 调用次数和其他限制，例如按秒、分钟或天计算的消耗。 

一个安全的API网关是怎么样的/span>

今天的分布式应用程序通常涉及部署在本地和云环境中的数千个微服务之间的交互。一般来说，API 网关对请求进行身份验证，检查它们的访问级别和服务质量，并将它们路由到适当的服务。尽管单个服务底层的网络和基础设施可能具有安全机制，但 API 网关是第一道防线。

传统上，安全性由防火墙强制执行的静态访问控制列表 (ACL) 处理。用户通过本地网络或 VPN 获得访问权限。对于当今可以跨越地理和组织边界的应用程序来说，这种方法过于简单。此外，漏洞利用变得更加复杂，远程工作人员正在增加，复杂的攻击（如 DDoS 或 SQL 注入）不依赖于基于端口的访问。

API 安全模型的组件

在高层次上，API 安全模型由三个组件组成：

1. 身份验证：验证 API 请求者的身份
2. 授权：验证并强制执行客户端访问 API 的权限
3. 威胁防御：采取必要措施防御 DDoS 攻击、注入或其他外部威胁

安全的 API 网关架构通过多种联锁技术处理这些要求。技术的具体选择取决于给定场景的集成需求。身份验证和授权控制应用于服务实体并映射到它们所代表的上游服务，这意味着仅针对这些上游服务直接验证身份验证。这启用了非常细粒度的权限控制。

保护 API 网关的最佳实践

让我们考虑几个保护我们的 API 和 API 网关的最佳实践。

使用 HTTPS

您可以采取的保护 API 的首要措施之一是使用 HTTPS 保护所有客户端通信。此外，您可以定期轮换 SSL 证书，并为同一应用程序的不同环境使用单独的 SSL 证书。

限制请求

API 速率限制可防止过多的 API 请求压倒上游服务——这是 DDoS 攻击的典型方案。通过速率限制，API 网关仅在给定时间间隔内接受一定数量的并发客户端请求。节流是一种速率限制形式，可在过载时减少带宽或终止客户端会话。大小限制是 API 网关阻止大于特定大小的客户端请求有效负载的另一个选项。

身份验证和授权

特权内容应始终受到安全 API 身份验证和授权的保护。因为不同的 API 接受不同类型的凭据来授予访问权限，所以 API 网关应该支持这些类型中的大多数，包括：

• 基本认证
• API 密钥认证
• mTLS
• … 和更多。

此外，由于第三方身份提供者的普遍存在，API 网关还应支持与这些提供者一起使用的各种标准协议，包括：

• OpenID 连接
• SAML
• OAuth 2.0
• LDAP

请求验证

另一项安全措施是使用正则表达式检查来验证输入，以在客户端请求中找到可疑条目。当然，API 应该执行自己的安全检查和输入验证。作为最佳实践，开发团队应定期审核和监控 API 代码，确保 API 使用最新的库并遵循编码最佳实践。

监控和分析

监控您的 API 可以让您持续了解每项服务的健康状况，并让您了解您的服务当前面临的潜在威胁或问题。API 网关集中了聚合指标和日志的任务。

API 网关可以集中捕获与请求和流量相关的指标。日志记录还有助于对所有客户端访问请求进行审计跟踪。这些汇总和集中的数据可以一起导出到安全信息和事件管理 (SIEM) 工具，以进行分析、可视化和警报。

配备监控工具的 API 网关可以识别是否以及何时发生攻击、涉及哪些 IP 以及是否使用内部 IP 发起攻击。

利用无服务器功能

云供应商提供的 AWS Lambda 等无服务器功能允许您在其托管和安全的计算环境中运行代码片段。无服务器函数运行代码以响应事件或 HTTP 请求。

一旦函数运行，临时计算基础设施就会被破坏。从安全角度来看，这有效地将任何后端服务器从潜在的攻击中移除。客户端只能访问函数前面的 API 网关。

使用 SIEM 监控 API 安全性

我们已经谈到了保留 API 访问日志的必要性。SIEM 是一种特殊的软件，可以将来自多个来源（如 WAF、防病毒、网络、服务器和 API 网关）的日志聚合到一个位置。它关联并分析这些日志，提供整体安全状况的整体视图。SIEM 工具可以从您的 API 日志中发现异常、威胁和攻击趋势，使其成为安全 API 网关架构的一部分。

此外，安全编排自动化和响应 (SOAR) 是一种新兴的安全技术，它通过针对检测到的异常和威胁自动应用补救步骤，更进一步。SOAR 广泛使用编排和自动化此类安全事件检测和响应的剧本。

零信任模型

零信任使用mTLS进行身份验证。通过验证交易双方的私钥，mTLS 在连接的每一端动态验证客户端的 ID。其单独的 TLS 证书中包含的信息提供了额外的验证。这就像在服务对象级别而不是在服务入口点具有检查点的虚拟护照。

实施零信任模型是服务网格发挥作用的地方。服务网格极大地简化了 API 网关管理。它是控制平面上的专用基础设施层，通过 Sidecar 代理处理服务或微服务之间的通信。

Sidecar 代理在数据平面上运行并加快微服务之间的快速交换。由于数据平面位于服务流量的执行路径上，边车代理提供可观察性、健康检查、路由、安全和负载平衡功能。它们从控制平面进行管理，控制平面聚合配置信息（按服务或其他属性分组），然后将它们作为策略从控制平面（不在执行路径上）推送到数据平面。

原文：What Does a Secure API Gateway Look Like| Kong Inc. https://konghq.com/learning-center/api-gateway/secure-api-gateway

八、API 网关对微服务的好处 

API 网关通过提供灵活性和完全独立的协议来帮助微服务在内部进行通信。它允许开发人员以各种形式创建架构子集，而无需公开暴露端点。API 网关提供以下优势。

• 来源：云上笛暮

  声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！