虽然 Spring Cloud 提供了非常强大的功能，但是它并不提供所有的实现，而是通过springcloud common 子项目，定义了统一的抽象 API。Alibaba 结合自己的 Nacos、Dubbo、Sentinel 等开源中间件，实现了 springcloud alibaba

Spring Cloud for Alibaba，它是由一些阿里巴巴的开源组件和云产品组成的。这个项目的目的是为了让大家所熟知的 Spring 框架，其优秀的设计模式和抽象理念，以给使用阿里巴巴产品的 Java 开发者带来使用 Spring Boot 和 Spring Cloud 的更多便利。

服务发现：

Nacos（Alibaba）：优点是社区活跃，支持各种协议，新特性频出，甚至兼容了istio这样的下一代微服务架构。

Eureka（Netflix）：老牌劲旅，优点是稳定，缺点社区不再维护，它的想象空间也就仅限于此了。

配置中心：

Apollo（携程）：一些通用的配置中心功能，比如热发布，灰度发布等，Apollo都能够cover。不同于Eureka，Apollo社区是在持续维护的，中文文档齐全，为其背书的厂商不在少数。

Nacos（Alibaba）：从功能上来看两者都能满足需求，Apollo在生产落地的经验上更胜一筹。

熔断限流：

Sentinel（Alibaba）：功能强大，稳定

Hystrix （Netflix）：功能强大，稳定，社区停止维护

建议采用Sentinel。

其他模块的选择，分布式事务，seata（Alibaba）；网关，Gateway（Spring）；分布式链路追踪：Sleuth。

springcloud alibaba生态：

spring cloud Alibaba 提供一套微服务开发一站式解决方案

主要功能

服务注册和发现

分布式配置中心

服务限流降级

分布式事务

消息驱动

组件

Nacos

Sentinel

优点

国产

比较全

阿里的经得起考验值得信赖

springcloud alibaba 总生态，最全面的一个服务架构图

微服务的介绍

系统架构演变

系统架构大体经历了：单体应用架构–》垂直应用架构–》分布式架构–》SOA架构–》微服务架构

1.单体应用架构

单体应用架构，所有的功能都在一个项目里完成

优点：

架构简单易懂
对于一些小型项目来讲，开发，维护简单
部署到一个单点tomcat上，后期维护方便

缺点：

对大型项目来讲，维护困难
模块之间紧密耦合，单点容错率低
无法针对某一个模块进行水平扩展或优化

2，垂直应用架构

单体服务进行拆分为多个服务

优点：

系统拆分之后，就可以进行水平扩展和优化
提高了单点容错率

缺点

系统之间无法相互调用
会有一部分代码重复

3.分布式架构

服务继续拆分，公共模块公用

优点

抽取公共代码为服务层，增强代码复用性

缺点

调用关系复杂，维护困难

4.SOA架构

优点

使用服务治理中心帮我们维护复杂的调用关系

缺点

服务有依赖性，可能会因为一个服务有问题导致多个系统不可用（拆分的不彻底，还有耦合）

5.微服务架构

服务的原子化拆分
微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步，他更加强调服务的“彻底拆分”
优点
服务原子化差分，独立打包，部署和升级，保证每个微服务清晰的任务划分，利于扩展
微服务之间采用Restful等轻量级http协议相互调用
缺点
分布式系统开发的技术成本高（容错、分布式事务等）

微服务架构介绍

微服务架构的常见问题

这么多的小服务，我们如果管理？
他们之间如何调用？
客户端如何来访问？
如果出现问题，那么作为服务自身来讲，应该如何处理
如果中间哪个环节出了问题，作为程序员来讲，如何排查

微服务架构的常见概念
服务治理：服务治理就是进行自动化管理，其核心是服务的自动注册与发现

服务注册：服务实例将自身的信息注册到注册中心
服务发现：服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求他们提供服务
服务剔除：服务注册中心

服务调用

在微服务构架中，通常存在多个服务之间的远程调用的需求。目前主流的远程调用技术1，有基于HTTP的RESTful接口，以及基于TCP的RPC协议
REST(Representational State Transfer)
是一种HTTP调用的格式，更标准，更通用，无论哪种语言都支持http协议

2，RPC(Remote Promote Call)
一种进程间的通信方式。允许像调用本地服务一样调用远程服务。RPC框架的主要目标就是让远程服务调用更简单、透明。RPC框架负责屏蔽底层的传输方式，序列化方式和通信细节。开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程

服务网关

