目录
微服务架构中的 API 问题
根据 Gartner 对微服务的定义：“微服务是范围狭窄、封装紧密、松散耦合、可独立部署且可独立伸缩的应用程序组件。”
与将模块高度耦合并部署为一个大的应用程序相比，微服务的目标是将应用程序充分分解或者解耦为松散耦合的许多微服务或者模块，这样做对下面几点有很大帮助：
- 每个微服务都可以独立于应用程序中的同级服务进行部署、升级、扩展、维护和重新启动。
- 通过自治的跨职能团队进行敏捷开发和敏捷部署。
- 运用技术时具备灵活性和可扩展性。
在微服务架构中，我们根据各自的特定需求部署不同的松耦合服务，其中每个服务都有其更细粒度的 API 模型，用以服务于不同的客户端（Web，移动和第三方 API）。
在考虑客户端与每个已部署的微服务直接通信的问题时，应考虑以下挑战：
- 如果微服务向客户端公开了细粒度的 API，则客户端应向每个微服务发出请求。在典型的单页中，可能需要进行多次服务器往返，才能满足请求。对于较差的网络条件下运行的设备（例如：移动设备），这可能会更糟。
- 微服务中存在的多种通信协议（例如：gRpc、thrift、REST、AMQP 等）使客户端很难轻松采用所有这些协议。
- 必须在每个微服务中实现通用网关功能（例如：身份验证、授权、日志记录）。
- 在不中断客户端连接的情况下，很难在微服务中进行更改。例如：在合并或划分微服务时，可能需要重新编写客户端部分代码。
API Gateway
为了解决上述挑战，人们引入了一个附加层，该附加层位于客户端和服务器之间，充当从客户端到服务器的反向代理路由请求。与面向对象设计的模式相似，它为封装底层系统架构的 API 提供了一个单一的入口，称为 API 网关。随着微服务架构概念的提出，APIGW 成为了微服务架构的一个标配组件。
APIGW，顾名思义，是出现在系统边界上的一个面向 API 的、串行集中式的强管控服务，这里的边界是企业 IT 系统的边界，可以理解为企业级应用防火墙，主要起到隔离外部访问与内部系统的作用。APIGW 是系统对外的唯一入口，封装了系统内部架构，为每个客户端提供定制的 API。所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有非业务功能。
简而言之，APIGW 的行为就像 API 管理员一样，但重要的是：不要将 API 管理与 API Gateway 混为一谈。
APIGW 应该支持：
- 路由：动态路由规则，网关封装了底层系统并与客户端分离，为客户端提供了与微服务系统进行通信的单个入口点。
- 安全：IAM 权限认证、鉴权、授权、脱敏，流量清洗，后端签名（保证全链路可信调用），IP 黑白名单（非法调用的限制）。
- 缓存：缓存响应结果。
- 监控：记录请求响应数据，API 耗时分析，性能监控。
- 限流：流量控制，错峰流控，可以定义多种限流规则。
- 高可用：API 高可用，负载均衡，容错机制。
- 服务发现。
- 重试策略、熔断。
- 日志、链路追踪。
APIGW 具有以下优势：
- 易于监控，可在微服务网关收集监控数据并将其推送到外部系统进行分析。
- 易于认证，可在微服务网关上进行认证，然后再将请求转发到后端的微服务，从而无需在每个微服务中进行认证。
- 减少了客户端与各个微服务之间的交互次数。
APIGW 实现的注意事项：
- 可能产生的单点故障或者瓶颈。
- 由于通过 APIGW 进行了额外的网络跳转以及复杂性风险，意味着响应时间增长了。
API 的组合/聚合
APIGW 中的一些 API 请求直接映射到单个服务的 API 上，可以通过将请求路由到相应的微服务来提供服务。但是，在需要从多个微服务获得结果的复杂 API 操作的情况下，可以通过 API 组合/聚合（分散 - 收集机制）来提供服务。在需要同步通信的情况下，如果服务彼此依赖，则必须遵循链式组合模式。组合层必须支持很大一部分的集成功能，例如：转换、编排、弹性和稳定性模式。
根容器的部署必须配备特殊的分发器和聚合器功能（或微服务）。分发者负责分解成细粒度的任务，并将这些任务分发给微服务实例。聚合器负责聚合业务工作流从组合微服务中得出的结果。
具备复杂功能的网关会增大测试和部署的难度。强烈建议大家避免在 API 网关中进行聚合和数据转换。领域专属的功能更应该遵循软件开发实践的定义，在应用程序的代码中完成。Netflix API Gateway Zuul 2 从他们在 Zuul 到原始系统的网关中，删除了许多业务逻辑。
Kong Gateway
Kong Gateway 是一个开源的，轻量级的微服务 APIGW，可提供无与伦比的延迟性能优化和可伸缩性。如果只需要这些基础能力，那么它就是很合适的选项。只需要增加更多节点就可以轻松横向扩展。它以非常低的延迟来支持大量可变的工作负载。
APIGW vs ServiceMesh
微服务中的 Service Mesh 是处理进程间通信的可配置网络基础结构层。这和通常称为 Sidecar（边车）代理或 Sidecar 网关的东西很像。它提供了许多功能，例如：
- 负载均衡
- 服务发现
- 健康检查
- 安全性
从表面上看，APIGW 和 Service Mesh 似乎解决了相同的问题，实际上它们确实解决了相同的问题，但是应用在不同的场景。APIGW 被部署为业务解决方案的一部分，被外部的服务发现，处理纵向的流量（面对外部客户端），但是，Service Mesh 是用来处理横向流量（在不同的微服务之间）。
实现 Service Mesh 可避免在代码中出现一些弹性交互，例如：熔断器、服务发现、健康检查以及服务观察。对于少量的微服务，应考虑使用其他替代方法来进行故障管理，因为 Service Mesh 集成可能代价太大了。但对于大量的微服务，它的收益是显著的。
结合这两种技术可能是确保应用程序正常运行时间和弹性伸缩能力的一种有效方法，同时又可以确保您的应用程序易于使用。将两者视为同样的产品是不对的，最好将两者视为在涉及微服务和 API 的部署中相辅相成的工具。
来源：oschina
链接：https://my.oschina.net/u/4324175/blog/4609981