极客时间已完结课程限时免费阅读

27 | API网关：系统的门面要如何做呢？

27 | API网关：系统的门面要如何做呢？-极客时间

27 | API网关：系统的门面要如何做呢？

2019-11-25 唐扬 来自北京
《高并发系统设计40问》
课程介绍

讲述：唐扬

时长14:08大小12.94M

你好，我是唐扬。
到目前为止，你的垂直电商系统在经过微服务化拆分之后已经运行了一段时间了，系统的扩展性得到了很大的提升，也能够比较平稳地度过高峰期的流量了。
不过最近你发现，随着自己的电商网站知名度越来越高，系统迎来了一些“不速之客”，在凌晨的时候，系统中的搜索商品和用户接口的调用量会急剧上升，持续一段时间之后又回归正常。
这些搜索请求有一个共同特征是来自固定的几台设备。当你在搜索服务上加一个针对设备 ID 的限流功能之后，凌晨的高峰搜索请求不见了。但是不久之后，用户服务也出现了大量爬取用户信息的请求，商品接口出现了大量爬取商品信息的请求。你不得不在这两个服务上也增加一样的限流策略。
但是这样会有一个问题：不同的三个服务上使用同一种策略，在代码上会有冗余，无法做到重用，如果其他服务上也出现类似的问题，还要通过拷贝代码来实现，肯定是不行的。
不过作为 Java 程序员，你很容易想到：将限流的功能独立成一个单独的 jar 包给这三个服务来引用。不过你忽略了一种情况，那就是你的电商团队使用的除了 Java，还有 PHP 和 Go 等多种语言。
用多种语言开发的服务是没有办法使用 jar 包来实现限流功能的，这时你需要引入 API 网关。

API 网关起到的作用

API 网关（API Gateway）不是一个开源组件，而是一种架构模式，它是将一些服务共有的功能整合在一起，独立部署为单独的一层，用来解决一些服务治理的问题。你可以把它看作系统的边界，它可以对出入系统的流量做统一的管控。
在我看来，API 网关可以分为两类：一类叫做入口网关，一类叫做出口网关。
入口网关是我们经常使用的网关种类，它部署在负载均衡服务器和应用服务器之间，主要有几方面的作用。
它提供客户端一个统一的接入地址，API 网关可以将用户的请求动态路由到不同的业务服务上，并且做一些必要的协议转换工作。在你的系统中，你部署的微服务对外暴露的协议可能不同：有些提供的是 HTTP 服务；有些已经完成 RPC 改造，对外暴露 RPC 服务；有些遗留系统可能还暴露的是 Web Service 服务。API 网关可以对客户端屏蔽这些服务的部署地址以及协议的细节，给客户端的调用带来很大的便捷。
另一方面，在 API 网关中，我们可以植入一些服务治理的策略，比如服务的熔断、降级、流量控制和分流等等（关于服务降级和流量控制的细节，我会在后面的课程中具体讲解，在这里你只要知道它们可以在 API 网关中实现就可以了）。
再有，客户端的认证和授权的实现，也可以放在 API 网关中。你要知道，不同类型的客户端使用的认证方式是不同的。在我之前项目中，手机 APP 使用 Oauth 协议认证，HTML5 端和 Web 端使用 Cookie 认证，内部服务使用自研的 Token 认证方式。这些认证方式在 API 网关上可以得到统一处理，应用服务不需要了解认证的细节。
另外，API 网关还可以做一些与黑白名单相关的事情，比如针对设备 ID、用户 IP、用户 ID 等维度的黑白名单。
最后，在 API 网关中也可以做一些日志记录的事情，比如记录 HTTP 请求的访问日志，我在25 讲中讲述分布式追踪系统时，提到的标记一次请求的 requestId 也可以在网关中来生成。
出口网关就没有这么丰富的功能和作用了。我们在系统开发中，会依赖很多外部的第三方系统，典型的例子：第三方账户登录、使用第三方工具支付等等。我们可以在应用服务器和第三方系统之间，部署出口网关，在出口网关中，对调用外部的 API 做统一的认证、授权、审计以及访问控制。
我花一定的篇幅去讲 API 网关起到的作用，主要是想让你了解，API 网关可以解决什么样的实际问题。这样一来，当你在面对这些问题时，你就会有解决的思路，不会手足无措了。

API 网关要如何实现

