微服务设计之API网关

Posted 2021-08-10 Go语言搬运工

Garter定义：微服务是高内聚、强封装、松耦合，可独立部署独立扩展的应用组件。

单体架构模块间强耦合并且整体部署，与之对比的微服务其目标是将应用拆分成松耦合的小型服务。这么做的优势有：

• 应用中的每个微服务都可以独立部署、升级、扩展、维护和重启。

• 团队之间可以灵活开发&部署

• 可灵活选择技术栈
  不同的松耦合服务可根据自身需求来部署，每个服务都有其细粒度的api模型来服务不同的客户端（web、手机和第三方APIs）

客户端与微服务间的连接

微服务间通信

考虑客户端直接与每个部署的微服务进行通信时，应考虑以下挑战:
1、在微服务向客户端公开内部API的情况下，客户端需要请求每个微服务。在一个典型的单页面中，为了满足请求，可能需要通过网络请求多个微服务。对于移动设备低带宽网络操作设备来说，情况可能更糟。
2、微服务通信协议多样（例如gRPC、thrift、REST、AMQP等等）客户端适配所有这些协议会导致客户端复杂笨重。
3、每个微服务都需要实现通用网关功能（例如认证、权限控制和日志）
4、要在不影响客户端连接的情况下更改微服务是很困难的。例如对微服务拆分或者合并时，要求客户端也要修改。

API网关

要解决上面这些挑战，在客户端和服务之间引入一个额外层，作为从客户端向服务发起请求路由的反向代理。类似面向对象设计中的外观模式，为封装底层系统架构的API提供了一个单一入口，称为API网关。

简而言之，它的行为与API管理完全相同，但重要的是不要将API管理与API网关混淆。

微服务API网关

API网关功能

路由

通过封装底层系统并与客户端解耦，网关为客户端提供了与微服务系统通信的单一入口点。

负载转移

API网关巩固了边缘功能，而不是让每个微服务都实现它们。这些边缘功能包括:

• 认证和授权

• 服务发现

• 重试策略、断路器和QoS

• 限流

• 负载均衡

• 日志，跟踪、相关性

• 请求header、查询字符串和声明的转换

• IP白名单

• IAM身份和访问管理

• 集中日志(跨服务器的事务ID、错误日志记录)

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

BFF模式（Backend For Frontend）

它是API网关模式的一种变体。它不是客户端的唯一入口点，而是基于客户端提供多个网关。其目的是根据客户端的需求提供定制的API，消除为所有客户端创建通用API所导致的不必要负担。

BFF模式

你需要多少个BFFs？

BFF的基本概念是为每个用户体验开发合适的后端。Phil Calcado的建议是“一种体验，一个BFF”。如果不同客户端(例如ios客户端，android客户端，web浏览器等)的需求差异很大，并且单个代理或API的发布时间出现问题，那么BFFs是一个很好的解决方案。还应该注意的是，越复杂的设计需要越复杂的设置。

GraphQL和BFF

GraphQL是一种API查询语言。Phil Calcado 在这篇文章中介绍BFF和GraphQL有相关性并非对立的概念。他补充道BFFs不侧重API端点的样子， 而是关于给您的客户端应用程序自主权，以尽可能多的BFFs或OSFA(通用的)API来构建GraphQL。

典型的API网关

Netflix API网关：Zuul

Netflix的流媒体服务可服务于1000多种不同的设备(电视、机顶盒、智能手机、游戏系统、平板电脑等)，在高峰时段每秒处理超过50,000个请求，发现OSFA(一刀切)REST API方法的巨大局限性，并使用了为每台设备量身定制的API网关。

Netflix的Zuul2是所有进入Netflix云基础设施请求的大门。Zuul2显著改进了架构和功能，使我们的网关能够处理、路由和保护Netflix的云系统，并帮助1.25亿用户提供最好的体验。

Netflix云架构中Zuul

亚马逊API网关

AWS提供完全托管的服务，用于创建、发布、维护、监控和保护REST、HTTP和WebSocket，开发人员可以在这些服务中创建访问AWS或其他web服务的API，以及访问存储在AWS云中的数据。

AWS API网关

kong API网关

Kong Gateway是为微服务进行了优化的一个开源轻量级API网关，提供了无与伦比的延迟性能和可伸缩性。如果你只是想要基本功能，kong API网关是一个合适的选择。通过添加更多的节点，它可以很容易地进行水平扩展。支持大的和可变的工作负载，并且延迟非常低。

kong API网关

其他API网关

• Apigee API Gateway

• MuleSoft

• Tyk.io

• Akana

• SwaggerHub

• Azure API Gateway

• Express API Gateway

• Karken D

选择合适的API网关

评估API网关的一些常见标准包括简单性、开源vs专有、可伸缩性和灵活性、安全性、特性、社区、管理(支持监控和部署)、环境配置(安装、配置、提供托管)、定价和文档。

API聚合

在API网关中将一些API请求直接映射到后端服务API。然而，一些复杂的API操作可能需要多个服务的结果组合之后才返回给客户端。在服务互相依赖并且需要同步通信的情况下，必须遵循链式组合模式。聚合层必须支持很大一部分ESB/集成功能，如转换、编排、弹性和稳定性模式。

API网关和聚合

添加了太多新特性的API网关会导致网关过于臃肿，使得设计难以测试和部署。强烈建议避免在API Gateway中进行聚合和数据转换。遵循软件开发实践，在应用程序代码中更适合使用领域智能。Netflix Zuul2删除了原有的很多业务逻辑。

分层微服务中的组合

Service Mesh和API网关

微服务中的服务网格是处理进程间通信的可配置网络基础设施层。这类似于通常被称为边车代理或边车（sidecar）网关。它提供了许多功能，如:

• 负载均衡

• 服务发现

• 健康检查

• 安全
  从表面上看，API网关和服务网格似乎解决了相同的问题，因此有点冗余。它们在不同的背景下解决了相同的问题。API网关作为业务解决方案的一部分部署，可以处理南北流量。然而，服务网格处理东西流量(在不同的微服务之间)。

实现服务网格避免了弹性通信模式，如断路器、服务发现、运行状况检查、服务可观察性等。对于少量的微服务，应该考虑故障管理的可替代方案，因为服务网格可能比较复杂。对于更多数量的微服务，这将是有益的。

结合这两种技术可以确保应用程序长时间正常运行和弹性扩展，同时确保应用程序易于使用。两种技术在微服务部署中相互补充，它们同时涉及微服务和API。

微服务使用服务网格

API网关实现的注意事项:

• 可能的单点故障或瓶颈。

• 增加响应时间，由于通过API网关增加额外的网络跳转，以及复杂性风险。

参加资料:

1. https://microservices.io/index.html

2. https://docs.microsoft.com/en-us/azure/architecture/

3. https://github.com/wso2/reference-architecture/blob/master/api-driven-microservice-architecture.md

4. https://tsh.io/blog/design-patterns-in-microservices-api-gateway-bff-and-more/

5. https://www.infoq.com/articles/service-mesh-ultimate-guide/

6. https://samnewman.io/patterns/architectural/bff/

7. https://netflixtechblog.com/