微服务学习记录1
SpringCloud的五大组件
Eureka : 注册中心，所有的微服务都会把其地址信息给注册中心
Ribbon : 负载均衡，比如文章微服务有80，81，82三个，那用户要选哪个，用户微服务里通过负载均衡挑选一个
Feign : 远程调用，不同的微服务互相调用
Hystrix : 服务熔断, 应对降级，熔断场景
Zuul/Gateway : 网关， 对外暴露接口，网关是服务的入口
随着SpringCloudAlibba在国内兴起 , 我们项目中使用了一些阿里巴巴的组件
注册中心/配置中心 Nacos
负载均衡 Ribbon
服务调用 Feign
服务保护 sentinel
服务网关 Gateway
Eureka
服务注册：服务提供者需要把自己的信息注册到eureka，由eureka来保存这些信息，比如服务名称、ip、端口等等
服务发现：消费者向eureka拉取服务列表信息，如果服务提供者有集群，则消费者会利用负载均衡算法，选择一个发起调用
服务监控：服务提供者会每隔30秒向eureka发送心跳，报告健康状态，如果eureka服务90秒没接收到心跳，从eureka中剔除
nacos
- 共同点
Nacos与eureka都支持服务注册和服务拉取，都支持服务提供者心跳方式做健康检测
- Nacos与Eureka的区别
①Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
②临时实例心跳不正常会被剔除，非临时实例则不会被剔除
③Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
④Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式
Ribbon
记住这个负载均衡是在服务消费者做的
负载均衡策略
- RoundRobinRule：简单轮询服务列表来选择服务器
- WeightedResponseTimeRule：按照权重来选择服务器，响应时间越长，权重越小
- RandomRule：随机选择一个可用的服务器
- BestAvailableRule：忽略那些短路的服务器，并选择并发数较低的服务器
- RetryRule：重试机制的选择逻辑
AvailabilityFilteringRule：可用性敏感策略，先过滤非健康的，再 - 选择连接数较小的实例
- ZoneAvoidanceRule：以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询
自定义的负载均衡策略
提供了两种方式：
1，创建类实现IRule接口，可以指定负载均衡策略（全局）
2，在客户端的配置文件中，可以配置某一个服务调用的负载均衡策略（局部）
服务雪崩
- 服务雪崩：一个服务失败，导致整条链路的服务都失败的情形
- 服务降级：服务自我保护的一种方式，或者保护下游服务的一种方式，用于确保服务不会受请求突增影响变得不可用，确保服务不会崩溃，一般在实际开发中与feign接口整合，编写降级逻辑
- 服务熔断：默认关闭，需要手动打开(在引导类上添加注解：@EnableCircuitBreaker)，如果检测到 10 秒内请求的失败率超过 50%，就触发熔断机制。之后每隔 5 秒重新尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求
skywalking
一个分布式系统的应用程序性能监控工具（ Application Performance Managment ），提供了完善的链路追踪能力， apache的顶级项目
- 服务（service）：业务资源应用系统（微服务）
- 端点（endpoint）：应用系统对外暴露的功能接口（接口）
- 实例（instance）：物理机
我们项目中采用的skywalking进行监控的
1，skywalking主要可以监控接口、服务、物理实例的一些状态。特别是在压测的时候可以看到众多服务中哪些服务和接口比较慢，我们可以针对性的分析和优化。
2，我们还在skywalking设置了告警规则，特别是在项目上线以后，如果报错，我们分别设置了可以给相关负责人发短信和发邮件，第一时间知道项目的bug情况，第一时间修复
限流
Nginx 漏桶算法
漏桶算法是把请求存入到桶中，以固定速率从桶中流出，可以让我们的服务做到绝对的平均，起到很好的限流效果
网关-令牌桶算法
令牌桶算法在桶中存储的是令牌，按照一定的速率生成令牌，每个请求都要先申请令牌，申请到令牌以后才能正常请求，也可以起到很好的限流作用
它们的区别是，漏桶和令牌桶都可以处理突发流量，其中漏桶可以做到绝对的平滑，令牌桶有可能会产生突发大量请求的情况，一般nginx限流采用的漏桶，spring cloud gateway中可以支持令牌桶算法
CAP理论
CAP主要是在分布式项目下的一个理论。包含了三项，一致性、可用性、分区容错性
- 一致性(Consistency)是指更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致(强一致性)，不能存在中间状态。
- 可用性(Availability) 是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。
- 分区容错性(Partition tolerance) 是指分布式系统在遇到任何网络分区故障时，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。
分布式系统无法同时保证一致性和可用性
首先一个前提，对于分布式系统而言，分区容错性是一个最基本的要求，因此基本上我们在设计分布式系统的时候只能从一致性（C）和可用性（A）之间进行取舍。
如果保证了一致性（C）：对于节点N1和N2，当往N1里写数据时，N2上的操作必须被暂停，只有当N1同步数据到N2时才能对N2进行读写请求，在N2被暂停操作期间客户端提交的请求会收到失败或超时。显然，这与可用性是相悖的。
如果保证了可用性（A）：那就不能暂停N2的读写操作，但同时N1在写数据的话，这就违背了一致性的要求。
BASE理论
BASE是CAP理论中AP方案的延伸，核心思想是即使无法做到强一致性（StrongConsistency，CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。它的思想包含三方面：
1、Basically Available（基本可用）：基本可用是指分布式系统在出现不可预知的故障的时候，允许损失部分可用性，但不等于系统不可用。
2、Soft state（软状态）：即是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
3、Eventually consistent（最终一致性）：强调系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。其本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
分布式事务解决方案(有点难，先不写)
Seata框架(XA、AT、TCC)
MQ
分布式服务的接口幂等性如何设计？
幂等: 多次调用方法或者接口不会改变业务状态，可以保证重复调用的结果和单次调用的结果一致。
需要幂等场景: 用户重复点击(网络波动), MQ消息重复, 应用使用失败或超时重试机制
xxl-job
xxl-job解决的问题：解决集群任务的重复执行问题,cron表达式定义灵活,定时任务失败了，重试和统计,任务量大，分片执行
路由策略
xxl-job任务执行失败怎么解决
故障转移+失败重试，查看日志分析—-> 邮件告警
大数据量的任务同时都需要执行
我们会让部署多个实例，共同去执行这些批量的任务，其中任务的路由策略是分片广播
在任务执行的代码中可以获取分片总数和当前分片，按照取模的方式分摊到各个实例执行就可以了
