微服务架构与API网关
http://www.primeton.com/read.php?id=2237
InfoQ：在一个微服务架构中，API网关会在架构中的那一层？他主要的作用是什么？
王延炯：接续前一个话题，我把API GW分为了五类，对于当前的企业而言被关注的是前三类或者前四类API GW。显然，它们都会出现在企业系统的边界上，也就是和企业外部交互的「独木桥」上。
它们除了保证数据的交换之外，还需要实现对接入客户端的身份认证、防报文重放与防数据篡改、功能调用的业务鉴权、响应数据的脱敏、流量与并发控制，甚至基于API调用的计量或者计费。
· · ·
InfoQ：你有研究过Netflix的API网关吗？在实现方式上，你觉得他们的方式有什么巧妙之处吗？
王延炯：Netflix 的API GW，主要是指Zuul, Netflix 将他们用于自己的三大场景： Website Service, API Service, Streaming Service。其中前两个定位与我的前两个分类：Web App, Mobile App比较类似，第三个Streaming Service主要是netflix的核心视频业务所形成的特有形态。
Netflix在Zuul的实现上，主要特色是：Filter的PRE ROUTING POST ERROR（PRPE 模型），以及采用Groovy脚本的Filter实现机制、采用Cassandra作为filter repository的机制。
Filter 以及 Filter的PRPE模型，是典型的「前正后反模型」的实现，为集成的标准化做好了框架层面的铺垫。
Netflix其实并没有对API GW进行深入的功能实现（或者说面相业务友好的相关功能），整体上它只提供了一个技术框架、和一些标准的filter实例实现，相信了解过filter chain原理的分布式中间件工程师也能搭出这样的框架。这么做的原因，我认为很大原因是API GW所扮演的角色是一个业务平台，而非技术平台，将行业特征很强的业务部分开源，对于受众意义也不是特别大。另外，除了Netflix Zuul，在商业产品上还有apigee公司所提供的方案，在轻量级开源实现上还有基于Nginx的kong，kong其实提供了19个插件式的功能实现，涵盖的面主要在于安全、监控等领域，但缺少对报文转换的能力（为什么缺 也很显而易见——避免产生业务场景的耦合，更通用）。
另外，还有基于TCP协议的GW，比如携程无线应用的后端实现有HTTP和TCP两种，有兴趣的读者也可以深入关注。
· · ·
InfoQ：在API网关的设计上，需要包含哪些要素？
王延炯：从三个方面说吧，API网关本身以及API网关客户端，还有配套的自助服务平台。具体如下：
API GW本身
? NIO接入，异步接出
? 流控与屏蔽
? 秘钥交换
? 客户端认证与报文加解密
? 业务路由框架
? 报文转换
? HTTP DNS/ Direct IP
API GW 客户端 SDK / Library
? 基本通信
? 秘钥交换与Cache
? 身份认证与报文加解密
配套的在线自助服务平台
? 代码生成
? 文档生成
? 沙盒调测
· · ·
InfoQ：在API网关的落地上，你有可行的方案吗？在API网关的落地上，难点是什么？
王延炯：在我所服务过的阿里系、非电商互联网公司里，内部的分布式服务调用采用的是Dubbo，但移动应用是iOS和Android，基本上没有PC Web端的客户端，在这种条件下，API GW所承担的一个重要角色就是报文转换，并且是跨语言、跨运行平台的报文转换。报文就是数据，在跨平台、跨语言的条件下，对于数据的描述——元数据——也就是类定义，对于API GW的系统性挑战是巨大的：传输时，报文内不能传输类定义，跨语言的类定义转换、生成与加载。
API GW的落地技术基本贯通没有太大的难度，但形成专业的实践，有一些外围的前置条件，比如：
后端API粒度
能和原子业务能力找到映射最好，一定要避免「万能接口」的出现。
业务路由的实现和含报文转换的API不停机发布
尽可能的在报文头里面存放业务路由所需要的信息，避免对报文体进行解析。
API GW上线后，面临的很大问题都是后端服务如何自助发布到外部，同时不能重启网关服务，以保障业务的连续。在此过程中，如果涉及到报文格式的转换，那对API网关实现的技术要求比较高。如果让网关完成报文转换，第一种方案，网关需要知道报文的具体格式（也就是报文的元数据，或者是类定义），这部分要支持热更新。第二种方案，需要客户端在报文内另外附加元数据，网关通过运行期加载元数据对报文进行解析在进行报文的转换，这种方案性能不会很好。第三种方案，就是在运行期首次报文转换的时候，根据元数据生成报文转换代码并加载，这种方案对技术实现要求比较高，对网关外围平台支撑力度要求也不低。
客户端的秘钥管理
很多人都会把安全问题简单的用加密算法来解决，这是一个严重的误区，很多时候都存在对秘钥进行系统性管理的短板。打个比方，加密算法就好比家里的保险箱，而秘钥是保险箱的钥匙，而缺乏秘钥管理的安全方案，就好比把钥匙放在自家的客厅茶几上。更何况，安全方案里加解密也只是其中的一部分。
· · ·
InfoQ：你认为一个设计良好的API网关应该做到什么？
王延炯：目前业界关注的API GW，主要是在前三类，下文对于API网关的设计上，侧重于「面向接入」的API GW。
在API网关的设计上，仅仅有类似Zuul这样的「面向接入」的运行期框架是远远不够的，因为一个完整的、「面向接入」的API GW需要包含以下功能：
面向运行期
? 对客户端实现身份认证
? 通信会话的秘钥协商，报文的加密与解密
? 日常流控与应急屏蔽
? 内部响应报文的场景化裁剪
? 支持「前正后反模型」的集成框架
? 报文格式的转换
? 业务路由的支撑
? 客户端优先的超时机制
? 全局流水号的生成与应用
? 面向客户端支持HTTP DNS / Direct IP
面向开发期
? 自助的沙盒测试环境
? 面向客户端友好的 SDK / Library以及示例
? 能够根据后端代码直接生成客户端业务代码框架
? 完善的报文描述能力（元数据），支撑配置型的报文裁剪
面向运维与运营
? 支持面向接入方的独立部署与快速水平扩展
? 面向业务场景或合作伙伴的自助API开通
? 对外接口性能与线上环境故障定位自助平台
关于作者：
王延炯
EAII-企业架构创新研究院 专家委员
王延炯，现任普元信息主任架构师。密码学博士，毕业于北京邮电大学。曾先后任职于西门子(中国)研究院、垂直行业互联网公司。带领团队交付了移动、金融、电信等多个行业、众多IT系统的咨询、设计、研发、实施、维护、优化工作。对分布式架构，企业架构，以及企业IT平台化运营有深入的研究和理解。