Spring Cloud 微服务技术栈入门到精通

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

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

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

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

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

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

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

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

缓存结果

断路器状态

线程池/请求队列/信号量是否满了

健康指标

@CacheKey

@CacheResult

@CacheRemove

@EnableHystrixDashboard

turbine集群监控

不论是HystrixCommand还是HystrixObervableCommand从类命名上可以看到Hystrix其实是使用了"命令模式"，通过命令模式实现对服务调用操作的封装，将每个命令在一个独立线程中进行执行；

当某个服务的错误率超过一定阀值时(默认在20秒内失败5次), Hystrix可以自动或手动进行服务跳闸，停止向该服务请求一段时间；

Hystrix为每一个服务依赖都维护了一个小型线程池，如果该线程池已满，那么发往该服务的请求就会立即被拒绝，而不是排队等候，从而加速服务失败的判定；

Hystrix可以近乎实时地监控运行指标和配置的变化，例如对请求的成功、失败、超时以及拒绝等；

当请求失败、超时、被拒绝、或当断路器打开时，执行相应的回退逻辑;

当断路器打开一段时间后，Hystrix会进入"半开"状态，断路器会允许一个请求尝试对服务进行请求，如果该服务可以调用成功，则关闭断路器，否则将继续保持断路器打开。

待完善

默认集群监控

指定集群监控

单机应用监控

通过Sleuth可以很方便的了解到每个采样请求的耗时，从而分析出哪些服务调用比较耗时;

对于程序未捕捉的异常，可以通过集成Zipkin服务界面上看到;

对于调用比较频繁的服务，可以针对这些服务实施一些优化措施。

Zipkin是一个致力于收集分布式服务的时间数据的分布式跟踪系统。

collector

storage

search

UI

在生成环境中，由于业务量比较大，所产生的跟踪数据可能会非常大，如果全部采集一是对业务有一定影响，二是对存储压力也会比较大，所以采样变的很重要。一般来说，我们也不需要把每一个发生的动作都进行记录。

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

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

zipkin-server-2.12.9-exec.jar

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

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

术语

可以探究原理以及修改代码

经过Netflix多年的生产环境考验，使用比较省心

不但提供了完整的注册发现服务，还有 Ribbon等配合使用的服务

当Eureka客户端向Eureka Server注册时，它提供自身的元数据，比如IP地址、端口，运行状况指示符URL，主页等。

Eureka客户会每隔30秒发送一次心跳来续约。 通过续约来告知Eureka Server该Eureka客户仍然存在，没有出现问题。 正常情况下，如果Eureka Server在90秒没有收到Eureka客户的续约，它会将实例从其注册表中删除。 建议不要更改续约间隔。

Eureka客户端从服务器获取注册表信息，并将其缓存在本地。客户端会使用该信息查找其他服务，从而进行远程调用。该注册列表信息定期（每30秒钟）更新一次。每次返回注册列表信息可能与Eureka客户端的缓存信息不同， Eureka客户端自动处理。如果由于某种原因导致注册列表信息不能及时匹配，Eureka客户端则会重新获取整个注册表信息。 Eureka服务器缓存注册列表信息，整个注册表以及每个应用程序的信息进行了压缩，压缩内容和没有压缩的内容完全相同。Eureka客户端和Eureka 服务器可以使用JSON / XML格式进行通讯。在默认的情况下Eureka客户端使用压缩JSON格式来获取注册列表的信息。

Eureka客户端在程序关闭时向Eureka服务器发送取消请求。 发送请求后，该客户端实例信息将从服务器的实例注册表中删除。该下线请求不会自动完成，它需要调用以下内容： DiscoveryManager.getInstance().shutdownComponent()；

在默认的情况下，当Eureka客户端连续90秒没有向Eureka服务器发送服务续约，即心跳，Eureka服务器会将该服务实例从服务注册列表删除，即服务剔除。

服务发现

健康检查

KV 存储

多数据中心

可视化WEB管理

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

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

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

Nacos: Dynamic Naming and Configuration Service

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

替代 Eureka 做服务注册中心

替代  Config 做服务配置中心

https://github.com/alibaba/nacos

