接上一部分「第二部:容器和微服务架构](9) API网关模式与客户端直接通信
API网关模式的主要特性
一个API网关可以提供多种功能。根据产品，它可能提供更丰富或更简单的特性，但是，任何API网关最重要和最基本的特点是以下设计模式：
- 反向代理或网关路由。API网关提供一个反向代理，用于将请求（第7层路由，通常是HTTP请求）重定向或路由到内部微服务的端点。网关为客户端应用程序提供一个端点或URL，然后在内部将请求映射到一组内部微服务。此路由功能有助于将客户端应用程序与微服务分离，但通过将API网关置于单片API和客户端应用程序之间，使单片API现代化时也非常方便，然后，您可以添加新的API作为新的微服务，同时仍然使用传统的单片API，直到将来将其拆分为许多微服务。由于API网关，客户端应用不会注意到所使用的API是作为内部微服务还是单片API实现的，更重要的是，在将单片API演化和重构为微服务时，由于API网关路由，客户端应用不会受到任何URI更改的影响。
有关详细信息，请参阅网关路由模式。
- 请求聚合。作为网关模式的一部分，您可以将针对多个内部微服务的多个客户端请求（通常是HTTP请求）聚合为一个客户端请求。当客户端页面/屏幕需要来自多个微服务的信息时，此模式特别方便。使用这种方法，客户端应用程序向API网关发送一个请求，API网关向内部微服务发送多个请求，然后聚合结果并将所有内容发送回客户端应用程序。这种设计模式的主要好处和目标是减少客户端应用程序和后端API之间的聊天，这对于微服务所在的数据中心之外的远程应用程序尤其重要，如移动应用程序或来自SPA应用程序的请求（来自客户端远程浏览器中的Javascript）。对于在服务器环境中执行请求的常规web应用程序（如ASP.NET核心MVC web应用程序），此模式并不重要，因为延迟比远程客户端应用程序小得多。
根据您使用的API网关产品，它可能能够执行此聚合。但是，在许多情况下，在API网关的作用域下创建聚合 微服务更为灵活，因此可以在代码（即C#代码）中定义聚合：
有关更多信息，请参阅网关聚合模式。
- 交叉问题或网关卸载。根据每个API网关产品提供的功能，您可以将功能从单个微服务卸载到网关，从而通过将横切关注点整合到一个层来简化每个微服务的实现。这对于在每个内部微服务中正确实现复杂的专用功能（如以下功能）尤其方便：
- 认证和授权
- 服务发现集成
- 响应缓存
- 重试策略、断路器和QoS
- 速率限制和节流
- 负载平衡
- 记录、跟踪、关联
- 头、查询字符串和声明转换
- IP白名单
有关更多信息，请参阅网关卸载模式。
使用具有API网关功能的产品
根据每个实现，API网关产品可以提供更多的交叉关注点。我们将在这里探索：
- Azure API Management
- Ocelot
-
Azure API管理
- Azure API管理（如图14所示）不仅解决了API网关的需求，还提供了一些功能，比如从API中收集见解。如果您使用的是API管理解决方案，那么API网关只是该完整API管理解决方案中的一个组件。
图14 为你的API网关使用Azure API管理- Azure API Management解决了你的API网关和管理需求，如日志记录、安全性、计量等。在这种情况下，当使用Azure API Management这样的产品时，你可能拥有一个单独的API网关并不那么危险，因为这类API网关“更薄”，也就是说，你没有实现定制的C代码，这些代码可能会演变成一个单一的组件。
- API网关产品通常充当入口通信的反向代理，在这里，您还可以从内部微服务中筛选API，并将授权应用于此单层中发布的API。
- API管理系统提供的洞察帮助您了解API是如何使用的，以及它们是如何执行的。他们通过让你查看近乎实时的分析报告和识别可能影响你业务的趋势来做到这一点。另外，您还可以拥有关于请求和响应活动的日志，以便进一步进行联机和脱机分析。
- 使用Azure API管理，您可以使用密钥、令牌和IP过滤来保护API。这些特性允许您实施灵活的细粒度配额和速率限制，使用策略修改api的形状和行为，并通过响应缓存提高性能。
- 在本指南和参考示例应用程序（eShopOnContainers）中，该体系结构仅限于更简单和自定义的容器化体系结构，以便在不使用诸如Azure API Management之类的PaaS产品的情况下专注于普通容器。但是对于部署到Microsoft Azure中的大型基于微服务的应用程序，我们鼓励您将Azure API管理作为生产中API网关的基础进行评估。
- Ocelot
- Ocelot是一个轻量级API网关，推荐用于更简单的方法。Ocelot是一个开源的基于.NET核心的API网关，特别是为需要统一进入系统入口点的微服务体系结构而设计的。它轻量级、快速、可扩展，并提供路由和身份验证等许多功能。
- 为eShopOnContainers reference应用程序选择Ocelot的主要原因是Ocelot是一个.NET Core轻量级API网关，您可以将其部署到部署微服务/容器（如Docker主机、Kubernetes等）的同一应用程序部署环境中，并且由于它基于.NET Core，它是跨平台的，允许您在Linux或Windows上部署。
- 前面显示在容器中运行的自定义API网关的图表正是如何在容器和基于微服务的应用程序中运行Ocelot的。
- 此外，市场上还有许多其他产品提供API网关功能，如Apigee、Kong、MuleSoft、WSO2和其他产品，如linker和Istio，用于服务网格入口控制器功能。
- 在最初的架构和模式解释部分之后，接下来的部分将解释如何使用Ocelot实现API网关。
API网关模式的缺点
- 最重要的缺点是，当您实现API网关时，您将该层与内部微服务耦合。这样的耦合可能会给您的应用程序带来严重的困难。Azure服务总线团队的架构师Clemens Vaster在GOTO 2016的“消息和微服务”会话中将这个潜在的困难称为“新ESB”。
- 使用microservices API网关会产生额外的单点故障。
- 由于额外的网络调用，API网关可以增加响应时间。然而，这个额外的调用通常比客户端接口直接调用内部微服务的影响要小。
- 如果扩展不当，API网关可能成为瓶颈。
- 如果API网关包含自定义逻辑和数据聚合，则需要额外的开发成本和未来的维护。开发人员必须更新API网关才能公开每个微服务的端点。此外，内部微服务中的实现更改可能会导致API网关级别的代码更改。但是，如果API网关只是应用安全性、日志记录和版本控制（如使用azureapi管理时），则可能不会应用此额外的开发成本。
- 如果API网关是由一个团队开发的，则可能存在开发瓶颈。这也是为什么更好的方法是有几个细粒度的API网关来响应不同的客户端需求的另一个原因。您还可以在内部将API网关隔离到多个区域或层中，这些区域或层由处理内部微服务的不同团队拥有。
额外资源
- Chris Richardson. Pattern: API Gateway / Backend for Front-End
https://microservices.io/patterns/apigateway.html - API Gateway pattern
https://docs.microsoft.com/azure/architecture/microservices/gateway - Aggregation and composition pattern
https://microservices.io/patterns/data/api-composition.html - Azure API Management
https://azure.microsoft.com/services/api-management/ - Udi Dahan. Service Oriented Composition
http://udidahan.com/2014/07/30/service-oriented-composition-with-video/ - Clemens Vasters. Messaging and Microservices at GOTO 2016 (video)
https://www.youtube.com/watch?v=rXi5CLjIQ9k - API Gateway in a Nutshell (ASP.net Core API Gateway Tutorial Series)
https://www.pogsdotnet.com/2018/08/api-gateway-in-nutshell.html
