微服务 笔记

一、Spring Cloud

·spring cloud五大组件：（阿里巴巴组件）

        ①注册中心/配置中心 Nacos

        ②负载均衡 Ribbon

        ③服务调用 Feign

        ④服务保护 sentinel

        ⑤服务网关 Gateway

·spring cloud如何实现服务注册发现？

        采用eureka作为注册中心，这也是spring cloud体系中的一个核心组件。

        服务注册：服务提供者需要把自己的服务名称、ip、端口等信息注册到eureka，由eureka保存这些信息；

        服务发现：消费者向eureka拉取服务列表信息，如果服务提供者有集群(多个端口)，则消费者会利用算负载均衡法，选择一个发起调用；

        服务监控：服务提供者每隔30s会向eureka发送心跳，如果eureka服务90s没收到心跳则剔除对应端口信息。

·nacos何eureka的区别(注册中心)

        相同点：①都支持服务注册何服务拉取；②都支持服务提供者心跳方式做健康检测。

        不同点：

                ①Nacos支持注册中心主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式；                //Nacos默认为临时实例

                ②临时实例心跳不正常会被剔除，非临时实例则不会被剔除；

                ③Nacos支持服务列表变更的消息推送模式，服务列表更新更及时；

                ④Nacos集群默认采用AP方式(高可用)，当集群中存在非临时实例时，采用CP模式(强一致)；Eureka只能采用AP方式

                ⑤Nacos还支持配置中心，eureka则只有注册中心。

·如何实现负载均衡？

        使用组件Ribbon，比如在使用feign远程调用的过程中就用到ribbon。

·Ribbon负载均衡策略有哪些？

*①RoundRobinRule：简单轮询(轮流)服务列表来选择服务器

*②WeightedResponseTimeRule：按权重选择服务器，响应时间越快(小)，权重越大

*③RandomRule：随机选一个可用的服务器

*④ZoneAvoidanceRule(默认)：区域敏感策略，使用Zone对服务器进行分类，而后再对Zone内服务器进行轮询。

⑤BestAvailableRule：忽略短路(暂时不可用)的服务器，并选择并发数较少的服务器

⑥RetryRule：重试机制的选择逻辑，允许在请求首次失败后进行一次或多次重试

⑦AvailabilityFilteringRule：可用性敏感策略，先过滤非健康的(确定不可用)服务器，再选择连接数较小的服务器

·自定义负载均衡策略

①全局：创建类实现IRule接口，可指定负载均衡策略；

②局部：在客户端的配置文件中，可配置某一服务调用的负载均衡策略。

·如何解决服务雪崩

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

        解决方法：

                ①服务降级：服务访问失败返回 失败，确保后续服务不会受请求突增影响变得不可用而

                        崩溃。一般于feign接口整合，编写降级逻辑。        //针对某个接口

                ②服务熔断：默认关闭。如果检测到10s内请求的失败率超过50%，则触发熔断机制。之

                        后每隔5s重新尝试请求微服务，如果不能响应继续走熔断机制。如果微服务可达则

                        关闭熔断机制，恢复正常请求。        //针对整个微服务

·微服务如何监控

        采用skywalking进行监控。能够解决：问题定位、性能分析、服务关系、服务告警。

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

        ②还可以在skywalking设置告警规则，在项目上线以后如果报错，可以设置给相关负责人发短信和发邮件，第一时间通知项目的bug情况，及时修复。

二、业务相关

·项目 限流常见算法

        nginx限流：

                控制速率(预防突发流量)，使用漏桶算法来实现过滤，让请求以固定速率处理。

                        //漏桶算法输出速率固定，适合对带宽有严格要求的场景。

                控制并发数，限制单个ip的链接数和并发链接的总数。

        网关限流：

                在spring cloud gateway中支持局部过滤器来做限流，使用令牌桶算法。

                        //令牌桶算法灵活，支持突发流量，允许在短时间内超出平均速率发送数据包。

                可以根据ip或路径进行限流，设置每秒填充令牌的平均速率和令牌桶总容量。

·CAP和BASE

CAP定理：（一致性、可用性、分区容错性）

        ①分布式系统节点通过网络连接，一定会出现分区问题（P）；

        ②当分区出现时，系统的一致性（C）和可用性（A）就无法同时满足。

BASE理论：

        ①基本可用：分布式系统故障时，运行损失部分可用性，即保证核心可用；

        ②软状态：在一定时间内，允许出现中间状态，如临时的不一致状态；

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

ps. 最终一致思想：各分支事务分别执行并提交，如果有不一致情况，再想办法恢复数据（AP）

      强一致思想：各分支事务执行完业务先不提交，等待彼此结果。而后统一提交或回滚（CP）

·分布式事务 解决方案（seata | MQ）

        只要是发生了多个服务之间的写操作，都需要进行分布式事务控制。

①seata的XA模式，CP，需要互相等待各个分支事务提交，保证强一致性，性能差。

②seata的AT模式，AP，底层使用undo log实现，性能好

③seata的TCC模式，AP，性能较好，不过需要人工编码实现

④MQ模式实现分布式事务，在A服务写数据时，需要在同一个事务内发送消息到另一个事务，异步，性能最好

ps. 其中XA、TCC模式用于银行业务；AT、MQ模式用于互联网业务。

·分布式服务的接口 幂等性

        幂等：多次调用同一方法或接口不会改变业务状态，可以防止重复提交订单。

        新增数据：可以使用数据库的唯一索引。

        新增、修改数据：

                ①分布式锁；        //注意及时释放锁，控制锁的粒度

                ②使用token+redis实现，性能较好：

                        (1)第一次请求生成一个唯一token存入redis，返回给前端；

                        (2)第二次请求，携带之前的token到redis验证，如果存在，执行业务，删除token；

                        如果不存在，则直接返回，不处理业务。

·项目如何进行分布式任务调度

        使用xxl-job路由策略。

·xxl-job路由策略有哪些

        Round(轮询)；

        failover(故障转移)：安装顺序依次进行心跳检测，第一个心跳检测成功的机器选为目标执行器并发起调度；

        sharding_broadcast(分片广播)：广播触发对应集群中所有机器执行一次任务，同时系统自动传递分片参数；可根据分片参数开发分片任务。

·xxl-job任务执行失败如何解决

        ①路由策略选择故障转移，使用健康的实例来执行任务；

        ②设置重试次数；

        ③查看日志+邮件告警通知相关负责人解决。

·如何同时执行大数据量的任务

        ①路由策略选择分片广播，让多个实例一块取执行（部署集群）；

        ②在执行代码中获取分片总数和当前分片，按照取模的方式分摊到各个实例执行。