接口调度者——API网关

image

背景

我们知道在微服务架构风格中，一个大应用被拆分成为了多个小的服务系统提供出来，这些小的服务他们自成体系，也就是说这些小系统可以拥有自己的数据库，框架甚至语言等，这些小系统通常以提供 Rest Api 风格的接口来被 H5, Android, IOS 以及第三方应用程序调用。
在《浅入浅出消息队列》这一篇文章中，我提到了消息队列是方便服务与服务之间的通信解耦，如下图所示：

image.png

那么这时候问题来了，如果一个外部的应用（浏览器、App）要去访问这个大应用怎么办？
很简单啊，直接通过HTTP请求不就完了？

问题

真的这么简单吗？我们以淘宝的商品详情页为例：

image

如上图所示，这个页面包含了视频、库存、商品价格、商品评价等内容，这些数据都来自不同的微服务中，所以没办法像传统单体应用一样依靠数据库的 join 查询来得到最终结果，因此就需要多次调用以检索数据，如下图所示：

image.png

这就会引发几个严重的问题：

• 不同的客户端设备可能需要不同的数据。Web,H5,APP，需要单独写一套API
• 多次客户端请求导致用户体验不佳。移动网络相较于服务于服务间的局域网，有更低的带宽和更高的延时，如果可以同时执行请求倒也还好，但如果客户端要按照顺序执行请求，就会让用户体验变得异常糟糕。
• 缺乏封装导致前后端不协调。过分的拆分API，会导致客户端和服务端过度耦合，再加上移动端APP的新版本迭代到每个手机用户时需要很久，这样会使后端很难更改服务的API。

这样显然是不好的设计，因此，本期的“天降猛男”就出现了——API网关。

API网关

再介绍API网关前，我们先来介绍一个设计模式——外观模式。
外观模式（Facade Pattern）它向现有的系统添加一个接口，来隐藏系统的复杂性。类图如下所示：

image

之所以要在说API网关前说一下外观模式，是因为二者的设计理念是类似的。

和外观模式类似，API 网关封装了应用程序的内部架构，并为其客户端提供API，他还可能具有其他职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。下图展示了客户端、API网关和服务之间的关系。

image

所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。其出现也是侧面贯彻了软件工程中“高内聚，低耦合”的思想。

核心作用

API 网关负责请求路由、API组合和协议转换。来自外部客户端的所有API请求首先会先转到API网关，后者再将请求路由到相应的服务。API网关使用API组合模式处理其他请求，调用多个服务并聚合结果。同时他还可以在客户端友好的协议（例如HTTP）与客户端不友好的协议之间进行转换。

请求路由

当API网关收到请求时，随机会查询路由映射，该映射将指定请求路由到哪个服务。例如，路由映射可以将HTTP方法和路径映射到服务的HTTP URL，这一点和Nginx提供的反向代理的功能是一样的，后面我们也会对其进行一个比较。
既然有路由映射，那存放在哪就是一个问题了，我们需要为API网关设置一个路由映射的存储位置，通过可能会用zookeeper等作为注册中心来使用，文末我们也会提一下弊端。

API组合

除去反向代理这个功能外，API网关还提供了API组合的操作。以上面的淘宝详情页为例，如果我们单独获取视频、商品价格、商品评论等信息，需要发多个请求（getVideo,getPrice,getComments）。有了API网关后我们就可以将API接口组合起来，通过一次请求（getItemDetail）来获取需要的信息，如下图所示，这样可以极大的改善由于网络延时导致的差用户体验。

image

协议转换

API网关可以为外部客户端提供RESTful API，即使内部的服务使用混合的通信协议，例如REST、gRPC等。这样做的好处是，对于外部客户端而言，服务端更像是一个不可见的黑盒。

API网关和Nginx

本质上看API网关也是做了请求的转发，那既然Nginx也可以做请求转发，这两者有什么区别？
一张图就可以很好的理解了。

image

Nginx做负载均衡时，考虑到API网关在系统中不止一个（以集群的方式做高可用），我们可以将Nginx至于API网关前，负责对API网关的负载均衡，然后再由网关决定进入到哪个真实的web 服务器。
这样就可以让两者的分工更加明确：API网关聚合服务，Nginx请求转发

API 网关的优缺点

API网关封装了应用程序的内部结构，使得客户端只需要同网关交互，而不必调用特定的服务。同时API 网关为每一类客户端提供了特定的 API ，从而减少客户端与应用程序间的交互次数，简化客户端代码的处理。
但就和所有中间件一样，他们都存在一个共同的问题，API网关的存在使系统增加了一个必须开发、部署和维护的高可用组件。如果这个组件没有处理好，那么 API 网关就会变成了应用的性能瓶颈。
而且为了暴露每个微服务，开发人员必须更新 API 网关，所以就有可能会搭配其他服务发现类的中间件使用，例如zookeeper，这样就又引入了新的中间件。所以我们需要保证API 网关的更新过程要尽可能地简单，否则为了更新网关，开发人员将不得不排队等待。
由此可见，API网关也并不是一颗”银弹”，我们在中间件的选择上还是需要结合项目的实际情况，万不可追求新颖就滥用中间件，适合自己的才是最好的。不过，API网关虽然仍有不足，但对于大多数现实世界的应用程序而言使用 API 网关是合理的。