随着微服务的不断增多，不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求，如果让客户端直接与各个微服务通信可能出现

客户端需要调用不同的url地址，难度增大
在一定的场景下，存在跨域请求的问题
每个微服务都需要进行单独的身份验证
针对这个问题，API网关顺势而生

API网关直面意思是将所有API调用统一接入到API网关层，由网关层统一接入和输出。一个网关的基本功能有：统一接口，安全防护，协议适配，流量管控，长短链接支持，容错能力。有了网关之后，各个API服务提供团队可能专注于自己的业务逻辑处理，而API网关更专注于安全、流量、路由等问题

服务容错

在微服务中，一个请求经常会涉及到调用几个服务，如果其中某个服务不可用，没有做服务容错的话，极有可能会造成一连串的服务不可用，这就是雪崩效应
我们设法预防雪崩效应的产生，只能尽可能去做好容错，服务容错的三个核心思想是：

不被外界环境影响
不被上游请求压垮
不被下游影响拖垮

链路追踪

服务按照不同维度进行拆分，一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发，可能使用不同的编程语言来实现、有可能分布在了几千台服务器，横跨多个不同的数据中心。因此，就需要对一次请求设计的多个服务器链路进行日志记录，性能监控即链路追踪。

微服务架构解决方案

SpringCloud Alibaba介绍
SpringCloud Alibaba 致力于提供微服务开发的一站式解决方案，此项目包含开发分布式应用微服务的必须组件，方便开发者通过Spring Cloud编程模型轻松使用这些组件来开发分布式应用服务
依托Spring Cloud Alibaba 您只需要添加一些注解和少量配置，就可以将Spring Cloud应用接入案例微服务解决方案，通过阿里中间件来迅速搭建分布式应用系统

环境搭建

案例准备
技术选型
模块设计
微服务调用
创建工程

Nacos Discovery——服务治理

Nacos提供服务配置、服务发现和服务管理

服务治理介绍

nacos支持ap,cp切换

nacos简介

1.1 为什么叫Nacos
前四个字母分别为Nameing和Configuration的前两个字母，最后的s为Service

1.2 Nacos是什么
一个更易于构建原生应用的动态服务发现、配置和服务管理平台。
Nacos: Dynamic Naming and Configuration Service
Nacos就是注册中心+配置中心的组合–>等价于 Nacos=Eureka+Config+Bus

nacos实战入门

@EnableDiscoveryClient

搭建nacos环境

        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
        </dependency>
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
        </dependency>

1. 多环境多项目管理
问题一：
实际开发中，通常一个系统会准备
dev开发环境
test测试环境
prod生产环境
如何保证指定环境启动服务能正确读取到Nacos上相应环境的配置文件
问题二：
一个大型分布式微服务会有很多微服务子项目
每个微服务项目都会有相应的开发环境、测试环境、预发环境、正式环境…
那怎么对这些微服务配置进行管理

理解一张图：

实现服务调用的负载均衡
什么是负载均衡
自定义实现负载均衡
基于openFeign实现服务调用
什么是openFeign

OpenFeign是springcloud在Feign的基础上支持了SpringMVC的注解，如@RequestMapping等等。OpenFeign的@FeignClient可以解析SpringMVC的@RequestMapping注解下的接口，并通过动态代理的方式产生实现类，实现类中做负载均衡并调用其他服务。

openFeign的使用

<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

spring:
  application:
    name: nacos
  cloud:
    nacos:
      discovery:
        #Nacos服务注册中心地址
        server-addr: xxx:8848 
      config:
        server-addr: xxx:8848
#        file-extension: properties
        file-extension: yaml
        # 组名
        group: DEFAULT_GROUP
server:
  port: 9898

Sentinel——服务容错

高并发带来的问题
服务雪崩效应
常见容错方案
Sentinel入门
什么是Sentine

随着微服务的流行，服务和服务之间的稳定性变得越来越重要。 Sentinel以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

Sentinel 具有以下特征:

丰富的应用场景： Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、实时熔断下游不可用应用等。
完备的实时监控： Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。
广泛的开源生态： Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。
完善的 SPI 扩展点： Sentinel 提供简单易用、完善的 SPI 扩展点。您可以通过实现扩展点，快速的定制逻辑。例如定制规则管理、适配数据源等。

微服务集成Sentinel

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

安装Sentinel控制台
实现一个接口的限流
Sentinel的概念和功能
Sentinel规则
流控规则

1.1 阈值类型

流量控制主要有两种统计类型：

