代码拉取完成，页面将自动刷新
#cloud2020
说明:
本项目是看B展阳哥的视频跟着敲写的项目.主要是跟着学习微服务
###学习到的springcloud相关组件 nacos 1.1.4 springBoot 2.2.2.RELEASE springCloud Hoxton.SR1 springCloud-alibaba 2.1.0.RELEASE mysql 8.0.20 druid 1.1.16 eureka: eureka注册中心 主要用于服务注册与发现 分为服务端和客户端 zookeeper 3.4.9 也可以用于服务注册与发现.但不仅限于此, consul 1.6.1 consul启动命令 首先双击安装 之后cmd运行 consul agent -dev Hystrix: 提供服务降级,服务熔断,服务治理 Hystrix Dashboard是Spring Cloud的仪表盘组件，可以查看Hystrix实例的执行情况，支持查看单个实例和查看集群实例，但是需要结合spring-boot-actuator一起使用 gateway: 的作用 1.权限控制：网关作为微服务入口，需要校验用户是是否有请求资格，如果没有则进行拦截。 2.路由和负载均衡：一切请求都必须先经过 gateway，但网关不处理业务，而是根据某种规则，把请求转发到某个微服务，这个过程叫做路由。当然路由的目标服务有多个时，还需要做负载均衡。 3.限流：当请求流量过高时，在网关中按照下流的微服务能够接受的速度来放行请求，避免服务压力过大。 springcloud-bus： bus 是springcloud配置中心的公共配置刷新的一个组件. 共有两种架构方式: 第一种是 每个服务连接上之后. 通过调用接口单独去刷新该服务的接口地址是: http://localhost:{服务端口号}/actuator/refresh 第二种是 整合RabbitMq/kafka. 通过消息总线 同时刷新所有连接到模块: http://localhost:3344{配置中心端口号}/actuator/bus-refresh/ 也可以指定某个服务去刷新最新的配置 地址是: http://localhost:3344/actuator/bus-refresh/cloud-client:3355{刷新服务的名称(spring.application.name)}:{端口号} 其它说明: 配置中心除了配置rabbitMq的链接 还需要 暴漏bus刷新配置的端点: 配置如下 ##rabbitmq相关配置,暴漏bus刷新配置的端点 management: endpoints: web: exposure: include: 'bus-refresh'
cloud-Stream: 说明: 它是一个框架屏蔽底层消息中间件的差异,降低切换成本,统一消息的编程模型 问题重复消费: 同一个组中会发生竞争关系,只有其中一个可以消费. 不同组是可以全面消费的(重复消费) 解决重复消费: 需要给binder下面进行分组group: atguiguA 不过不配置这个分组那么服务挂了之后在启动也不会重新消费之前没有消费的消息.消息队列中的数据会丢失.
cloud-sleuth: 说明: 它是一个链路追踪的组件. 整合了zipkin. zipkin服务端下载地址: https://repo1.maven.org/maven2/io/zipkin/zipkin-server/ 通过在生产者(payment8001)和消费者(order80)之间的yml增加如下配置: zipkin: base-url: http://localhost:9411 sleuth: sampler: probability: 1 #采样率值介于 0 到 1之间, 1 则表示全部采集 可以在调用接口之后在访问地址: http://localhost:9411/zipkin/ 可以看到服务的链路 依赖(调用的流程图) 以及调用的服务关系(谁调用了谁)等西悉尼
##=========================下面正式进入springcloud Alibaba===##
Nacos : 说明: 主要作用于 服务的注册与发现 默认端口 8848 下载地址:https://github.com/alibaba/nacos/releases/tag/2.1.0 nacos默认是五秒钟向注册中心发送一次心跳 至于单个运行和linux中集群配置 我都记到自己的印象笔记里面了. 下面就简单的说一下配置 2.x以后默认是集群配置需要打开 bin目录下面的startup.cmd 文本方式打开找到 set MODE="cluster" 改成 set MODE="standalone"
切换数据库配置的话就打开 conf文件夹下面 application.properties 文件 加上如下配置 spring.datasource.platform=mysql
db.num=1
db.url.0=jdbc:mysql://127.0.0.1:3306/nacos?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true&useUnicode=true&useSSL=false&serverTimezone=UTC
db.user=root
db.password=123456
##注册中心: eureka zookeeper consul 这三个都可以用作注册中心 eureka的设计思想是分布式cap里面的ap 某个时刻微服务不能用了不会立刻清楚服务节点
zookeeper 主要是cap理论中的cp理论 如果某个服务宕机，服务断开一定时间(默认30s)临时节点会自动删除.
zookeeper下载地址: https://zookeeper.apache.org/
consul 主要是cap理论中的cp理论 如果某个服务宕机，服务断开一定时间(默认10s)临时节点会自动删除.
consul说明:
consul下载地址: https://www.consul.io/
1.什么是CAP理论 CAP 理论是针对分布式数据库而言的，它是指在一个分布式系统中， 一致性（Consistency, C）、 可用性（Availability, A） 分区容错性（Partition Tolerance, P）三者不可兼得.
Consistency（一致性）：即更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致。对于客户端来说，一致性指的是并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。 Avaliability（可用性）：即服务一直可用，而且是正常响应时间。系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。 Partition Tolerance（分区容错性）：即分布式系统在遇到某节点或网络故障的时候，仍然能够对外提供满足一致性和可用性的服务。分区容错性要求应用虽然是一个分布式系统，但看上去切好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能够正常运转满足系统要求，对于用户而言并没有什么体验上的影响
2. Eureka 是AP zookeeper 和 consul 是cp
3. cap理论关注粒度是数据,而不是整体系统设计的策略
4. Eureka 语言是java Consul 语言是Go Zookeeper java
###服务调用
Hystrix: 服务降级: 服务降级通俗点来说呢. 就是指定一个统一的错误返回信息. 也可以说成找一个备胎装上. 不难 1.服务降级个人理解说明: 当接口服务发生超时,报错,或者宕机 接口应该找一个备用方法直接return(返回一个)信息.避免服务挂起,耗死服务器 2. 服务降级主要是在接口 或者openFeign调用方法中 使用 @HystrixCommand 2.1 为了解决代码膨胀(一个方法要指定一个降级方法会导致代码膨胀) 可以在openFeign调用的接口层,创建一个新的类 来继承openFeign指定的接口. @FeignClient(value = "CLOUD-PROVIDER-HYSTRIX-PAYMENT",fallback = PyamentFallbackService.class) PyamentFallbackService 实现后 如果服务发生 超时,报错,或者宕 接口会直接返回里面的数据 2.2 为了解耦合可以在controller上面指定一个全局的@DefaultProperties(defaultFallback = "payment_global_fallbackMethod") 异常处理
@HystrixCommand(fallbackMethod = "circuitBreaker_fallback",commandProperties = { @HystrixProperty(name = "circuitBreaker.enabled",value = "true"),//是否开启熔断器 @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold",value = "10"),//请求次数 @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds",value = "10000"),//时间窗口期 @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage",value = "60"),//失败率达到多少后跳闸
})
###(各个module说明)模块说明: eureka服务中心: cloud-eureka-server7003 cloud-eureka-server7002 cloud-eureka-server7001 服务提供者: cloud-provider-payment8001 cloud-provider-payment8001 eureka消费者: cloud-consumer-order80 ribbon: cloud-consumer-order80 公共包: cloud-api-commons zookeeper作为服务注册: 服务提供者: cloud-provider-payment8004 消费者:cloud-consumerzk-order80 consul作为服务注册: 服务提供者: cloud-providerconsul-payment8006 消费者: cloud-consumerconsul-order openfeign作为消费者: cloud-consumer-feign-order80 hystrix框架: 服务提供者: cloud-provider-hystrix-payment-8001 消费者: cloud-consumer-feign-hystrix-order80 hystrixDashboard图形化处理: 监控服务降级和服务熔断的图形化界面 访问地址是 http://localhost:9001/hystrix 豪猪页面 gateway网关: cloud-gateway-gateway9527 SpringCloud-config:分布式配置中心: 配置中心: cloud-config-center-3344 客户端: cloud-config-client-3355 和 cloud-config-client-3366 客户端刷新: http://localhost:3355/actuator/refresh
springcloud-bus 消息总线作用:
springcloud-stream: 消息驱动 生产者: cloud-stream-rabbitmq-provider8801 消费者: cloud-stream-rabbitmq-consumer8802 消费者: cloud-stream-rabbitmq-consumer8803
springcloud-sleuth: Spring Cloud Sleuth 主要功能就是在分布式系统中提供追踪解决方案。Spring Cloud Sleuth是对Zipkin的一个封装，对于Span、Trace等信息的生成、接入HTTP Request，以及向Zipkin Server发送采集信息等全部自动完成 zipkin下载地址: https://repo1.maven.org/maven2/io/zipkin/zipkin-server/ spanid：每次调用服务的顺序。 traceid：每次请求的唯一标识。 parentid：标识调用服务的层级关系。 timestamp：上述的三个标识还不够，还需要加上时间戳，时间戳可以更精细一点，精确到微秒级。 整合zipkin需要引入以下jar包 org.springframework.cloud spring-cloud-starter-zipkin 模块有: cloud-provider-payment8001 消费者: cloud-consumer-feign-order80
Nacos模块有: 服务提供者: cloudalibaba-provide-payment9001 cloudalibaba-provide-payment9002
消费者: cloudalibaba-consumer-nacos-order83 配置中心: cloudalibaba-config-nacos-client3377
sentinel模块有: cloudalibaba-sentinel-service8401
服务提供者:
cloudalibaba-nacos-provide-papyment9003 cloudalibaba-nacos-provide-papyment9004
消费者: cloudalibaba-consumer-nacos-order84
seata模块有: 用户模块: seata-account-service2003 订单模块: seata-order-service2001 库存模块: seata-storage-service2002
###微服务模块开发的总结: 1. 创建module 2. 该POM 中的引入 3. 写YML 的配置 4. 主启动 别忘了写 5. 业务类 最后才是写自己的增删改查业务
###微服务技术说明:
Eureka 是通过c/s的架构设计. Eureka Server作为服务注册公的服务器,他是服务注册中心,而系统中的其它微服务,使用Eureka的客户端
EurekaClient 通过注册中心进行访问. 用于简化EurekaServer的交互,客户端同事也具备一个内置的,使用轮询(round-robin)负载算法
的负载均衡器. 在应用启动后,将会向Eureka Server发送心跳(默认周期为30秒).如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳
,urekaServer将会从服务注册表中把这个服务节点移除(默认90秒)
其它知识点记载:
学习新框架的方法： 它是什么？ 能干什么 ？ 去哪里下载？多思考?
学习的三板斧是: 理论 实操 小总结 三板斧搞起来
最多只能同时较好的满足两个 CAP理论的核心：一个分布式系统不可能同时很好的满足三个需求。因此根据CAP原理将 NOSQL数据库分成了满足CA原则，满足CP原则和满足AP原则三大类。
CA：单点集群，满足一致性，可用性的系统，通常扩展性不强大。 CP：满足一致性，分区容错性的系统，对数据一致性要求高，所以性能负担大。 Zookeeper/Consul 要求数据必须一致性。 AP：满足可用性，分许容错性的系统，通常可能对一致性要求低一些。 Eureka 场景：商场，暂时不一致错一点没关系，只要能正常访问下单即可。 Eureka通过设置一些属性，也可以通过牺牲高可用性实现一致性的要求。
A: 代表 可用性 Eureka这一点做的很好 C: 代表 一致性 P: 分区容错性
分布式必须满足:P: Partition tolerance 分区容错性
Eureka主要保证高可用：AP Zookeeper/Consul主要保证数据的一致：CP nacos可以是AP也可以是cp
web界面 ●Eureka/Consul/nacos都有一个web界面。 ●Zookeeper只有一个linux客户端
描述一下Ribbon怎样使用自定一的算法,和换一种算法是怎么实现的
1.怎样使用自定义的算法:
1.1 首先定义一个接口. 接口中定义一个方法 通过传入提供的所有服务的列表List 然后通过算法 去选择你对应的服务提供者
1.2 在controller中注入这个接口通过DiscoveryClient.getInstances("服务名称"); 得到所能提供的所有服务.在传给注入的接口选出服务
1.3 要关闭@RibbonClient(name = "CLOUD-PAYMENT-SERVICE",configuration = MySelfRule.class)
2. ribbon怎样换一种算法.
2.1 首先自定义一个算法实现类. 定义一个方法 返回IRule 默认是RoundRobinRule
我们可以 new RandomRule 等等
同时要在启动类上加上@RibbonClient(name = "CLOUD-PAYMENT-SERVICE",configuration = MySelfRule.class)
总结 自定义算法 和 修改默认算法. 只能使用一个.
##随堂小记
SpringCloud config+bus 和Nacos 配置中心对比:
SpringCloud Bus的配置中心指定在那个项目中去读取配置文件 而客户端通过设置label(哪一个分支),name(配置文件名称),profile(后缀名称)去配置读取文件名称
而nacos指定的是你的配置文件的名称要按照:
${spring.application.name}-${spring.profile.active}.${spring.cloud.nacos.config.file-extension}
${服务名称}-{什么分支}.{配置文件格式yaml/yml等}
nacos-config-client-dev.yaml 对应模块: cloudalibaba-config-nacos-client3377
这个规则去创建.
Nacos的优点：
可以按照命名空间(Namespace)/分组(group)/dataid(配置文件名称)/等进行 分类配置
1. nacos的配置是在本地读取的. 创建的配置文件都有对应的操作界面 维护管理起来非常的方便
2. nacos的配置刷新不需要用到消息队列rabbitmq/kafka
默认五秒钟向注册中心发送心跳
Nacos的缺点:
指定配置文件的创建规则.不对的话读取不到配置
Nacos配置文件的优先级
共享配置(shared-configs) 可以将一些公共的配置放在一个自定义的配置文件中.多个服务去加载这个共享配置 如redis。mysql
A：通过内部相关规则(应用名、扩展名、profiles)自动生成相关的 Data Id 配置优先级最高
B：扩展配置(extension-configs) > 共享配置(shared-configs)
C：同为扩展配置，存在如下优先级关系：extension-configs[3] > extension-configs[2] > extension-configs[1] > extension-configs[0]
D：同为共享配置，存在如下优先级关系：shared-configs[3] > shared-configs[2] > shared-configs[1] > shared-configs[0]
eureka: 默认是30向服务端发送心跳
Sentinel组件说明:
说明:
sentinel的官网地址是: https://sentinelguard.io/zh-cn/ 其它介绍请看官网
sentinel中的实时监控,要想监控服务提供者的完整链路调用,必须得开启sentinel对feign得支持
流控规则:
阈值类型:
QPS: 什么是qps？ qps的意思就是每秒请求数量来进行限流 相当于大门每秒只能进多少个人.超过了就不让你进了.
线程数: 什么是线程数呢？. 线程数的意思就是同时可以有几个人访问这个api. 相当于大门里面的工作人员同时能处理几个事情. 超过了请求虽然进来了.但是也直接告诉你我忙不过来.还得等.
流控模式:
直连: 直连是什么? 直连的意思是直接对接口进行管控 输入什么接口管控的就是输入的接口
关联: 关联什么意思呢? 关联的意思是 连坐机制 通过配置另外一个的接口达到阈值 那么这个接口就会返回 Blocked by Sentinel (flow limiting)
如: testB 达到阈值了 testA就先不能访问了. 可以理解为 B犯罪了 但是A死了 注意 这时 testB还是可以访问的.
流控效果:
1.快速失败: 当接口满足阈值类型的时候接口直接返回: Blocked by Sentinel (flow limiting)
2.Warm up:
是预热的意思 . 阈值/3 代表每秒只能访问 你阈值的三分之一.
2.1,warm up 预热时常: 就当接口经过预热时长之后. 就可以按照你的阈值来进行访问了.
3.排队等待: 只在QPS的时候起作用 也只能是QPS
排队等待则是让所有请求进入一个队列中，然后按照阈值允许的时间间隔依次执行。后来的请求必须等待前面执行完成，如果请求预期的等待时间超出最大时长，则会被拒绝
降级规则:
说明: sentinel没有半开状态 这点跟hystrix不一样
降级策略:
RT: 什么是RT？ RT的意思是<秒级平均相应时间>
RT最大4900（更大的需要通过-Dcsp.sentinel.statistic.max.rt=XXXX设置）
满足rt有两个点需要满足
1. 平均响应时间超出阈值
2.且在时间窗口内通过的请求>=5，两个条件同时满足后触发降级. 降级后接口不可用返回: Blocked by Sentinel (flow limiting)
窗口期时间(S)过后关闭断路器. 接口恢复正常
异常比例:
满足异常比例有两个点需要满足
1.当资源的每秒请求量>=5，
2.并且每秒异常总数占通过量的比值超过阈值（DegradeRule中的count）之后，资源进入降级状态.窗口期时间(S)过后关闭断路器. 接口恢复正常
如果满足就会进入断路器. 如果不满足 方法报错 那么直接500
异常数:
当资源近1分钟的异常数目超过阈值之后会进行熔断。注意由于统计时间窗口是分钟级别的，
若timeWindow 小于60s，则结束熔断状态后仍可能再进入熔断状态
热点规则:
参数索引代表第几个参数
单机阈值: 代表一秒钟可以执行几次.
统计窗口时长: 代表降级时间 限流规则的时间窗口
@SentinelResource(value = "testHotKey",blockHandler = "deal_testHotKey")
SentinelResource中配置 @SentinelResource(value = "fallback",fallback ="handlerFallback")
1. 配置 fallback可以接管代码运行时异常
2. 配置 blockHandler 可以管理接口违背sentinel配置时返回的数据
3. 如果两个都进行配置了 违背了sentinel配置的限制 那么起作用的是blockHandler
sentinel持久化配置到nacos的json数据: [ { "resource":"/rateLimit/byUrl", "limitApp":"default", "grade":1, "count":1, "strategy":0, "controlBehavior":0, "clusterMode":false } ]
上述持久化json参数说明: resource: 资源名称 limitApp: 来源应用; grade: 阈值类型,0 表示线程数,1表示QPS; count: 单机阈值； strategy: 流控效果,0表示快速失败, 1表示Warm Up，2表示排队等待; clusterMode: 是否集群.
seata组件: 什么是seata? seata是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务
分布式事务处理过程的一ID+三组件模型，一ID即Transaction ID XID，全局唯一的事务ID。
三组件：
1.TC (Transaction Coordinator) - 事务协调者
维护全局和分支事务的状态，驱动全局事务提交或回滚。
2.TM (Transaction Manager) - 事务管理器
定义全局事务的范围：开始全局事务、提交或回滚全局事务。
3.RM (Resource Manager) - 资源管理器
2PC概念：
2PC，两阶段提交，将事务的提交过程分为资源准备和资源提交两个阶段，并且由事务协调者来协调所有事务参与者，
如果准备阶段所有事务参与者都预留资源成功，则进行第二阶段的资源提交，否则事务协调者回滚资源
Seata有四种模式: XA、AT(默认)、TCC、Seaga
XA：强一致性，基于数据库隔离，无代码侵入，在一阶段不提交事务
AT：默认模式，基于全局锁隔离，无代码侵入，一阶段提交事务，在提交事务前，会记录undolog日志，性能比XA模式好，二阶段TC通知回滚，则根据undolog回滚，通知提交，则删除undolog日志。
TCC:性能最好，不需要依赖关系型数据库，但代码入侵读高。Try:冻结可用数据，Confirm:确认提交数据，删除冻结数据 Canel:恢复数据，将冻结数据恢复
Seaga: 用于长事务，例如A项目调另外一个公司的项目接口。
分布式唯一ID生成算法: 雪花算法: 优点: 毫秒数在高位.自增序列在地位,整个ID都是趋势递增的. 不依赖第三方系统. 生成ID性能也非常高. 缺点 时钟回拨,会导致重复ID生成.
2023-04-07 end
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。