spring cloud 1代笔记

微服务架构:

微服务的概念:
	微服务架构的核心思想就是"微",功能单一,服务细小,耦合更低,可快速的单独部署.不影响其他的服务.维护性更好.每个服务可用不同语言开发.模块之间组装容易,每个服务可快速升级,不用考虑其他服务.
	缺点显而易见,拆分后导致结构复杂.出现错误很难定位到出处.链路跟踪难.
微服务的一些概念:
	熔断概念:
		被调用的服务出现性能压力很慢,这样会影响调用方的性能,这样就会导致更上层的调用服务整体缓慢导致系统的可用性下降,这时我们就可以切断下游(被调用方)的服务来保证上层的性能稳定来维持可用性,这就是熔断机制,这很好解决了一环调用一环导致的性能阻塞.
	链路追踪概念:
		大型web项目可能有成百上千个服务,这时如果出现问题,无法精准定位具体在哪里出现的.那么我们为了避免这个问题,在每次调用服务时,都会带有一个服务ID(taceid),这样无论调用几层,到用到哪这个ID都会跟着,还会有一些调用时间等信息,这样一块一块的信息就形成了一个链路,我们就可以追踪这个链路找到具体的问题.
	API网关的概念:
		各个服务可能在不同的服务器IP就会不同.这时候能不能有个模块统一管理这些IP,让我们调用网关时不用关心被调用服务的IP.这时API网关的作用就来了,调用方只需要知晓API网关的地址和调用服务的URL,其余的都交给API网关来路由引导.而且也可以控制权限,哪些服务可以调用哪些服务.也可以做流量监控,监控哪些服务流量增加,进行一个处理操作.负载均衡也可以.协议适配,不同服务技术栈协议都不同,API网关来负责适配.也可以设置黑白名单,限制一些服务调用.

Spring cloud:

Spring cloud是一系列框架的有序集合;(是一个规范.定义一些微服务架构的解决方案)
利用spring boot的开发便利性简化微服务开发;
spring cloud 调出一些成熟的技术,屏蔽一些不好用的东西,拿来主义.
前浪:第一代的sping cloud 大部分组件是netflix公司提供.(SCN)
后浪:官方的开发了一套 
后后浪:第二代.alibaba搞了一套框架实现 spring cloud alibaba (SCA)

Spring cloud架构:

组件化开发,一堆组件组成了Spring cloud的技术栈
SCN 一代核心组件Netflix :
	注册中心:Eureka
	负载:Ribbon
	熔断:Hystrix
	网关:Zuul (不太好用)
	配置中心:spring cloud config
	服务调用:Feign
	消息驱动:spring cloud Stream
	链路追踪:spring cloud Sleuth/Zipkin
SCA 二代核心组建 Alibaba :
	注册中心:Nacos
	负载:Dubbo LB 、spring cloud Loadbalancer
	熔断:Sentinel
	网关:Spring cloud Gateway
	配置中心:Nacos 、 Apollo(携程)
	服务调用:Dubbo rpc
	消息驱动:spring cloud Stream
	链路追踪:spring cloud Sleuth/Zipkin
	分布式事物方案:seata
	Nacos这个组件可注册中心可配置中心,高端

Spring cloud结构:

注册中心Eureka:

	心跳续约:默认30s一次,90s没续约就踢出信息
	集群的结构:复制型的结构
	可以缓存节点信息,zk断链无法访问,Eureka可以
搭建demo时的步骤和注意事项.
	引入spring.cloud依赖、eureka依赖、jaxb相关依赖(JDK9后默认不引入)
	yml文件配置eureka的属性:
	client:
		instance: 
			hostname:主机名
		service-url:
			defualutZone: 交互的eureka的server地址,多个","隔开
		register-with-eureka: 当前为server 不许要注册自己 默认为true 集群下就需要把自己注册到其他eureka中了 设为true
		fetch-registry:查询注册中心的信息, 服务端就需要false 默认为true 集群需要获取,就要配置为true
	添加@EnableDiscoveryClient注解(@SpingCloudApplication 整合了spring boot、eureka、hystrix注解)

负载均衡Ribbon:(消费者负载)

