微服务相关知识点（上）

 1. SpringCloud组件

Spring Cloud 5大组件有那些？

是这些吗？网关、注册中心、配置中心、用户中心、微服务端

其实是这些：

1. 注册中心——Eureka、Nacos
2. 负载均衡——Ribbon
3. 远程调用——Feign
4. 服务熔断/保护——Hystrix、sentinel
5. 网关服务——Gateway、Zuul
6. 配置中心——Nacos、SpringCloud Config

这里说一下负载均衡，Ribbon有一个场景是为了解决客户端不同的性能、配置，指定的轮询策略。如果公司用的是docker部署、或者Kubernetes部署，不管是走Kubernetes还是nacos的注册中心，都是有默认轮询负载的。

 2. Eureka服务注册发现

 SpringCloul如何实现服务注册和发现的?

服务注册：服务提供者会向【注册中心Eureka】注册，由Eureka来保存这些信息，服务名称，ip端口例如：name=userService{10.1.1.101,10.1.1.102,10.1.1.103}

服务发现：服务消费者（发起调用者）向Eureka拉去服务列表信息，通过name去发起调用，底层就是通过name找到对应的ip。

服务监控：服务提供者会每隔30秒向eureka发送心跳，报告监控状态，如果eureka服务90秒内没有收到心跳，那么就会从eureka中踢出。

 注册中心：服务注册和服务发现；

种类：euraka、nacos、zookeeper

Nacos

3. Nacos服务、与Eureka差异

nacos和eureka的区别？

• Nacos和Eureka的共同点（注册中心）：
  • 都支持服务注册和服务拉取
  • 都支持服务者提供心跳方式做健康监测
• Nacos 和 Eureka 的区别（注册中心）
  • Nacos支持服务端（nacos）主动监测 提供者 状态：临时实例采取心跳模式，非临时实例采取主动监测模式；
  • 临时实例心跳不正常会被剔除，非临时实例则不会被剔除
  • Nacos支持服务列表变更的消息推送模式，更新列表更及时
  • Nacos集群默认采取AP模式，当集群存在非临时实例时，采用CP模式；  Eureka采用AP模式。
• Nacos还支持配置中心，Eureka则只有注册中心，也是悬着一个nacos的一个重要原因。

4. Nacos扩展

扩展：为什么Nacos非临时实例不会被剔除呢？

Nacos 中对于临时实例和非临时实例采取不同的健康检查和处理机制，这主要源于它们在设计上的差异和满足不同场景下的服务发现需求。

临时实例（Ephemeral Instances）

1. 心跳机制：
   • 临时实例需要通过周期性地向Nacos发送心跳信号来表明自己仍然“活着”。这种机制可以确保Nacos能够及时感知到实例的状态变化。
   • 默认情况下，如果当前客户端是临时的（ephemeral: true），则Nacos会触发心跳机制，默认5秒发送一次心跳。
2. 健康检查和剔除机制：
   • 如果Nacos在指定时间内（如15秒内）没有收到某个临时实例的心跳，会先将其标记为非健康状态。
   • 如果在更长的时间段内（如30秒内）仍然没有接收到心跳，Nacos则会将该实例从服务列表中移除，这有助于保持服务列表的准确性和最新性。

非临时实例（Non-Ephemeral Instances）

1. 持久化存储：
   • 非临时实例会在Nacos服务端进行持久化存储，即使服务重启或崩溃，实例信息仍然保留在Nacos中。
2. 健康检查机制：
   • 对于非临时实例，Nacos不会依赖于心跳信号来检查其健康状态，而是采用主动询问或服务端反向探测的机制。
   • Nacos会定期向注册的服务发送请求，以验证其健康状况。这种方式不需要实例主动发送心跳，而是由注册中心主动进行健康检查。
3. 不剔除机制：
   • 由于非临时实例的信息会被持久化，并且Nacos会主动进行健康检查，因此即使实例暂时无法响应，也不会立即从服务列表中剔除。
   • 这为服务的稳定运行提供了更高的保障，尤其是在服务重启或暂时故障时，可以避免因错误剔除导致的服务中断。

总结

Nacos 对临时实例和非临时实例采取不同的健康检查和处理机制，主要是为了满足不同场景下的服务发现需求。临时实例适用于那些对稳定性要求不高或者不需要持久化存储的场景，通过心跳机制可以快速剔除无响应实例，保持服务列表的清洁和准确。而非临时实例则适用于生产环境中对服务稳定性和可靠性有较高要求的场景，通过持久化存储和主动询问机制来确保服务的稳定运行和及时恢复。

5. 负载均衡

项目是如何实现负载均衡的？

负载均衡Ribbon，发起远程调用Feign就会使用Ribbon。

Ribbon负载均衡的策略有那些？

如果想自定义负载均衡策略如何实现？

Ribbon负载均衡的策略有那些？

