为什么微服务开发体系中,一定要有 API 网关?

2022-08-0720:31:07软件工程与架构Comments1,019 views字数 2339阅读模式

微服务不能没有网关,就如同 Java 程序员不能没有 IDEA、Eclipse。为什么呢?文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

之所以网关对微服务这么重要,主要有以下几点原因:文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

1. 解决 API 放哪里的问题

要知道,采用微服务架构的系统本身是由很多的独立服务单元组合起来的。而客户端要调用系统,则必须通过系统提供的各种对外开放的 API 来实现。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

问题来了,这些 API 要放在哪里呢?直接放在组成系统的服务单元上行不行?文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

比如,在一套电商系统上,关于订单相关的 API ,放在组成订单服务的服务单元上;风控服务的 API ,放在组成风控服务的服务单元上。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

好,咱们假设有这么一个场景,有一位用户想在这套电商系统上查看下商品详情。那么,这个查看商品详情的操作,就可能:文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

  • 调用商品服务的 API 获取商品描述
  • 调用评价服务的 API 获取相关评价
  • 调用商家服务的 API 获取商家信息
  • 调用礼券服务的 API 获取相关礼券
  • ……

可以看到,就这么一个商品查看操作,就可能会调用许多服务的 API。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

那这些 API 如果全部分散到各个服务单元上,供客户端调用,像查看商品这么简单的一次操作,客户端就可能需要远程访问好几次甚至十几次服务器。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

微服务自己又讲究把 API 的粒度划分的很细,也就是说,可能从商品服务上调用商品信息,不止是调用一次商品服务就够了,很可能需要多次对商品服务的不同 API 进行调用,才能获取到足够的数据。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

这样一来,客户端需要访问服务器的次数就更多了,可能十几次都不够,得几十次。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

这种多次访问服务器的行为,会极大延迟客户端的界面响应时间,很不现实。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

所以,把 API 放到各个业务相关的服务单元上,看上去问题很大。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

那为什么引入网关就能解决这个问题呢?文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

因为引入网关,就相当于在客户端和微服务之间加了一层隔离。通常,网关本身会和各个服务单元处于同一个机房,这样,客户端做业务操作的时候,只需要访问一次网关。然后剩下的事情,再由网关分别访问同在一个机房的不同的服务,再把拿到的数据统一在网关封装好,返回给客户端就好。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

2. 解决边缘功能集成的问题

在一套微服务组成的系统里,除了必须的业务功能以外,还有为了系统自身的健壮与安全,以及微服务本身的管理,而必须引入的一些非业务功能。对于这些非业务又很重要的功能,我们统称为边缘功能。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

还是拿电商系统为例,我们来看一些重要的边缘功能。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

假设因为我们做了一次非常大的促销活动,导致流量过大,系统承载不了了。此时,为了保证系统本身的稳定,我们就需要把一些承载不了的流量给通过各种手段消化掉,一般的做法有三种:文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

  • 限流:通过令牌桶等算法,把一些额外的流量挡在系统外面,不让其访问。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html
  • 降级:由于系统可能已经过载了,此时,我们就放弃处理一些服务和页面的请求或者仅简单处理,比如直接返回一个报错。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html
  • 熔断:有些时候,系统过载过度或者上线出了 bug,降级都解决不了问题。比如,缓存失效了,导致大量请求频繁访问了数据库,而这种频繁访问数据库可能造成了大量的 IO 操作,结果又去影响了数据库所在的操作系统,同时,这个操作系统上又有着别的重要服务,直接也被影响了。对于这种连锁反应,我们称之为雪崩。而为了防止雪崩,我们就会坚决把缓存失效导致数据库被频繁访问的服务给停掉,这就是熔断。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

可以看到,像限流、降级、熔断这些系统保障策略,最合适的地方应该是有一个集中的请求入口点,就像古时候,老百姓进城需要过城门那样。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

当系统出现问题的时候,直接就在这个入口点做相应的操作即可。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

  • 限流,就直接在这个入口点限制后续请求。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html
  • 降级,就直接在这个入口点判断请求想要访问的服务或者页面,直接报错返回。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html
  • 熔断,就直接在这个入口点,断开所有访问特定服务的请求连接,然后再把后继对特定服务的访问,也统统拦在门外。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

在电商系统里,有很多特殊场景的接口,需要受到严格的限制。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

比如,支付接口,访问它就需要认证和权限控制。又比如,对于系统的访问,有时候不能让国外的去访问国内的网站,这就需要限制客户端的访问 IP,所以系统还需要认证和授权功能。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

那这种认证和授权也最合适放在请求的一个集中入口点,统一实现。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

还记得上面咱们说过的网关的 API 统一存放吗?我们只需要对这些 API 做对应的权限设置,当请求访问特殊场景接口的时候,必定会通过 API 访问。所以,限制接口的访问,本质上就是对特定 API 的限制,那么,放在网关再合适不过了。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

现实里,我们有时候需要把线上的流量镜像出来,转发到灰度环境,利用这些镜像出来的流量既可以用于小范围测试,又可以更好的评估系统所能承载的最大吞吐量,也因此,系统需要有一个统一入口做分流。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

可以看到,无论是系统需要的保障策略,认证授权,还是流量分流等功能,都应该放到一个统一的请求入口处才能得到最好的实现。网关恰好就承担了这么个统一请求入口的角色。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

所以,对于微服务中,林林总总的边缘功能,往往会通过插件的形式,集成在 API 网关中。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

3. 解耦了客户端和后端微服务

一套项目,在使用微服务模式的初期,往往后端变化是十分频繁的。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

频繁变化的原因有很多,像业务领域划分不合适啊,像某个业务模块急速膨胀啊,都可能导致后端微服务的剧烈变化。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

在这种情况下,如果没有网关,很可能就会出现客户端需要被迫随着后端的变化而变化的情况。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

比如,在电商系统里,初期我们很可能会把风控服务做的非常小。随着业务的发展,风控服务越来越庞大,此时,风控服务就可能被分解为决策引擎和分析中心等更多更细的服务。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

在电商里,风控往往是下单、支付等操作的必要前置操作。如果没有网关去分隔开客户端和微服务,客户端直接和风控服务打交道,那么风控服务拆分,API 必然不会稳定,API 的变化,自然会引发调用 API 客户端代码的变化。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

有了网关之后,情况就好了很多了。当风控服务本身频繁变化的时候,我们只需要改动网关的代码就好。而服务器代码的升级可是远远要比客户端代码的升级容易太多了。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/arc/26804.html

  • 本站内容整理自互联网,仅提供信息存储空间服务,以方便学习之用。如对文章、图片、字体等版权有疑问,请在下方留言,管理员看到后,将第一时间进行处理。
  • 转载请务必保留本文链接:https://www.cainiaoxueyuan.com/arc/26804.html

Comment

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定