来源：mikechen的互联网架构

大家好，我是mikechen。

SpringCloudAlibaba是微服务的核心实现，也是大型网站架构必备技能，下面我就全面来详解Spring Cloud Alibaba

Spring Cloud Alibaba

Spring Cloud Alibaba致力于提供微服务开发的一站式解决方案，是微服务Spring Cloud的第二代实现。

Spring Cloud Alibaba功能，主要包含如下：

1.服务限流降级

默认支持 Servlet、Feign、RestTemplate、Dubbo 和 RocketMQ 限流降级功能的接入，还支持查看限流降级 Metrics 监控。

2.服务注册与发现

适配 SpringCloud 服务注册与发现标准(默认集成了 Ribbon的支持)。

3.分布式配置管理

基于Nacos实现分布式系统中的外部化配置。

4.分布式事务

基于Seata实现分布式事务解决方案。

5.消息驱动能力

基于 SpringCloudStream 为微服务应用构建消息驱动能力。

6.分布式任务调度

提供秒级、精准、高可靠、高可用的定时任务调度服务。

Spring Cloud Alibaba组件

Sentinel

Sentinel从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

1.流量控制

我们的机器不可能无限制的接受和处理客户端的请求，如果不加以限制，当发生高并发情况时，系统资源将很快被耗尽。为了避免这种情况，我们就可以添加流量控制

Sentinel 作为一个调配器，可以根据需要把随机的请求调整成合适的形状，如下图所示：

流量控制有以下几个角度：

资源的调用关系：例如资源的调用链路，资源和资源之间的关系；

运行指标：例如 QPS、线程池、系统负载等；

控制的效果：例如直接限流、冷启动、排队等；

2.限流

Sentinel提供了两种流量统计方式：

一种是统计并发线程数；

另外一种则是统计 QPS；

当并发线程数超出某个设定的阈值，新的请求会被立即拒绝，当QPS超出某个设定的阈值，系统可以拒绝等方式来应对，从而起流量控制的作用。

3.熔断降级

接触过Spring Cloud的同学，都知道熔断降级的概念。

服务之间会有相互依赖关系，例如：服务A做到了1秒上万个QPS，但这时候服务B并无法满足1秒上万个QPS，那么如何保证服务A在高频调用服务B时，服务B仍能正常工作呢？

一种比较常见的情况是：服务A调用服务B时，服务B因无法满足高频调用出现响应时间过长的情况，导致服务A也出现响应过长的情况，进而产生连锁反应影响整个依赖链上的所有应用。

这时候就需要熔断和降级的方法，Sentinel 熔断降级会在调用链路中某个资源出现不稳定状态时，进行限制，避免影响到其它的资源而导致级联错误。

在Sentinel中判断资源是否处于稳定状态的指标或者纬度：

慢调用比例（SLOW_REQUEST_RATIO）

异常比例（ERROR_RATIO）

异常数（ERROR_COUNT）

Nacos

Nacos是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台，你可以用Nacos代替Eureka和Apollo两个组件。

Nacos主要的功能有：注册中心和配置中心。

1.注册中心

服务注册是在服务治理框架中，都会构建一个注册中心，每个服务单元向注册中心登记自己提供服务的详细信息。

Nacos的注册中心，架构如下图所示：

2.配置中心

Nacos 客户端会循环请求服务端变更的数据，并且超时时间设置为30s，当配置发生变化时，请求的响应会立即返回。

RocketMQ

消息队列在工作中你或多或少都会接触到，有用Kafka的，也有用RabbitMQ的，在Spring CloudAlibaba体系中，推荐使用RocketMQ了。

使用消息队列可以让服务之间更加解耦，可以进行流量消峰，还有一个场景就是利用事务消息来实现分布式事务。

RocketMQ主要由NameServer、Broker、Producer以及Consumer四部分构成。

1）NameServer：主要负责对于源数据的管理，包括了对于Topic和路由信息的管理。

NameServer是一个功能齐全的服务器，其角色类似Dubbo中的Zookeeper，但NameServer与Zookeeper相比更轻量。主要是因为每个NameServer节点互相之间是独立的，没有任何信息交互。

