服务注册
spring cloud 5大组件(不能错)：注册中心（Eureka）、负载均衡（Ribbon）、远程调用（Feign）、服务熔断（Hystrix）、网关（Gateway）
注册中心：服务提供者，需要向注册中心注册服务信息，服务消费者就需要去注册中心拉起服务提供者的信息（心跳检测是不是宕机），然后进行负载均衡，进行远程调用
比如采用eureka作为注册中心，这是spring cloud体系里面的一个核心组件。服务注册：服务提供者需要把组件的信息注册到eureka里面，有eureka来保存这些信息，比如服务的名称，服务的端口号，ip等。服务发现：消费者向eureka拉起服务列表信息，如果服务提供者有集群，那么消费者就会利用负载均衡算法，选择一个来发起调用。服务监控：服务提供者每隔一定时间（30s）向eureka发送心跳，报告监控状态，如果eureka服务90s没有接收到心跳，就会从eureka
nacos和eureka区别
ephemeral：false：设置为非临时实例（如果是临时实例，那么nacos和eureka流程是一样的，监控检测也是心跳），非临时实例，注册中心会主动询问服务提供者。如果服务提供者有修改，那么nacos会主动把变更消息push到服务消费者
同：两个都支持服务的注册和拉取，都支持服务提供者心跳方式做健康检测
不同：nacos支持服务端主动检测提供者状态，临时实例采用心跳模式，非临时实例采用主动检测模式；临时实例心跳不正常会被剔除，非临时实例则不会被剔除；nacos支持服务列表变更的消息推送模式，服务列表更新及时；nacos集群默认采用ap（高可用）方式，当集群存在非临时实例时候，采用cp（强一致）模式，而eureka采用ap模式
nacos还支持配置中心，eureka则只有注册中心
负载均衡
服务消费者发送请求，到负载均衡，负载均衡去注册中心拉取服务消息，注册中心把相关服务列表进行返回，负载均衡轮询查询这个服务列表
负载均衡策略：
- RoundRobinRule：简单轮询服务列表来选择服务器
- WeightedResponseTimeRule：按照权重来选择服务器，响应时间越长，权重越小
- RandomRule：随机选择一个可用的服务器
- BestAvailableRule：忽略哪些短路服务器，并选择并发数比较低的服务器
- RetryRule：重试机制的选择逻辑
- AvailabilityFilteringRule：可用性敏感策略，先过滤非健康的，再选择连接数较小的实例
- ZoneAvoidanceRule：区域敏感策略，以区域可用的服务器为基础进行服务器的选择，使用Zone对服务器进行分离，这个Zone可以看成一个机房，一个机架，而后再对Zone内的多个服务做轮询
自定义负载均衡怎么实现？
- 创建类实现IRule即可，可以指定负载均衡策略（全局）
- 在客户端的配置文件里面。配置一个服务调用的负载均衡策略（局部）
熔断和降级
服务雪崩：一个服务识别导致整个链路的失败 解决方案：熔断降级 预防：限流
服务降级：是服务自我保护的一种方式，或者保存下游服务的一种方式，确保服务不好受请求突增影响变大不可以，确保服务不会崩溃
服务熔断：Hystrix熔断机制，用于监控微服务的调用情况，默认是关闭的，如果需要开启要在引导类上面添加注解（@EnableCircuitBreaker）如果检测到10s内请求失败了大于50%，就触发熔断机制，之后每5s重新尝试请求微服务，如果服务不能响应，就进行走熔断机制，如果服务可达，就关闭熔断，恢复正常
监控
为了某一个微服务挂掉后迅速找到他，接口响应时间台词，快速定位是哪一个服务慢，服务之间的关系，服务出问题了能不能马上知道有问题
skywalking：一个分布式系统应用程序的性能监控工具，提供了完善的链路追踪能力。
限流
为什么要限流？并发量大，防止用户恶意刷接口
限流方式：
- tomcat可以设置最大连接数（maxThreads）单体项目合理
- Nginx：漏桶算法
- 网关：令牌桶
- 自定义拦截器
Nginx：
- 控制速率
- 控制并发连接数
网关限流：yml配置文件里面添加局部锅炉去RequestRateLimiter
比如抢优惠券的服务，qps最大为xxx，平时是xx，为了应对突发的流量，我们需要进行限流，常规的限流是为了防止恶意攻击，包含我们系统的正常运行，当时我们压测结果是xxx
分布式事务
CAP：一致性（Consistency）、可用性（Avakiability）、分区容错性（Partition tolerance） 。分布式系统不能同时满足者三个指标，最多满足其中两个，这个就是cap。
一致性：用户访问分布式系统任意节点，得到数据必须一致
可用性：访问集群里面的任意健康节点，都必须得到响应，而不是超时或者拒绝
分区容错：分区（因为网络问题或者其他原因，导致分布式系统里面部分节点和其他节点事情连接，形成独立的分区）容错（集群出现分区时候整个系统也需要对外提供服务）
- 分布式系统节点之间肯定需要网络连接的，分区p必然存在
- 如果保证访问高可用性a，可以持续对外提供服务，但不能保证数据的强一致性-》AP
- 如果要保证强一致性c就需要放弃高可用性-》cp
BASE:对cap的解决思路
- Basically Avaiable（基本可用）:分布式系统出现故障时候，运行部分可用性丢失，保证核心可用即可
- soft state（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态
- Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态接收之后，最终达到了数据一致
