Spring-Cloud.H版和Alibaba 思维导图模板_ProcessOn思维导图、流程图

概述

版本选择 2.2.5.RELEASE + Hoxton.SR3

IDEA File Type 过滤

SpringCloud
服务注册中心

Eureka (目前停止更新）

Eureka 原理

Eureka 基本搭建

服务端(Server)环境配置

客户端环境配置

BUG

Eureka 集群环境搭建

修改系统配置

vim /etc/hosts

修改配置文件

127.0.0.1 eureka7001.com

127.0.0.1 eureka7002.com

YML 修改

启动参数

服务注册到 Eureka集群

YML 注册

服务的负载均衡

RestTemplate Bean 声明添加 @LoadBalanced

代码实例

修改请求地址

原始地址：http://localhost:8001

修改后地址：http://PAYMENT-SERVCIE

@LoadBalanced 默认采用轮询算法

actuator 微服务信息完善

显示主机名称

YML 配置

IP 配置

YML 配置

服务发现 Discovery

启动类

获取注册信息

Eureka 自我保护

自我保护的理论

禁用自我保护

某一时刻，不会自动删除服务

配置

Eureka Server YML 配置

Eureka Client YML 配置

Eureka 停止更新

Zookeeper

安装zk

docker 命令

添加 POM

YML

主启动类

Controller

注意：zk-discovery 中带的 zk 驱动版本和服务器上的 zk 版本是否一致

注册中心内容(基本信息)

zk 节点的划分

持久节点

临时节点

Consul

Consul 简介

是什么

能做什么

服务发现

提供HTTP 和 DNS 两种方式

健康检查

支持多种方式，HTTP，TCP，Docker。 Shell 脚本定制化

KV 存储

Key、Value 存储方式

多数据中心

Consul 支持多数据中心

可视化WEB管理

下载地址

安装步骤：https://learn.hashicorp.com/consul/getting-started/install

与 spring-cloud 整合

安装并运行 Consul

服务提供者

POM

YML

启动类

业务代码

服务消费者(同服务提供者类似)

三个注册中心的异同

Eureka(java、AP、健康检查支持、HTTP、集成Spring Cloud)

Consul(Go、CP、健康检查支持、HTTP/DNS 、集成Spring Cloud)

Zookeeper(java、CP、健康检查支持、客户端、集成 Spring Cloud)

CAP

C: Consistency（强一致性）

A： Availability (可用性)

P：Partitiontolerance（分区容错性）

CAP 理论关注细粒度是数据，而不是整体系统设计的

AP（Eureka）

CP (Consul/Zeekeeper)

Spring Cloud Ribbon
负载均衡

概述

是什么

官网

停止维护

替代方案 [Spring Cloud Loadbalancer]

功能

LB（负载均衡）

集中式 LB

进程内 LB

配置轮询（默认轮询）

Ribbon + RestTemplate

Ribbon 负载均衡演示

架构说明

POM

RestTemplate

(java doc)https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/web/client/RestTemplate.html

getForObject 方法/ getForEntity 方法

postForObject / postForEntity

GET 请求

POST 请求

Ribbon 核心组件 IRule

如何替换

注意事项

创建包

cn.edu.cqvie.myrule

添加自定义规则配置

启动类上添加 @RibbonClient

@RibbonClient(name="PAYMENT-SERVICE", configuration = MySelfRule.class)

测试

IRule: 根据特定算法中从服务列表中选取一个要访问的服务

com.netflix.loadbalancer.RoundRobinRule

轮询

com.netflix.loadbalancer.RandomRule

随机

com.netflix.loadbalancer.RetryRule

先按照RoundRobinRule的策略获取服务，如果获取服务失败则在指定时间内会惊醒冲你是，获取可用的服务

WeightedResponseTimeRule

对RoundRobinRule 的拓展，响应速度越快的实例选择权重越大，越容易被选择

BestAvailableRule

会先过滤掉由于多次访问故障而处断路器跳闸状态的服务，然后选择一个并发量最小的服务

AvailabilityFilteringRule

先过滤掉故障实例，在选择并发较小的实例

ZoneAvoidanceRule

默认规则，符合判断Server 所在区域的性能和 Server 的可用性选择服务器

Ribbon 负载均衡算法

原理

RoundRobinRule 源码

自定义实现

SpringCloud OpenFeign
服务调用

概述

feign 是一个声明式的Web服务客户端，让编写Web服务客户端变得非常容易，只需要创建一个接口并正在接口上添加注解即可。

GitHub

https://github.com/spring-cloud/spring-cloud-openfeign

fegin 能做什么

fegin 和 openfegin 区别

OpenFeign 使用步骤

接口 + 注解

微服务调用接口 + @FeignClient

POM

YML

启动类

@EnableFeignClients

微服务调用接口

业务逻辑接口 + @FeignClient 配置调用 Provider 服务

新建 PaymentFeignServer 接口 并新增注解 @FeignClient

@FeignClient

控制层 Controller

测试

小总结

OpenFeign 超时控制

YML 配置

OpenFeign 日志打印

日志级别

申明代码

YML 申明

SpringCloud Hystrix
服务降级/熔断/隔离

Hystrix（目前停止更新）

服务降级

解决场景

服务超时（前台显示转圈）

出错（宕机或者程序运行出错）

解决

对方服务超时了，调用者不能一直死等，必须有服务降级

对方服务器 down 机了，调用者不能卡死等待，必须有服务降级

对方服务OK，调用者自己出现故障（自己等待时间小于服务的超时时间，自己要求服务降级）

Hystrix 基本搭建

POM

主启动类

对方法添加降级

Hystrix 调用侧使用

POM

YML

主启动类

调用方法实例

Hystrix 统一的全局配置

配置方法代码

FeigClient

服务熔断

大神理论

https://martinfowler.com/bliki/CircuitBreaker.html

简单搭建

代码实例

总结

大神结论

熔断核心参数

断路器关闭的条件

当满足一定的阈值的到时候（默认10秒内超过20次请求）

当失败率到达一定的时候，默认10秒内超过50%的请求失败

到达以上阈值，断路器将会开启

当开启的时候，所有的请求都不会进行转发

一段时间之后，（默认5秒），这个时候断路器是半开状态，会让其中一个请求进行转发。如果成功，断路器会挂壁，若失败，继续开始重复 4，5

断路器打开之后

服务限流在（Alibaba - Sentiel 学习）

服务监控

POM

启动类

访问端口

http://127.0.0.1:8001/hystrix

监控使用

注意事项

注意依赖

注意新版本 Hystrix 需要在启动类中指定监控路径

Unable to connect to Command Metric Stream

404

启动类

测试地址

监控配置地址：http://127.0.0.1:8001/hystrix.stream

异常访问：http://127.0.0.1:8001/payment/payInfo/1

正常访问：

Spring Cloud Gateway
服务网关

概述简介

是什么

一句话

SpringCloud Gateway 使用的 Webflux 中的 reactor-netty 响应式比亲车给你组件，底层采用了netty 通讯框架

源码架构

网关在架构中的位置

网关是在微服务访问的入口，对外是负载均衡 Nginx

zuul 和 gateway

我们为什选择 gateway

1. netflix 不靠谱，zuul2.0 一直跳票，迟迟不发布

2. springcloud gateway 具有如下特征

3. springcloud gateway 和 zuul 的区别

zuul1.0 模型

gateway 模型

webflux

是什么

三大核心概念

Route (路由)

路由是构建网关的基本模块，它由ID，目标 URI ，一系列的断言和过滤器组成，如果断言为true 则匹配该路由

Predicate （断言）

参考 Java8 的 java.util.funcation.Predicate
开发从人员可以陪陪HTTP 请求中的所有内容（例如请求头或请求参数），如果请求与断言适配类则进行路由

Filter （过滤）

指的是Spring框架中的GateFilter 的实例，使用过滤器，可以在请求被路由前或者之后进行修改

总体

Gateway 工作流程

匹配路由转发

在执行转发的前后执行过滤链

入门配置

POM

YML

主启动类

路由映射

YML 网关配置

测试

添加网关之前：http://localhost:8501/payment/get/1

添加网关之后：http://localhost:8501/payment/get/1

YML 配置说明

Gateway 网关路由有两种配置方式

在配置文件YML 中配置

见前面的步骤

代码中注入 RouteLoctor 的 Bean

自己实现

业务需求

通过网关转发百度新闻网址

config

http://news.baidu.com/guonei

通过微服务名实现动态路由

默认情况下 Gateway 会更具注册中心的服务列表
以注册中心上服务名为路径 动态路由进行转发，从而实现动态路由的功能

启动：

POM

YML

Predicate 的使用

1. After Route Predicate

2. Before Route Predicate

3. Between Route Predicate

4. Cookie Route Predicate

5. Header Route Predicate

6. Host Route Predicate

7. Method Route Predicate

8. Method Route Predicate

9. Query Route Predicate

10. 总结

Filter 的使用

是什么

Spring Cloud Gateway 的Filter

常用的 GatewayFilter

GatewayFilter

GlobalFilter

自定义过滤器

自定义全局过滤器

两个主要接口介绍

implements GlobalFilter

能做什么

全局日志记录

统一鉴权网关

案例代码

测试

SpringCloud Config
服务配配置

概述

解决了什么问题

是什么

能干什么

集中管理配置文件

不同环境的不同配置，动态化的配置更新，分环境部署比如：/dev/test/prod/beta/release

运行期间动态调整配置，不再需要在每个服务器部署的机器上编写配置文件，服务会向配置中心统一拉取配置自己的信息

当配置发生变动，服务不需要重启即可感知配置的并发并应用新的配置

将配置信息以REST接口的形式暴露

与GitHub整合配置

官网

Config 服务端配置与测试

github 创建仓库

ssm-laboratory-config

拉取远程仓库

git clone https://github.com/zhengsh/ssm-laboratory-config.git

添加配置(git)

表示多个环境的配置文件

config-dev.yml

config-test.yml

config-prod.yml

保存格式必须为 UTF-8

如果需要修改，此处模拟运维人员操作git 和 gitub

git add .

git commit -m 'init yml'

git push

POM

YML

主启动类

@EnableConfigServer

修改本机 Host 映射

127.0.0.1 config3344.com

测试通过 Config 微服务是否可以从 GitHub 上面读取配置内容

启动 3344

http://127.0.0.1:3344/master/config-dev.yml

配置读取规则

官网

/{lable}/{applicaton}-{profile}.yml

master 分支

http://127.0.0.1:3344/master/config-dev.yml

http://127.0.0.1:3344/master/config-test.yml

http://127.0.0.1:3344/master/config-prod.yml

dev 分支

http://127.0.0.1:3344/dev/config-dev.yml

/{application}-{profile}.yml

http://127.0.0.1:3344/config-dev.yml

http://127.0.0.1:3344/config-test.yml

http://127.0.0.1:3344/config-prod.yml

http://127.0.0.1:3344/config-xx.yml

/{application}/{profile}[/{lable}]

http://127.0.0.1:3344/config/dev/master

http://127.0.0.1:3344/config/test/master

http://127.0.0.1:3344/config/prod/master

重要配置细节总结

成功实现了通过 SpringCloud Config 从 GItHub 获取配置信息

Config 客户端配置与测试

POM 配置

bootstrap.yml

YML 解释

主启动类

业务代码

测试

curl curl http://127.0.0.1:8001/configInfo

master branch,spring-cloud-config/config-dev.yml version=1

问题随之而来，分布式分配至的动态刷新问题

Linux 运维修改了GitHub 上的配置文件内容作出了调整

刷新 Config-Server，发现 ConfigServer 配置中心立刻响应

刷新 Config-Client, 发现 ConfigClient 客户端没有任何响应

Config-Client 没有变化，除非自己重新启动或者重新加载

如果每次修改都需要重启画的，那将是一个非常复杂的操作

Config 客户端值动态刷新（手动版）

避免每次刷新配置都要重启客户端微服务

动态刷新

步骤

修改 Server-Client

POM 引入 actuator 监控

修改 YML , 暴露监控端口

@RefeshScope 业务类Controller 修改

此时修改 GitHub -> Config-Server -> Config-Client

curl http://127.0.0.1:8001/configInfo

此时 Config-Client 依然没有生效？？

How

需要发送 POST 请求到 Config-Client

必须是 POST 请求

curl -X POST "http://127.0.0.1:8001/actuator/refresh"

再次

curl http://127.0.0.1:8001/configInfo

成功将配置更新到 Config-Client

避免了服务器的重启

思考还有什么问题

如果有多个微服务客户端 config-client1、config-client2、config-client3

每个微服务都要执行一次 post 请求，手动刷新

是否可以官博，一处通知，处处生效？

我们需要大范围的自动刷新？？

SpringCloud Bus
消息总线

概述

解决什么问题？

分布式自动刷新配置功能

可以结合 SpringCloud Config 实现自动刷新配置

是什么？

Bus 支持两种消息代理

RabbitMQ

Kafka

为什么被称作总线

RabbitMQ 环境配置（Mac）

安装：brew install rabbitmq

进入目录: cd /usr/local/Cellar/rabbitmq/3.8.2

启动：brew services start rabbitmq

访问地址（可视化页面）

http://localhost:15672

输入账号密码：guest guest

SpringCloud Bus 动态刷新全局广播

必须具备 RabbitMQ 环境

广播效果，需要准备2个接受服务

设计思想

1）利用消息总线触发一个客户端 /bus/refresh, 而刷新所有客户端的配置

2）利用消息总线触发一个服务端 ConfigServer 的 bus/refresh 端点，而刷新所有客户端的配置

第二种方案更加合适，第一种方案不合适的原因

打破了微服务的职责单一性，因为微服务本省是业务模块，它本不应该承担配置刷新的职责

破坏了微服务各个节点的对等性

有一定的局限性，例如, 在微服务迁移时，它的网络地址常常会发生变化，如果此时时想自动属性，会增加更多的工作

配置中心添加消息支持

POM

YML

客户端添加消息支持

POM

YML

如果多个节点，需要对应配置

测试

运维工程师

修改 GitHub 上的配置

发送POST 请求

curl -X POST ”http://127.0.0.1:3344/actuator/bus-refresh“

一次发送，处处生效

配置中心

http://127.0.0.1:3344/dev/config-dev.yml

客户端

http://127.0.0.1:8001/configInfo

一次修改，广播通知处处生效

ok

SpringCloud Bus 动态属性定点通知

不想全部通知，只想定点通知

只通知 payment-8001

不通知 payment-8002

简单理解

指具体某一个实例生效而不是全部

公式：http://127.0.0.1:配置中心端口/actuator/bus-refresh/{destination}

/bus/refresh 请求不在发送到具体的服务实例上，而是发送给config server
通过 destination 参数指定需要更新配置的服务或实例

案例

我们这里以刷新 payment-service 为例

只通知 payment-8001

不通知 payment-8002

curl -X POST "http://127.0.0.1:3344/actuator/bus-refresh/payment-service:8001"

通知总结All

Spring Cloud Stream
消息驱动

消息驱动概述

是什么

一句话

屏蔽消息中间件的差异，降低切换恒本，统一的消息编程模型

官网

https://github.com/spring-cloud/spring-cloud-stream

https://cloud.spring.io/spring-cloud-static/spring-cloud-stream/3.0.3.RELEASE/reference/html/

中文资料

https://m.wang1314.com/doc/webapp/topic/20971999.html

设计思想

标准 MQ

生产者/消费者之间靠消息媒介传递内容

Message

消息必须走特定的通道

消息通道 MessageChannel

消息通道中的消息如何被消费，谁来负责收发处理

消息通道 MesssageChannel 的子接口 SubscribableChannel , 由 MessageHandler 消息处理器所订阅

为什么用 Cloud Stream

Stream 为什么可以统一底层的差异

Binder

INPUT 对应于消费者

OUTPUT 对应于生产者

Stream 中的消息通讯方式遵循了发布-订阅模式

Topic 主题进行广播

在RabbitMQ 就是 Exchange

在Kafka中就是 Topic

Spring Cloud Stream 标准流程

Binder

很方便的连接中间件，屏蔽差异

Channel

通道，是队列 Queue 的一种抽象，在消息通讯系统中就是实现存储和转发的媒介，通过channel 队列进行配置

Source 和 Sink

简单的理解为参照对象 Spring Cloud Stream 自身，
从 Steam 发布消息就是输出，接受消息就是输入

编码API 和常用注解

Meddleware

中间件，目前只支持 RabbitMQ 和 Kafka

Binder

Binder 是应用消息中间件之间的封装，目前实现了 Kafka 和 RabbitMQ 的Binder
通过 Binder 可以很方便的连接中间件，可以动态的改变消息类型（对于 Kafka 的 topic , rabbitmQ 的 exchange）,
这些都可以通过配置文件来实现。

@Input

注解标识输入通道，通过该输入通道接收到的消息进入应用程序

@Output

注解标识输入通道，发布的消息将通过通道离开应用程序

@StramListener

监听队列，用于消费者的队列的消息接受

@EnableBinding

指信道 channel 和 exchange 绑定在一起。

案例说明

RbbitMQ 环境OK

工程模块

stream-provider

stream-consumer

消息驱动-生产者

POM

YML

主启动类

业务类

发送消息接口

发送下次接口实现类

Controller

测试

启动 Eureka

启动 RabbitMQ

启动 RabbitMQ-Provider

访问

消息驱动-消费者

POM

YML

主启动类

业务类

测试

curl http://127.0.0.1:8701/rabbit/send

消息发送端：=======> serial: b63ca8ce81ec4c2bb4429c5b9bff8bf8

消费者:8801, ------> 接受到的消息:b63ca8ce81ec4c2bb4429c5b9bff8bf8

分组消费与持久化

创建多个消费者服务

启动

RabbtMQ

Eureka 服务注册

消息生产者

消息消费者-1

消息消费者-2

运行后的2个问题

有重复消费问题

消息持久化问题

消费

目前消费者-1、消费者-2都同时受到了，存在重复消费的问题

curl http://127.0.0.1:8701/rabbit/send

如何解决

分组和持久化属性 group

重要

生产实际问题

分组

现状描述

故障现象是重复消费

导致现象是默认分组是不同的，组流水号不同，可以消费

自定义配置分组，自定义配置分为同一个组，解决

重复消费问题

原理

微服务应用放置于同一个group 中，就能保证消息只会被其中一个应用消费一次
不停的小组是可以消费的，同一个组内会发生竞争关系，只有其中一个可以消费

消费者-1，消费者-2 都变成了不同组，group 两个不同

group: atcqvie-01, atcqvie-02

消费者-1 修改 YML

消费者-2 修改 YML

自己的配置

结论

消费者-1，消费者-2 实现了轮询分组，每次只有一个消费者
发布者模块发出的消息只能被消费者-1，消费者-2 其中一个接收到，这样避免了重复消费的问题

消费者-1，消费者-2 都变成了相同组，group 两个相同

group: atcqvie-01

消费者-1 修改 YML

消费者-2 修改 YML

持久化

通过上述，解决了重复消费问题，在看看持久化

停止消费者-1，消费者-2，并去掉消费者-2 的 group

消费者-1 的 group: atcqvie-01 没有去掉

发布者先发布消息到 rabbitmq

启动消费者-2，无分组属性配置，后台没有打印出来消息

在启动消费者-1，有分组属性配置，后台打印出来了MQ上的消息

SpringCloud Sleuth
链路追踪

概述

为什么会出现这个技术？
需要解决那些问题？

问题

是什么

https://github.com/spring-cloud/spring-cloud-sleuth

Spring Cloud Sleuth 提供了一套完整的服务跟踪的解决方案。

在分布式系统中提供链路追踪解决方案并兼容支持了zipkin

解决

搭建链路监控步骤

1，zipkin

下载

Spring Cloud 从 F 版本过后已经不需要自己构建 Zipkin Server 了，只需要调用jar 即可

https://dl.bintray.com/openzipkin/maven/io/zipkin/java/zipkin-server/

zipkin-server-2.12.9-exec.jar

运行 jar

java -jar zipkin-server-2.12.9-exec.jar

运行控制台

访问控制台：http://localhost:9411/zipkin/

术语

完整的调用链路

子主题

理解调用链路设计

一条链路Trace ID 唯一标识， Span 标识发起的请求信息，各个 Span 通过 parent id 关联起来

名词解释

Trace : 类似于树结构的Span集合，标识一条链路，存在唯一标识

Span: 标识调用链路来源，通俗的理解 span 就是一个请求信息

2. 服务提供者

POM

YML

启动类

业务类

3. 服务消费者（调用方）

POM

YML

启动类

业务类

4. 依次启动 eureka/ 8001 /8101

5. 打开浏览器访问：http://localhost:9411

SpringCloud Alibaba
入门简介

why 会出现 SpringCloud alibaba

Spring Cloud Netflix 项目进入维护模式

说明

Spring Cloud Netflix Projects Entering Maintenance Mode

什么是维护模式

进入维护模式意味着什么呢

SpringCloud alibaba 带来了什么

是什么

能干什么

去哪里下

https://github.com/alibaba/spring-cloud-alibaba/blob/master/README-zh.md

怎么使用

官网

英文

https://github.com/alibaba/spring-cloud-alibaba

https://github.com/alibaba/spring-cloud-alibaba/tree/greenwich

中文

https://github.com/alibaba/spring-cloud-alibaba/blob/master/README-zh.md

SpringCloud alibaba 学习资料获取

SpringCloud Alibba
Nacos 服务注册中心

简介

为什么叫 Nacos

前面四个字母分别表示 Naming 和 Configuration 的前两个字母，最后一个s 为 Service

是什么？

一个更易于构建云原生运用的动态服务发现、配置管理和服务管理平台

Nacos: Dynamic Naming and Configuration Service

Nacos 就是注册中心+ 配置中心

等价于

Nacos = Eureka + Config + Bus

能做什么

替代 Eureka 做服务注册中心

替代 Config 做服务配置中心

去哪里下载

https://github.com/alibaba/nacos

官方文档

https://nacos.io/en-us/

https://spring-cloud-alibaba-group.github.io/github-pages/greenwich/spring-cloud-alibaba.html

各个注册中心比较

运行 Nacos

下载地址：https://github.com/alibaba/nacos/releases

nacos-server-1.2.0.zip

创建数据库和导入SQL

创建数据库 nacos

导入数据： config/nacos-mysql.sql

修改配置

mysql 连接字符串（application.yml）

启动: ./bin/startup.sh -m standalone

访问地址：http://127.0.0.1:8848/nacos

结果

作为服务中心演示

官方文档

https://spring-cloud-alibaba-group.github.io/github-pages/greenwich/spring-cloud-alibaba.html

基于 Nacos 的服务提供者

POM

YML

主启动类

业务类

测试

注册到 nacos

curl http://127.0.0.1:9002/payment/nacos/2

基于 Nacos 的服务消费者

POM

YML

主启动类

业务类

测试

启动 nacos

启动 payment-service、order-service

curl http://127.0.0.1:9101/consumer/payment/nacos/1

服务注册中心对比

各种注册中心的对比

Nacos 全景图所示

nacos 整体架构图

Nacos 和 CAP

切换

Nacos 支持 AP 和 CP模式的切换

作为服务配置中心演示

Nacos 作为配置中心 - 基础配置

POM

YML

bootstrap.yml

application.yml

主启动类

业务类

在 Nacos 中添加配置信息

Nacos 中的匹配规则

理论

cos 中的dataid 有的组成结构与 Spring boot 配置文件中的匹配规则

官网

实际操作

新增配置

Nacos 界面配置对应

设置DataId

公式

${spring.application.name}-${spring.profile.active}.${spring.cloud.nacos.config.file-extension}

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

spring.profile.active 即为当前环境对应的 profile，详情可以参考 Spring Boot文档。注意：当 spring.profile.active 为空时，对应的连接符 - 也将不存在，dataId 的拼接格式变成 ${prefix}.${file-extension}

file-exetension 为配置内容的数据格式，可以通过配置项 spring.cloud.nacos.config.file-extension 来配置。目前只支持 properties 和 yaml 类型。

小总结

历史配置

测试

curl http://127.0.0.1:9001/config/info

启动配置信息

自带动态刷新

修改下 Nacos 中的yaml 配置文件，再次调用查看配置的接口，就会发现配置已经刷新

Nacos 作为配置中心 - 分类配置

问题

多环境多项目管理

Nacos 的图形化管理界面

配置空间

命名空间

Namespace + Group + Data ID 三者之间的关系？为什么这样设计？

Case

三种方案加载配合

DataID 方案

指定 spring.profile.active 和配置文件的 DataID 来使不同环境读取不同的配置

默认空间+ 默认分组 + 新建 dev 和 test 两个 dataID

新建 dev DataID

新建 test DataID

通过 spring.profile.cative 属性就能惊醒多环境下配置文件的读取

测试

http://127.0.0.1:9001/config/info

配置环境是什么就加载什么

test

Group 方案

通过 Group 实现环境区分

新建 Group

在 Nacos 图形界面控制台上面新建配置文件 DataID

bootstrap + application

在 config 下增加一条 group 的配置即可。
可配置为 DEV_GROUP 或 TEST_GROUP

Namespace 方案

新建 dev/test 的Namespace

回到服务管理-服务列表查看

按照域名配置填写

YML

bootstrap.yml

集群和持久化配置

官网说明

https://nacos.io/zh-cn/docs/cluster-mode-quick-start.html

官网架构图

上图翻译真实情况

说明

持久化

按照上述，我们需要mysql 数据库

官网说明

Nacos 持久化配置解释

Nacos 默认自带的是嵌入式数据库 derby 。

https://github.com/alibaba/nacos/blob/develop/config/pom.xml

derby 到 mysql 切换配置步骤

nacos-server-version\nacos\conf 目录下找到 sql 脚本

nacos-mysql.sql

执行脚本

nacos-server-version\nacos\conf 目录下找到 application.properties

启动 Nacos , 可以看到一个全新的空界面，以前是记录进 derby

Linux 版 Nacos + MySQL 生产环境配置

预计需要， 1 个 Nginx + 3个nacos 注册中心 + 1个 mysql

Nacos 下载 liunx 版本

https://github.com/alibaba/nacos/releases/tag/1.2.0

nacos-server-1.2.0.tar.gz

解压后安装

集群配置步骤（重点）

1. Linunx 服务器上 mysql 数据库配置

SQL 脚本在哪里

SQL 语句源文件

nacos-mysql.sql

自己 Linunx 机器上的 MySQL 数据库

执行结果

2. apolication.properties 配置

位置

config/application.properties

内容

3. Linux 服务器上 nacos 集群配置 cluster.conf

梳理出3台 nacos 集群积极的不同服务器端口号

复制出cluster.conf

内容

这个IP不能写 127.0.0.1. 必须是
Linux 命令 hostname -i 能够识别的 IP

4. 编辑Nacos 的启动脚本straup.sh, 使它能够接受不同的启动端口

/nacos/bin 目录下有一个 startup.sh

在什么地方，修改什么，怎么修改

思考

修改内容

执行方式

./startup.sh -p 3333

5. Nginx 的配置，由它作为负载均衡器

修改 Nginx 的配置文件

nginx.config

按照指定启动

查看启动 nacos 服务数量

ps -ef | grep nacos-server | grep -v grep| wc -l

启动 niginx

./nginx -c ../conf/nginx.conf

6. 截止到此处， 1 个 Nginx + 3个nacos 注册中心 + 1个 mysql

测试通过 nginx 访问 nacos

http://192.168.1.3:1111/nacos

记得开放端口，或者云服务器的安全组，如果使用阿里云服务器学生机或者试用机，可能出现启动不了那么多台nacos 服务，此处我启动三台nacos，但是实际只启动了2台，

新建一个配置测试

如图：可见config配置已经持久化到mysql中

测试

微服务启动注册进入 nacos 集群

查看服务注册情况

实现服务之间的相互调用

高可用小总结

SpringCloud Alibaba
Sentinel 实现熔断与限流

Sentinel

官网

https://github.com/alibaba/Sentinel

中文

https://github.com/alibaba/Sentinel/wiki/%E4%BB%8B%E7%BB%8D

是什么

一句话解释，之前我们讲过的Hystrix

去哪下

https://github.com/alibaba/Sentinel/releases

能干什么

主要特征

怎么玩

安装 Sentinel

sentinel 组件由2部分组成

后台

前台8080

安装步骤

下载

https://github.com/alibaba/Sentinel/releases

下载到本地： sentinel-dashboard-1.7.1.jar

运行命令

前提

jdk 1.8

8080 端口不能被占用

命令

java -jar 下载到本地： sentinel-dashboard-1.7.1.jar

访问 sentinel 管理页面

http://127.0.0.1:8080

登录账号密码均为: sentinel

界面

初始化演示

启动 Nacos 8848

项目工程

POM

YML

主启动类

业务类

启动 Sentinel 8080

java -jar sentinel-dashboard-1.7.1.jar

启动微服务 9301

启动微服务 9301 微服务后查询看 sentienl 控制台

空空的什么东西都没有

sentienl 采用的是懒加载说明

服务访问

curl "http://127.0.0.1:9001/testA"

curl "http://127.0.0.1:9001/testB"

效果

结论

流控规则

基本介绍

流控规则

进一步说明

流控模式

直接（默认）

直接 -> 快速失败

系统默认

配置说明

测试

快速调用： http://127.0.0.1:9001/testA

结果

Blocked by Sentinel (flow limiting)

思考？？？

直接调用默认报错信息，技术方面 OK
但是，是否应该有我们自己的后续处理？

累屎有个 fallback 的兜底方法

关联

关联是什么

当关联的资源达到阈值，时就限流自己

当A关联的资源B到达阈值后，就吸纳流自己

B热事情了，A挂了

配置 A

配置界面

postman 模式并发密集访问 testB

效果

运行后发现testA 挂了

curl "http://127.0.0.1:9001/testA"

Blocked by Sentinel (flow limiting)

链路

多个请求调用同一个微服务

自己试试

流控效果

直接 -> 快速失败（默认流控处理）

直接失败，抛出异常

Blocked by Sentinel (flow limiting)

源码

com.alibaba.csp.sentinel.slots.block.flow.controller.DefaultController

预热

说明

公式：阈值除以 coldFactor (默认值3)，经过预热时常后才会到达阈值

官网

https://github.com/alibaba/Sentinel/wiki/%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6

https://github.com/alibaba/Sentinel/wiki/%E9%99%90%E6%B5%81---%E5%86%B7%E5%90%AF%E5%8A%A8

源码

com.alibaba.csp.sentinel.slots.block.flow.controller.WarmUpController

代码

WarmUp 配置

配置

多次点击 http://localhost:9001/testB

刚开始不行，后面慢慢OK

应用场景

排队等待

设置

设置效果

官网

https://github.com/alibaba/Sentinel/wiki/%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6-%E5%8C%80%E9%80%9F%E6%8E%92%E9%98%9F%E6%A8%A1%E5%BC%8F

源码

com.alibaba.csp.sentinel.slots.block.flow.controller.RateLimiterController

测试

降级规则

官网

https://github.com/alibaba/Sentinel/wiki/%E7%86%94%E6%96%AD%E9%99%8D%E7%BA%A7

基本介绍

配置图示

进一步说明

Sentinel 的断路器是没有半开状态的

半开的状态系统自动去检测是否请求有异常，
没有异常就关闭断路器恢复使用，
有异常则继续打开断路器不可用。具体可以参考 Hystrix

复习 Hystrix

降级策略实战

RT

是什么

代码

jemter 压测

结论

异常比例

是什么

代码

配置

jemter 测试

总结

异常数

是什么

异常数是按照分钟统计的

测试

代码

配置

jemeter

热点key 限流

基本介绍

是什么

官网

https://github.com/alibaba/Sentinel/wiki/%E7%83%AD%E7%82%B9%E5%8F%82%E6%95%B0%E9%99%90%E6%B5%81

承上启下

代码

com.alibab.csp.sentinel.slots.block.BlockException

配置

代码

sentinel 配置

配置

测试

curl http://127.0.0.1:9001/testHotKey\?p1\=1

结论

➜ Downloads curl http://127.0.0.1:9001/testHotKey\?p1\=1
----- testHotKey% ➜ Downloads curl http://127.0.0.1:9001/testHotKey\?p1\=1
----- testHotKey% ➜ Downloads curl http://127.0.0.1:9001/testHotKey\?p1\=1
----- testHotKey% ➜ Downloads curl http://127.0.0.1:9001/testHotKey\?p1\=1
----- deal_testHotKey% ➜ Downloads curl http://127.0.0.1:9001/testHotKey\?p1\=1
----- testHotKey%

配置

1

@SentinelResource(value = "testHotKey"

异常达到了前台用户解决看到，不友好

2

@SentinelResource(value = "testHotKey", blockHandler = "deal_testHotKey")

方法 testHotKey 里面第一个参数只要 QPS 超过每秒1次，马上降级处理

我们自定义的

测试

error

http://127.0.0.1:9001/testHotKey?p1=1

error

http://127.0.0.1:9001/testHotKey?p1=1&p2=2

right

http://127.0.0.1:9001/testHotKey?p2=2

参数例外项

上述案例演示了第一个参数 p1, 当QPS 超过1秒1次后立即马上被限流

特殊情况

普通

超过1秒钟一个后，达到阈值1后马上被限流了。

我们期望P1参数当它是某个特殊值时，他的限流值和平时不一样

特例

加入当p1 的值等于5时，它的阈值可以达到 200

配置

子主题

测试

http://127.0.0.1:9001/testHotKey\?p1\=5

前提条件

其他

系统规则

是什么

官网

https://github.com/alibaba/Sentinel/wiki/%E7%B3%BB%E7%BB%9F%E8%87%AA%E9%80%82%E5%BA%94%E9%99%90%E6%B5%81

各个参数的配置

测试

curl http://127.0.0.1:9001/testA

是系统级别的限制，一揽子看姐

@SentinelResource

按资源名称 + 后续处理

启动 Nacos 成功

启动 Sentinel 成功

项目配置

POM

YML

业务 RateLimitController

主启动类

配置流控规则

配置步骤

配置

图形配置和代码关系

表示1秒钟内查询次数大于1 ，就跑到我们自定义的限流

测试

1秒钟点击1下，OK

超过上述，疯狂点击，返回了自定义的限流信息，限流发生

额外问题

关闭服务试试

Sentinel 控制台，流控规则消失了？？？

按 URL 地址限流 + 后续处理

通过访问的URL 来限流，会返回Sentinel 自带默认的限流处理信息

业务类 RateLimitController

访问一次

http://127.0.0.1:9001/byResource

Sentinel 控制台配置

配置

测试

http://127.0.0.1:9001/byResource

结果

上面兜底方法面料的问题

客户自定义限流处理逻辑

创建 CustomerBlockHandler 类用于自定义限流处理逻辑

自定义限流处理类

CustomerBlockHandler

RateLimitController

启动微服务后先调用一次

http://127.0.0.1:9001/rateLimit/customerBlockHandler

Seninel 控制台配置

测试我们自定义的出来了

进一步的说明

更多注解属性说明

多说一句

Snetinel 主要又三个核心 API

SphU 自定义资源

Tracer 定义统计

ContextUtil 定义了上下文

服务熔断功能

sentinel 整合 ribbon + openfeign + fallback

ribbon 系列

启动 Nacos 和 sentinel

提供者 9001/9002

POM

YML

主启动类

业务类

测试地址

消费者 9101

POM

YML

主启动类

业务类

AppConfig

CircleBreakerController

修改后重启微服务

目的

fallback 管运行异常

blockHander 管配置违规

测试地址

http://127.0.0.1:9101/consumer/fallback/1

没有任何配置

给客户error页面不友好

只有 fallback

只配置 blockHandler

fallback 和 blockHandler 都配置

编码

结果

忽略属性。。。。

exceptionsToIgnore

编码

结果

程序异常打印到了前台了，对用户不友好

Feign 系列

修改消费侧

消费侧提供者 9001/9002

Feign 组件一般是消费侧

POM

YML

业务类

带 @FeignClient 注解的业务接口

fallback = PaymentFallbackService.class

Controller

主启动类

访问

http://127.0.0.1:9101/paymentSQL/1

测试 9101 调用 9001 ，此时故意关闭 9001 微服务提供者，看看消费侧自动降级

？？？遇到问题：com.alibaba.cloud.sentinel.feign.SentinelContractHolder.parseAndValidateMetadata

处理参考

处理方案

熔断框架比较

对比

规则持久化

是什么

一旦我们重启应用，sentinel 规则将消失，生产环境需要将配置规则进行持久化

怎么玩

将想留配置规则持久化经Nacos 保存，只需要刷新服务提供者的一个rest地址， sentinel 控制台的
流控规则就能看到，只要Nacos 里面的配置不删除，针对服务提供者的 sentinel 上的控流规则

步骤

POM

YML

添加Nacos 数据源配置

添加Nacos业务规则配置

内容解析

内容

启动 9101 后刷新 sentinel 发现业务规则有了

快速访问测试接口

停止9101 再看 sentinel

重启 9101 再看 sentinel

默认无法加载流控规则

多次调用

http://127.0.0.1:9101/rateLimit/byUrl

重新配置出现，持久化验证通过

SpringCloud Alibaba
Seata 分布式事务

分布式事务问题

分布式前

单机没有问题

从 1:1 => 1:N => N:N

分布式之后

一句话

一次业务操作需要跨多个数据源或需要跨多个系统进行远程调用，就会产生分布式事务

Steate 简介

是什么

Seata 是一款开源的分布式事务解决方案，致力于在微服务的分布式事务处理

https://seata.io/zh-cn

能干什么

一个典型的分布式事务过程

分布式事务处理过程的一个ID + 三个组件模型

Transaction ID XID

全局唯一的事务ID

3组件概念

Transaction Coordinator（TC）

事务协调者, 维护全局和分支事务的状态，驱动全局事务提交或回滚。

Transaction Manager (TM)

事务管理器, 定义全局事务的范围：开始全局事务、提交或回滚全局事务。

Resource Manager (RM)

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

处理过程

去哪里下载

https://seata.io/zh-cn/blog/download.html

怎么玩?

本地 @Transactional

全局 @GlobalTransactional

SEATA 的分布式交易解决方案

Seata-Server 安装

1. 官网地址

https://seata.io/zh-cn

2. 下载版本

3. seata-server-1.0.0.zip 解压到指定目录并
修改conf 目录下的 file.conf 配置文件

先备份

主要修改：自定义事务组名称 + 事务日志存储模式为db + 数据库链接信息

file.conf

service 模块

store 模块

完整文件

创建GC日志目录

mkdir -p logs

4. mysql5.7 新建数据库 seata

5. 在seate 库中创建表

SQL 1.1.0 版本下载包中没有在此备份

6. 修改 seata-server-1.0.0\seata\conf 目录下的 registry.conf 配置文件

7. 先启动 Nacos 端口号 8848

8. 再启动 seata-server

订单/库存/账户业务数据库准备

以一下的演示都需要先启动 Nacos 后启动 Seata 确保两个都 OK

Nacos

Seata

分布式事务说明

创建业务数据库

seata_order; 存储订单的数据库

seata_storage; 存储库存的数据库

seata_account; 存储账户信息的数据库

建库SQL

在上述的三个库创建对应的业务表

seata_order 库下创建 t_order 表

seata_storage 库下创建 t_storage 表

seata_account 库下创建 t_account 表

三个库的回滚日志表

订单-库存-账户3个库下都需要创建各自的回滚日志表

\seata\conf 目录下的 db_undo_log.sql (1.0.0 还是没有)

建表SQL

最终结果

订单/库存/账户业务微服务准备

业务需求

下订单 -> 减库存 -> 库余额 -> 改（订单）状态

新建订单 Order

1. seata-order-service

2. POM

3. YML

Nacos配置

4. file.conf

5. registry.conf

6. domain

7. Dao 接口以及实现

OrderDao

resources 文件夹下面创建文件夹 mapper

8. Service 接口以及实现

OrderService

AccountService

StorageService

9. Controller

10. Config 配置

11. 主启动类

新建库存 Storage

参考订单

新建账户 Account

参考订单

Test

数据库初始情况

下单 -> 减库存 -> 扣余额 -> 改（订单）状态

正常下单

http://127.0.0.1:2001/order/create?userId=1&productId=1&count=1&money=10

数据库情况

超时异常，没加 @GlobalTransactional

AccountServiceImpl 添加超时

数据库情况

故障情况

当库存和账户金额扣减后，订单状态并没有设置为已经完成，没有从零改为1

而且由于feign 的重试机制，账户余额还有可能被多次扣减

超时异常，添加 @GlobalTransactional

AccountServiceImpl 添加超时

OrderServiceImpl @GlobalTransactional

下单后没有任何变化

补充部分

seata

2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的一个分布式事务解决方案

Simple Extensible Autonomous Transaction Architecture ，简单刻拓展自治事务框架

2020开始，可以使用 1.0 以后版本

在看 TC/TM/RM 三大组件

TC ==> Seata 服务

TM => @GlobalTransactional 事务的发起方

RM 事务的参与方（数据库）

执行流程

TM 开启分布式事务（TM 向 TC注册全局事务记录）

按业务场景，编排数据库，服务等事务内资源（RM 让TC 回报资源）

TM 结束分布式事务，事务一阶段结束（TM 同志 TC 提交/回滚分布式事务）

TC 汇总事务信息，决定分布式事务是提交还是回滚

TC 通知所有 RM 提交/回滚资源，事务二阶段结束

AT 模式如何做到对业务的无侵入

https://seata.io/zh-cn/docs/overview/what-is-seata.html

一阶段加锁

二阶段提交

二阶段回滚

DEBUG

补充

Apache Doubbo
服务注册中心

概述

官网

http://dubbo.apache.org/zh-cn/index.html

是什么？

Apache Dubbo是一个高性能、基于Java的开源RPC框架

分布式系统理论

是什么？

《分布式系统管理与规范》定义：
“分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统”，
分布式系统（distributed system）是建立在网络上的软件系统

总结

随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已经无法应对，
分布式服务架构以及流动计算架构势在必行，需一个治理系统确保架构有一条不絮的演进。

发展演变

演变过程

RPC

RPC 基本原理

能做什么

1. 面向接口代理的高性能 RPC 调用

提供高性能的基于代理的远程调用能力，服务以接口为粒度，为开发者屏蔽远程调用底层细节。

2. 智能负载均衡

内置多种负载均衡策略，智能感知下游节点健康状况，显著减少调用延迟，提高系统吞吐量。

3. 服务注册与发现

支持多种注册中心服务，服务实例上下线实时感知。

4. 高度可拓展能力

遵循微内核+插件的设计原则，所有核心能力如Protocol、Transport、Serialization被设计为扩展点，平等对待内置实现和第三方实现。

5. 运行期流量调度

内置条件、脚本等路由策略，通过配置不同的路由规则，轻松实现灰度发布，同机房优先等功能。

6. 可视化服务治理和韵味

提供丰富服务治理、运维工具：随时查询服务元数据、服务健康状态及调用统计，实时下发路由策略、调整配置参数。

技术架构

设计架构

环境搭建

1. zookeeper 注册中心

是什么？

Zookeeper 是 Apacahe Hadoop 的子项目，是一个树型的目录服务，支持变更推送，
适合作为 Dubbo 服务的注册中心，工业强度较高，可用于生产环境，并推荐使用。

下载地址

http://zookeeper.apache.org/

安装

子主题

服务注册与发现

小总结