线程数：通过统计当前资源的并发线程数来进行流控
QPS：通过统计当前资源的QPS来进行流控

1.2 流控模式

直接：当前资源达到阈值，就限流自己
关联：当关联的资源达到阈值，就限流自己
链路：只记录指定链路上的流量

降级规则
热点规则
授权规则
系统规则
SentinelResource的使用
Sentinel规则持久化
Feign整合Sentinel

Gateway——服务网关

Gateway简介

Cloud全家桶中有个很重要的组件就是网关，在1.x版本中都是采用的Zuul网关
但是在2.x版本中，SpringCloud最后自己研发了一个网关代替Zuul
那就是Springcloud Gateway一句话： gateway是原zuul 1.x版的替代

1.1 一句话形容Gateway
Springcloud Gateway使用的Webflux中的reactor-netty响应式编程组件，底层使用了Netty通讯框架

网关在服务中的位置

Gateway快速入门

<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>

Gateway核心架构
内置路由断言工厂
自定义路由断言工厂
局部过滤器
全局过滤器
网关限流

Sleuth——链路追踪

链路追踪介绍
Sleuth入门
ZipKin介绍
Zipkin的集成
ZipKin服务端安装
ZipKin客户端集成
ZipKin数据持久化
使用mysql实现数据持久化
使用elasticsearch实现数据持久化

Rocketmq--消息驱动

MQ简介

RockertMQ是阿里巴巴2016年MQ中间件，使用Java语言开发，在阿里欸不，RocketMQ承接了例如“双11”等高并发场景的消息流转，能够处理万亿级别的消息

什么是MQ
MQ的应用场景

解耦、削峰、数据分发

异步解耦
流里削峰

常见的MQ产品

RocketMQ环境搭建

RocketMQ集群搭建
1.各角色介绍
Producer：消息的发送者；
Consumer：消息的接收者；
Broker：暂存和传输消息；
NameServer：管理Broker;
Topic：区分消息的种类；一个发送者可以发送消息给一个或者多个Topic;一个消息的接收者可以订阅一个或多个Topic消息
Message Queue：相当于是Topic的分区；用于并行发送和接收消息

集群特点

NameServer是一个几乎无状态节点，可集群部署，节点之间无任何信息同步

Broker不是相对复杂，Broker分为Master与Slave,一个Master可以对应多个Slave,但是一个Slave只能对应一个Master，Master与Slave的对应关系通过指定相同的BrokerName,不同的BrokerId来定义，BrokerID为0表示Master,非0表示Slave。Master也可以部署多个。每个Broker与NameServer集群中的所有节点建立长连接，定时注册Topic信息到所有NameServer。

Producer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameSer取Topic路由信息，并向提供Topic服务的Master建立长连接，且定时向Master发送心跳。Producer完全无状态，可集群部署

Consumer与NameServer集群中其中一个节点（随机选择）长连接，定期从NameServer取Topic路由信息，并向提供Topic服务的Master，Slave建立长连接，且定时向Master，Slave发送心跳。Consumer即可以从Master订阅消息，也可以从Slave订阅消息，订阅规则由Broker配置决定

集群模式

多Master多Slave模式（异步）
每个Master配置一个Slave，有多对Master-Slave，HA采用异步复制方式，主备有短暂消息延迟（毫秒级），这种模式的优缺点如下：

优点：即使磁盘损坏，消息丢失的非常少，且消息实时性不会受影响，同时Master宕机后，消费者仍然可以从Slave消费，而且此过程对应用透明，不需要人工干预，性能同多Master模式i几乎一样
缺点：Master宕机，磁盘损坏情况下会丢失少量消息。

多Master多Slave模式（同步）
每个Master配置一个Slave，有多对Master-Slave,HA采用同步双写方式，即只有主备都写成功，才向应用返回成功，这种模式的优缺点如下

优点：数据与服务都无单点故障，Master宕机情况下，消息无延迟，服务可用性与数据可用性都非常高
缺点：性能比异步复制模式略低（大约低10%左右），发送单个消息的RT会略高，且目前版本在主节点宕机后，备机不能自动切换为主机。

RocketMQ的架构及概念

RocketMQ控制台安装

消息发送和接收演示

消息发送：同步消息，可靠性同步地发送方式使用的比较广泛，比如：重要的消息通知，短信通知

异步消息，

异步消息通常在对响应时间敏感的业务场景，即发送端不能容忍长时间的等待Broker的响应
与发送同步消息不同的是添加了回调函数

