SpringCloud
微服务分布式架构的一站式解决方案，俗称微服务全家桶
目前主流微服务架构大概分为先通过服务网关，找到注册中心，然后去配置中心读取多个springboot开发的微服务进行协调调度，那么需要认证，如果说有容错和限流，降级熔断等等，那么整个服务的运作需要监控，日志，警告等等
SpringCloud技术栈
服务注册 EUREKA（2.0之后停更不停用） 、Zookeper 、Consul （go）、Nacos（√）
负载与调用 RIBBON（√） 、OpenFeign 、LoadBalance
熔断降级 Hystrix 、 Sentinel（阿里√）
网关 Zuul 、gateway（√）
分布式配置 SpringCloud Config 、Nacos（√）
服务总线 Nacos
开发 SpringBoot
SpringBoot、SpringCloud版本选择
ud依赖关系 Spring Cloud
更详细对应版本 https://start.spring.io/actuator/info 在线工具 - 你的工具箱
dependencyManagement 和dependencies的区别 ：dependencyManagement一般出现在顶层父pom中，用做版本管理，dependencyManagement只是实现依赖，并不实现引入，dependencies锁定子类版本号
微服务开启多个服务 view -tool-Windows -service
Jrebel安装
1.Plugins搜索 安装
2. 打开settings >Jrebel > Licence , 在线生成GUID GUID online erstellen Welcome to JetBrains License Server!:){GUID}
3.settings > Compiler > Build Project
多个服务之间的调用 ： RestTemplate（提供了多种便捷访问http服务的方法，是一种简便的访问restful服务的模板类，spring提供的访问Rest服务的工具集）
为什么有时候postman显示200，数据库却没改变，可能是因为controller中方法里面没加@requestBody
Eureka
服务治理：在传统的远程服务调用框架中，管理每个服务的与服务之间的依赖关系比较复杂，所以需要服务治理，用来服务调用，负载均衡，容错等，实现服务注册
服务注册与发现：
Eureka集群 原理：互相注册，相互守望 对外是一个整体，内部有多个eureka，互相注册
微服务远程调用核心：高可用
负载均衡 Ribbon整合Eureka之后，消费者调用服务可以直接通过服务名称，而不用通过地址端口调用，达到负载均衡效果
加注解@LoadBalanced
服务发现Discovery
对于注册到Eureka中的服务，通过服务发现获取服务信息
启动类加注解 @EnableDiscoveryClient
Eureka自我保护机制
某时刻在eureka注册的微服务不可用了，Eureka不会立刻清理，会对信息进行保存
为什么会产生保护机制：防止注册中心可以正常运行，但是在网络不通情况下，注册中心不会立刻删除注册的服务，默认90秒删除
禁止自我保护机制：
服务端
eureka server: enable-self-preservation: false #禁用保护机制 eviction-interval-timer-in-ms: 2000 #间隔时间检测心跳包（毫秒）
客户端
eureka
instance
lease-renewal-interval-in-seconds: 1 #像注册中心发送心跳时间间隔（秒）
lease-expiration-duration-in-seconds: #注册中心收到最后一次心跳机制等待时间上限（秒 默认90秒）
Ribbon 负载均衡 + RestTemplate调用
NetFilx发布的开源项目，主要提供客户端的软件负载均衡和服务调用，提供一系列完善的配置，例如连接超时，重试等，在配置文件中配置
Ribbon本地负载均衡客户端 调用微服务接口时，会在注册中心获取注册信息之后缓存到JVM本地，从本地实现RPC远程调用
Nginx服务端负载均衡 ，客户端所有请求都会提交给Nginx，然后由Nginx实现转发请求
Ribbon工作机制
1.先选择Eureka Server 优先选择在用同一个区域负载较少的服务
2.根据用户指定策略，从服务取到的服务注册列表中选择一个地址
RestTemplate使用
restTemplate.postForObject() 返回对象为json
restTemplate.getForEntity().getBody 返回对象为ResponseEntity对象，包含了响应中的一些信息，例如响应头、响应状态码、响应体等
Ribbon负载均衡机制
主要根据IRle接口， 它的实现类 AbstractLoadBalanceRule ，它的实现类 RoundRobinRule（轮询）、 RandomRule（随机） 、RetryRule（重试 ，如果轮询失败了，在指定时间类进行重试）、WeightedResponseTimeRule（权重，感觉响应速度选择，权重越大越容易被选中）
规则替换
自定义配置类不能放在@ComponentScan所扫描的当前包以及子类下，否则会被所有的客户端所共享，达不到特殊化定制的目的
启动类加注解 @RibbonClient(name = "访问的微服务名称",configuration = MySelfRule.class)
负载均衡轮询算法原理
原理 ： rest接口第几次请求 % 集群总数量 取余数 = 实际调用服务器的下标，每次重启之后，rest请求数从1开始
计数 2台
list[0] instances = 127.0.0.1 :8002
list[1] instances = 127.0.0.1: 8001
1 % 2 = 1 index = 1
2 % 2 = 0 index = 0
3 % 2 = 1 index = 1
4 & 2 = 0 index = 0
源码
int count = 0;
while(true) {
if (server == null && count++ < 10) {
List<Server> reachableServers = lb.getReachableServers(); //获取活着的服务
List<Server> allServers = lb.getAllServers(); //获取集群
int upCount = reachableServers.size(); //服务数量
int serverCount = allServers.size(); //服务器集群总数量
if (upCount != 0 && serverCount != 0) {
int nextServerIndex = this.incrementAndGetModulo(serverCount); //得到下一个服务器下标
server = (Server)allServers.get(nextServerIndex);
if (server == null) {
Thread.yield();
} else {
if (server.isAlive() && server.isReadyToServe()) {
return server;
}
server = null;
}
continue;
}
log.warn("No up servers available from load balancer: " + lb); // 如果服务== 0，报错
return null;
}
if (count >= 10) {
log.warn("No available alive servers after 10 tries from load balancer: " + lb);
}
return server;
//cas + 自旋锁 获取当前的下标
private int incrementAndGetModulo(int modulo) {
int current;
int next;
do {
current = this.nextServerCyclicCounter.get();
next = (current + 1) % modulo;
} while(!this.nextServerCyclicCounter.compareAndSet(current, next));
return next;
}
手写负载均衡轮询算法
去掉@LoadBalanced注解
OpenFeign
Feign是一个声明式WebService客户端。使用Feign能让编写WebService客户端更简单，只需要创建一个接口加注解，完成对服务方的接口绑定
Feign和OpenFeign的区别：Feign是cloud组件中的一个轻量级Restful的Http服务客户端，内置了Ribbon，OpenFeign在Feign的基础上支持了SpringMVC的注解，通过@FeignClient可以解析@RequestMaaping注解下的接口
主启动类加注解 @EnableFeignClients
OpenFeign超时控制
OpenFeign日志打印
日志级别：NONE（默认）、 BASIC（仅记录请求方法、URL、响应状态码及执行时间）、HEADERS（除了BASIC的信息之外，还有请求和响应的头信息）、FULL（除了HEADRES的信息之外，还有请求和响应的中文及元数据）
Hystrix断路器
随着系统拆分了以后，变成多个服务，这样这样低耦合了，但是随着服务的增加，数十个服务来回调用，不可避免的会失败，Hystrix是一个用途处理分布式的延迟和容错开的资源库，它能够保障在一个服微服务出现问题的情况下，不会导致整个系统失败，避免级联故障
服务雪崩：多个微服务之间的调用，如果某个服务响应时间过长或者不可用，那么会占用越来越多的系统资源，从而引发系统崩溃
断路器：本身是一种开关配置，当某个服务发生故障后，通过断路器的故障监控，给调用方法返回一个符合预期、可处理的备选响应（FallBack）而不是长时间的等待或者抛出无法处理的异常，保证服务调用方的线程不会被长时间，不必要的占用，避免发生雪崩
服务降级 （fallback）当某个服务发生故障后，通过断路器的故障监控，给调用方法返回一个符合预期、可处理的备选响应（FallBack），例如服务器忙，请稍后再试，不让客户端等待并立刻返回一个提示 什么情况下会发生降级：程序运行异常，超时，服务熔断触发服务降级
服务熔断 （break）应对雪崩效应的一种微服务链路保护机制，当某个服务不可用或响应时间过长的时候，会进行服务降级，进而熔断该节点微服务的调用，并快速返回响应信息，当检测到服务恢复正常之后，恢复调用链路。 服务降级 -> 熔断 --> 恢复调用链路
服务限流（flowlimit）例如一个系统涌进大量流量后，严禁一窝蜂的过来拥挤，需要排队，一秒N个，有序进行
服务提供者超时，或运行异常降级解决：
设置自身调用超时时间的峰值，超过峰值需要进行降级 （启动类加注解@EnableHystrix）修改@HystrixCommand内的属性建议重启项目
消费者等待时间小于服务提供者，客户端自己降级
Hystrix全局服务降级
1. 写一个fallback方法 2. 类上加注解@DefaultProperties(defaultFallback = "方法名") 3.方法上加注解@HystrixCommand ，自定义的降级就在@HystrixCommand 指定方法
Hystris通配服务降级（解耦） 案例 客户端调用服务端，服务端突然宕机
服务熔断：
服务熔断案例
Hystrixe服务监控Dashboard
导包
启动类加注解@EnableHystrixDashboard
被监控服务主启动类添加配置
服务网关GateWay
提供简单有效的方式对API进行路由，以及提供一些强大的过滤器功能：熔断，限流，重试等 ，ZUUL 1.X的替代，底层基于WebFlux框架实现，而WebFlux底层则使用了高性能的Reactor模式通信框架Netty
为什么用gateway
具有以下特性：
动态理由：可以对路由指定断言和过滤器、能够匹配任何请求属性 、集成Hystrix的断路器功能 、 请求限流功能 、 集成springcloud服务发现功能
GateWay和Zuul的区别：
Zuul基于阻塞I/O，GateWay基于异步非阻塞I/O
Zuul 1.x基于servlet2.5使用阻塞框架，不支持任何长连接（WebSocket），每次I/O操作都是从工作线程中选择一个执行，直到请求线程被阻塞到工作线程完成，性能相对较差
GateWay三大核心概念
路由：构建网关的基本模块，由ID,目标URL，一系列的断言和过滤器组成，如果断言为true则匹配该路由
断言：开发人员匹配Http请求中的所有内容，如果请求和断言匹配则进行路由
过滤：spring框架中GatewatFilter的实例，使用过滤器，可以在请求被路由前后对请求进行修改
GateWay工作流程
gateway配置 第一种方式（pom文件不需要web包 底层是webfulx，不兼容，只能有一个 ，如果删了还报错，添加spring-mvc包）
gateway配置 第二种方式
gateway配置动态路由
gateway常用的Predicate（断言）
curl调试
gateway的filter
Nacos （SpringCloud Alibaba）(github.com/alibaba/Nacos）
进入到nacosbin目录，输入cmd startup.cmd 成功之后 ： localhost:8848/nacos
AP和CP： C是所有节点在同一时间看到的数据是一致的；A的定义是所有的请求都会得到响应（高可用）
何时选择何种模式：如果不需要存储服务级别的信息，并且服务实例是通过nacos-client注册，能够保持心跳上报，那么就可以使用AP模式；如果需要在服务级别编辑或者存储配置信息，那么必须是CP模式
Nacos持久化配置
#Date Id 格式
#${spring.application.name}-${spring.profiles.active}.${file-extension}
Namespace + Group +Data Id 的关系
Namespace主要用来实现环境隔离 ，不同的Namespace之间是隔离的
Group可以把不同的微服务划分到同一个组去
Service就是微服务，一个微服务可以包含多个集群（Cluster）
Sentinel（豪猪哥的阿里版） 本地jar存放路径 cmd 》java -jar sentinel-dashboard-1.7.0.jar
修改端口 ：java -jar .\sentinel-dashboard-1.7.0.jar --server.port=9999
Senitnel流控规则（流量限制控制）
Sentinel流控效果（QPS（每秒请求数）直接失败）
Sentinel流控效果（线程数直接失败）
QPS是每秒请求数量，超过这个阈值报错，线程数是多个请求同时进来了，但是线程只有一个，多个请求同时访问报错
Sentinel流控-关联（当与A关联的资源B达到阈值，限流A）Postman使用集合模拟并发
Sentinel流控-预热（预防请求数量突然增高 Warm Up）
Sentinel流控-排队等待
Stntinel降级规则 （Sentinel的断路器没有半开状态）
Sentinel降级-RT（平均响应时间 秒级）
Sentinel降级-异常比例
Sentinel降级-异常数（时间窗口必须 >= 60s）
Sentinel热点规则（HotKey）
热点：经常访问的数据，对某个热点数据中访问次数最频繁的Top K，进行限流；热点参数限流会统计传入参数中的热点参数，并根据配置的限流阈值与模式，对包含热点参数的资源调用进行限流
参数例外项：例如p1被限流了，但是不希望所有含p1的参数都被限流
@SentinelResource只官Sentinel配置异常，不管其他的异常，其他的需要fallback参数处理
Sentinel系统规则 （系统自适应限流，对整个维度进行限流）
@SentinelResource注解配置 （自定义限流）
按资源名称限流
按URL地址限流
自定义限流
Sentinel服务熔断（配置fallback和blockhandler，exceptionsToIgnore = {异常.class} 忽略异常放行 ）如果java运行异常，会执行兜底异常，如果超过了sentinel配置的阈值，就算java报异常，也会执行sentinel的异常
Sentinel Feign
1.导包 openfeign
2.yml添加
feign: sentinel: enabled: true #激活sentinel对feign的支持
3.启动类加@EnableFeignClients
4.写接口
Sentinel持久化
1.导包
<dependency> <groupId>com.alibaba.csp</groupId> <artifactId>sentinel-datasource-nacos</artifactId> </dependency>
480
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