备注：下面的消息类型有Topic的介绍。

2） Producer

消息生产者，负责产生消息，一般由业务系统负责产生消息。

Producer由用户进行分布式部署，消息由Producer通过多种负载均衡模式发送到Broker集群，发送低延时，支持快速失败。

3 ）Broker

消息中转角色，负责存储消息，转发消息。

Broker是具体提供业务的服务器，单个Broker节点与所有的NameServer节点保持长连接及心跳，并会定时将Topic信息注册到NameServer，顺带一提底层的通信和连接都是基于Netty实现的。

Broker负责消息存储，以Topic为纬度支持轻量级的队列，单机可以支撑上万队列规模，支持消息推拉模型。

官网上有数据显示：具有上亿级消息堆积能力，同时可严格保证消息的有序性。

4）Consumer

消息消费者，负责消费消息，一般是后台系统负责异步消费。

Consumer也由用户部署，支持PUSH和PULL两种消费模式，支持集群消费和广播消息，提供实时的消息订阅机制。

Seata

Seata是阿里巴巴开源的高性能微服务分布式事务解决方案。

Seata事务管理中有三个重要的组件角色，如下图所示：

三个组件相互协作，TC 以 Server 形式独立部署，TM和RM集成在应用中启动。

1.TC (Transaction Coordinator) 事务协调者

TC：维护全局和分支事务的状态，协调全局事务提交或回滚。

2.TM (Transaction Manager) 事务管理器

TM：定义全局事务的范围、开始全局事务、提交或回滚全局事务。

3.RM (Resource Manager) -资源管理器

RM：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

一个典型的seata分布式事务的流程如下：

Alibaba Cloud OSS: 阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。

Alibaba Cloud SchedulerX: 阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。

Alibaba Cloud SMS: 覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。

Dubbo

Dubbo是一款Java RPC框架，致力于提供高性能的RPC远程服务调用方案。

Dubbo主要包含如下几个核心组件：

Dubbo工作原理

Dubbo的调用流程，大致如下图所示：

对照上面的整体架构图，大致分为以下8大步骤：

1、服务提供者启动，开启Netty服务，创建Zookeeper客户端，向注册中心注册服务；

2、服务消费者启动，通过Zookeeper向注册中心获取服务提供者列表，与服务提供者通过Netty建立长连接；

3、服务消费者通过接口开始远程调用服务，ProxyFactory通过初始化Proxy对象，Proxy通过创建动态代理对象；

4、动态代理对象通过invoke方法，层层包装生成一个Invoker对象，该对象包含了代理对象；

5、Invoker通过路由，负载均衡选择了一个最合适的服务提供者，在通过加入各种过滤器，协议层包装生成一个新的DubboInvoker对象；

6、再通过交换成将DubboInvoker对象包装成一个Reuqest对象，该对象通过序列化通过NettyClient传输到服务提供者的NettyServer端；

7、到了服务提供者这边，再通过反序列化、协议解密等操作生成一个DubboExporter对象,再层层传递处理,会生成一个服务提供端的Invoker对象；

8、这个Invoker对象会调用本地服务，获得结果再通过层层回调返回到服务消费者，服务消费者拿到结果后，再解析获得最终结果。

Spring Cloud Alibaba 的典型应用场景如下：

大型复杂的系统，例如：大型电商系统，大型的直播系统，大型网站系统等;

高并发系统，例如：阿里双11为代表的商品秒杀系统，以及亿级高并发的系统;

Spring Cloud Alibaba总结

总结使用Spring Cloud来构建微服务架构时我们可以使用哪些框架，为大家做技术选型提供一个参考。

服务注册与发现：Nacos；

服务熔断限流：Sentinel；

服务通信调用：Feign；

配置中心：Nacos；

服务网关：Spring Cloud Gateway；

分布式事务：Seata；

消息队列：RocketMQ；

调用链监控：Sleuth+Zipkin；

分布式任务调度：XXL-JOB；