单向消息，这种方式主要用在不特别关心发送结果的场景，例如日志发送

消息消费

两种基本的消息消费

1.负载均衡模式

该模式也是默认的模式，消费者采用负载均衡方式消费消息，多个消费者共同消费队列消息，每个消费者处理的消息不同

2. 广播模式

指的是不同的consumer接收到的消息是一样的

消息发送者步骤分析

创建消息生产者producer，并制定生产者组名
指定Nameserver地址
启动producer
创建消息对象，指定主题Topic、Tag和消息体
发送消息
关闭生产者producer

消息消费者步骤分析

创建消费者consumer，指定消费者组名
指定Nameserver地址
订阅主题Topic和Tag
设置回调函数处理消息
启动消费者consumer

订单微服务发送消息

顺序消息
消息有序指的是可以按照消息的发送顺序来消费（FIFO）。RocketMq可以严格的保证消息有序，可以分为区分有序或者全局有序。

顺序消费的原理解析，在默认的情况下消息发送会采取Round Robin轮询方式把消息发送到不同的queue（分区队列）；而消费消息的时候从多个queue上拉取消息，这种情况发送和消息式不能保证顺序。但是如果控制发送的顺序消息只依次发送到同一个queue中，消费的时候只从这个queue上拉取，则就保证了顺序。当发送和消费参与的queue只有一个，则是全局有序；如果多个queue参与，则为份去有序，即相对每个queue，消息都是有序的。

一个订单的顺序流程是：创建、付款、推送、完成。订单号相同的消息会被先后发送到同一个队列中，消费时，同一个OrderId获取到的肯定时同一个队列。

用户微服务订阅消息

延时消息
比如电商里，提交了一个订单就可以发一个延时消息，1h后去检查这个订单的状态，如果还是未付款就取消订单释放库存。

使用限制
现在RocketMq并不支持任意时间的延迟，需要设置几个固定的延时等级从1s到2h分别对应着等级1-18

// org/apache/rocketmq/store/config/MessageStoreConfig.java
private String messageDelayLevel = "1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h";

普通消息
顺序消息
事务消息

事务消息的大致方案，其中分为两个流程：正常事务消息的发送及提交、事务消息的补偿流程

1. 事务消息发送及提交

发送消息（half消息)
服务端响应消息写入结果
根据发送结果执行本地事务（如果写入失败，此时half消息对业务不可见，本地逻辑不执行）
根据本地事务状态执行Commit或者Rollback（Commit操作生成消息索引，消息对消费者可见）

2. 事务补偿

