参考链接：
http://www.infoq.com/cn/news/2016/07/API-background-architecture-floo
APIGW除了要保证数据的交换外，还要实现对接入客户端的身份认证、防报文重放与防数据篡改、功能调用的业务鉴权、响应数据的脱敏、流量与并发控制，甚至基于API调用的计量或者计费。
一、普元大咖
1、应用场景分类
1.1、面向Web App
这类场景，在物理形态上类似前后端分离，此时的Web App已经不是全功能的Web App，而是根据场景定制、场景化的App。
1.2、面向Mobile App
这类场景，移动App是后端Service的使用者，此时的API GW还需要承担一部分MDM（此处是指移动设备管理，不是主数据管理）的职能。
1.3、面向Partner OpenAPI
这类场景，主要为了满足业务形态对外开放，与企业外部合作伙伴建立生态圈，此时的API GW需要增加配额、流控、令牌等一系列安全管控功能。
1.4、面向Partner ExternalAPI
这类场景，业界提的比较少，很多时候系统的建设，都是为了满足企业自身业务的需要，实现对企业自有业务的映射。当互联网形态逐渐影响传统企业时，很多系统都会为了导入流量或者内容，依赖外部合作伙伴的能力，一些典型的例子就是使用「合作方账号登录」、「使用第三方支付平台支付」等等，这些对于企业内部来说，都是一些外部能力。此时的API GW就需要在边界上，为企业内部Service 统一调用外部的API做统一的认证、（多租户形式的）授权、以及访问控制。
1.5、面向IoT SmartDevice
这类场景，业界就提的更少了，但在传统企业，尤其是工业企业，传感器、物理设备从工业控制协议向IP转换，导致具备信息处理能力的「智能产品」在被客户激活使用直至报废过程中，信息的传输不能再基于VPN或者企业内部专线，导致物理链路上会存在一部分公网链路。此时的API GW所需要满足的，就是不是前三种单向的由外而内的数据流，也不是第四种由内而外的数据流，「内外兼修」的双向数据流，对于企业的系统来说终端设备很多情况下都不是直连网关，而是进过一个「客户侧」的集中网关在和企业的接入网关进行通信。
2、API网关的能力
API GW本身
- NIO接入，异步接出
- 流控与屏蔽
- 秘钥交换
- 客户端认证与报文加解密
- 业务路由框架
- 报文转换
- HTTP DNS/ Direct IP
API GW 客户端 SDK / Library
- 基本通信
- 秘钥交换与Cache
- 身份认证与报文加解密
配套的在线自助服务平台
- 代码生成
- 文档生成
- 沙盒调测
3、最佳实践
后端API粒度：能和原子业务能力找到映射最好，一定要避免「万能接口」的出现。
业务路由的实现和含报文转换的API支持不停机发布，在报文头里面存放业务路由所需要的信息，避免对报文体进行解析。
API GW上线后，面临的很大问题都是后端服务如何自助发布到外部，同时不能重启网关服务，以保障业务的连续。在此过程中，如果涉及到报文格式的转换，那对API网关实现的技术要求比较高。如果让网关完成报文转换，
- 第一种方案，网关需要知道报文的具体格式（也就是报文的元数据，或者是类定义），这部分要支持热更新。
- 第二种方案，需要客户端在报文内另外附加元数据，网关通过运行期加载元数据对报文进行解析在进行报文的转换，这种方案性能不会很好。
- 第三种方案，就是在运行期首次报文转换的时候，根据元数据生成报文转换代码并加载，这种方案对技术实现要求比较高，对网关外围平台支撑力度要求也不低。
客户端的秘钥管理
很多人都会把安全问题简单的用加密算法来解决，这是一个严重的误区，很多时候都存在对秘钥进行系统性管理的短板。
打个比方，加密算法就好比家里的保险箱，而秘钥是保险箱的钥匙，而缺乏秘钥管理的安全方案，就好比把钥匙放在自家的客厅茶几上。更何况，安全方案里加解密也只是其中的一部分。
4、一个好的API网关
在API网关的设计上，仅仅有类似Zuul这样的「面向接入」的运行期框架是远远不够的，因为一个完整的、「面向接入」的API GW需要包含以下功能：
面向运行期
- 对客户端实现身份认证
- 通信会话的秘钥协商，报文的加密与解密
- 日常流控与应急屏蔽
- 内部响应报文的场景化裁剪
- 支持「前正后反模型」的集成框架
- 报文格式的转换
- 业务路由的支撑
- 客户端优先的超时机制
- 全局流水号的生成与应用
- 面向客户端支持HTTP DNS / Direct IP
面向开发期
- 自助的沙盒测试环境
- 面向客户端友好的 SDK / Library以及示例
- 能够根据后端代码直接生成客户端业务代码框架
- 完善的报文描述能力（元数据），支撑配置型的报文裁剪
面向运维与运营
- 支持面向接入方的独立部署与快速水平扩展
- 面向业务场景或合作伙伴的自助API开通
- 对外接口性能与线上环境故障定位自助平台
二、其他观点
1、API网关负责服务请求路由、组合及协议转换。
客户端的所有请求都首先经过API网关，然后由它将请求路由到合适的微服务。API网管经常会通过调用多个微服务并合并结果来处理一个请求。它可以在Web协议（如HTTP与WebSocket）与内部使用的非Web友好协议之间转换。
API网关还能为每个客户端提供一个定制的API。通常，它会向移动客户端暴露一个粗粒度的API。
例如，考虑下产品详情的场景。API网关可以提供一个端点（/productdetails?productid=xxx），使移动客户端可以通过一个请求获取所有的产品详情。API网关通过调用各个服务（产品信息、推荐、评论等等）并合并结果来处理请求。
2、API的优缺点
使用API网关的最大优点是，它封装了应用程序的内部结构。客户端只需要同网关交互，而不必调用特定的服务。API网关为每一类客户端提供了特定的API。这减少了客户端与应用程序间的交互次数，还简化了客户端代码。
API网关也有一些不足，它增加了一个我们必须开发、部署和维护的高可用组件。为了暴露每个微服务的端点，开发人员必须更新API网关。API网关的更新过程要尽可能地简单，这很重要。否则，为了更新网关，开发人员将不得不排队等待。不过，虽然有这些不足，但对于大多数现实世界的应用程序而言，使用API网关是合理的。
3、服务调用
基于微服务的应用程序是一个分布式系统，必须使用一种进程间通信机制。有两种类型的进程间通信机制可供选择。一种是使用异步的、基于消息传递的机制。有些实现使用诸如JMS或AMQP那样的消息代理，而其它的实现则没有代理，服务间直接通信。另一种进程间通信类型是诸如HTTP或Thrift那样的同步机制。通常，一个系统会同时使用异步和同步两种类型。它甚至还可能使用同一类型的多种实现。总之，API网关需要支持多种通信机制。
4、服务发现
API网关需要知道它与之通信的每个微服务的位置（IP地址和端口）。在传统的应用程序中，或许可以硬连线这个位置，但在现代的、基于云的微服务应用程序中，这并不是一个容易解决的问题。基础设施服务（如消息代理）通常会有一个静态位置，可以通过OS环境变量指定。但是，确定一个应用程序服务的位置没有这么简单。应用程序服务的位置是动态分配的。而且，单个服务的一组实例也会随着自动扩展或升级而动态变化。总之，像系统中的其它服务客户端一样，API网关需要使用系统的服务发现机制，可以是服务器端发现，也可以是客户端发现。
5、问题记录
在实现API网关时，还有一个问题需要处理，就是局部失败的问题。该问题在所有的分布式系统中都会出现，无论什么时候，当一个服务调用另一个响应慢或不可用的服务，就会出现这个问题。API网关永远不能因为无限期地等待下游服务而阻塞。不过，如何处理失败取决于特定的场景以及哪个服务失败。例如，在产品详情场景下，如果推荐服务无响应，那么API网关应该向客户端返回产品详情的其它内容，因为它们对用户依然有用。推荐内容可以为空，也可以，比如说，用一个固定的TOP 10列表取代。不过，如果产品信息服务无响应，那么API网关应该向客户端返回一个错误信息。
如果缓存数据可用，那么API网关还可以返回缓存数据。例如，由于产品价格不经常变化，所以如果价格服务不可用，API网关可以返回缓存的价格数据。数据可以由API网关自己缓存，也可以存储在像Redis或Memcached那样的外部缓存中。通过返回默认数据或者缓存数据，API网关可以确保系统故障不影响用户的体验。
6、API目录管理
当需要编辑某个API的定义时，如果该API已经发布，对定义的修改不会对线上产生影响，定义修改后需要再次发布才能把修改后的定义同步到线上环境。
当想要删除某个API，如果该API已经发布，则不允许直接删除API定义，需要先将API下线，然后删除。
提供了复制定义的功能。可以从测试环境/线上环境复制线上的定义覆盖当前的最新定义，然后重新点击编辑进行修改。