从API-gateway 到 API-management

2015年，Chris Richardson在NGINX官方博客上一连发布了七篇微服务系列的文章，为micro-service这个从05年就被提出来的概念加了一把柴火。这个系列中的第二篇文章-"Building Microservices: Using an API Gateway”[1] 提出了一个概念: API Gateway。今天不想细聊微服务，而是讲讲与之紧紧关联的API网关。

标题楔子：聊两句微服务。

上图是Amazon商城的Android app界面，图上指出了1到6个模块，从历史订单查阅到推荐商品等等，如果在学校中做过一些学生管理系统这样的crud应用，会想当然地这样来设计这个这个系统。

这样的设计非常经典和简洁，但是要考虑一些问题:
除了移动端，可能还有网站，那么就意味着要在网站开发过程中使用和移动端业务逻辑相同的代码
单个功能可能要给其他功能提供一些调用接口，那么随着这个应用越来越丰富，接口之间的边界越来越模糊，功能与功能之间交叉的地方可能越来越多
所有应用在一个数据库上操作，不同功能都在调用同一个数据库，数据库的性能出现瓶颈。
这样的设计，在想要小小修改其中的某个功能的时候，需要把整个应用关闭，再一起发布。
如果是团队开发，功能中交叉的部分，公共的部分都应该让哪个模块的成员来实现呢？这时候分工会很复杂，出现问题的责任也很难准确落实。
随着应用越来越庞大，出现各种规范，这种结构还会出现诸多问题，所以就出现了微服务这个概念，还是上面这个例子, 在使用了微服务的结构之后。

和单体应用程序框架不同，产品页上不同的功能、数据会分布在如下不同的微服务上。
购物车服务网——购物车中的件数
订单服务——订单历史
目录服务——商品基本信息，如名称、图片和价格
评论服务——客户的评论
库存服务——低库存预警
送货服务——送货选项、期限和费用，这些信息单独从送货方API获取
推荐服务——推荐商品
简单来说，采用微服务架构来开发设计，就是在抽象出公用的业务，做成几个公共的服务，各个应用后台只要通过非常轻量的控制层和前端，从这一个个服务中获取数据，从而规避了大量的冗余代码，另一方面使整个系统分工更明确。这里的介绍还是比较笼统的，为引出API网关和API管理做一个铺垫，如果想要更详细地了解微服务相关的知识请参考一些博客和书籍。

一：从API gateway说起：

上面说到了微服务的改造过程，从理论上讲，客户端上收到的各种信息现在由各个微服务来提供了，那么怎么访问这些微服务呢？
首先可以知道的是，每个微服务都有一个公开的断点(https ????/.api.company.name）该 URL 映射到微服务的负载均衡器，由后者负责在可用实例之间分发请求。那么想当然的，为了获取产品详情，移动客户端可以逐一向 N 个微服务发送请求。但是这样做的问题是，每个客户端可能需要发送非常多的访问请求，按照Amazon的说法，在打开一个商城的产品页面时候就已经调用了数百个微服务，客户端通过公网发送这么多访问请求是很糟糕的。而且在客户端上发请求也可能造成了客户端的开发复杂，改造微服务，重新架构的时候就得把客户端也进行大量的修改。
另一点是不同服务由于一些规范或者需求会使用一些特殊的协议，比如一个服务可能使用 Thrift 二进制 RPC，而另一个服务可能使用 AMQP 消息传递协议，这些协议对于浏览器和防火墙都不够友好，我们往往希望防火墙外的应用程序只使用HTTP和WebSocket之类的协议。所以这时候需要API-gateway。我们先看看上面的案例加了API-Gateway之后的样子。

API 网关是一个服务器，也可以说是进入系统的唯一节点，他负责服务请求路由、组合及协议转换。客户端的所有请求都首先经过 API 网关，然后由它将请求路由到合适的微服务。API 网关经常会通过调用多个微服务并合并结果来处理一个请求，以产品详情的场景为例，API 网关可以提供一个端点（/productdetails?productid=xxx），使移动客户端可以通过一个请求获取所有的产品详情。
当然，有时候API网关的开发并不简单。就像苹果公司的一些产品，让你觉得操作精巧，使用逻辑流畅简单，但是这些的背后，在黑箱的内部可能是看不见的、难以模仿的复杂设计。一旦选择使用API网关，这就是一个必须付诸足够精力去开发、部署、维护的高可用组件，需要考虑他的性能和扩展性，需要设计合理的进程通信方式，要像一个将军一样清楚知道手下每个微服务的所在位置（service invocation）。Netflix、Amazon、Microsoft，国内的许多互联网厂商，API gateway都被验证是一个重要的很有意义的一个环节。

二：开源API网关 （以Kong为例）

除了自研API gateway，很多开源的方案也非常热门。常用的开源网关如下所示：

本人学习期间接触的一个开源网关就是Kong。2009年，Kong的第一个版本诞生在意大利米兰，而后公司命名Mashape，在美国注册，专注于API市场的建设，到16年的时候，mashape的APImarket上已经有了大约25万个开发人员。

Kong
可能学习过spring cloud 的同学都碰到过Zuul这个组件，Zuul 只提供了基本的路由功能，开发者需要自己研发 Zuul Filter, 而对Kong来说，很多功能都是其可以即插即用的插件，只需要经过简单配置就可以使用，例如：
云原生 : 与平台无关，Kong 可以从裸机运行到 Kubernetes
动态路由 ：Kong 的背后是 OpenResty+Lua，所以从 OpenResty 继承了动态路由的特性
熔断
健康检查
日志 : 可以记录通过 Kong 的 HTTP，TCP，UDP 请求和响应。
鉴权 : 权限控制，IP 黑白名单，同样是 OpenResty 的特性
SSL: Setup a Specific SSL Certificate for an underlying service or API.
监控 : Kong 提供了实时监控插件
认证 : 如数支持 HMAC, JWT, Basic, OAuth2.0 等常用协议
限流
REST API: 通过 Rest API 进行配置管理，从繁琐的配置文件中解放
可用性 : 天然支持分布式
高性能 : 背靠非阻塞通信的 nginx，性能自不用说
插件机制 : 提供众多开箱即用的插件，且有易于扩展的自定义插件接口，用户可以使用 Lua 自行开发插件
关于Docker版本的安装部署操作：
Kong 网关使用入门 - 掘金
​
juejin.im
进行配置管理的可视化分析工具:
https://blog.****.net/ronon77/article/details/84905102?utm_medium=distribute.pc_relevant.none-task-blog-baidujs-2
​
blog.****.net

三、API management

API管理系统的需求。有了api网关后，相当于有了一个专门接受API请求的服务器，那么作为API的提供商，依托这个服务器，我们还可以
制作一个API发布工具，负责API的测试和调试，协调API的整个生命周期。
制作成一个API商店，或者开发人员的门户potal，提供使用的教程，文档，交互界面等等。
将API的网关的监视数据提取出来让使用者、管理者进行分析。
支持收费和商业访问。
这一块的开源也是很丰富的，WSO2、3scale、Gravitee等，私有这一块，微软的Azure API Management是比较出名的，大概长下面这个样子。




那么如何具体设计一个APIM（API management），要设计哪些数据结构，如何与API网关进行交互，就是下一篇文章要将的了。