1. RoundRobinRule:简单轮询服务列表来选择服务器
2. WeightResponseTimeRule:按照权重来选择服务器，响应时间越长，权重越小
3. RandomRule：随机选择一个可用的服务器
4. BestAvailableRule:忽略那些短路的服务器，选择并发数较低的服务器（空闲比较多的服务器进行连接）
5. RetryRule:重试机制的选择逻辑；
6. AvailabilityFilteringRule:可用性敏感策略，先过滤非健康的，在选择连接数较小的实例。
7. ZoneAvoidanceRule：默认，以区域可用服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、机架等。然后在对Zone内的多个服务做轮询。

如果想自定义负载均衡策略如何实现？

可以自己创建类实现IRule接口，然后再通过配置类或者配置文件配置即可，通过定义IRule实现可以修改负载均衡规则，有两种方式:

6. 服务雪崩

什么是服务雪崩，如何解决这个问题？

 针对雪崩问题如何解决？

熔断降级——解决

限流——预防

6.1 雪崩概念

概念：一个服务失败，导致整条链路的服务都失败的情况

6.2 服务降级概念

服务降级是微服务自我保护的一种方式，或者保护下游服务的一种方式，由于确保服务不会手请求突增影响，而变得不可用。确保服务不会崩溃。

实现方式：通过Feign去实现的。

当服务正常提供访问时，他就走↑面的逻辑，当服务异常调用失败后，就会走下面的逻辑直接返回异常。

扩展阅读：

什么场景服务调用失败吗？

在使用Feign结合Ribbon进行微服务间调用时，Feign的fallback机制主要用于处理由于服务调用过程中发生的各种异常情况，这些异常通常指的是在尝试调用远程服务时遇到的网络问题、服务不可用、超时等问题，而不一定特指HTTP状态码如404或502等特定错误。

这里的“失败”可以包含多种情况，包括但不限于：

1. 服务找不到（404错误）：当Feign尝试连接到一个不存在的服务时，如果服务注册中心（如Eureka）中确实没有这个服务的实例，或者服务实例的IP和端口不正确，那么Feign的调用可能会失败，并触发fallback机制。

2. 服务暂时不可用（502、503等错误）：如果服务本身存在问题，如服务器过载、维护中或因为某些原因暂时无法处理请求，那么返回给Feign的HTTP状态码可能是502、503等，这些也会被认为是调用失败，并可能触发fallback。

3. 网络问题：在微服务架构中，服务间的调用可能跨越多台服务器，甚至跨越多个数据中心。网络问题（如延迟、丢包、DNS解析失败等）都可能导致服务调用失败，从而触发fallback。

4. 超时：Feign调用可以设置超时时间。如果服务在指定的时间内没有响应，那么调用会被视为超时，并触发fallback。

5. 其他异常：除了上述明确的错误码和网络问题外，任何在调用过程中发生的异常（如Feign自己的异常、序列化/反序列化错误等）都可能导致调用失败，并可能触发fallback。

需要注意的是，Feign的fallback机制通常是通过实现一个特定的fallback类，并在该类中定义与服务接口相同的方法签名（但方法体内包含了当服务调用失败时的备选逻辑）来实现的。在FeignClient注解中通过fallback属性指定这个fallback类的类名，这样当服务调用失败时，Feign会自动调用fallback类中对应的方法。

然而，需要注意的是，并非所有类型的失败都会自动触发fallback。例如，如果服务返回了一个业务上的错误码（如2xx以外的HTTP状态码，但服务本身是可达的），并且这个错误码在业务逻辑上被认为是有效的，那么这种情况下通常不会触发fallback，而是由调用方根据返回的错误码进行相应的业务处理。

6.3 服务熔断

Hystrix(hao:s:trcs)熔断机制，用于监控微服务调用情况，默认是关闭的。如果需要开启需要在引导类上添加注解：@EnableCircuitBreaker 如果检测到10秒内请求的失败率超过50%，那就出发熔断机制。之后每隔5秒重新尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求。

关闭、打开、半开状态

默认是关闭状态，接口都可以正常访问。

当10秒内请求的失败率大于50%时，那么熔断状态变为打开。

当熔断机制为开启状态，每个5秒会尝试请求微服务，如果可以访问，那么熔断机制状态就会变为关闭，服务恢复正常访问。

总结：

什么是服务雪崩，如何解决这个问题？

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

服务降级：服务自我保护的一种机制，或者保护下游的一种方式，由于确保服务不会由于请求突增的影响变得不可用，确保服务不会崩溃，一般在实际开发中与feign接口整合，编写降级逻辑。——通俗讲：流量突增，服务请求异常后，直接返回错误信息的情况

服务熔断：默认关闭，需要手动打开。如果检测到10秒内请求的失败率超过50%，就会触发熔断机制。之后每隔5秒内重新尝试请求服务，如果微服务不能响应，继续走熔断机制。如果微服务可以访问，则关闭熔断机制，恢复正常请求。

