为什么要使用API网关而不是直接通信？

在微服务架构中，客户端应用程序通常需要使用来自多个微服务的功能。如果直接执行该消费，则客户端需要处理多个微服务端点以进行呼叫。当应用程序发展并引入新的微服务或更新现有的微服务时会发生什么？如果您的应用程序有许多微服务，则从客户端应用程序处理如此多的端点可能是一场噩梦，并且由于客户端应用程序将耦合到这些内部端点，因此未来发展微服务可能会对客户端应用程序造成很大影响。

因此，具有中间级别或间接层级（网关）对于基于微服务的应用程序非常方便。如果您没有API网关，则客户端应用程序必须将请求直接发送到微服务，并引发问题，例如以下问题。

耦合：如果没有API网关模式，客户端应用程序将耦合到内部微服务。客户端应用程序需要知道应用程序的多个区域如何在微服务中分解。在发展和重构将影响客户端应用程序的内部微服务时，由于客户端应用程序需要跟踪多个微服务端点，因此很难维护它们。
往返次数过多：客户端应用程序中的单个页面/屏幕可能需要多次调用多个服务。这可能导致客户端和服务器之间出现多次网络往返，增加了严重的延迟。在中间级别处理的聚合可以改善客户端应用的性能和用户体验。
安全问题：没有网关，所有微服务必须暴露于“外部世界”，使得攻击面比隐藏客户端应用程序未直接使用的内部微服务更大。攻击面越小，应用程序就越安全。
跨领域问题：每个公开发布的微服务都必须处理诸如授权，SSL等问题。在许多情况下，这些问题可以在单层中处理，以便简化内部微服务。

Ocelot：轻量级和开源API网关。非常适合使用.NET Core微服务开始学习这种模式

Ocelot是一款基于开源.NET核心的API网关，特别针对需要统一进入系统的微服务架构。它轻巧，快速，可扩展，并提供许多其他功能之间的路由和身份验证。

选择Ocelot用于eShopOnContainers参考应用程序的主要原因是因为它是一个.NET Core轻量级API网关，您可以将它部署到您部署微服务/容器的相同应用程序部署环境中，例如Docker主机， Kubernetes，Service Fabric等，由于它基于.NET Core，因此它是跨平台的，允许您在Linux或Windows上进行部署。

在初始架构和模式解释部分之后，下一部分将介绍如何使用Ocelot实现API网关。

什么是API网关模式

当您使用多个客户端应用程序设计和构建大型或复杂的基于微服务的应用程序时，考虑的一个好方法可以是API网关。这是为某些微服务组提供单一入口点的服务。它类似于外观模式从对象-导向的设计，但在这种情况下，它是一种分布式系统的一部分。API网关模式的变体也被称为“前端后端”（BFF），因为您可能会根据每个客户端应用程序的不同需求创建多个API网关。

因此，API网关位于客户端应用程序和微服务之间。它充当反向代理，将来自客户端的请求路由到服务。它还可以提供额外的交叉功能，如身份验证，SSL终止和缓存。

下图显示了自定义API网关如何适用于基于微服务的体系结构。

640?wx_fmt=jpeg

使用实现为自定义Web API服务的API网关

在前面的示例中，API网关将作为以容器运行的自定义Web API或ASP.NET WebHost服务的形式实现。

突出显示在该图中非常重要，您将使用面向多个不同客户端应用程序的单个定制API网关服务。这个事实可能是一个重要的风险，因为您的API网关服务将根据客户端应用程序的许多不同要求而不断增长和发展。最终，它会因为这些不同的需求而臃肿，并且它可能非常类似于单一应用程序或单一服务。这就是为什么非常推荐将API网关分成多个服务或多个较小的API网关，例如每种形式的网关类型。

您需要注意API网关模式。通常，使用单个API网关汇总应用程序的所有内部微服务并不是一个好主意。如果确实如此，它就像一个单一的聚合器或协调器，并通过耦合所有微服务来违反微服务自治。

因此，API网关应该根据业务边界和客户端应用进行分离，而不是作为所有内部微服务的单一聚合器。

将API网关层拆分为多个API网关时，如果您的应用程序有多个客户端应用程序，那么在识别多个API网关类型时可能是主要关键点，以便您可以根据每个客户端应用程序的需要设置不同的外观。这种情况是一种名为“前端后端”（BFF）的模式，其中每个API网关都可以为每个客户端应用类型提供不同的API，甚至可以基于客户端形式因子实现特定的适配器代码，该代码在下面调用多个内部微服务，如下图所示。

640?wx_fmt=jpeg

上图显示了一个具有多个细粒度API网关的简化体系结构。在这种情况下，为每个API网关确定的边界完全基于“前端后端”（BFF）模式，因此仅基于每个客户端应用程序所需的API。但是在更大的应用程序中，您还应该进一步研究并根据业务边界创建其他API网关作为第二个设计支点。

API网关模式中的主要功能

API网关可以提供多种功能。但是，根据产品可能提供更丰富或更简单的功能，任何API网关的最重要和最基本的功能都是以下设计模式。

反向代理或网关路由。API网关提供反向代理来重定向或路由请求（第7层路由，通常是Http请求）到内部微服务的端点。网关为客户端应用程序提供单个端点或URL，然后在内部将请求映射到一组内部微服务。这种路由功能有助于将客户端应用程序与微服务分离，但通过将API网关置于整体式API和客户端应用程序之间来实现整体式API的现代化时，它也非常方便，然后您可以将新的API作为新的微服务添加，同时仍在使用传统的单片API，直到将来它被分成许多微服务。由于API网关，客户端应用程序不会注意到所使用的API是作为内部微服务还是单片API实现的，更重要的是

有关更多信息，请查看网关路由模式信息。

请求聚合。作为网关模式的一部分，您可以将针对多个内部微服务的多个客户端请求（通常是Http请求）聚合为一个客户端请求。当客户端页面/屏幕需要来自多个微服务的信息时，此模式特别方便。通过这种方法，客户端应用程序将向API网关发送一个请求，该请求将向内部微服务发送几个请求，然后汇总结果并将所有内容发送回客户端应用程序。这种设计模式的主要优点和目标是减少客户端应用程序与后端API之间的沟通，这对于微服务所在数据中心内的远程应用程序尤其重要，例如移动应用程序或来自SPA应用程序的请求客户端远程浏览器中的Javascript。

根据您使用的API网关产品，它可能能够执行此聚合。但是，在许多情况下，在API网关的范围内创建聚合微服务更加灵活，因此您可以在代码中定义聚合（即C＃代码）。

有关更多信息，请查看网关聚合模式信息。

交叉担忧或网关卸载。根据每个API Gateway产品提供的功能，您可以将各个微服务的功能卸载到网关，从而通过将横切关注点合并到一个层级中来简化每个微服务的实施。这对于特殊功能来说尤其方便，因为这些功能在每个内部微服务（如以下功能）中都可以很复杂地实现。

认证和授权
服务发现集成
响应缓存
重试策略，断路器和QoS
限速和节流
负载均衡
记录，追踪，关联
标题，查询字符串和声明转换
IP白名单

根据每种实现方式，API网关产品可能存在更多的交叉问题，但这些是最常见的功能。例如，Azure API Management提供了大多数这些功能以及许多对商业API非常有用的高级功能。但是，对于更简单的方法，像Ocelot这样的轻量级API网关非常灵活，因为您可以将它与微服务一起部署到选定的环境（任何编排器）。