在微服务体系结构中，不同的松散耦合服务根据各自的具体需求进行部署，每个服务都有一个更细粒度的api模型来服务不同的客户端(web、移动性和第三方api)。今天，我们主要关注微服务中的api网关，并深入讨论为什么需要api网关、它们的功能以及相关的设计模式。

        API网关的起源

        API网关是客户机和服务器之间的附加层，充当从客户端到服务器的反向代理路由请求。类似于面向对象的设计模式，它为API提供了一个单一的入口点，封装了底层的系统架构。显然，它是为了解决客户端与每个部署的微服务之间直接通信的挑战而出现的：

        如果微服务向客户端公开了一个细粒度的api，客户端应该向每个微服务提出请求。在一个典型的单个页面中，可能需要多个服务器往返来满足请求。对于网络条件较差的设备(例如移动设备)来说，这可能会更糟。

        微服务中各种通信协议的存在，如GRPC、节俭、REST、AMQP等，使得客户很难轻易地采用所有这些协议。

        通用网关功能(如身份验证、授权、日志记录)必须在每个微服务中实现。

        要在不中断客户端连接的情况下对微服务进行更改是很困难的。例如，在合并或分割微服务时，可能需要重写一些客户端代码。

        简而言之，API网关的行为就像API管理员，但重要的是不要将API管理与APIGateway混为一谈。

        API网关的功能

        路线

        网关封装底层系统并将其与客户端分离，为客户端提供一个与微服务系统通信的单一入口点。

        API网关的集成集成了一些边缘重复，而不需要每个微服务来实现它们。它包括以下功能：

        认证和授权

        服务发现集成

        缓存响应结果

        重试策略，保险丝，QoS

        限速节流

        负载平衡

        日志记录、链接跟踪、关联

        标题、查询字符串和声明转义

        IP白名单

        IAM

        集中日志管理(服务、错误日志等之间的事务ID)

        身份提供者、身份验证和授权

        后端服务前端模式(BFFBackendforFron趋向)

        它是API网关模式的一个变体。它提供基于客户端的多个网关，而不是为客户提供一个单一的入口点。目的是根据客户的需要提供自定义API，从而消除为所有客户创建通用API的浪费。

        BFF的基本概念是为每个用户体验开发一个利基后端。PhilCalzado(PhilCalado)的指导是"一个体验，一个BFF。"如果客户(iOS客户端、Android客户端、Web浏览器等)的需求差异很大，并且严格要求单个代理或API的发布时间，那么BFF是一个很好的解决方案。还应该指出，更复杂的设计需要复杂的步骤。

        GraphQL是API的一种查询语言。PhilCalado关于BFF和GraphQL的想法相似，但并不相互排斥。他补充说，BFF与您的端口形状无关，而是给予客户相对于应用程序的自主权，在应用程序中，您可以使用许多BFF或OSFA构建GraphQLAPI(一刀切)。

        最后，下面是由API网关实现的一些提示：在此过程中，可能存在一个单一的故障点或瓶颈，响应时间由于通过API网关而增加的网络跳变和复杂性风险而增加。