设置方法:在restTemplate的bean中添加@loadBlancer即可客户端负载均衡
自定义负载规则:配置文件中添加ribbon.NFLoadBalancerRuleClassName = 负载规则实现类(base接口为IRule)	
ribbon在配置文件作用范围:用在一个注册中心服务名下的话 针对该服务生效,写在根下对所有服务生效.
源码解析:
	1.负载的实现原理:通过给Resttemplate添加一个拦截器来拦截请求,根据请求的url中servicename去注册中心进行获取提供者列表,根据负载规则进行选择提供者再进行访问.
		源码流程:根据@LoadBlancer注解标记的restTmeplate,加载到集合中,然后在定制器中有一个拦截器定制器.再循环集合给每个restTmeplate添加定制器,其中就有拦截器定制器.
	2.拦截器的具体内容:根据拦截到的URL获得serviceName,然后loadblancerclient的实现类来具体实现负载处理.这个实现类一开始自动装配时就被注入了.其中核心方法就是execute.它获取了负载均衡器loadBalancer,选择出一个server,封装成RibbonServer,继续执行下一步操作,loadBalancer也是在自动装配中注入的,还有负载均衡规则都是在自动装配的类时注入,
		2-1.server的选择:因为默认的负载策略是区域条件轮询,首先根据地区进行选择,因为亚马逊云有zone的概念,所以如此设计,国内没有这个概念,也就是一个zone那么直接进入负载均衡器的实现类的choose方法,(方法其中有一些过滤条件),在choose方法中进行轮询算法的设计,拿到当前的索引,通过实例总数求余方式获得下一个索引,cas设置下一个索引(解决并发问题),然后从list中获取该实例返回.
			2-1-1:负载均衡器选择server时,server列表已经存在,这个列表是在LoadBalancer注入时做为形参被注入到其中.所以这个bean就在LoadBalancer之前被注入.而这个列表开始注入时是空的,数据是在父类构造方法中调用restOfInit方法,该方法中的enableAndInitLearnNewServerFeature方法进行发现新的server,在这个方法中通过设置定时任务(延时启动的任务)来从注册中心获取信息,更新到本地缓存,开始时直接先获取一次.然后定时任务按时间间隔进行定时获取.获取的核心方法就是doupdateList.
		2-2.进行下一步操作,请求:在下一步中apply方法进行发起请求.进一步执行器进行execute方法,进行restTemplate的底层方法进行请求.

Hystrix熔断器:

什么是雪崩效应:微服务之间互相调用形成一个大型的调用链,如果其中的一个服务出现网络分区、宕机等问题造成的阻塞,将会影响整个链路的效率,更可能导致整条链路崩溃.这就是雪崩效应. 在某一层服务角度上说,被上游链路服务调用学名扇入,调用下游服务学名扇出,扇入量大说明复用性好.而扇出大 说明业务较为复杂,不一定是好事.
解决办法:
1.熔断:切断下游链路的调用
2.降级:不再调用该服务,直接返回本地默认值.保留核心功能
3:限流:有些功能不能直接熔断,只能通过控制量级来保证功能可用性.限制并发数、限制瞬时并发、限制时间窗口的平均速率、借口调用速率,MQ消费速率
Hystrix是防止级联失败的微服务框架
	包裹请求:添加hystrixCommand包装调用方达成熔断.(底层为切面开发)
	跳闸机制:出错率达到一定阀值,直接切断下游
	资源隔离:设置线程池,线程池已满那么再来的请求直接拒绝.不等待.加速熔断结果.
	监控:记录这些调用的情况
	回滚机制:断路器打开回退默认值的逻辑
	自我修复:熔断一定时间后,会放行小部分请求进行试验服务是否正常(半开模式)
Hystrix的应用:
	1.配置jar包
	2:添加@EnableCircuitBreaker注解开启熔断器(@SpingCloudApplication 整合了spring boot、eureka、hystrix注解)
	3.添加@HystrixCommand注解
		3-1:注解属性commandProperties,每个属性用@HystrixProperty
		3-2:服务回退,设置fallbackMethod = methodName 方法的返回值和参数都要一致.
		3-3:资源隔离,当没有设置线程池,那么所有添加@HystrixCommand注解的方法都共用一个线程池,那么这个线程池随时会满,其余请求将被拒绝.而下游服务并没有出现问题,所以要根据每个@HystrixCommand的方法单独设置线程池来保证每个方法不会被统一大并发而牵连影响,也就是舱壁模式,设置threadPoolKey 线程池ID ,设置threadPoolProperties 线程池属性.
			*Linux下jstack查看进程ID中的线程
		3-4:时间窗口 在一定的时间内,根据设置的最小请求数,如果请求失败的数量达到设置的阀值了,那么进行熔断操作.如果没达到或者时间到了,那么重新初始化.
			利用spring boot 健康检查 配置(依赖actuator)
				management.endpoints.web.exposure.include: *(所有)
				endpoint.health.show-details: always(全部显示)
			@HystrixCommand中 hystrixProperties设置属性:
				@HystrixProperty timeInMilliseconds 窗口时间
											  requestVolumeThreshod 窗口最小请求数
											  errorThresholdPercentage 阀值百分比
											  sleepWindowInMilliseconds 恢复休眠时长
		3-5:自我修复 断路一定时间,放行一个请求,检查请求是否恢复正常.入果正常,那么恢复服务关系.
	4.监控的应用:
		单个监控:监控某一个微服务实例
			引入hystrix-dashboard依赖
			添加@EnableHystirxDasdboard注解
			被监控的微服务要注册监控servelet的bean
			public ServletRegistrationBean getServlet(){
				HystrixMetricsStreamServlet streamServlet = new HystrixMetricsStreamServlet();
				ServletRegistrationBean registrationBean = new ServletRegistrationBean(streamServlet);
				registrationBean.setLoadOnStartup(1);

				registrationBean.addUrlMappings("/actuator/hystrix.stream");
				registrationBean.setName("HystrixMetricsStreamServlet");
				return registrationBean;
			}
			/actuator/hystrix.stream这个URL就可以看到健康检查的原始数据,启动项目即可查看监控页面,查看整理过的数据
		聚合监控:同时监控多个微服务实例
			创建trubine项目,专门负责聚合监控
			引入turbine依赖
			引入eureka依赖,微服务都注册到注册中心,方便发现与管理,尤其turbine更需要使用注册中心来互享信息
			添加turbine.appConfig(被监控的微服务名称) 和 turbineclusterNameExpression(集群默认名称)
			添加@EnableTurbine注解
	源码解析:
		启动类利用了spring的自动装配,加载一个启动类
		熔断器通过切面编程定义了切点,规则是添加了@HystrixCommand的注解的方法
		环绕通知具体:

