在该图中需要强调的是我们将使用一个面向多个不同客户端的自定义API网关服务。这可能是一个重要的风险，因为你的API网关服务将根据客户端需求的不断增长和发展，最终由于这些不同的需求，它将变得臃肿不堪，实际上它可能非常类似于单片应用程序或单片服务。这就是为什么我们非常推荐将API网关拆分为多个服务或多个更小的API网关。
在使用API网关模式时我们也要非常小心，通常使用单个API网关聚合应用程序的所有内部微服务不是一个好的实践，因为一旦这样做了它就充当一个整体聚合器或协调器并通过耦合所有微服务来违反微服务自治。因此API网关应该基于业务边界和客户端应用程序进行隔离，而不是作为所有内部微服务的单一聚合器。当把API网关层分解为多个API网关时, 如果你的应用程序有多个客户端, 这可以是一个主要的枢纽来识别多个API的网关类型，这样你就可以有不同的外观类来应对每个客户端的需求。这是我们称之为“Backend for front-end”的模式(BFF)，其中每个API网关可以为每个客户端提供不同的API，甚至可能基于客户端的特定需求实现特定的适配器代码，该代码在下面调用多个内部微服务，如下图所示：
上图展示了一个带有多个细粒度API网关的简化体系结构，在这种情况下识别每个API GateWay的边界纯粹是基于BFF的模式，因此只是基于每个客户端提供各自所需的API，但在较大的应用程序也应该更进一步，以创建基于业务边界的网关作为第二设计衡量因素。
API网关模式中的主要特性API网关可以根据产品的不同提供多种特性，它可能提供更丰富或更简单的特性，但是对于任何API网关来说，最重要和基本的特性是以下设计方式：
反向代理或网关路由：API网关提供反向代理，将请求(通常是Http请求)重新定向或路由到内部微服务的端点。网关为客户端应用程序提供一个endpoint或URL，然后在内部将请求映射到一组内部微服务。这个路由特性有助于从微服务的方式来解耦客户端，而且也很方便在单一API和客户端之间实现网关的控制，这样的话你可以添加新的API作为新的microservices同时仍然使用遗留单一的API，直到它在未来被分成许多microservices。因为API的网关的存在，客户端应用程序不会注意到所使用的API实现为内部microservices或单一的API，当在演进和和重构我们的单一API到 microservices的过程中因为有了API网关路由的存在，才不会带来Client请求的URI的变化。想了解更多网关路由的东西请戳这里。
请求聚合：作为网关模式的一部分，你可以将针对多个内部微服务的多个客户端请求(通常是Http请求)聚合到单个客户端请求中。当客户端页面需要调用来自多个微服务的数据时，这种模式特别方便。使用这种方法客户端将发送一个请求到API网关，然后网关将负责发送多个请求来获取内部microservices然后聚合结果再发送回客户端。这种设计模式的主要优点和目标是减少客户端应用程序和后端API之间的隔阂，对于微服务所在的数据中心之外的远程应用程序来说这一点尤为重要，比如移动应用程序或来自客户端远程浏览器中的Javascript的SPA应用程序的请求。对于在服务器环境中执行请求的常规web应用程序(如ASP)，这种模式并不重要，因为延迟比远程客户机应用程序要小得多。是否能够执行此聚合取决于你使用的API网关产品，然而在许多情况下，在API网关的范围内创建聚合微服务将会更加的灵活，所以你也可以在代码中定义聚合(即c#代码)。想了解更多请求聚合的东西请戳这里。
横切关注点或网关卸载：根据每个API网关产品提供的特性，你可以将功能从单个微服务转移到网关，通过将横切关注点合并到一层来简化每个微服务的实现。这对于可以在每个内部微服务(如以下功能)中正确实现的复杂的特殊功能来说特别方便。
身份验证和授权
服务发现集成
响应缓存
重试策略，断路器和QoS。
速度限制和节流
负载平衡
日志记录、跟踪、相关性
头文件、查询字符串和声明转换
IP白名单
根据每个实现API网关产品可以提供更多的横切关注点，但这些都是最常见的特性。例如Azure API管理提供了这些特性中的大部分，以及许多对商业API非常有用的高级特性。但是对于更简单的方法，像Ocelot这样的轻量级API网关是相当灵活的，因为你可以将它部署到你所选择的环境和你的微服务。有关网关卸载模式的更多信息请戳这里。