官方文档

创建数据库 nacos

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

mysql 连接字符串（application.yml）

结果

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

POM

YML

主启动类

业务类

测试

POM

YML

主启动类

业务类

测试

各种注册中心的对比

POM

YML

主启动类

业务类

在 Nacos 中添加配置信息

测试

自带动态刷新

问题

Nacos 的图形化管理界面

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

Case

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

官网架构图

上图翻译真实情况

说明

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

derby 到 mysql 切换配置步骤

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

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

Nacos  下载 liunx 版本

集群配置步骤（重点）

测试

高可用小总结

集中管理配置文件

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

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

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

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

ssm-laboratory-config

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

表示多个环境的配置文件

保存格式必须为 UTF-8

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

@EnableConfigServer

127.0.0.1 config3344.com

启动 3344

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

官网

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

/{application}-{profile}.yml

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

重要配置细节总结

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

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 没有变化，除非自己重新启动或者重新加载

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

步骤

服务端和客户端公用相同接口

注解相似

优缺点

指定服务配置

全局配置

重试配置

全局配置

禁用配置

降级配置

请求压缩

日志设置

微服务调用接口 + @FeignClient

@EnableFeignClients

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

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

控制层 Controller

@Service

逐渐增加某一个服务集群的流量，以了解服务性能; 

为每一个负载类型分配对应的容量，对超过限定值的请求弃用;

敏感字段

过滤类型

执行顺序

执行条件

具体操作

动态路由

动态过滤器

@Service

SpringCloud Gateway 使用的 Webflux 中的 reactor-netty 响应式异步非阻塞组件，底层采用了netty 通讯框架

源码架构

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

我们为什选择 gateway

zuul1.0 模型

gateway 模型

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

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

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

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

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

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

POM 

YML

GatewayFilter

GlobalFilter

自定义全局过滤器

分布式自动刷新配置功能

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

Bus 支持两种消息代理

http://localhost:15672

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

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

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

POM

YML

POM

YML

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

运维工程师

配置中心

客户端

ok

只通知 payment-8001

 不通知 payment-8002

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

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

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

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

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

@Service

集中式 LB

进程内 LB

配置轮询（默认轮询）

Ribbon + RestTemplate

cn.edu.cqvie.myrule

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

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

SEATA 的分布式交易解决方案

service 模块

store 模块

完整文件

mkdir -p logs

Nacos配置

OrderDao

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

OrderService

AccountService

StorageService

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

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

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

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

演变过程

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

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

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

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

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

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

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

http://zookeeper.apache.org/

解压

创建配置文件

运行 

https://github.com/apache/dubbo-admin

mvn clean install

java -Dserver.port=8081 -jar dubbo-admin-server-0.2.0.jar

http://127.0.0.1:8081

准备工作

启动服务发布端（dubbo-provider）

启动服务消费者（dubbo-consumer）

查看服务生产者/消费者

http://dubbo.apache.org/zh-cn/docs/user/best-practice.html

-Ddubbo.registry.address=zookeeper://127.0.0.1:2181

dubbo.registry.address=zookeeper://127.0.0.1:2181

RegistryConfig.setAddress("zookeeper://127.0.0.1:2181")

dubbo.registry.address=zookeeper://127.0.0.1:2181

dubbo.reference.com.foo.BarService.check=false
dubbo.reference.check=false

dubbo.consumer.check=false

dubbo.registry.check=false

查询/修改/删除，不管查询多少次都是幂等的。

数据库新增，比如超时了，就不能是幂等的。

声明服务 1.0.0

声明服务 2.0.0

@EnableDubbo

dubbo.scan.base-packages=cn.edu.cqvie

@org.apache.dubbo.config.annotation.Service(version = "1.0.0")
public class UserServiceImpl implements UserService {
    // other code
}

@Reference(version = "1.0.0")
private UserService userService;

provider.xml 示例

consumer.xml 示例

配置文件

指定Spring扫描路径

健壮性

监控中心宕机不影响使用，只是丢失部分采样数据

数据库宕机后，注册中心仍然能通过缓冲提供服务列表查询，但不能注册新服务