7. 微服务监控

随着系统设计变得日趋复杂，越来越多的组件开始走向分布式化，如微服务、分布式数据库、分布式缓存等，使得后台服务构成
了一种复杂的分布式网络。往往前端的一个请求需要经过多个微服务、跨越多个数据中心才能最终获取到结果，如下图

并且随着业务的不断扩张，服务之间互相调用会越来越复杂，这个庞大的分布式系统调用网络可能会变的如下图所示：

为什么需要做监控？

问题监控：出现问题排查问题

性能分析：慢接口分析

服务关系：服务调用关系比较复杂

服务告警：出现问题及时告警

常用的工具

1. SpringBoot-admin    （监控普通的微服务，状态信息都可以监控到）
2. Prometheus + Grafana   
3. zipkin  （链路追踪工具，代码有耦合）
4. skywalking （链路追踪工具，用的较多）

7.1 skywalking介绍

2015年由个人吴晟（华为开发者）主导开源，作者是华为开发云监控产品经理，主导监控产品的规划、技术路线及相关研发工
作，也是OpenTracing分布式追踪标准组织成员 ，该项目 2017年加入Apache孵化器，是一个分布式系统的应用程序性能监控工
具（APM），专为微服务、云原生架构和基于容器（Docker、K8s、Mesos）架构而设计。
官方站点：http://skywalking.apache.org/
GitHub项目地址：https://github.com/apache/skywalking
其核心功能要点如下：
● 指标分析：服务，实例，端点指标分析
● 问题分析：在运行时分析代码，找到问题的根本原因
● 服务拓扑：提供服务的拓扑图分析
● 依赖分析：服务实例和端点依赖性分析
● 服务检测：检测慢速的服务和端点
● 性能优化：根据服务监控的结果提供性能优化的思路
● 链路追踪：分布式跟踪和上下文传播
● 数据库监控：数据库访问指标监控统计，检测慢速数据库访问语句（包括SQL语句）
● 服务告警：服务告警功能

7.2 javaAgent概述 

Java Agent这个技术对大多数人来说都比较陌生，但是大家都都多多少少接触过一些，实际上我们平时用过的很多工具都是基于
java Agent来实现的，例如：热部署工具JRebel，springboot的热部署插件，各种线上诊断工具（btrace, greys），阿里开源的
arthas等等。
其实java Agent在JDK1.5以后，我们可以使用agent技术构建一个独立于应用程序的代理程序（即Agent），用来协助监测、运行
甚至替换其他JVM上的程序。使用它可以实现虚拟机级别的AOP功能，并且这种方式一个典型的优势就是无代码侵入。
Agent分为两种，一种是在主程序之前运行的Agent，一种是在主程序之后运行的Agent（前者的升级版，1.6以后提供）。

7.3 原理

ava Agent作为SkyWalking实现APM（应用性能管理）链路监控的关键组件，其工作原理可以归纳为以下几个步骤：

1. Java Agent的加载

Java Agent是Java命令的一个参数，通过-javaagent参数在Java应用程序启动时指定。这个参数后面跟的是Agent的jar包路径。当JVM启动时，会先加载并运行这个Agent jar包中的特定类和方法，即premain方法。这个过程发生在应用程序的main方法执行之前，因此Agent有机会在应用程序启动初期就介入到字节码的处理中。

2. 字节码增强技术

Java Agent利用字节码增强技术（如ASM、Javassist等）对应用程序的类进行动态修改。这些技术允许在运行时对类的字节码进行读取、修改和重新生成。SkyWalking的Agent通过这些技术，在类的加载过程中插入监控代码，以实现对方法调用、异常信息、服务调用链路等运行时数据的收集。

3. 监控数据的收集

通过字节码增强技术，SkyWalking Agent能够在不修改原有应用程序代码的情况下，自动收集到各种运行时数据。这些数据包括但不限于：

• 方法调用：记录方法的调用次数、调用时间等。
• 异常信息：捕获并记录异常堆栈，以便进行问题定位。
• 服务调用链路：通过拦截HTTP请求、数据库访问、RPC调用等，构建分布式服务调用链路图。
• 性能指标：收集方法执行时间、响应状态等性能指标。

4. 数据的发送与处理

收集到的监控数据会被发送到SkyWalking的后端服务（OAP Server）进行处理和存储。OAP Server负责数据的聚合、分析和存储，以便后续的可视化展示和告警。

5. 可视化展示

SkyWalking提供了丰富的可视化界面，用于展示收集到的监控数据。通过这些界面，用户可以直观地看到应用程序的性能状况、服务调用链路、异常分布等信息，从而快速定位问题并进行优化。

参考资料：
Nacos资料：acos架构&原理免费下载_在线阅读_藏经阁-阿里云开发者社区 (aliyun.com)

Eureka官网： Spring Cloud Netflix