一、服务注册中心-Nacos
首先，假设现在有两个系统，咱们就假设是系统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部署在哪台机器上吗？我想调用一下他的接口，这个动作有专业术语，叫做【服务发现】。
我们再来看下一个问题，假设系统B是个大美女，然后还有多个孪生姐妹花，也就是说系统B部署在了多台服务器上，我们管这种情况叫做系统B有多个服务实例部署在了多台服务器上，然后这个时候系统A想要调用系统B，应该怎么办呢？其实也很简单，系统B的每个服务实例部署了一台机器后，他们都得对Nacos服务注册中心发起服务注册的请求，所以Nacos是知道系统B部署的每台机器的ip地址和端口号的。然后这个系统A找Nacos进行服务发现的时候，一下子就会发现系统B部署在了两台机器上，也就是说两台机器的ip地址和端口号他都会发现。
这个时候问题就来了，系统A很犹豫啊，到底调用系统B的哪个机器呢？很简单，他可以第一次调用机器1，第二次调用机器2，第三次调用机器1，第四次机器2，以此类推，循环往复，这个过程叫做负载均衡，系统A可以通过负载均衡把自己的所有请求均匀的分发给系统B的每台机器。
二、RPC-Dubbo
那么下一个问题又来了，系统A如果要想办法去调用系统B的某个接口的话，就必须要跟系统B建立一个网络连接，然后通过这个网络连接发送请求过去给系统B，接着系统B收到了请求，以后就会调用自己本地的某个接口的代码，然后再把响应结果通过网络连接返回给系统A，这个过程就叫做RPC远程调用。其实这个RPC调用的过程，说白了就类似于跟人聊微信的过程，微信聊天你总得先加个好友，完了再发个消息过去，接着人家再给你回一个消息吧？没错，咱们这 RPC 调用也是同理，你两台机器总得先建立个网络连接，然后系统A发个请求过去，系统B本地代码执行一下，再返回个响应给你。
那现在问题来了，这个系统A那里要对系统B部署的多台机器实现负载均衡，然后建立网络连接，接着发起RPC调用，就是系统A发个请求过去，系统B执行一下代码返回个响应，就这套看起来很复杂的流程是谁负责搞定的呢？简单，就是SpringCloudAlibaba里的另外一个关键组件Dubbo。这个Dubbo就是一个RPC的框架，他就是专门负责帮你做负载均衡、网络连接、RPC调用这些事情的的，这是SpringCloudAlibaba组件体系中的第二个关键组件。
三、流量防护-Sentinel
3.1 一台4核8G的服务器-QPS
接着再来讨论下一个问题，很多人可能知道，也可能不知道，那就是：一台4核8G的服务器，每秒钟可以抗多少并发请求？
有一些同学平时玩儿过高并发系统，应该是知道这个数值的，那就是4核8G的服务器上部署的如果是一个Java系统，这个Java系统连接的是MySQL数据库的话，那么通常来说，这一台服务器每秒大致可以抗1000以内的QPS。这是为什么呢？原因很简单，我们要从两个维度来分析
第一个维度是，我们的系统A有多少个线程来处理请求，每个请求要耗费多少ms来完成，每个线程每秒可以执行多少个请求。
第二个维度是，我们系统A的n多线程拼命处理请求，这个时候会对机器的CPU负载造成多大压力，大概所有线程每秒处理多少请求的时候，机器的CPU就扛不住了。
把这两个问题解决清楚了，也就知道系统每秒可以抗多少请求了。首先看第一个维度，系统A一般来说对外接受用户的请求，都是通过Tomcat这种web服务器，对外用spring mvc提供controller这种接口的，接收的都是http请求，所以实际上tomcat一般来说，我们都会配置200左右的线程，就是说系统A有200个线程会并发的处理用户发来的请求。
3.2 Tomcat线程处理一个请求耗时
那么下一个问题来了：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会被打死。
3.3 Sentinel
所以这个时候怎么办呢？我们就得引入SpringCloudAlibaba里的第三个组件了，就是Sentinel，这个Sentinel就是帮助你的系统实现流量防护的。当你在系统A里加入Sentinel以后，如果要是每秒请求超过了1000，Sentinel会直接帮你把多出来的那些请求都直接拒绝掉，这就叫做限流，限制你的系统可以处理的请求数量，这样就可以保护你的系统不会被打死。
四、分布式事务-Seata
那现在我们已经搞明白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逆向补偿日志拿出来，把你之前提交的事务恢复到提交前的数据状态，搞一个逆向回滚。
