拜托,面试不要再问我 SpringCloudAlibaba 底层原理

开发 架构
今天我们先一步一步的来让大家理解一下 SpringCloudAlibaba 里面都包含哪些技术组件,在系统里都是用来干什么的,然后再给大家分析一下这些技术底层的原理。

大家好,今天给大家介绍一个非常热门的技术,同时也是面试的时候面试官特别喜欢问的一个话题,那就是 SpringCloudAlibaba 的底层原理。

现在大家都知道,SpringCloudAlibaba 风靡 Java 开发行业,各个公司都在用这套技术,所以咱们 Java 工程师出去面试,面试官对 SpringCloudAlibaba 都搞成了面试必问选项了,但凡面试,总会有面试官问问:“兄弟,SpringCloudAlibaba 玩儿过吗?能聊聊 SpringCloudAlibaba 的底层原理吗?”

这个时候你要是一脸懵圈的说:“兄弟,我们玩儿的是 SpringCloud 啊,你后面加个 Alibaba 干什么?这东西什么时候跟阿里扯上钩了?”要是面试时你这么回答,那么恭喜你,基本上面试官应该会借口肚子疼要上厕所,然后 30 分钟就结束这场面试了。

所以说,咱们这篇文章,就是希望各位兄弟别出现上面那种 30 分钟就被迫结束面试的窘迫问题。

今天我们先一步一步的来让大家理解一下 SpringCloudAlibaba 里面都包含哪些技术组件,在系统里都是用来干什么的,然后再给大家分析一下这些技术底层的原理。

首先,假设你们公司有两个系统,咱们就假设是系统 A 和系统 B 吧,这俩系统现在的需求就是要让系统 A 可以发送一个请求给系统 B 来实现系统间的接口调用。

咱们看下面这个图:

现在有一个最大的问题,系统 A 是部署在一台服务器上的,系统 B 又是部署在另外一台服务器上的,那系统 A 怎么可能莫名其妙的就知道系统B部署在哪台机器上呢?

这就好比说,您在大马路上走着走着,看到一个美女,回家了特别想微信联系她一下,结果您都不知道她的微信号,没加过好友,凭空也没法跟美女搭讪啊!

那跟美女搭讪的正确姿势应该是什么呢?这得有一个前提,就是您有一个中间的朋友,他认识那美女有人家的微信号,这个时候你可以找那中间的朋友要到人家微信号,再根据微信号加人家美女好友,接着就可以实现无缝情感沟通啦!

开个玩笑,上面仅仅是枯燥技术文章中的一个插曲,其实对于您的系统 A 来说,这时就必须引入一个 SpringCloudAlibaba 的关键技术组件,叫做 Nacos。

大家请擦亮眼睛,这个 Nacos 是一个关键名词,一定要记住了,他的学术定位叫做“服务注册中心”。

这个 Nacos 就类似上面说的那个有美女微信号的第三方朋友,他是知道你的系统B部署在哪台机器上的,因为系统 B 在启动的时候会主动向 Nacos 服务注册中心进行服务注册,告诉 Nacos 说自己部署在哪台机器上,自己的机器 ip 地址是 172.86.76.251,自己的端口号是 20880。

大家看下图:

这个时候,系统 A 如果想要调用系统B的接口,就可以发送请求给 Nacos 服务注册中心说,兄弟,能告诉我系统 B 部署在哪台机器上吗?我想调用一下他的接口,这个动作有专业术语,叫做“服务发现”。

然后呢,Nacos 服务注册中心绝对会很大方的把系统 B 的微信号,奥不对,是系统 B 的机器 ip 和端口号都告诉你的。

这时系统 A 知道了系统 B 的 ip 地址和端口号,就可以发送请求过去调用系统 B 的接口了,大家请看下图:

我们再来看下一个问题,假设系统 B 是个大美女,然后还有多个孪生姐妹花,也就是说系统 B 部署在了多台服务器上,我们管这种情况叫做系统 B 有多个服务实例部署在了多台服务器上,然后这个时候系统 A 想要调用系统 B,应该怎么办呢?

我们看下图:

其实也很简单,系统 B 的每个服务实例部署了一台机器后,他们都得对 Nacos 服务注册中心发起服务注册的请求,所以 Nacos 是知道系统 B 部署的每台机器的 ip 地址和端口号的,看下图。

然后这个系统 A 找 Nacos 进行服务发现的时候,一下子就会发现系统 B 部署在了两台机器上,也就是说两台机器的 ip 地址和端口号他都会发现。这个时候问题就来了,系统 A 很犹豫啊,到底调用系统 B 的哪个机器呢?

很简单,他可以第一次调用机器 1,第二次调用机器 2,第三次调用机器 1,第四次机器 2,以此类推,循环往复,这个过程叫做负载均衡,系统 A 可以通过负载均衡把自己的所有请求均匀的分发给系统 B 的每台机器,看下图。