了解 API 网关的作用之后，接下来，我们来看看 API 网关在实现中需要关注哪些点，以及常见的开源 API 网关有哪些，这样，你在实际工作中，无论是考虑自研 API 网关还是使用开源的实现都会比较自如了。
在实现一个 API 网关时，你首先要考虑的是它的性能。这很好理解，API 入口网关承担从客户端的所有流量。假如业务服务处理时间是 10ms，而 API 网关的耗时在 1ms，那么相当于每个接口的响应时间都要增加 10%，这对于性能的影响无疑是巨大的。而提升 API 网关性能的关键还是在 I/O 模型上（我在23 讲中详细讲到过），这里只是举一个例子来说明 I/O 模型对于性能的影响。
Netfix 开源的 API 网关 Zuul，在 1.0 版本的时候使用的是同步阻塞 I/O 模型，整体系统其实就是一个 servlet，在接收到用户的请求，然后执行在网关中配置的认证、协议转换等逻辑之后，调用后端的服务获取数据返回给用户。
而在 Zuul2.0 中，Netfix 团队将 servlet 改造成了一个 netty server（netty 服务），采用 I/O 多路复用的模型处理接入的 I/O 请求，并且将之前同步阻塞调用后端服务的方式，改造成使用 netty client（netty 客户端）非阻塞调用的方式。改造之后，Netfix 团队经过测试发现性能提升了 20% 左右。
除此之外，API 网关中执行的动作有些是可以预先定义好的，比如黑白名单的设置，接口动态路由；有些则是需要业务方依据自身业务来定义。所以，API 网关的设计要注意扩展性，也就是你可以随时在网关的执行链路上增加一些逻辑，也可以随时下掉一些逻辑（也就是所谓的热插拔）。
所以一般来说，我们可以把每一个操作定义为一个 filter（过滤器），然后使用“责任链模式”将这些 filter 串起来。责任链可以动态地组织这些 filter，解耦 filter 之间的关系，无论是增加还是减少 filter，都不会对其他的 filter 有任何的影响。
Zuul 就是采用责任链模式，Zuul1 中将 filter 定义为三类：pre routing filter（路由前过滤器）、routing filter（路由过滤器）和 after routing filter（路由后过滤器）。每一个 filter 定义了执行的顺序，在 filter 注册时，会按照顺序插入到 filter chain（过滤器链）中。这样 Zuul 在接收到请求时，就会按照顺序依次执行插入到 filter chain 中的 filter 了。
另外还需要注意的一点是，为了提升网关对于请求的并行处理能力，我们一般会使用线程池来并行的执行请求。不过，这就带来一个问题：如果商品服务出现问题造成响应缓慢，那么调用商品服务的线程就会被阻塞无法释放，久而久之，线程池中的线程就会被商品服务所占据，那么其他服务也会受到级联的影响。因此，我们需要针对不同的服务做线程隔离或者保护。在我看来有两种思路：
如果你后端的服务拆分得不多，可以针对不同的服务，采用不同的线程池，这样商品服务的故障就不会影响到支付服务和用户服务了；
在线程池内部可以针对不同的服务甚至不同的接口做线程的保护。比如说，线程池的最大线程数是 1000，那么可以给每个服务设置一个最多可以使用的配额。
一般来说，服务的执行时间应该在毫秒级别，线程被使用后会很快被释放回到线程池给后续请求使用，同时处于执行中的线程数量不会很多，对服务或者接口设置线程的配额不会影响到正常的执行。可是一旦发生故障，某个接口或者服务的响应时间变长，造成线程数暴涨，但是因为有配额的限制，也就不会影响到其他的接口或者服务了。
你在实际应用中也可以将这两种方式结合，比如说针对不同的服务使用不同的线程池，在线程池内部针对不同的接口设置配额。
以上就是实现 API 网关的一些关键的点，你如果要自研 API 网关服务的话可以参考借鉴。另外 API 网关也有很多开源的实现，目前使用比较广泛的有以下几个：
Kong是在 Nginx 中运行的 Lua 程序。得益于 Nginx 的性能优势，Kong 相比于其它的开源 API 网关来说，性能方面是最好的。由于大中型公司对于 Nginx 运维能力都比较强，所以选择 Kong 作为 API 网关，无论是在性能还是在运维的把控力上，都是比较好的选择；
Zuul是 Spring Cloud 全家桶中的成员，如果你已经使用了 Spring Cloud 中的其他组件，那么也可以考虑使用 Zuul 和它们无缝集成。不过，Zuul1 因为采用同步阻塞模型，所以在性能上并不是很高效，而 Zuul2 推出时间不长，难免会有坑。但是 Zuul 的代码简单易懂，可以很好地把控，并且你的系统的量级很可能达不到 Netfix 这样的级别，所以对于 Java 技术栈的团队，使用 Zuul 也是一个不错的选择；
Tyk是一种 Go 语言实现的轻量级 API 网关，有着丰富的插件资源，对于 Go 语言栈的团队来说，也是一种不错的选择。
那么你要考虑的是，这些开源项目适不适合作为 API 网关供自己使用。而接下来，我以电商系统为例，带你将 API 网关引入我们的系统之中。