注册中心对等集群，任意一台宕机后，将自动切换到另一台

注册中心全部宕机后，服务提供者和服务消费者仍能通过本地缓存通讯

服务提供者无状态，任意一台宕掉后，不影响使用

服务提供者全部宕掉， 服务消费者应用将无法使用，并无限次重连等待服务提供者恢复

@Reference(version = "1.0.0", url ="dubbo://192.168.1.4:20881")

当服务器压力剧增的情况下，根据实际业务情况以及流量，对一些服务和页面有策略的不处理
或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运作或高效运作。

可以通过服务降级功能 [1] 临时屏蔽某个出错的非关键服务，并定义降级后的返回策略。

向注册中心写入动态配置覆盖规则：

RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getAdaptiveExtension();
Registry registry = registryFactory.getRegistry(URL.valueOf("zookeeper://10.20.153.10:2181"));
registry.register(URL.valueOf("override://0.0.0.0/com.foo.BarService?category=configurators&dynamic=false&application=foo&mock=force:return+null"));
其中：

mock=force:return+null 表示消费方对该服务的方法调用都直接返回 null 值，不发起远程调用。用来屏蔽不重要服务不可用时对调用方的影响。
还可以改为 mock=fail:return+null 表示消费方对该服务的方法调用在失败后，再返回 null 值，不抛异常。用来容忍不重要服务不稳定时对调用方的影响。

Failover Cluster

Failfast Cluster

Failsafe Cluster

Failback Cluster

Forking Cluster

Broadcast Cluster

RPC 原理

Netty 原理

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

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

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

前提

命令

http://127.0.0.1:8080

登录账号密码均为: sentinel

界面

服务访问

效果

直接 -> 快速失败

配置说明

测试

关联是什么

配置 A 

postman 模式并发密集访问 testB

运行后发现testA 挂了

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

自己试试

直接失败，抛出异常

源码

说明

官网

源码

WarmUp  配置

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

应用场景

设置

设置效果

官网

源码

测试

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

复习 Hystrix

是什么

代码

jemter 压测

结论

是什么 

代码

配置

jemter 测试

总结

是什么

异常数是按照分钟统计的

测试

配置

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%    

配置

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

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

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

普通

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

特例

子主题

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

POM

YML

业务 RateLimitController

主启动类

配置步骤

图形配置和代码关系

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

1秒钟点击1下，OK

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

关闭服务试试

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

http://127.0.0.1:9001/byResource

配置

http://127.0.0.1:9001/byResource

结果

CustomerBlockHandler 

http://127.0.0.1:9001/rateLimit/customerBlockHandler

SphU 自定义资源

Tracer 定义统计

ContextUtil 定义了上下文

POM

YML

主启动类

业务类

测试地址

POM 

YML

主启动类

业务类

消费侧提供者  9001/9002

Feign 组件一般是消费侧

带 @FeignClient 注解的业务接口

fallback = PaymentFallbackService.class

Controller

http://127.0.0.1:9101/paymentSQL/1

处理参考

处理方案

添加Nacos 数据源配置

内容解析

默认无法加载流控规则

多次调用

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

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

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

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

中文资料

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

消息必须走特定的通道

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

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

Binder

Topic 主题进行广播

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

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

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

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

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

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

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

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

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

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

如何解决

生产实际问题

故障现象是重复消费

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

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

重复消费问题

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

group: atcqvie-01, atcqvie-02

消费者-1 修改 YML

消费者-2 修改 YML

自己的配置

结论

group: atcqvie-01

消费者-1 修改 YML

消费者-2 修改 YML

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

等价于

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

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

注册到 nacos

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

启动 nacos

启动 payment-service、order-service

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

Nacos 全景图所示

Nacos 和 CAP

切换

bootstrap.yml

application.yml

Nacos 中的匹配规则

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

启动配置信息

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

多环境多项目管理

配置空间

命名空间

三种方案加载配合

持久化

官网说明

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

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

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

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

nacos-server-1.2.0.tar.gz

解压后安装

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

2. apolication.properties 配置

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

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

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

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

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

查看服务注册情况

实现服务之间的相互调用