关于微服务——springcloud

微服务问题总结

 

1.微服务的五大组件：

• 注册中心 eureka nacos（外加了配置中心）
• 网关 gateway
• 远程调用 feign
• 服务保护与熔断 sentinel hystrix
• 负载均衡 ribbon，loadbalance

 

2.注册中心eureka和nacos

eureka：

• 服务注册：服务提供者把自己的信息注册到注册中心，注册中心会保存这些信息，比如服务名称,IP,PORT。
• 服务发现：消费者向eureka拉取服务列表信息，如果生产者是集群，那么消费者会利用负载均衡算法选一个调用。
• 服务监控：服务提供者会每搁30秒向eureka发送心跳，报告健康状态。如果90秒eureka没回复默认提供者挂了。

nacos：在eureka的基础上

• 使用非临时实例时，nacos会定期主动询问提供者是否存活（由心跳模式转为主动检测模式）。默认情况下注册中心都是AP模式（高可用），当启用非临时实例会采用CP模式。
• nacos的消费者不仅会在注册中心拉取pull实例，注册中心还会主动向消费者push推送。

 

3.负载均衡ribbon（一般配合eureka使用），目前nacos默认使用spring cloud loadbalancer

ribbon的实施流程

1. 发起请求到ribbon
2. ribbon去注册中心拉取相关模块的集群
3. 注册中心返回服务列表
4. ribbon根据策略找到对应实例（例如轮询）

ribbon都有哪些负载均衡策略

• 以区域可用的服务器为基础进行服务器选择
• 简单轮询
• 按权重选择服务器，响应时间越长，权重越小
• 随机选择
• 忽略短路服务器，选择并发较低的服务器
• 轮询的基础上，按指定的时间重试
• 先过滤宕机的，再选择连接数比较小的实例

自定义负载均衡策略：通过实现IRule接口

 注意在新版本中，由于ribbon已经停止维护更新，nacos默认使用spring cloud loadbalancer作为负载均衡，而openFeign默认使用的是ribbon

 

4.服务雪崩与熔断降级

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

怎么解决服务雪崩：采用服务降级、服务熔断。

服务降级：一般在实际开发中写在feign中，当服务异常时会走服务降级策略从而保护服务

服务熔断：一般用hystrix或者sentinel。默认情况下是关闭的，打开后如果检测到一个服务在10秒内请求失败率高于50%，就触发熔断机制，会使模块处于不可使用状态。而后每5秒重新尝试请求微服务，如果服务不能用则继续熔断；如果服务可用，则关闭熔断。服务熔断按上述分为三种状态：close->open->half-open

上述解决措施中，服务降级仅仅是保护某一接口；而服务熔断则是保护一个微服务模块；即可能某一微服务模块中有些接口是可用的，但是由于服务熔断他会连带转为不可用状态

 

5.微服务的监控skywalking

为什么微服务需要监控：1.问题定位，2.性能分析，3.服务关系，4.服务告警

skywalking具有上述功能，他可以监控一些服务，接口，实例的状态，而且可以明显看出问题服务与接口；还具有预警功能，在超过设置的预警阈值后可以进行第一时间的告知

 

 

微服务业务相关问题

1.微服务业务限流

为什么要限流：突发流量太高系统难以承受；恶意刷接口

限流方法：

• tomcat设置最大连接数
• nginx使用漏桶算法：
  • 通过控制速率（应对突发情况）
  • 控制并发数，比如限制单个IP（防止单IP恶意刷接口），限制并发链接总数
• 网关使用令牌桶算法：使用requestRateLimiter做局部限流，根据ip或者路径进行限流；可自定义每秒桶的填充速率，令牌桶的总容量
• spring的拦截器

 

2.CAP BASE理论

CAP理论：三个只能满足两个，一般是AP或CP

• Consistency（一致性）访问任意节点，数据必须是一致的
• Availability（高可用）用户访问集群中任意节点，必须得到响应而不是超时或拒绝
• Partion tolerance（分区容错性）分区：部分节点因为网络故障或其他原因而失去连接，形成了独立的分区。容错：集群出现分区时，整个系统也要对外提供服务

在分布式系统中，网络分区是不可避免的，因此分布式必须要满足P。网络分区是指因为网络故障导致网络不通，不同子节点分布在不同子网中，子网络内部通信正常，但子节点之间无法通信。

BASE理论：对CAP的一种解决思路（就是AP思想吧）

• basically available（基本可用）集群出现故障时，允许损失部分可用性，保证核心可用
• soft state（软状态）运行短暂不一致，中间状态的出现
• eventually consistent（最终一致性）

AP思想：各分支事务执行完了就提交，如果有不一致的情况想办法恢复事务，并不一定是回滚。（会出现短暂不一致状态）