如何在你的系统中引入 API 网关

目前为止，我们的电商系统已经经过了服务化改造，在服务层和客户端之间有一层薄薄的 Web 层，这个 Web 层做的事情主要有两方面：
一方面是对服务层接口数据的聚合。比如，商品详情页的接口可能会聚合服务层中，获取商品信息、用户信息、店铺信息以及用户评论等多个服务接口的数据；
另一方面 Web 层还需要将 HTTP 请求转换为 RPC 请求，并且对前端的流量做一些限制，对于某些请求添加设备 ID 的黑名单等等。
因此，我们在做改造的时候，可以先将 API 网关从 Web 层中独立出来，将协议转换、限流、黑白名单等事情挪到 API 网关中来处理，形成独立的入口网关层；
而针对服务接口数据聚合的操作，一般有两种解决思路：
再独立出一组网关专门做服务聚合、超时控制方面的事情，我们一般把前一种网关叫做流量网关，后一种可以叫做业务网关；
抽取独立的服务层，专门做接口聚合的操作。这样服务层就大概分为原子服务层和聚合服务层。
我认为，接口数据聚合是业务操作，与其放在通用的网关层来实现，不如放在更贴近业务的服务层来实现，所以，我更倾向于第二种方案。
同时，我们可以在系统和第三方支付服务，以及登陆服务之间部署出口网关服务。原先，你会在拆分出来的支付服务中完成对于第三方支付接口所需要数据的加密、签名等操作，再调用第三方支付接口完成支付请求。现在，你把对数据的加密、签名的操作放在出口网关中，这样一来，支付服务只需要调用出口网关的统一支付接口就可以了。
在引入了 API 网关之后，我们的系统架构就变成了下面这样：

课程小结

本节课我带你了解了 API 网关在系统中的作用，在实现中的一些关键的点，以及如何将 API 网关引入你的系统，我想强调的重点如下：
API 网关分为入口网关和出口网关两类，入口网关作用很多，可以隔离客户端和微服务，从中提供协议转换、安全策略、认证、限流、熔断等功能。出口网关主要是为调用第三方服务提供统一的出口，在其中可以对调用外部的 API 做统一的认证、授权、审计以及访问控制；
API 网关的实现重点在于性能和扩展性，你可以使用多路 I/O 复用模型和线程池并发处理，来提升网关性能，使用责任链模式来提升网关的扩展性；
API 网关中的线程池可以针对不同的接口或者服务做隔离和保护，这样可以提升网关的可用性；
API 网关可以替代原本系统中的 Web 层，将 Web 层中的协议转换、认证、限流等功能挪入到 API 网关中，将服务聚合的逻辑下沉到服务层。
API 网关可以为 API 的调用提供便捷，也可以为将一些服务治理的功能独立出来，达到复用的目的，虽然在性能上可能会有一些损耗，但是一般来说，使用成熟的开源 API 网关组件，这些损耗都是可以接受的。所以，当你的微服务系统越来越复杂时，你可以考虑使用 API 网关作为整体系统的门面。

一课一思

你的项目中是否有使用 API 网关呢？你在使用 API 网关的时候，遇到过什么样的问题吗？欢迎在留言区与我分享你的经验。
最后，感谢你的阅读，如果这篇文章让你有所收获，也欢迎你将它分享给更多的朋友。
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 14

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
26 | 负载均衡：怎样提升系统的横向扩展能力？
下一篇
28 | 多机房部署：跨地域的分布式系统如何做？
 写留言