Feign 远程调用:

RestTemplate的URL存在硬编码问题
Feign可以像dubbo一样面向接口进行远程调用
Feign的应用:
	feign的效果相当于 RestTemplate+ribbon+hystrix 所以不需要引入熔断器了.
	加入@EnableFeignClients注解 来开启feign
	创建接口,对应远程调用.加入@FeignClient(value = 注册中心提供者服务名称 ,path = 类级别的RequestMapping属性)注解
	相当于dubbo的@service
	service中将requestmapping属性都配置上,相当于将url拆开,feign进行组装并发起请求.
	我们调用服务时就变成了接口式的调用.不再使用rest而是直接调用service接口.
Feign的负载均衡:
	feign的默认超时时间是1s,如果超时,那么feign将会出发超时机制去访问提供者服务集群其他服务.
	配置文件中属性: 在ribbon上设置的一些属性
	NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RoundRobinRule
	#请求连接超时时间
	ConnectTimeout: 2000
	#请求处理超时时间
	ReadTimeout: 5000
	#对所有操作都进⾏重试
	OkToRetryOnAllOperations: true
	####根据如上配置，当访问到故障请求的时候，它会再尝试访问⼀次当前实例（次数由MaxAutoRetries配置），
	####如果不⾏，就换⼀个实例进⾏访问，如果还不⾏，再换⼀次实例访问（更换次数由MaxAutoRetriesNextServer配置），
	####如果依然不⾏，返回失败信息。
	MaxAutoRetries: 0 #对当前选中实例重试次数，不包括第⼀次调⽤
	MaxAutoRetriesNextServer: 0 #切换实例的重试次数
Feign的日志级别:
	添加一个bean 返回 Logger.level 
	配置文件logging.level.feign客户端类 = 日志级别(INFO、DEBUG)
Feign熔断器的支持:
	开启熔断器:
		feign.hystrix.enable = true
	服务降级:
		通过一个类实现feign客户端的接口,实现的方法就为降级的回退方法,在Feign客户端的FeignClient注解中设置fallback = 实现的class
		配置文件中也要注意设置hystrix的超时时间. 这个超时时间和feign的超时时间 以最小的为准, 最小的超时了 就走最小的处理逻辑,比如feign小,那么超时了就可以根据配置重试机制进行重试或者直接回退方法执行,如果hystrix时间小,那么超时就只会进入回退方法.
feign请求压缩:
	设置配置文件:

GateWay网关:

生产环境架构:外部请求->nginx-负载>网关,网关转发到不同的服务
关键词:
	路由route:一个id,一个目标url,一系列断言条件和过滤器组成,
	断言:一些规则匹配
	过滤器:根据业务进行条件过滤,可进行进出过滤.(来前添加一些参数,出前包装一些参数)
