API 网关的出现的原因是微服务架构的出现，不同的微服务一般会有不同的服务地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求，如果让客户端直接与各个微服务通信，会有以下的问题：
客户端会多次请求不同的微服务，增加了客户端的复杂性。
存在跨域请求，在一定场景下处理相对复杂。
认证复杂，每个服务都需要独立认证。
难以重构，随着项目的迭代，可能需要重新划分微服务。例如，可能将多个服务合并成一个或者将一个服务拆分成多个。如果客户端直接与微服务通信，那么重构将会很难实施。
某些微服务可能使用了防火墙 / 浏览器不友好的协议，直接访问会有一定的困难。
网关是介于客户端和服务器端之间的中间层，所有的外部请求都会先经过 API 网关这一层。也就是说，API 的实现方面更多的考虑业务逻辑，而安全、性能、监控可以交由 API 网关来做 ，所以网关的性能，高可用，安全性都是至关重要的。
备注：Spring Cloud 微服务中搭建 OAuth2.0 认证授权服务
常用网关有哪些 ?
Nginx、Kong、ZUUL、Spring Cloud Gateway(Spring Cloud 官方)、Linkerd 等
Spring Cloud ZuulZuul 是 Netflix 开源的微服务网关组件，它可以和 Eureka、Ribbon、Hystrix 等组件配合使用。Zuul 的核心是一系列的过滤器 (比如：动态路由)。Spring Cloud Zuul 对 Zuul 进行了整合 ，从而更方便的与 Spring Cloud 一起使用。
Zuul1
Zuul1 是基于 Servlet 框架构建，采用的是阻塞和多线程方式，即一个线程处理一次连接请求，这种方式在内部延迟严重、设备故障较多情况下会引起存活的连接增多和线程增加的情况发生。
Zuul2
Zuul2 与 Zuul1 最大的区别是它运行在异步和无阻塞框架上，每个 CPU 核一个线程，处理所有的请求和响应，请求和响应的生命周期是通过事件和回调来处理的，这种方式减少了线程数量，因此开销较小。又由于数据被存储在同一个 CPU 里，可以复用 CPU 级别的缓存，前面提及的延迟和重试风暴问题也通过队列存储连接数和事件数方式减轻了很多（较线程切换来说轻量级很多，自然消耗较小）。这一变化一定会大大提升性能。
注：zuul 2.0 版本 Spring Cloud 官方现阶段不打算集成，官方还是推荐使用 Spring Cloud Gateway
性能
可以参考：纠错帖：Zuul & Spring Cloud Gateway & Linkerd性能对比 ，简单来说，Zuul 1.x 是一个基于阻塞 IO 的 API Gateway，另外 Spring Cloud Gateway 性能很好。
高可用
一般生产环境需要将多个 Zuul 节点注册到 Eureka Server 上，就可以实现 Zuul 的高可用。事实上，这种情况下的高可用和其他服务做高可用（例如：Eurka Server 集群）的方案没有什么区别。当 Zuul 客户端注册到 Eureka Server 上时，Zuul 客户端会自动从 Eureka Server 查询 Zuul Server 列表，然后使用负载均衡组件（例如: Ribbon）请求 Zuul 集群。另外的方式也可以使用 Nginx 或者硬件 F5 的来实现。
安全性