精选留言(37)

  • Julien
    2019-11-25
    上一讲的负载均衡和这一讲的API网关是什么关系呢？

    作者回复: 作用不同，负载均衡作用是分流，API网关作用是服务治理

    29
  • 小洛
    2020-02-11
    之前用zuul做过网关，思路和老师说的大同小异，有授权，有检验，有限流熔断，也有线程池隔离等，就是聚合服务没有抽成单独的服务来做，因为在组织架构上，大家都不想接手这种聚合别人接口的服务，有时候这种非技术的问题让人特别困惑！所以当初就设计了一个配置api中可以配置多个服务接口，网关把结果整合，然后json返回了！

    作者回复: 这样也好

    共 3 条评论
    20
  • Darren
    2020-04-01
    Spring cloud gateway 性能比zuul好一些，并且是异步的

    作者回复: 是的

    共 2 条评论
    13
  • 张德
    2019-11-25
    老师 请教一下 这个oauth2.0的登录认证 请求是先经过网关后验证是否登录了 还是什么别的流程 能否讲一下这个架构下 登录鉴权应该怎么做？？？

    作者回复: 就是请求在经过网关后，先做oauth的认证，认证成功后，将一些用户信息写入到request里面，这样业务服务器就不需要关心认证了

    共 2 条评论
    9
  • Hesher
    2020-05-26
    出口网关这个概念还是第一次听到，感谢老师。对于出口网关，做与三方机构接口调用的封装、鉴权和审计。 但问题是第三方接口调用逻辑（比如调用哪几个接口、顺序是什么样的）、鉴权方式差异很大，都放在出口网关去封装，不是反而互相耦合了吗？我这边支付系统是把同类逻辑抽离出来，具体的接口调用和鉴权流程，是对每个二方或三方平台单独部署的微服务。 老师能否在细化讲一下出口网关呢？
    展开
    共 1 条评论
    4
  • Xiang
    2020-02-24
    apisix 这个API网关性能很好 https://github.com/apache/incubator-apisix

    作者回复: 谢谢，我研究一下

    4
  • 刘冲
    2019-11-27
    请问，像sql注入拦截这种工作，是后端每个微服务要做的事情呢？还是都应该只需要放在api网关来做？

    作者回复: 这种安全策略可以放在API网关中来做

    共 4 条评论
    4
  • 钱
    2020-04-28
    API网关，这个也一定使用过，不过距离自己的编码距离有些远，没实际直接接触过。 类似一个村子的主路口，进村时做安全、鉴权、限流、熔断等控制，出村时做认证、审计、授权等工作。

    作者回复: 是的，可能开发同学了解不多

    共 2 条评论
    3
  • JOHN
    2020-03-10
    看了本文，这边我有几个问题想请教下老师？ 1、不太清楚业务网关与聚合服务层之间的区别 2、在服务调用上，我觉得很多接口并不是聚合接口，那是否api网关也可以直接调用原子服务层 3、api网关与web服务的最大区别点就是 web服务多了服务聚合的功能么？？

    作者回复: api网关有转换协议，限流，熔断等功能

    2
  • 古德
    2020-01-06
    我的理解聚合业务层就是BFF层吧，一般是按照业务范围来分，应该放网关层后面，网关层和业务要无关

    作者回复: 可以认为是BFF层

    2
  • 高志强
    2020-03-31
    老师我想问一下，这个api网关处在，负载均衡服务和应用服务之间么，都用它这个api网关万一挂了怎么办？

    作者回复: 是的，服务要保证可用性呀

    共 2 条评论
    1
  • sami
    2020-03-19
    Spring推出了一个spring cloud gateway

    作者回复: 也是一种网关选型

    1
  • 电光火石
    2019-12-05
    聚合服务是否可以考虑用graphql来做？
    共 1 条评论
    1
  • longslee
    2019-11-27
    打卡。只是简单的使用nginx。职责链模式是我最喜欢的设计模式没有之一，哈哈哈。 提个问题：出口网关这里，还是倾向于设计一个直接调用的出口网关吗？那这样的话出口网关怎样通知调用它的下游呢？ 是否采用消息队列？

    作者回复: 出口网关是直接调用第三方的服务的

    1
  • 刘楠
    2019-11-25
    好像一个过滤器，系统
    1
  • stubborn
    2019-11-25
    请教一下老师，增加聚合服务有什么约束条件吗？比如聚合服务要同时写入服务A和服务B，这样很容易引起分布式事务。
    共 5 条评论
    1
  • 刘聪为
    2021-10-18
    线程池配额怎么做的
  • codewor
    2020-12-08
    老师，请教一个问题，聚合服务与原子服务是同级还是父子关系的？
  • windfly
    2020-11-21
    老师，我是做前端的，我经常听说用nodejs搭建BFF，这里的BFF层和API网关是不是同一个意思，或者说BFF层是API网关架构的一种实现？
    共 1 条评论
  • null
    2020-09-27
    老师，您好，原文提到的：针对不同的服务使用不同的线程池，在线程池内部针对不同的接口设置配额。 这是针对自研网关的方案么？像使用开源的网关如 zuul，spring cloud gateway，是不是就不太好应用这个解决方案了？ 还想问一个问题，springmvc 它属于网关框架么？因为文中提到了 zuul 和 spring cloud gateway，却没有提到 springmvc。或者说，springmvc 和这两者有啥不同？ 谢谢老师！！
    展开