微服务相关问题（2）

1、Spring Cloud相关常用组件

注册中心（nacos、Eureka等）、负载均衡（Ribbon、LoadBalancer）、远程调用（feign）、服务熔断（Sentinel、Hystrix）、网关（Gateway）

2、nacos与Eureka的区别

相同：

• 都支持服务注册和服务拉取
• 都支持服务提供者心跳方式做健康检测

区别：

• nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式。
• 临时实例心跳异常会被剔除，非临时实例不会。
• nacos支持服务列表变更的消息推送，服务列表更新及时。
• nacos集群默认采用AP模式（高可用模式），当集群中存在非临时实例时，采用CP模式（强一致模式），Eureka采用AP方式。
• nacos还支持配置中心，Eureka只有注册中心。

3、服务雪崩

服务雪崩：一个服务失败，导致整条链路的服务都失败的情形

解决方式：

• 服务降级（针对某个接口）：服务自我保护的一种方式，或者保护下游服务的一种方式，用于确保服务不会受到请求突增影响变得不可用，确保服务不会崩溃，一般在实际开发中与feign接口整合，编写降级逻辑。
• 服务熔断（针对整个服务）：默认关闭，需要手动打开，如果检测到10秒内请求的失败率超过一定比率（如50%），就会触发熔断机制，之后每隔5秒重新尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果服务可达，则关闭熔断机制，恢复正常请求

4、微服务的监控——skywalking

skywalking：一个分布式系统的应用程序性能监控工具，提供了完善的链路追踪能力。

skywalking主要可以监控接口、服务、物理实例的一些状态。特别是在压测的时候可以看到众多服务的中哪些服务和接口比较慢，我们可以针对性的分析和优化。

skywalking还可以设置告警规则，特别是在项目上线后，如果报错，我们分别设置了可以给相关负责人发短信和发邮件，第一时间知道bug，第一时间修复。

5、微服务限流

限流实现方式：tomacat:可以设置最大连接数（一般在单体项目中使用），nginx：漏桶算法，网关：令牌桶算法，自定义拦截器。

nginx限流：

基于客户端IP：

语法：limit_req_zone key zone rate

key:定义限流对象，binary _remote_addr就是一种key，基于客户端ip限流方式。

zone:定义共享存储区来存储访问信息，10m可以存储16wip地址访问信息。

rate:最大访问速率，rate=10r/s，表示每秒最多请求10个请求。

burst=20，相当于桶的大小。nodelay：快速处理。

基于控制并发数：

语法一样，还是上面这个：limit_req_zone key zone rate。

对应的key变为： $binary_remote_addr,表示限制单个IP同时最多能持有多少个连接。

网关限流：

yml配置文件中，微服务路由设置添加局部过滤器RequestRateLimiter。默认是使用redis的连接去存储令牌。

6、分布式事务

CAP定理：CAP是一致性（consistency）、可用性（availability）、分区容错性（partition tolerance）的首字母缩写

分布式系统节点之间肯定是需要网络连接的，分区（P）是必然存在的。

如果保证访问的高可用性，可以持续对外提供服务，但是不能保证数据的强一致性，那这种就是AP。如果保证访问数据的强一致性（C），那么就要放弃高可用性，这种就是CP。

BASE理论是对CAP的一种解决思路，包含三个思想。

Basically Available（基本可用）：分布式系统出现故障时，允许损失部分可用性，即保证核心可用。

Soft State （软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。

Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

7、分布式事务解决方案

常用解决方案：seata框架（XA、AT、TCC）、MQ。

seata框架：

该框架中用三个重要角色：

TC（事务协调者）：维护全局和分支事务状态，协调全局事务提交或回滚。

TM（事务管理器）：定义全局事务的范围，开始全局事务、提交或回滚全局事务。

RM（资源管理器）：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

这里的XA模式就是上面提到的CP模式（数据强一致性）。

AT模式就是上面提到的AP模式（高可用性），底层使用undo log实现。

TCC模式也是AP模式，使用try、confirm、cancel进行事务操作。

MQ：

这种一般时保证高可用，对数据强一致没有效果。

8、分布式服务的接口幂等性的设计

幂等：多次调用方法或接口不会改变业务状态，可以保证重复调用的结果和单次调用的结果一致。

解决方案：数据库唯一索引（新增操作时）、token+redis(新增、修改都可以解决）、分布式锁（也可以解决新增、修改时的幂等性问题）

9、分布式任务调度

这里主要介绍xxl-job。

xxl-job:解决集群任务重复执行的问题、cron表达式定义灵活、定时任务失败了，重试和统计、任务量大、分片执行。

xxl-job的路由策略：大概有十种：轮询、随机、第一个（固定找第一个实例执行）、最后一个（固定找最后一个实例执行）、一致性hash（按照hash算法固定选择某一个实例，且所有任务均匀散列在不同实例上）、最不经常使用、最近最久未使用、故障转移（当去执行的实例出现故障，则选择新的健康的实例去执行）、忙碌转移、分片广播。

xxl-job任务执行失败怎么解决：

故障转移+失败重试，查看日志分析——>邮件警告