springcloud

** 1.spring cloud的5大组件**
注册中心（Nacos/Eureka）：服务注册与发现。所有服务启动时注册自己，调用别人时来这里查地址
负载均衡（LoadBalancer/Ribbon）：一个服务多开实例，自动均匀分配请求
远程调用（openFeign）：像调用本地方法一样调用其他服务接口
服务保护（Sentinel）：服务挂了或超时，直接返回兜底数据，防止雪崩
服务网关（Gateway）：统一入口，路由转发，权限校验，限流，跨域

2.什么是服务雪崩？如何解决？
服务雪崩：一个服务失败，导致其他关联的服务也失败，继而引起雪崩效应。
解决：1服务降级：在服务的注解上的openFeign里添加指定fallback=***.class，并在其类中编写与服务名相同的名字
再在方法里编写返回的信息，例：发生了未知的错误。
2服务熔断：降级是还链接得到服务，假设服务都找不到了就用服务熔断：Hystrix熔断机制，
添加上注解@EnableCircuitBreaker开启，检测到10秒内请求失败率达50%，就触发熔断机制。之后每个5秒尝试重新请求微服务，不响应就继续直至可达

3.你的微服务是如何监控的?
采用skywalking,可监控接口,服务,物理实例的一些状态.比如那些服务或者接口比较慢等.
skywalking设置了告警规则,如果服务发生了错误,会发给负责人短信邮件等,以便了解修复

4.分布式中的CAP和Base
C:一致性 A:可用性 P:分区容错性,网络分区时仍能对外提供服务,,CAP定义指出只能同时满足2个,
而base是对cap的优化补充, BA:基本可用,允许部分损失保证核心可用, S:软状态:允许数据暂时不一致
E: 最终一致性

5.分布式服务接口的幂等性如何设计？
幂等：类似于防抖，对于新增，可使用数据库唯一索引来防抖。
新增或修改可用分布式锁或token+redis来实现，性能较好

6.MQ
1.消息的可靠性
使用场景：异步发送（验证码，短信，邮件），MYSQL，Redis，ES之间的数据同步，分布式事务，削峰填谷等。
为了保证消息不丢失（Rabbit）有生产者确认机制返回给生产者ACK，真的某一环节失败了就重发，记录日志，定时重发等。
消息默认在内存中交换机或队列可能会宕机导致消息丢失，可开启消息持久化确保不丢失，交换机队列，消息（默认开）都开
消费者也可能会丢失消息，可开启消费者确认机制为auto，由spring确认消息处理成功后完成ack，也开启重试机制

 2.消费者重复消费rebbit
     针对每条消息设置校验唯一id，也可设置相关的锁，性能较低

 3.RabbitMQ的死信交换机？（或延迟队列）
       延迟队列中就用到了死信交换机和设置TTL
       消息超时未消费就会变成死信，交给死信交换机处理

 4.RabbitMQ消息堆积如何解决？
        1.增加消费者
        2.在消费者内开启线程池加快消息处理速度
        3.扩大队列容积，采用惰性队列。
            在声明队列中设置属性x-queue-mode为lazy，即为惰性队列。是基于磁盘的，消息上限高，性能稳定，受限于磁盘IO

 5.R高可用机制（集群模式）
       我的项目采用镜像模式，共有三个节点，所有操作都是主节点完成，同步给从节点。
       如果在同步完成前主节点宕机了可能会导致数据丢失，采用了仲裁队列，与镜像队列一样，都是主从，仅需声明指定是即可使用

7，为什么要用微服务？
1- 模块解耦
2- 独立部署
3- 按需扩容：订单压力大就多开几台
4- 技术灵活：订单模块用Java，支付用Go都行
缺点：机构复杂。分布式问题多，学习成本高

8，微服务执行流程
1-所有服务启动 -> 注册到Nacos
2-前端请求 -> Gateway网关
3-网关路由 -> 用户服务
4-用户服务调用 订单服务（Feign）
5-Feign从Nacos拿到订单地址
6-负载均衡选一个实例调用
7-返回结果

9，微服务的会话怎么保持？
JWT+Redis共享登陆状态