CP思想：各分支执行完事务不提交，等待彼此结果，如果有不一致的情况统一回滚。（在等待期间是弱可用）

 

3.分布式事务解决方案

seata（XA,AT,TCC）

seata中主要有三个角色：

• TC（事务协调者）：需要额外部署的协调者。维护全局和分支的事务状态，协调事务提交或回滚
• TM（事务管理器）：管理所有微服务的所有事务。定义全局事务的范围，开启全局事务、提交或回滚全局事务
• RM（资源管理器）：每一个微服务模块都是一个RM

seata的三种模式

• XA模式（CP思想）：总管理器TM开启全局事务告知协调者TC，调用分支RM，RM向TC注册分支后执行sql但不提交，先向TC报告自己的状态，如果全成功则继续进行，一旦有失败则全回滚
• AT模式（AP思想）：TM开启全局事务并告知TC，调用RM，执行其中的sql并提交，而后记录更新前后快照至undolog中，并报告事务状态。提交则删除log，回滚则根据undolog实现。
• TCC模式（AP思想）：TM开局全局事务并告知TC，调用RM，RM会向TC注册分支事务，然后try一下sql；try完后报告事务状态并锁定相关资源，如果事务全都成功，则进行Confirm，真正执行所有SQL，；如果事务有失败，则调用Cancel，释放try锁定的资源。

TCC模式中try-confirm-cancel是需要我们手动写的，而XA和AT都是框架自动实现的

MQ

模块A写数据时，在同一个事务内发送消息至另一个模块的事务，异步实现数据同步。这样做性能最好，但是不一致性的存在时间较长

 

4.分布式服务中接口幂等性的设计方案

什么叫幂等性：f(x)=x，一个接口不管是单次调用还是多次调用，结果都是一致的

幂等场景：网络波动造成的重复点击；MQ消息的重复；应用失败/超时重试机制

CRUD中，新增肯定是不幂等的，更新在增量时也是不幂等的。

解决方案：

• 数据库唯一索引（解决新增）新增的时候涉及到唯一索引（unique）的新增，无法重复新增数据
• token+redis（解决新增与修改）分为两次请求，前置请求和当前请求：前置请求发送后会通过token给redis存一条唯一的数据；第二次请求时会去redis中查询业务数据是否存在，如果存在则删除数据并放行，如果不存在则拒绝放行操作
• 分布式锁（解决新增与修改）在操作的时候上锁，操作结束后释放锁，保证短时间内只能处理一个请求。如果是使用CAS的话，可能会出现ABA问题，解决方法是为数据加上一个版本号来控制改变，如果是在java中记得给版本号加上volatile。

 

5.分布式任务调度XXL-JOB

XXL-JOB可以防止任务重复执行，cron表达式不定义在代码内，具有同一的日志管理，可以分片执行

XXL-JOB的路由策略：（很类似负载均衡）

• 轮询、固定第一个/最后一个、随机、一致性hash算法、最不常使用LFU、最近最久未使用LRU
• 故障转移：向第一个心跳检测成功的发起调用
• 忙碌转移：向第一个空闲检测成功的发起调用
• 分片广播：对集群内的机器都发起一次执行任务，系统会自动传递相应的分片参数，代码来区别哪一分片该执行哪一步骤

注意：XXL-JOB的邮件告警功能需要先在springboot中配置一下yaml信息，才会生效

 

额外拓展：

如何实现一个注册中心？

首先，注册中心最好是高可用的，即我们需要保证AP模型，常见的eureka,nacos都是AP模型

注册中心的主要功能有：

服务注册、注册表变动：注册的信息是手动填写的，直接用MySQL存储。可以像nacos那样设置一个namespace group详细区分。namespace用于区分环境，group用于区分大概功能，dataId用于区分模块

心跳感知：每隔一段时间去ping生产者，看他是否存活，适合用定时任务

服务发现、服务订阅、服务推送：简单来说这一部分就是需要消费者了解生产者的情况。我们把所有信息都存在注册中心中，最合理的情况是消费者定时去拉取一下最新的注册表

数据同步：如果追求高可用，则需要搭建注册中心集群，那么就会涉及到数据同步问题，可以通过mq实现吧

服务调用：消费者通过负载均衡算法选出一个地址再发起调用

4399JAVA校招笔试：微服务模块之间的通信方式有什么？请你列举两种，并说明他们的优劣

HTTP/restful API：最常用的方式，优点：简单，灵活通用 缺点：性能开销大，安全性有待提高，耦合性高

其他RPC框架：例如dubbo,gRPC。优点：高效，通常提供服务治理（服务发现，服务注册，负载均衡）  缺点：复杂，依赖环境

消息队列：优点：异步，解耦，可靠，削峰   缺点：复杂，有延迟性