SpringCloud学习笔记(1)--工具

SPRING CLOUD

微服务整体解决方案,框架集,全家桶而不是一个单独的框架.

包括:
1.eureka 注册中心
2.ribbon 负载均衡 重试
3.hystrix 降级 熔断
4.htstrix dashboard 仪表盘,hystrix数据监控
5.turine 聚合监控数据
6.feign 声明式客户端,整合ribbon(默认启用)/hystrix(不推荐)
7.zuul api网关,统一的调用入口,统一的权限校验;整合ribbon(默认启用负载均衡,默认不启用重试);整合hystrix(默认启用降级熔断,但需要自己写降级代码)
8.config 配置中心,默认git(github/码云/…)存储,但是也可以用本地存储或数据库存储
9.bus 消息总线,配置刷新
10.sleuth+zipkin 链路跟踪

1.eureka

注册中心(是微服务的核心)
eureka    VS     zookeeper
  A       P          C
可用性  分区容错性  一致性
对等结构集群     主从结构集群

注册/拉取

服务启动后每30s尝试连接一次eureka,并把地址向注册中心注册,
而eureka每30s刷新一次地址值,即从服务器拉取一次地址值.
调用其他服务,从注册中心发现其他服务的地址.

心跳及自我保护模式:

服务每30s发送一次心跳数据,eureka每30s接收一次心跳数据
连续三次丢失服务的心跳,就会删除其注册信息

eureka 的自我保护状态：
心跳失败的比例，在15分钟内是否低于85%,如果出现了低于的情况，Eureka Server会将当前的实例注册信息保护起来，同时提示一个警告，一旦进入保护模式，Eureka Server将会尝试保护其服务注册表中的信息，不再删除服务注册表中的数据。也就是不会注销任何微服务

2.ribbon(不会单独使用)