应用:
	引入gateway依赖 webflux依赖 eureka依赖
	配置文件:
		server.port配置
		eureka配置
		spring.application.name 配置
		spring:
			cloud:
				gateway:
					routes: # 路由可以有多个
						- id: service-autodeliver-router 
						# 我们⾃定义的路由 ID，保持唯⼀
						uri: http://127.0.0.1:8096  (需要切换为eureka的服务name)
						# ⽬标服务地址 ⾃动投递微服务（部署多实例） 动态路由：uri配置的应该是⼀个服务名称，⽽不应该是⼀个具体的服务实例的地址
						#gateway⽹关从服务注册中⼼获取实例信息然后负载后路由
						predicates: 
						#断⾔：路由条件，Predicate接受⼀个输⼊参数，返回⼀个布尔值结果。该接⼝包含多种默认⽅法来将Predicate组合成其他复杂的逻辑（⽐如：与，或，⾮）。
							- Path=/autodeliver/**

						- id: service-resume-router # 我们⾃定义的路由 ID，保持唯⼀
						uri: http://127.0.0.1:8081 (需要切换为eureka的服务name)
						# ⽬标服务地址
						predicates: #断⾔：路由条件，Predicate接受⼀个输⼊参数，返回⼀个布尔值结果。该接⼝包含多种默认⽅法来将Predicate组合成其他复杂的逻辑（⽐如：与，或，⾮）。
						- Path=/resume/**

						filters:
							- StripPrefix=1
路由规则的详解:
	断言的的种类:
		时间类:- after  before between
		cookie: Cookie
		header:头信息
		host:主机信息
		method请求方法
		path路径, 主要使用
		queryParam参数信息
		RemoteAddr远程地址过滤
	动态路由: 一个路由的uri应该是eureka的服务,而不应该是具体某个IP的实例.具体IP无法负载.
		uri语法: uri: lb://serviceName
Gateway过滤器:
	Global全局,所有路由
	GateWay单个路由
	过滤器生命周期时机点:
		pre请求之前
		post请求之后
	一个常用的过滤器 StripPrefix=NUM 取消掉num层url目录层
	自定义全局过滤器:
		实现GlobalFilter和Orderd接口,前者是拦截器处理方法,后者为拦截器执行的优先级.
		在拦截器执行完毕返回数据上,要注意使用流处理进行write返回
Gateway的高可用:将gateway集群,通过nginx负载

Spring Cloud Config 分布式配置中心:

集群多实例下,单个更改配置文件比较麻烦容易出错,不停下服务的情况下动态更新配置.
需求点:集中配置、多环境、动态调整、自动更新配置
结构跟注册中心差不多, 需要一个配置中心,其余服务都为这个配置中心的客户端,但同样要注册到注册中心
配置中心依托git进行仓储配置,所以配置文件是放入git中
应用:
	添加EnableConfigServer注解
	配置文件配置:
	spring:
		application:
			name: lagou-service-autodeliver
		cloud:
			config:
				server:
					git:
						uri: https://github.com/5173098004/lagou-config-repo.git
						#配置git服务地址
						username: 517309804@qq.com #配置git⽤户名
						password: yingdian12341 #配置git密码
						search-paths:
							- lagou-config-repo
				# 读取分⽀
				label: master
	服务配置为配置中心客户端:
		添加配置中心客户端客户端依赖.
		配置文件使用顶级配置文件bootstrap.yml 设置配置中心的的属性
			spring:
				cloud:
					name:配置文件名称
					profile: 环境名称
					labe:分支名称
					uri: 配置中心uri
		客户端更新配置:
			手动更新:
				暴露刷新接口 actuator/refresh.
				添加@RefreshScope注解
				主动调用暴露的接口URL刷新.
			自动更新(广播机制):
				通知改动,涉及到的服务去更新,否则不更新
				消息总线方案Bus:
					基于MQ,当配置文件变更后,配置中心发送消息给消息中心,消息中心再根据订阅的服务进行发送
				应用:
					安装MQ rabbitMq.配置mq:
						spring:
							rabbitmq:
								host:
								port:
								username:
								password:
					暴露接口配置 actuator/的一些东西
					通过启动配置中心并访问刷新url
					/actuator/bus-refresh即可刷新,如果指定某个服务刷新,那么就加上/服务名:端口

spring cloud stream消息驱动组件:

基于消息机制做一些事情:这其中将使用MQ消息队列,MQ可解耦、异步消息处理、流量削峰.但众多MQ各有各的特点,各有各的核心组件,而这些组件可能不通用,接口不统一.那么MQ与业务代码将耦合在一起,更改MQ会比较麻烦.SpringcloudStream就解决了这个问题.但目前只支持rabbitMq和Kafka
spring cloud stream是一个构建消息微服务的框架,通过Binder组件来抵消不同MQ之间的差异,切换不同的MQ只需要切换不同的binder
一些概念:
	input:输入是指MQ针对于咱们的消费者角度来提出的概念,既MQ将消息输入到消费者服务,消费者来消费这些数据,这就是input的概念
	output:同理,消息生产者将数据输出到MQ,等待被消费者消费,这就是输出的概念
	通道:binddings binder与业务服务交互的通道
一些注解:
	@Input 标记输入通道 消费数据
	@output 标记输出通道 生产数据
	@StreamListener 监听队列 监听消息接收
	@EnableBinding 绑定 通道和 MQ的 topic