对没有Commit/Rollback的事务消息(pending状态的消息），从服务端发起一次“回查”
Producer收到会查消息，重新Commit或者Rollback
其中，补偿阶段用于解决消息Commit或者Rollback发生超时会哦这失败的情况

3. 事务消息状态
事务消息共有三种状态，提交状态，回滚状态，中间状态

TransactionStatus.CommutTransaction:提交事务，它允许消费者消费此消息
TransactionStatus.RollbackTransaction: 回滚事务，它代表该消息将被删除，不允许被消费。
TransactionStatus.Unknown: 中间状态，它代表需要检查消息队列来确定状态。
消息消费要注意的细节

死信队列

当一条消息初次消费失败，消息队列RocketMQ会自动进行消息重试；达到最大重试次数后，若消费依然失败，则表明消费者在正常情况下无法正确地消费该消息，此时，消息队列RocketMQ不会立刻将消息丢弃，而是将其发送到该消费者对应的特殊队列中。
在消息队列RocketMQ中，这种正常情况下无法被消费的消息称为死信消息（Dead-Letter Message），存储死信消息的特殊队列称为死信队列(Dead-Letter Queue)。

死信特性
死信消息具有以下特性

不会再被消费者正常消费
有效期与正常消息相同，均为3天，3天后会被自动删除。因此，请在死信消息产生后的3天内即时处理。
死信队列具有以下特性：

一个死信队列对应一个Group ID,而不是对应单个消费者实例
如果一个Group ID未产生死信消息，消息队列RocketMQ 不会为其撞见相应的死信队列
一个死信队列包含了对应Group ID产生的所有死信消息，不论该消息属于哪个Topic

消费幂等

消息队列RocketMQ 消费者在接受到消息以后，有必要根据业务上的唯一Key对消息做幂等处理的必要性

消费幂等的必要性
在互联网应用中，尤其在网络不稳定的情况下，消费队列RocketMQ的消息有可能会出现重复，这个重复简单可以概括为以下情况：

发送时消息重复
当一条消息已被成功发送到服务端并完成持久化，此时出现了网络闪断或者客户端宕机，导致服务端对客户端应答失败。如果此时生产者意识到消息发送失败并尝试再次发送消息，消费者后续会收到两条内容相同并且Message ID 也相同的消息
投递时消息重复
消息消费的场景下，消息已投递到消费者并完成业务处理，当客户端给服务端反馈应答的时候网络闪断，为了保证消息至少被消费一次，消息队列RocketMQ的服务端将在网络恢复后再次尝试投递之前已经被处理过的消息，消费者后续会收到两条内容相同并且Message ID呀相同的消息
负载均衡时消息重复（包含但不限于网络抖动，Broker重启以及订阅方应用重启）
当消息队列RocketMq 的Broker或客户端重启，扩容或缩容时，会触发Rebalance,此时消费者可能会收到重复消息

处理方式

因为Message ID 有可能出现冲突（重复）的情况，所以真正安全的幂等处理，不建议以Message ID 作为处理依据，最好的方式是以业务唯一表示作为幂等处理的关键依据，而业务的唯一标识可以通过消息key进行设置

消息存储存储介质、RMQ消息存储和发送、消息存储结构、刷盘机制

消息存储

分布式队列因为有高可靠性的要求，所以数据要进行持久化存储
消息生成者发送消息
MQ收到消息，将消息进行持久化，在存储中新增一条记录
返回ACK给生产者
MQ push 消息给对应的消费者，然后等待消费者返回ACK
如果消息消费者在指定时间内成功返回ack,那么MQ认为i消息消费成功，在存储中删除消息，即执行第6步；如果MQ在指定时间内没有收到ACK，则认为消息消费失败，会尝试重新push消息，重复执行4.5.6步骤
MQ删除消息

存储介质

关系型数据库DB
文件系统

性能对比

文件系统>关系型数据库DB

刷盘机制

RocketMQ的消息是存储到磁盘上的，这样既能保证断电后恢复，又可以让存储的消息量超出内存的限制。RocketMQ为了提高性能，会尽可能地保证磁盘地顺序写。消息在通过Producer写入RocketMQ地时候，有两种写磁盘地方法，分布式同步刷盘和异步刷盘

高可用机制——消息消费高可用，消息发送高可用，消息主从复制

消息消费高可用

消息发送高可用

实际应用中要结合业务场景，合理设置刷盘方式和主从复制方式，尤其是SYNC_FLUSH方式，由于频繁的触发磁盘写动作，会明现降低性能。通常情况下，应该把Master和Save配置成ASYNC_FLUSH的刷盘方式，主从之间配置成SYNC_MASTER的复制方式，这样即时有一台机器出故障，仍然能保证数据不丢，是个不错的选择
异步刷盘+主从同步复制

负载均衡,消息重试

生产，消费端负载均衡

顺序消息的重试
对于顺序消息，当消费者消费消息失败后，消息队列RocketMQ会自动不断进行消息重试（每次间隔时间为1秒），这时，应用会出现消息消费被阻塞的情况。因此，在使用顺序消息时，务必保证应用能够即时监控并处理消费失败的情况，避免阻塞现象的发生

无序消息的重试
对于无须消息（普通，定时，延时，事务消息），当消费者消费消息失败时，你可以通过设置返回状态达到消息重试的结果。无需消息的重试只针对集群消费方式生效；广播方式不提供失败重试特性，即消费失败后，失败消息不再重试，继续消费新的消息

重试次数
消息队列RocketMQ默认允许每条消息最多重试16次，可配置

SMS--短信服务

短信服务介绍
短信服务使用
短信服务API介绍
短信发送(SendSms)
短信查询(QuerySendDetails)

Nacos Config--服务配置

服务配置中心介绍

默认情况：Namespace=public,Group=DEFAULT_GROUP,默认Cluster是DEFAULT

Nacos默认的命名空间是public，Namespace主要用来实现隔离
比方说我们现在有三个环境：开发、测试、生产环境、我们就可以创建三个Namespace,不同德Namespace之间是隔离的

Group默认是DEFAULT_GROUP,Group可以把不同的微服务划分到同一个分组里去

Service就是微服务；一个Service可以包含多个Cluster(集群），Nacos默认Cluster是DEFAULT,Cluster是对指定微服务的一个虚拟划分。
这时就可以给杭州机房的Service微服务起一个集群名称（HZ），给广州机房的Service微服务起一个集群名称（GZ），还可以尽量让同一个机房的微服务互相调用，以提升性能。

最后是Instance,就是微服务的实例。

Nacos Config入门
Nacos Config深入

Nacos的匹配规则：
需要配置 spring.application.name ，它是构成 Nacos 配置管理 dataId字段的一部分。

在 Nacos Spring Cloud 中，dataId 的完整格式如下：
${prefix}-${spring.profile.active}.${file-extension}

prefix 默认为 spring.application.name 的值，也可以通过配置项 spring.cloud.nacos.config.prefix来配置。

spring.profile.active 即为当前环境对应的 profile，注：当 - spring.profile.active 为空/未填写时，相对应的连接符-也将不存在(省略)，dataId 的拼接格式变成 ${prefix}.${file-extension}file-exetension` 为配置内容的数据格式，可以通过配置项 spring.cloud.nacos.config.file-extension 来配置。目前只支持properties 和 yaml 类型。

最终格式：{spring.application.name}-${spring.profile.active}.${spring.cloud.nacos.config.file-extension}

配置动态刷新

nacos集群化

Nacos 支持三种部署模式

单机模式-用于测试和单机试用。
集群模式-用于生产环境，确保高可用
多集群模式-用于多数据中心场景

nacos配置持久化

Nacos持久化到Mysql

Seata--分布式事务

分布式事务基础
分布式事务的场景
分布式事务解决方案
全局事务
可靠消息服务
最大努力通知
TCC事务
Seata介绍
Seata实现分布式事务控制
修改or der微服务
修改Pr oduct微服务
异常模拟
修改配置文件
初始化seata在nacos的配置
启动seata服务
使用Seata实现事务控制
在order微服务开启全局事务
seata运行流程分析

SpringCloud Alibaba微服务实战三十三- Spring Cloud Alibaba 全家桶

微服务的介绍

系统架构演变

1.单体应用架构

2，垂直应用架构

3.分布式架构

4.SOA架构

5.微服务架构

微服务架构介绍

微服务架构的常见问题

微服务架构的常见概念

服务注册：服务实例将自身的信息注册到注册中心
服务发现：服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求他们提供服务
服务剔除：服务注册中心

服务调用

环境搭建

Nacos Discovery——服务治理

Sentinel——服务容错

1.1 阈值类型

1.2 流控模式

Gateway——服务网关

Sleuth——链路追踪

Rocketmq--消息驱动

消息发送：同步消息，可靠性同步地发送方式使用的比较广泛，比如：重要的消息通知，短信通知

异步消息，

单向消息，这种方式主要用在不特别关心发送结果的场景，例如日志发送

消息消费

两种基本的消息消费

消息存储存储介质、RMQ消息存储和发送、消息存储结构、刷盘机制

消息存储

高可用机制——消息消费高可用，消息发送高可用，消息主从复制

负载均衡,消息重试

SMS--短信服务

Nacos Config--服务配置

Nacos持久化到Mysql

Seata--分布式事务

猜你喜欢

SpringCloud Alibaba微服务实战三十三- Spring Cloud Alibaba 全家桶

微服务的介绍

系统架构演变

1.单体应用架构

2，垂直应用架构

3.分布式架构

4.SOA架构

5.微服务架构

微服务架构介绍

微服务架构的常见问题

微服务架构的常见概念

服务注册：服务实例将自身的信息注册到注册中心 服务发现：服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求他们提供服务 服务剔除：服务注册中心

服务调用

环境搭建

Nacos Discovery——服务治理

Sentinel——服务容错

1.1 阈值类型

1.2 流控模式

Gateway——服务网关

Sleuth——链路追踪

Rocketmq--消息驱动

消息发送：同步消息，可靠性同步地发送方式使用的比较广泛，比如：重要的消息通知，短信通知

异步消息，

单向消息，这种方式主要用在不特别关心发送结果的场景，例如日志发送

消息消费

两种基本的消息消费

消息存储 存储介质、RMQ消息存储和发送、消息存储结构、刷盘机制

消息存储

高可用机制——消息消费高可用，消息发送高可用，消息主从复制

负载均衡,消息重试

SMS--短信服务

Nacos Config--服务配置

Nacos持久化到Mysql

Seata--分布式事务

猜你喜欢

服务注册：服务实例将自身的信息注册到注册中心
服务发现：服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求他们提供服务
服务剔除：服务注册中心

消息存储存储介质、RMQ消息存储和发送、消息存储结构、刷盘机制