那么下一个问题又来了,系统 A 如果要想办法去调用系统B的某个接口的话,就必须要跟系统 B 建立一个网络连接,然后通过这个网络连接发送请求过去给系统 B。

接着系统 B 收到了请求,以后就会调用自己本地的某个接口的代码,然后再把响应结果通过网络连接返回给系统 A,这个过程就叫做 RPC 远程调用,看下图。

其实这个 RPC 调用的过程,说白了就类似于跟人聊微信的过程,微信聊天你总得先加个好友,完了再发个消息过去,接着人家再给你回一个消息吧?

没错,咱们这 RPC 调用也是同理,你两台机器总得先建立个网络连接,然后系统 A 发个请求过去,系统 B 本地代码执行一下,再返回个响应给你。

那现在问题来了,这个系统 A 那里要对系统 B 部署的多台机器实现负载均衡,然后建立网络连接,接着发起 RPC 调用,就是系统 A 发个请求过去,系统 B 执行一下代码返回个响应,就这套看起来很复杂的流程是谁负责搞定的呢?

简单,就是 SpringCloudAlibaba 里的另外一个关键组件,Dubbo。

这个 Dubbo 就是一个 RPC 的框架,他就是专门负责帮你做负载均衡、网络连接、RPC 调用这些事情的的,这是 SpringCloudAlibaba 组件体系中的第二个关键组件。

大家看下图:

接着再来讨论下一个问题,很多人可能知道,也可能不知道,那就是:一台 4 核 8G 的服务器,每秒钟可以抗多少并发请求?

有一些兄弟平时玩儿过高并发系统,应该是知道这个数值的,那就是 4 核 8G 的服务器上部署的如果是一个 java 系统,这个 java 系统连接的是 MySQL 数据库的话,那么通常来说,这一台服务器每秒大致可以抗 1000 以内的 QPS,如下图,每秒 1000 请求我还特意标红了。

这是为什么呢?原因很简单,我们要从两个维度来分析:

第一个维度是,我们的系统 A 有多少个线程来处理请求,每个请求要耗费多少 ms 来完成,每个线程每秒可以执行多少个请求。

第二个维度是,我们系统 A 的 n 多线程拼命处理请求,这个时候会对机器的 CPU 负载造成多大压力,大概所有线程每秒处理多少请求的时候,机器的 CPU 就扛不住了。

把这两个问题解决清楚了,也就知道系统每秒可以抗多少请求了。

首先看第一个维度,系统 A 一般来说对外接受用户的请求,都是通过 Tomcat 这种 web 服务器,对外用 spring mvc 提供 controller 这种接口的,接收的都是 http 请求。

所以实际上 tomcat 一般来说,我们都会配置 200 左右的线程,就是说系统 A 有 200 个线程会并发的处理用户发来的请求,如下图。

那么下一个问题来了:tomcat 线程处理一个请求要耗费多长时间?

这个就不好说了,因为一个线程处理一个请求的时候,往往会执行你自己写的一大堆业务代码,从 controller 到 service 再到 dao,如果你用 mybatis 做数据持久层框架,那么应该会用 mybatis mapper 执行一大堆的 SQL 语句。

这往往取决于你的系统代码有多复杂,执行的 SQL 语句有多复杂,要执行多少个 SQL,数据库里的表数据是万级、十万级、还是百万级,甚至是千万级、亿级。

所以影响因素太多,我们这里取一个不多不少的均值,假设你一个请求需要调用 n 多次数据库,执行 n 个 SQL 语句,而且数据库里的数据量还小,基本在十万到百万级,那么此时大概你一个请求处理要耗费 200ms,如下图。

所以一个简单的小学公式就可以计算出来了,你一个线程处理一个请求要耗费 200ms,那么每秒就可以处理 5 个请求,你有 200 个线程,每秒可以处理 200*5=1000 个请求,这个小学生级别的算数大家没问题吧?

所以说,按这个维度来说,系统 A 部署在 4 核 8G 的系统上,连接了 MySQL 数据库,然后开 200 个 tomcat 线程处理请求,每秒处理 1000 个请求是比较合理的。

第二个维度呢?就是 CPU 负载这个角度来看,其实也是差不多的,这个没法用算数来计算,只能告诉大家一个经验值,那就是当你的系统部署在 4 核 8G 机器上,连接 MySQL 数据库,然后每个请求都要执行一堆 SQL 语句的时候,往往你的系统每秒处理到 1000 左右的请求量,你的机器 CPU 负载就会达到 80% 甚至 90% 的使用率,这个时候系统负载已经很高了,再让机器处理更多请求,他已经完全就做不到了。

