API网关的一个成功例子是Netflix API Gateway。 Netflix流服务包含数百种终端设备，像电视、移动电话、游戏等。Netflix向提供一种统一形式的API。但是，他们发现由于涵盖的设备太多和个性化需求导致这种方案太难实现。现在，他们为每种类型的设备实现一种设备适配，通过API网关做具体适配。一种适配通过调用六、七种服务处理请求。The Netflix API Gateway每天处理数十亿请求。
API网关的优缺点
正如期望的那样，API网关也存在优点和缺点。最大的优势是API网关屏蔽了后端服务的结构。客户可以简单的通信，而不用处理服务之间的关系。API网关为每种客户端提供单独的接口。它减少了客户端和应用程序之间的往返次数。它也简化了客户端的代码。
API网关也有缺陷。它必须是一个开发、设计和部署的高可用组建。API网关成为开发的瓶颈是一种风险。研发必须升级网关服务以便暴露所有的服务。尽可能的轻量化部署API网关非常重要。开发者发版时必须要线性等待。尽管有这些缺点，程序采用API网关将会是有意义的。
个人认为：在程序框架的前期当服务并不是很多的时候，可以尝试采用客户端直连的形式实现，但是前端必须创建前端路由。如果后期服务较多，则尽量采用API路由网关的形式，因为这种情况下可以缩短请求次数、缩短请求路径，此种问题的请求不包含静态文件的处理。
实现API网关
现在我们已经了解了创建API网关的目的和意义了。让我们看一下创建时需要考虑的事情：
性能和伸缩性
仅有很少的公司如Netflix一样伸缩操作和单日处理数十亿请求。但是，API网关的性能和伸缩性非常重要。在一个平台上创建一个异步、非阻塞的IO API网关是由意义的。有多重技术实现API网关的自由伸缩。在JVM上，你可以实现基于NIO框架的程序，类似于 Netty, Vertx, Spring Reactor, or JBoss Undertow。一个流行的费JVM技术是Node.js,它建立在Chrome的javascr上.另一个解决方案是 NGINX Plus.,它提供了生出的伸缩、高性能Web服务和易于创建、配置和编程的反向代理。
NGINX Plus.能够提供管理权限、获得控制、负载请求、缓存处理结果和提供心跳感知和监控。
采用自适应编程模型
API网关通过简单的路由请求到不同的服务处理客户端请求。它通过引用多个后端服务和聚合结果来处理其他服务。一些请求像请求产品详情的请求独立与其他请求。为了最小化请求，API网关需要并行处理请求。有时，不同请求之间存在依赖。AIP网关在处理请求之前，可能首先验证服务请求。类似的，为了获取与客户相关的产品列表信息，可能首先获取用户信息，其次获取相关的产品信息。API组件的例子是 Netflix Video Grid.。
如果采用传统的异步请求代码变下API网关，可能会进行请求地狱。这些代码非常难写、难于理解和易错。写这种代码的一种较好办法是采用反应法以一种清晰的样式书写。适应抽象的例子包括 Future in Scala, CompletableFuture in Java 8, and in JavaScript. There is also Reactive Extensions (also called Rx or ReactiveX)。
服务调用
微服务程序是一个分布式的程序，但是必须提供进程间通信的机制。在进程间通信有两种形式。一种是异步的、基于消息的通信。一些实现采用消息代理例如JMS or AMQP。还有不采用代理的，如 Zeromq（这种消息直接通信）。另一种是直接通信，像HTTP or Thrift。一个系统会用同步或者异步通信。一种形式会有多种的实现形式。因此，API网关需要实现多种通信机制。
服务发现
API网关知道相互通信服务的地址。在传统系统，你可能硬编码地址，但是在现代云服务平台这将是一个巨大的问题。基础服务，像消息代理，可以通过系统变量设置，但是固定一个程序服务地址并不可行。因为一个应用程序服务的地址是动态指定的，同时服务随着伸缩或者更新，地址也可能会发生改变。因此，API网关就像其他客户端程序一样，需要应用系统的服务发现功能：服务端发现和客户端发现。
处理局部报错
另一个你需要关注的问题是局部报错问题。这个问题发生在一个服务调用另一个服务时，导致的原因是服务慢或者服务不可用。API网关永远不要无限制的阻塞服务调用。具体怎么处理依赖于具体的场景和哪个服务失败。例如，如果推荐服务报错，则API网关需要将产品的其他信息返回给客户端，因为这些信息依然对于客户有用。如果产品信息不再服务，则需要向用户返回报错信息。