接口调度者—— API 网关
背景 我们知道在微服务架构风格中，一个大应用被拆分成为了多个小的服务系统提供出来，这些小的服务他们自成体系，也就是说这些小系统可以拥有自己的数据库，框架甚至语言等，这些小系统通常以提供 Rest Api 风格的接口来被 H5, Android, IOS 以及第三方应用程序调用。 在《浅入浅出消息队列》这一篇文章中，我提到了消息队列是方便服务与服务之间的通信解耦，如下图所示： 那么这时候问题来了，如果一个外部的应用（浏览器、App）要去访问这个大应用怎么办？ 很简单啊，直接通过 HTTP 请求不就完了？ 问题 真的这么简单吗？我们以淘宝的商品详情页为例： 如上图所示，这个页面包含了视频、库存、商品价格、商品评价等内容，这些数据都来自不同的微服务中，所以没办法像传统单体应用一样依靠数据库的 join 查询来得到最终结果，因此就需要多次调用以检索数据，如下图所示： 这就会引发几个严重的问题： 不同的客户端设备可能需要不同的数据。Web,H5,APP，需要单独写一套 API 多次客户端请求导致用户体验不佳。移动网络相较于服务于服务间的局域网，有更低的带宽和更高的延时，如果可以同时执行请求倒也还好，但如果客户端要按照顺序执行请求，就会让用户体验变得异常糟糕。 缺乏封装导致前后端不协调。过分的拆分 API，会导致客户端和服务端过度耦合，再加上移动端 APP 的新版本迭代到每个手机用户时需要很久，这样会使后端很难更改服务的 API。 这样显然是不好的设计，因此，本期的“天降猛男”就出现了——API 网关。 API 网关 在介绍 API 网关前，我们先来介绍一个设计模式——外观模式。 外观模式（Facade Pattern）它向现有的系统添加一个接口，来隐藏系统的复杂性。类图如下所示： 之所以要在说 API 网关前说一下外观模式，是因为二者的设计理念是类似的。 和外观模式类似，API 网关封装了应用程序的内部架构，并为其客户端提供 API，他还可能具有其他职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。下图展示了客户端、API 网关和服务之间的关系。 所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。其出现也是侧面贯彻了软件工程中**“高内聚，低耦合”**的思想。 核心作用 API 网关负责请求路由、API 组合和协议转换。来自外部客户端的所有 API 请求首先会先转到 API 网关，后者再将请求路由到相应的服务。API 网关使用 API 组合模式处理其他请求，调用多个服务并聚合结果。同时他还可以在客户端友好的协议（例如 HTTP）与客户端不友好的协议之间进行转换。 请求路由 当 API 网关收到请求时，随机会查询路由映射，该映射将指定请求路由到哪个服务。例如，路由映射可以将 HTTP 方法和路径映射到服务的 HTTP URL，这一点和 Nginx 提供的反向代理的功能是一样的，后面我们也会对其进行一个比较。...