大家好，今天给大家介绍一个非常热门的技术，同时也是面试的时候面试官特别喜欢问的一个话题，那就是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分布式事务组件，大家看看上面的那个图，是不是很有成就感？请大家好好收藏这个，面试的时候，把上面那个图画出来给面试官看看，一看您就是个懂行的，相信面试流程一定会麻溜儿的继续走下去！
END
【石杉的架构笔记】读者交流群（领取技术干货、技术分享、职场交流），扫码回复：666，即刻加入：
想要更深入学习 Spring Cloud Alibaba 在大型项目中的实战，推荐儒猿课堂重磅出品的《大型企业级分布式订单系统项目》，课程详细介绍参见链接：sourl.cn/aict6k