阅读 1481

接口调度者——API 网关

背景

我们知道在微服务架构风格中,一个大应用被拆分成为了多个小的服务系统提供出来,这些小的服务他们自成体系,也就是说这些小系统可以拥有自己的数据库,框架甚至语言等,这些小系统通常以提供 Rest Api 风格的接口来被 H5, Android, IOS 以及第三方应用程序调用。 在《浅入浅出消息队列》这一篇文章中,我提到了消息队列是方便服务与服务之间的通信解耦,如下图所示: image.png 那么这时候问题来了,如果一个外部的应用(浏览器、App)要去访问这个大应用怎么办? 很简单啊,直接通过HTTP请求不就完了?

问题

真的这么简单吗?我们以淘宝的商品详情页为例: image.png 如上图所示,这个页面包含了视频、库存、商品价格、商品评价等内容,这些数据都来自不同的微服务中,所以没办法像传统单体应用一样依靠数据库的 join 查询来得到最终结果,因此就需要多次调用以检索数据,如下图所示: image.png 这就会引发几个严重的问题:

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

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

API网关

再介绍API网关前,我们先来介绍一个设计模式——外观模式。 外观模式(Facade Pattern)它向现有的系统添加一个接口,来隐藏系统的复杂性。类图如下所示: image.png 之所以要在说API网关前说一下外观模式,是因为二者的设计理念是类似的。 和外观模式类似,API 网关封装了应用程序的内部架构,并为其客户端提供API,他还可能具有其他职责,如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。下图展示了客户端、API网关和服务之间的关系。 image.png 所有的客户端和消费端都通过统一的网关接入微服务,在网关层处理所有的非业务功能。其出现也是侧面贯彻了软件工程中**"高内聚,低耦合"**的思想。

核心作用

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

请求路由

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

API组合

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

协议转换

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

API网关和Nginx

本质上看API网关也是做了请求的转发,那既然Nginx也可以做请求转发,这两者有什么区别? 一张图就可以很好的理解了。 image.png Nginx做负载均衡时,考虑到API网关在系统中不止一个(以集群的方式做高可用),我们可以将Nginx至于API网关前,负责对API网关的负载均衡,然后再由网关决定进入到哪个真实的web 服务器。 这样就可以让两者的分工更加明确:API网关聚合服务,Nginx请求转发

API 网关的优缺点

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

文章分类
后端
文章标签