好,那么针对这个系统 A 每秒可以处理 1000 个请求的经验值,我们来考虑一个问题,万一要是你公司搞个活动,突然之间每秒有 2000 个请求过来,或者是被黑客来了个攻击,每秒的请求数量特别多,这个时候你怎么办?

显而易见你的系统 A 会被打死,如下图:

所以这个时候怎么办呢?我们就得引入 SpringCloudAlibaba 里的第三个组件了,就是 Sentinel,这个 Sentinel 就是帮助你的系统实现流量防护的。

当你在系统 A 里加入 Sentinel 以后,如果要是每秒请求超过了 1000,Sentinel 会直接帮你把多出来的那些请求都直接拒绝掉,这就叫做限流,限制你的系统可以处理的请求数量,这样就可以保护你的系统不会被打死,如下图。

那现在我们已经搞明白 SpringCloudAlibaba 里的三个组件的运行原理和使用场景了,Nacos 是服务注册中心,Dubbo 是 RPC 调用框架,Sentinel 是流量防护组件,接着来看最后一个组件,那就是 Seata,分布式事务组件。

既然提到了分布式事务,那就肯定是跟事务是有关系的了,这个事务相信大家都知道,就是我们对 MySQL 可以开启一个事务,事务里执行 n 条 SQL,但凡有一个 SQL 失败了,事务就会回滚,这 n 个 SQL 都不会生效的。

可是在系统 A 调用系统 B 这种分布式的场景下,事务会怎么样呢?

大家看下图,假设系统 A 处理一个请求的时候,先对自己的数据库执行了一堆 SQL,提交了事务 A,然后通过 Dubbo 发起 RPC 调用系统 B,系统 B 对自己的数据库执行了一堆 SQL,提交了事务 B。

那么现在问题来了,假设我系统 A 的事务 A 都提交了,结果到系统 B 的时候,事务 B 执行失败,事务 B 回滚了,这可怎么整?

也就是说一个请求的处理不一致了,一个系统的事务成功都提交完了,没法回滚了,另外一个系统的事务失败了!

别着急,只要你引入 Seata 分布式事务框架,就可以轻松搞定这个问题,Seata 这个框架会自动记录你的事务 A 执行的 SQL 语句的逆向补偿 SQL。

什么意思呢?假设你事务 A 执行的是 insert,那么 Seata 就知道补偿的时候可以 delete 删除。

假设你执行的是 update,那么 Seata 就可以记录你 update 之前的老数据,补偿的时候可以把数据重新 update 回老版本数据,而且这个逆向补偿日志也是记录在数据库里的,如下图。

接着 Seata 还会提供一个 Seata server 来监控你的各个系统的事务执行情况,系统 A 的事务 A 执行成功了得告诉 Seata server,系统 B 的事务 B 执行失败了也得告诉 Seata server,如下图。

当 Seata server 知道你的系统 B 的事务 B 执行失败了,他会告诉系统 A 里的 Seata 框架,小兄弟,人家系统 B 都失败了,你赶紧的吧,别墨迹,把你之前记录的事务 A 逆向补偿日志拿出来,把你之前提交的事务恢复到提交前的数据状态,搞一个逆向回滚,如下图。

好了,到此为止,就给大家把 SpringCloudAlibaba 组件体系的几个组件的使用场景和工作原理介绍清楚了,包括 Nacos 服务注册中心、Dubbo RPC 调用框架、Sentinel 流量防护组件、Seata 分布式事务组件,大家看看上面的那个图,是不是很有成就感?

责任编辑:武晓燕 来源: 石杉的架构笔记
相关推荐

2018-11-09 09:34:05

面试Spring Clou底层

2018-09-28 05:25:53

TopK算法代码

2018-10-28 22:37:00

计数排序排序面试

2018-11-01 13:49:23

桶排序排序面试

2019-08-29 09:49:50

2018-11-06 11:40:19

时间复杂度面试算法

2019-04-16 13:30:05

表达式求值数据结构算法

2019-01-08 15:11:50

最大值最小值算法

2020-04-22 11:19:07

贪心算法动态规划

2021-01-22 10:09:23

简历求职者面试

2020-03-30 17:20:54

B+树SQL索引

2020-09-02 08:04:59

多线程互联网高并发

2020-08-26 08:18:39

数据索引查询

2021-11-24 10:10:32

axios前端拦截器

2020-04-16 08:22:11

HTTPS加解密协议

2022-02-21 22:58:25

排序rowid 排序优化

2020-04-20 13:11:21

HashMap底层存储

2020-12-11 09:24:19

Elasticsear存储数据

2020-09-24 14:40:55

Python 开发编程语言

2021-01-20 07:28:02

nullcollections对象
点赞
收藏

51CTO技术栈公众号