介绍
我们知道在微服务架构风格中，一个大应用被拆分成为了多个小的服务系统提供出来，这些小的系统他们可以自成体系，也就是说这些小系统可以拥有自己的数据库，框架甚至语言等，这些小系统通常以提供 Rest Api 风格的接口来被 H5, Android, IOS 以及第三方应用程序调用。现在我们的结构就是这个情况。
为什么需要使用API GateWay
现状：
由图可以看出，在没有API网关作为统一出口的情况下，需要调用方自己组合各种服务，而且容易让调用方感知后端各种服务的存在，各个需要各个做很多相同的工作。
加入API Gateway之后：
加入API Gateway之后的作用
一般也会把路由，安全，限流，缓存，日志，监控，重试，熔断等都放到 API 网关来做，然后服务层就完全脱离这些东西，纯粹的做业务，也能够很好的保证业务代码的干净，不用关心安全，压力等方面的问题。
由于在我们公司基础服务已经提供了一个API Gateway ，我们只是基于之前的Api Gateway进行一个补充，使之使用我们的业务，所以我们自己的API Gateway的功能就不需要那么多。
1.路由、重试 公司的API Gateway已经是有了路由，基于域名到IP的路由，我们也是要做路由，但是路由是统一我们事业部的大域名下分发到规范的小域名(不做IP、机器的管理 如下图)。这样可以防止域名泛滥使用，不规范 （etca、etcb、etcc …… 这些根本猜不出意义的域名）
除了路由就是一些通用的服务，主要是为了防止模块服务提供方陷入繁琐的逻辑校验，安全校验
2.鉴权: 通过APIGateway对访问进行统一鉴权，不需要每个应用单独对调用方进行鉴权，应用可以专注业务。
3.限流、熔断 在配置路由规则的时候可以定制化限流、熔断策略。
4.日志服务 对访问
5.监控 可以根据唯一请求Id，监控调用流程，以及调用的响应时间
API Gateway的优点和缺点
采用API Gateway也是优缺点并存的。API Gateway的一个最大好处是封装应用内部结构。相比起来调用指定的服务，客户端直接跟gatway交互更简单点。服务提供方也能够减轻繁琐的安全日志等判断。API Gateway也有一些缺点。它是一个高可用的组件，必须要开发、部署和管理。还有一个问题，所有的流量都需要通过API Gateway，所以它可能成为开发的一个瓶颈。
可选方案：
Zuul: Netflix Zuul，作为Spring cloud 中的一员，作为其中的api gateway，为服务架构提供前置保护作用。属于Spring cloud体系中，所以基于Java， Spring boot ，可以更好的集成到系统中。
Kong: Kong 是一个现成 的 api gateway 的解决方案，它在 nginx 上进行了开发。
最终结果
Zuul的性能，单台机器 600 tps