底层是使用 RestTemplate 进行 Rest api 调用;
RestTemplate 是用来调用其他微服务的工具类，封装了远程调用代码，提供了一组用于远程调用的模板方法;
负载均衡 - @LoadBalanced rt.getForObject(“http://service-id/…”);
重试 - spring-retry依赖,yml配置参数,代码配置超时时间参数.

3.hystrix - 快速失败达到系统容错的目的(不会单独使用)

降级 - HystrixCommand(fallbackMethod = “降级方法”), 实现降级代码
熔断 - 只要加了降级 熔断就默认配置
10s - 20次 - 50%失败执行降级代码 - 触发熔断
半开状态, 尝试发送一次请求,失败继续保持打开状态,成功自动关闭断路器恢复正常

4.hystrix dashboard

仪表盘, hystrix数据监控
actuator暴露监控端点: hystrix.stream

5.turbine

聚合监控数据
app-config:配置服务id(多个)
cluster-name-expression: new String("集群名")

6.feign

声明式客户端:只需要声明一个远程调用接口
通过接口可以调用远程服务
@FeignClient("调用的远程服务名")
public interface ItemFeignClient(){
	@GetMapping("/{orderId}") -- 指出访问远程服务的那个路径 以及 传递的参数
	JsonResult<List<Item>> getItem(String orderId);
}

feign + ribbon
	已经启用ribbon的负载均衡和重试
	默认配置:
	ConnectTimeout:1000
	ReadTimeout:1000
	MaxAutoRetries:0
	MaxAutoRetriesNextServer:1

feign + hystrix
	feign 默认不启用 hystrix

	启用hystrix: 
		启用: feign.hystrix.enable = true
		添加完整 hystrix 依赖,添加actuator 依赖
		添加 @EnableCircuitBreaker
		添加降级代码
			@FeignCilent(name = "服务id", fallback = 降级类)
			定于降级类,实现声明式客户端接口
			只要实现降级就有了熔断
		添加暴露监控端点 h.s

7.zuul(neflix公司写的,springcloud 进行集成)

	--springcloud自己开发了一个网关:spring cloud gatway
api网关

统一的调用入口(向后台转发)
	配置路由规则(默认配置):
	zuul:
		routes:
			服务id: /服务id/**
			item-service:/item-service/**
			
统一的权限校验 
	继承ZuulFilter抽象类,添加自定义过滤器
	@Component 交给spring管理
	
zuul + ribbon
	默认自动启用负载均衡
	默认不启用重试
		启用重试 - 
			zuul.retryable = true
			添加spring-retry 依赖
			重试的参数配置

zuul + hystirx
	zuul已经集成了hystrix,默认启用hystrix
	但是实现降级:
		实现 FallbackProvide 接口,定义降级类
		@component 交给spring管理
	暴露监控端点: h.s

zuul + filter过滤器
	定义过滤器，继承 ZuulFilter抽象类
	过度设计:返回值 Object
	zuul的第五个过滤器 向context(ctx) 对象放了serviceid
	想要使用服务id 必须在第五个过滤器后添加自定义过滤器

zuul + cookie过滤

8.feign 和 zuul 的区别

	1>都可以实现调用服务 都可以整合 hystrix ribbon
	
	2>feign
		后台微服务之间调用 后台的每个服务想要调用其他服务都要添加feign
		
	3>zuul
		部署在最前面,作为整个系统的入口

	4>feign不推荐使用 hystrix:
			每个位置添加 降级 熔断(复杂)
			特殊应用 自己添加断路器(例如热水器)
			绝大多数应用统一在前面(zuul)添加断路器(例如家庭电箱)
		
	5>zuul不推荐使用重试: 
			后面服务太多,重试一下要执行太多服务
			会对后台整条调用链路造成很大压力
			而服务之间的调用(feign)可以设置重试 影响一台而不是所有

9.config 配置中心(默认使用git存储)

1>相当于一个整个系统的中心服务
2>所有的配置文件不在项目中,而是放在配置中心
3>所有服务启动时都要去连接配置中心 从中下载配置 得到配置根据配置去启动	
4>方便管理维护配置,统一维护和管理配置文件
5>配置中心不直接保存配置文件,而是默认存放到一个git仓库(官方推荐)
	连接git仓库,从中下载所有配置文件.充分的利用了git仓库中代码存储管理功能,对配置文件进行管理维护

一.GitHub
		1.注册: - wz4j - wuze19976
		2.将项目保存到本地仓库 commit
		3.将项目上传到git仓库 push
		4.从git仓库拉取项目 pull


二.客户端从配置中心获取配置
	添加 config client 依赖
	添加 bootstrap.yml 配置文件,指定 连接的配置中心服务id和下载的配置文件	
		
三.refresh配置动态刷新:
	(只能对一台服务器指定刷新配置)
	1.添加actuator依赖,暴露 refresh刷新 端点
	2. @RefreshScope 指定到需要重新注入数据的对象
	3. @ConfigurationProperties 根据配置文件刷新
	4.向 refresh 刷新端点发送 post 请求		
	
	只能刷新一些自定义配置,一些基础配置不允许刷新,例如:
		server.port
		application.name
		eureka.client.service-url.defaultZone
		...........

10.BUS 消息总线 配置刷新

Q:---> 如何配置所有服务器同时执行刷新?
	1.不能每个服务都配置刷新 --> 服务器太多,操作复杂
	2.--->使用 BUS工具(消息总线)
		1>同时多态服务器执行配置刷新
		2>BUS 是一个 :消息队列服务器/消息中间件服务器(重要)的 连接器
		3>配置中心向BUS工具发送一条刷新指令的消息,
			  BUS将指令发送给所有的服务器,服务器执行指令,
			  重新连接配置中心,刷新配置信息
		4>只有一个解耦作用
		5>本质上是由消息队列服务器来完成

11. sleuth + zipkin --链路监控/链路跟踪

-- 链路越来越大 微服务越来越多 调用关系非常复杂 调用链路非常长

1>sleuth
	添加 sleuth 依赖 -- 就可以产生链路跟踪日志,日志发送到 rabbitmq
	
	a--->b--->c--->d
	[服务id,请求id,span id,是否发送到zipkin]
	a,26fe1621w1f6a 26fe1621w1f6a false  
	b,26fe1621w1f6a 156ds1fs++e1f false  
	c,26fe1621w1f6a 1561651651sf1 false
	d,26fe1621w1f6a 1f5e5f16ads6f false
	默认链路跟踪数据的 10% 传递到 zipkin 分析展现

2>zipkin
	zipkin client 依赖
	rabbitmq 依赖 和连接信息
	zipkin-server-2.12.9-exec.jar
	执行 zipkin 启动命令

消息中间件优点:

解耦

冗余〈存储)：有些情况下处理数据的过程会失败，造成数据丢失，可使用消息中间件进行数据持久化；

扩展性:消息中间件解耦了应用的处理过程，所以提高消息入队和处理的效率是很容易的，只要另外增加处理过程即可，不需要改变代码，也不需要调节参数。

削峰: 在访问量剧增的情况下，程序不会因为突发的超负荷请求而崩溃。

可恢复性: 当系统一部分组件失效时，不会影响到整个系，消息中间件降低了进程间的耦合度，所以即使 个处理消息的进程挂掉，加入消息中间件中的消息仍然可以在系统恢复后进行处理。

顺序保证: 在大多数使用场景下，数据处理的顺序很重要，大部分消息中间件支持一定程度上的顺序性

缓冲: 在任何重要的系统中，都会存在需要不同处理时间的元素。消息中间件通过个缓冲层来帮助任务最高效率地执行，写入消息中间件的处理会尽可能快速 该缓冲层有助于控制和优化数据流经过系统的速度。

异步通信: 在很多时候应用不想也不需要立即处理消息,消息中间件提供了异步处理机制，允许应用把 些消息放入消息中间件中，但并不立即处理它，在之后需要的时候再慢慢处理