1.API-gateway(含义)
所有API的调用统一接入API网关层，由网关层负责接入和输出。
API Gateway是一个服务器，也可以说是进入系统的唯一节点。这跟面向对象设计模式中的Facade模式很像。API Gateway封装内部系统的架构，并且提供API给各个客户端.
2.gateway功能
一个API网关的基本功能包含了统一接入、协议适配、流量管理与容错、以及安全防护，这四大基本功能构成了网关的核心功能。
1)统一接入 系统中所有请求，都走该网关
2)协议适配 将请求的协议转换成内部的协议接口，如用户发起请求的接口是HTTP，但是下游的接口类型却为RPC或者JSF。
3)流量管理和容错 在调用过程中限流、降级、熔断等方式来保护网关的整体稳定
4)安全防护 防刷控制、黑白名单等措施
3.为何要用网关?
举个栗子
下面的图展示了你在淘宝客户端上滑动产品最终页时看到的信息
虽然这是一个智能手机应用，这个产品最终页展示了非常多的信息。例如，不仅这里有产品基本信息（名字、描述和价格），还有以下内容：
- 购物车中的物品数
- 下单历史
- 用户评论
- 低库存警告
- 快递选项
- 各式各样的推荐，包括经常跟这个物品一起被购买的产品、购买该物品的其他顾客购买的产品以及购买该产品的顾客还浏览了哪些产品。
- 可选的购物选项
当采用一个单体式应用架构，一个移动客户端将会通过一个REST请求（GET api.company.com/productdetails/productId）来获取这些数据。一个负载均衡将请求分发到多个应用实例之一。应用将查询各种数据库并返回请求给客户端。
相对的，若是采用微服务架构，最终页上的数据会分布在不同的微服务上。下面列举了可能与产品最终页数据有关的一些微服务：
- 购物车服务 -- 购物车中的物品数
- 下单服务 -- 下单历史
- 分类服务 -- 基本产品信息，如名字、图片和价格
- 评论服务 -- 用户评论
- 库存服务 -- 低库存警告
- 快递服务 -- 快递选项、截止时间、来自不同快递API的成本计算
- 推荐服务 -- 推荐产品
客户端到微服务直接通信
如上图所示，如果用户想展示次页面，需要请求客户端需要7次单独请求。在更复杂的场景中，可能会需要更多次请求。虽然一个客户端可以通过LAN发起很多个请求，但是在公网上这样会很没有效率，这个问题在移动互联网上尤为突出。总之就是客户端单独请求多个服务贼费劲。
另一个存在的问题是客户端直接请求微服务的协议可能并不是web友好型。一个服务可能是用Thrift的RPC协议，而另一个服务可能是用AMQP消息协议。它们都不是浏览或防火墙友好的，并且最好是内部使用。应用应该在防火墙外采用类似HTTP或者WEBSocket协议。总之就是用户访问协议不友好，不同应用端提供协议不统一。
这个方案的另一个缺点是它很难重构微服务。随着时间的推移，我们可能需要改变系统微服务目前的切分方案。例如，我们可能需要将两个服务合并或者将一个服务拆分为多个。但是，如果客户端直接与微服务交互，那么这种重构就很难实施。无论是对以后的研发重构难度，还是对于用户灰度体验都极差。
采用一个API Gateway
基于以上种种原因，网关方式诞生了。
1.客户端的请求多个服务，我直接在网关处统一封装，返回统一结果集，就用户而言请求一次或者少几次。暴漏粗粒度接口给前端。
2.用户可以直接http访问，不同项目里协议转换，转换成跟客户端兼容的协议。
4.API-Gateway基础架构
1）网关运行良好的环境还包括注册中心（比如：ZK读取已发布的API接口的动态配置）
2）为了实现高性能，将数据全部异构到缓存（如：Redis）中，同时还可以配合本地缓存来进一步提高网关系统的性能
3) 为了提高网关的吞吐率，可以使用NIO+Servlet 3 异步的方式，还可以利用Servlet 3 的异步特性将请求线程与业务线程分开，为后续的线程池隔离做好基本的支撑
4) 访问日志的存储我们可以放到Hbase中
5) 开放网关使用，那么需要一个支持OAuth2.0的授权中心
6) 还可以引入Nginx + lua的方式将一些基本的校验判断放到应用系统之上，这样可以更轻量化的处理接入的问题
5.网关的技术选型
- SpringCloud-Zuul : 社区活跃,基于 SrpingCloud 完整生态, 是构建微服务体系前置网关服务的最佳选型.
- Kong : 基于OpenResty的 API 网关服务和网关服务管理层.
- 自建网关服务: 如 谈谈基于 OpenResty 的接口网关设计
感谢博主：
https://cloud.tencent.com/developer/article/1440628