网关一词来源于计算机网络中的定义，网关(Gateway)又称网间连接器、协议转换器。网关的准确定义是： 两个计算机程序或系统之间的连接，网关作为两个程序之间的门户，允许它们通过不同计算机之间的协议通信来共享信息。顾名思义API网关就是API之间相互调用的关卡和屏障。
API之间为什么需要网关试想一下我们在实现一个非常庞大的业务系统，分为不同的业务domain和子系统，各个domain和子系统提供处理业务的API，不同系统之间以API的方式进行数据交互。通常情况下我们可能会将所有实现业务功能的API集成到一起（API Center）给不同的Channel的Portal提供数据处理的能力。当有一天我们的系统需要与第三方发生交互，我们既需要暴露给外部系统调用的公开API，同时也需要调用外部的API实现自身的业务需求。此时我们将会考虑很多的问题，比如：服务之间访问的授权和认证，安全和性能的监控，缓存和日志的处理，超时的Retry，负载和熔断的处理，查询请求的聚合等等一系列的问题。此时你需要一个可以集中处理所有可能在服务调用之间需要处理的一切事情，就像是小区的物业和安保一样，需要对小区所有的业主处理职责范围内的一切事情。
这是通常情况下API网关需要帮我们处理的事情，随着系统业务的不断复杂化，我们的系统越越庞大，API的交互越来越错综复杂。此时我们可能会考虑将这个庞大的系统拆分成多个细小的domain，分别提供各自domain的API。这便是时下最流行的话题：微服务。当我们的系统演进到微服务的架构时，API网关将是系统必不可少的关键部分。在微服务体系结构中，客户端应用程序通常需要使用多个微服务的功能。客户端如果直接消费某服务，那通常情况下将需要处理和协调用多个微服务endpoint。当应用程序引入新的微服务或更新现有微服务时会发生什么?试想一下如果你的应用程序有许多微服务，那么处理和协调来自客户端如此多的endpoint的请求，那对系统来说是一场噩梦，而且由于客户端应用程序将与这些endpoint产生耦合，这将会使我们的系统边的混乱不堪。
因此，我们需要一个中间层或间接层(Gateway)来处理不同client对API的请求，这将会使得我们的应用程序处理起来非常方便。如果没有API网关，客户端应用程序必须直接向微服务发送请求，这就会产生很多混乱的问题，比如：
耦合: 如果没有API网关，客户端的应用程序将与内部微服务间耦合。客户端序需要知道实现业务需求的API分散在服务中的哪些部分，当我们开发和重构内部服务时，将会影响到客户端应用程序，并且很难维护，因为客户端应用程序需要跟踪多个服务的endpoint
多次请求:客户端应用程序中的一个页面可能需要多次调用多个服务来完成某个功能，这可能导致客户端和服务器之间的多次往返请求，增加了显著的延迟。我们知道在中间级别处理的聚合可以提高客户端应用程序的性能和用户体验。
安全问题:如果没有网关，所有的服务都必须公开给“外部世界”，这使得攻击面比隐藏内部服务更大，而这些服务不是客户端应用程序直接使用的。攻击面越小应用程序就越安全。
横切关注点:每个公开发布的服务都必须处理诸如授权、SSL等问题。在许多情况下这些关注点可以在一个层中处理，这样内部服务就可以简化，这让我想起了面向切面的编程（AOP）
什么是网关模式当我们在使用多个客户端应用程序设计和构建大型或复杂的基于微服务的应用程序时，可以考虑使用API网关，这是为某些微服务组提供单一入口点的服务，它类似于面向对象设计的Facade（外观类）模式，但在微服务中它是系统的一部分。API网关模式的一个变体也称为“Backend for front-end”(BFF)，因为你可能会根据每个客户端应用程序的不同需求创建多个API网关。因此API网关位于客户端应用程序和微服务之间，它充当反向代理将请求从客户端路由到服务，它还可以提供额外的横切特性，如身份验证、SSL终止和缓存。
下面的图显示了自定义API网关如何适合于基于微服务的体系结构。
在上面的示例中，API网关将作为自定义Web API或ASP.NET WebHost服务的一个容器运行