微服务相关

1.什么是微服务

微服务（Microservices）是一种软件架构风格，将一个大型应用程序划分为一组小型、自治且松耦合的服务。每个微服务负责执行特定的业务功能，并通过轻量级通信机制（如HTTP）相互协作。每个微服务可以独立开发、部署和扩展，使得应用程序更加灵活、可伸缩和可维护。

同时微服务带来以下问题，

  1.系统复杂性增加：一个服务拆成了多个服务，整体系统的复杂性增加，需要处理服务之间的通信、部署、监控和维护等方面的复杂性。

  2.服务间通信开销：微服务之间通过网络进行通信，传递数据需要额外的网络开销和序列化开销，可能导致性能瓶颈和增加系统延迟。

  3.数据一致性和事务管理：每个微服务都有自己的数据存储，数据一致性和跨服务的事务管理变得更加复杂，需要额外解决分布式事务和数据同步的问题。

  4.部署和运维复杂性：微服务架构涉及多个独立部署的服务，对于部署、监控和容错机制的要求更高，需要建立适当的部署管道和自动化工具，以简化部署和运维过程。

  5.团队沟通和协作成本：每个微服务都由专门的团队负责，可能增加团队之间的沟通和协作成本。需要有效的沟通渠道和协作机制，确保服务之间的协调和一致性。

  6.服务治理和版本管理：随着微服务数量的增加，服务的治理和版本管理变得更加复杂。需要考虑服务的注册发现、负载均衡、监控和故障处理等方面，以确保整个系统的可靠性和稳定性。

微服务架构图

2.目前有哪些流行的微服务解决方案

Dubbo

Dubbo 是阿里开源的一个高性能、轻量级的 Java 微服务框架。使用基于 RPC（Remote Procedure Call）的通信模型。它支持多种传输协议（如 TCP、HTTP、Redis）和序列化方式（如 JSON、Hessian、Protobuf）
Dubbo 更多地被认为是一个高性能的 RPC（远程过程调用）框架，一些服务治理功能依赖于第三方组件实现，比如使用 ZooKeeper、Apollo 等等

Spring Cloud Netflix

Spring Cloud Netflix 是 Spring Cloud 的一个子项目，该项目包含了许多流行的 Netflix 组件，如 Eureka（服务注册与发现）、Ribbon（客户端负载均衡）、Hystrix（断路器）、Zuul（API 网关）等

Spring Cloud Alibaba

Spring Cloud Alibaba 是 Spring Cloud 的另一个子项目，它提供了一整套与 Alibaba 生态系统集成的解决方案
该项目包括 Nacos（服务注册与发现、配置管理）、Sentinel（流量控制、熔断降级）、RocketMQ（消息队列）等组件，以及与 Alibaba Cloud（阿里云）的集成

三种方案的区别：

3.微服务有哪些组件

微服务的各个组件和常见实现：

注册中心 ：用于服务的注册与发现，管理微服务的地址信息。常见的实现包括：
```
Spring Cloud Netflix：Eureka、Consul

Spring Cloud Alibaba：Nacos
```
配置中心 : 用于集中管理微服务的配置信息，可以动态修改配置而不需要重启服务。常见的实现包括：
```
 Spring Cloud Netflix：Spring Cloud Config

 Spring Cloud Alibaba：Nacos Config
```
远程调用 : 用于在不同的微服务之间进行通信和协作。常见的实现保包括：
```
 RESTful API：如 RestTemplate、Feign

 RPC（远程过程调用）：如 Dubbo、gRPC
```
API 网关 : 作为微服务架构的入口，统一暴露服务，并提供路由、负载均衡、安全认证等功能。常见的实现包括：
```
 Spring Cloud Netflix：Zuul、Gateway

 Spring Cloud Alibaba：Gateway、Apisix 等
```
分布式事务 : 保证跨多个微服务的一致性和原子性操作。常见的实现包括：
```
 Spring Cloud Alibaba：Seata
```
熔断器 : 用于防止微服务之间的故障扩散，提高系统的容错能力。常见的实现包括：
```
 Spring Cloud Netflix：Hystrix

 Spring Cloud Alibaba：Sentinel、Resilience4j
```
限流和降级 : 用于防止微服务过载，对请求进行限制和降级处理。常见的实现包括： Spring Cloud Netflix：Hystrix
```
 Spring Cloud Alibaba：Sentinel
```
分布式追踪和监控 : 用于跟踪和监控微服务的请求流程和性能指标。常见的实现包括：
```
 Spring Cloud Netflix：Spring Cloud Sleuth + Zipkin

 Spring Cloud Alibaba：SkyWalking、Sentinel Dashboard
```

微服务组件

4.注册中心的作用

注册中心是用来管理和维护分布式系统中各个服务的地址和元数据的组件。它主要用于实现服务发现和服务注册功能。

服务注册：各个服务在启动时向注册中心注册自己的网络地址、服务实例信息和其他相关元数据。这样，其他服务就可以通过注册中心获取到当前可用的服务列表。
服务发现：客户端通过向注册中心查询特定服务的注册信息，获得可用的服务实例列表。这样客户端就可以根据需要选择合适的服务进行调用，实现了服务间的解耦。
负载均衡：注册中心可以对同一服务的多个实例进行负载均衡，将请求分发到不同的实例上，提高整体的系统性能和可用性。
故障恢复：注册中心能够监测和检测服务的状态，当服务实例发生故障或下线时，可以及时更新注册信息，从而保证服务能够正常工作。
服务治理：通过注册中心可以进行服务的配置管理、动态扩缩容、服务路由、灰度发布等操作，实现对服务的动态管理和控制

5.Eureka、ZooKeeper、Nacos 的区别

Eureka 和 ZooKeeper 的最大区别是一个支持 AP，一个支持 CP。Nacos既支持既支持 AP，也支持 CP。

注册中心区别

6.Nacos配置中心服务发现和配置自动更新原理

服务发现

服务消费者动态获取服务提供者的网络地址，而无需硬编码。其核心机制是“实时推送 (Push) 为主，定期拉取 (Pull) 为辅”

 服务注册与寻址：服务提供者启动后，通过 Nacos SDK 向 Nacos Server 注册自身的 IP、端口等元数据。客户端在初始化时，会根据配置（如 server-addr 或 Endpoint）获取 Nacos Server 的地址列表，并建立通信连接。

 实时推送 (Push)：服务消费者首次查询服务列表后，会向 Nacos Server 订阅该服务。当服务实例发生变化（如新增、下线、健康状态改变）时，Nacos Server 会通过 gRPC 长连接（或 HTTP 长轮询）立即将最新的实例列表推送给消费者，消费者接收后刷新本地缓存。

 定期拉取 (Pull)：作为兜底机制，客户端 SDK 会启动后台定时任务（如默认每 30 秒），主动向 Nacos Server 拉取最新的服务列表并与本地缓存比对，以防止因网络问题导致推送失败时数据不一致。

 健康检查：Nacos 支持临时实例（客户端主动发送心跳）和永久实例（服务端主动探测）两种模式。不健康的实例会被过滤，不会返回给消费者，从而保障调用安全。

配置中心

nacos实现配置信息的 CRUD，springcloud实现配置自动更新。可以分成这么几个部分：

 配置信息存储：Nacos 默认使用内嵌数据库 Derby 来存储配置信息，还可以采用 MySQL 等关系型数据库。

 注册配置信息：服务启动时，Nacos Client 会向 Nacos Server 注册自己的配置信息，这个注册过程就是把配置信息写入存储，并生成版本号。

 获取配置信息：服务运行期间，Nacos Client 通过 API 从 Nacos Server 获取配置信息。Server 根据键查找对应的配置信息，并返回给 Client。

 监听配置变化：Nacos Client 可以通过注册监听器的方式，实现对配置信息的监听。

 长轮询机制：客户端向服务端发起带有较长超时时间的请求。如果配置未发生变化，服务端会保持连接不响应；一旦配置发生变更或达到超时时间，服务端会立即返回响应。这种方式有效减少了网络请求次数，提高了效率

 Spring Cloud 集成刷新：在 Spring Cloud 环境中，对于配置了 @RefreshScope 注解的 Bean，当客户端接收到配置变更通知后，Spring 框架会触发刷新事件，重新加载受影响的 Bean，使得通过 @Value 等注入的配置值能够自动更新为最新内容。

兜底全量拉取：为了应对长连接推送可能存在的失败情况，Nacos 2.0 引入了每 5 分钟进行一次全量拉取的机制，进一步增强了配置更新的可靠性

7. Feign 怎么实现认证传递

Feign 是在 RestTemplate 和 Ribbon 的基础上进一步封装，使用 RestTemplate 实现 HTTP 调用，使用 Ribbon 实现负载均衡。

认证传递，比较常见的一个做法是，使用拦截器传递认证信息。可以通过实现 RequestInterceptor 接口来定义拦截器，在拦截器里，把认证信息添加到请求头中，然后将其注册到 Feign 的配置中。

@Configuration
public class FeignClientConfig {

    @Bean
    public RequestInterceptor requestInterceptor() {
        return new RequestInterceptor() {
            @Override
            public void apply(RequestTemplate template) {
                // 添加认证信息到请求头中
                template.header("Authorization", "Bearer " + getToken());
            }
        };
    }

    private String getToken() {
        // 获取认证信息的逻辑，可以从SecurityContext或其他地方获取
        // 返回认证信息的字符串形式
        return "your_token";
    }
}

8. Fegin 怎么做负载均衡

在 Feign 中，负载均衡是通过集成 Ribbon 来实现的。

Ribbon 是 Netflix 开源的一个客户端负载均衡器，可以与 Feign 无缝集成，为 Feign 提供负载均衡的能力。

Ribbon 通过从服务注册中心获取可用服务列表，并通过负载均衡算法选择合适的服务实例进行请求转发，实现客户端的负载均衡。

常见的负载算法有：

 轮询（Round Robin）：按顺序依次将请求分配给每个节点，循环往复。优点是简单公平，缺点是无法根据节点的实际负载做出调整。

 加权轮询（Weighted Round Robin）：为每个节点分配不同的权重，处理能力更强（如 CPU、内存配置更高）的节点会被分配更高的权重，从而接收更多请求。

 源地址哈希（IP Hash）：基于客户端 IP 地址计算哈希值，确保来自同一客户端的请求始终被路由到同一台服务器。优势是天然支持会话保持（Session Persistence），但在节点增减时可能导致大量请求重定向。

 最少连接数（Least Connections）：优先将新请求分配给当前活跃连接数最少的节点。这能有效避免某台服务器因处理多个长连接请求而产生瓶颈，特别适合 WebSocket 等长连接场景

 随机算法（Random）：随机算法将请求随机分配给后端服务器。每个后端服务器有相等的被选中概率，没有考虑服务器的实际负载情况。这种算法简单快速，适用于后端服务器性能相近且无需考虑请求处理能力的场景。

9.什么是服务雪崩、服务熔断和服务降级

在微服务中，假如一个或者多个服务出现故障，如果这时候，依赖的服务还在不断发起请求，或者重试，那么这些请求的压力会不断在下游堆积，导致下游服务的负载急剧增加。不断累计之下，可能会导致故障的进一步加剧，可能会导致级联式的失败，甚至导致整个系统崩溃，这就叫服务雪崩。

一般为了防止服务雪崩，可以采用这些措施：

服务高可用部署：确保各个服务都具备高可用性，通过冗余部署、故障转移等方式来减少单点故障的影响。

限流和熔断：对服务之间的请求进行限流和熔断，以防止过多的请求涌入导致后端服务不可用。

 服务熔断是微服务架构中的容错机制，用于保护系统免受服务故障或异常的影响。当某个服务出现故障或异常时，服务熔断可以快速隔离该服务，确保系统稳定可用

缓存和降级：合理使用缓存来减轻后端服务的负载压力，并在必要时进行服务降级，保证核心功能的可用性。

服务降级：当系统出现异常情况时，主动屏蔽一些非核心或可选的功能，而只提供最基本的功能，以确保系统的稳定运行。通过减少对资源的依赖，保证系统的可用性和性能

常见的服务降级方案

10.Hystrix 怎么实现服务容错

Hystrix服务容错六大机制

服务熔断（Circuit Breaker）：Hystrix 通过设置阈值来监控服务的错误率或响应时间。当错误率或响应时间超过预设的阈值时，熔断器将会打开，后续的请求将不再发送到实际的服务提供方，而是返回预设的默认值或错误信息。这样可以快速隔离故障服务，防止故障扩散，提高系统的稳定性和可用性。
服务降级（Fallback）：当服务熔断打开时，Hystrix 可以提供一个备用的降级方法或返回默认值，以保证系统继续正常运行。开发者可以定义降级逻辑，例如返回缓存数据、执行简化的逻辑或调用其他可靠的服务，以提供有限但可用的功能。

/*服务降级示例*/
@Service
public class MyService {

    	@HystrixCommand(fallbackMethod = "fallbackMethod")
    	public String myServiceMethod() {
        	// 实际的服务调用逻辑
        	// ...
    	}

    	public String fallbackMethod() {
        	// 降级方法的逻辑，当服务调用失败时会执行此方法
       	 // 可以返回默认值或执行其他备用逻辑
        	// ...
    	}
    }

请求缓存（Request Caching）：Hystrix 可以缓存对同一请求的响应结果，当下次请求相同的数据时，直接从缓存中获取，避免重复的网络请求，提高系统的性能和响应速度。
请求合并（Request Collapsing）：Hystrix 可以将多个并发的请求合并为一个批量请求，减少网络开销和资源占用。这对于一些高并发的场景可以有效地减少请求次数，提高系统的性能。
实时监控和度量（Real-time Monitoring and Metrics）：Hystrix 提供了实时监控和度量功能，可以对服务的执行情况进行监控和统计，包括错误率、响应时间、并发量等指标。通过监控数据，可以及时发现和解决服务故障或性能问题。
线程池隔离（Thread Pool Isolation）：Hystrix 将每个依赖服务的请求都放在独立的线程池中执行，避免因某个服务的故障导致整个系统的线程资源耗尽。通过线程池隔离，可以提高系统的稳定性和可用性

11.Spring Cloud Gateway 原理

在 Spring Cloud Gateway 里，有三个关键组件：

Route（路由）：路由是 Spring Cloud Gateway 的基本构建块，它定义了请求的匹配规则和转发目标。通过配置路由，可以将请求映射到后端的服务实例或 URL 上。路由规则可以根据请求的路径、方法、请求头等条件进行匹配，并指定转发的目标 URI。
Predicate（断言）：断言用于匹配请求的条件，如果请求满足断言的条件，则会应用所配置的过滤器。Spring Cloud Gateway 提供了多种内置的断言，如 Path（路径匹配）、Method（请求方法匹配）、Header（请求头匹配）等，同时也支持自定义断言。
Filter（过滤器）：过滤器用于对请求进行处理和转换，可以修改请求、响应以及执行其他自定义逻辑。Spring Cloud Gateway 提供了多个内置的过滤器，如请求转发、请求重试、请求限流等。同时也支持自定义过滤器，可以根据需求编写自己的过滤器逻辑。

具体工作流程

Gateway Handler（网关处理器）：网关处理器是 Spring Cloud Gateway 的核心组件，负责将请求转发到匹配的路由上。它根据路由配置和断言条件进行路由匹配，选择合适的路由进行请求转发。网关处理器还会依次应用配置的过滤器链，对请求进行处理和转换。
Gateway Filter Chain（网关过滤器链）：网关过滤器链由一系列过滤器组成，按照配置的顺序依次执行。每个过滤器可以在请求前、请求后或请求发生错误时进行处理。过滤器链的执行过程可以修改请求、响应以及执行其他自定义逻辑

核心请求处理流程

 一个客户端请求经过 Spring Cloud Gateway 的完整生命周期如下：

请求入口与封装：客户端的 HTTP 请求首先被 Gateway 内嵌的 Reactor Netty 服务器接收，并由 HttpWebHandlerAdapter 提取组装成网关上下文（ServerWebExchange 对象），随后传递给核心分发处理器 DispatcherHandler。

路由匹配：DispatcherHandler 将请求分发到路由断言处理器映射器（RoutePredicateHandlerMapping）。该映射器会循环遍历加载的路由定义，通过断言（Predicate）判断请求是否可用。若匹配失败则继续查找，若断言成功则确定目标路由。
构建过滤器链：路由匹配成功后，FilteringWebHandler 会为该请求组装过滤器链（Filter Chain），将全局过滤器（GlobalFilter）和特定路由过滤器（GatewayFilter）按 Order 排序组合。
执行前置过滤器（Pre Filter）：依次执行过滤器链中虚线之前的“前置过滤器”，完成诸如统一鉴权、限流、跨域处理、请求头改写等逻辑。
请求转发与负载均衡：前置过滤器执行完毕后，Gateway 通过响应式 WebClient 将请求非阻塞地转发到目标微服务。如果配置了服务发现（如 Nacos/Eureka），还会通过 LoadBalancerClient 自动进行服务实例的负载均衡选择。
执行后置过滤器（Post Filter）：下游微服务处理完毕并将响应返回给 Gateway 后，接着执行过滤器链中虚线之后的“后置过滤器”，进行日志记录、响应内容修改等操作。
响应返回：最终将处理后的响应结果返回给客户端，完成整个请求流程。

12. Seata支持哪些模式的分布式事务

AT （Auto Transaction，自动事务模式）模式

Seata 默认支持的模式，也是最常用的模式之一。这是一种无侵入的分布式事务解决方案。用户只需关注自己的业务SQL，Seata框架会自动生成事务的二阶段提交和回滚操作（通过生成回滚日志 undo_log 实现）

TCC（Try-Confirm-Cancel）模式

TCC 模式是一种基于补偿机制的分布式事务模式。业务逻辑需要实现 Try、Confirm 和 Cancel 三个阶段的操作。Seata 通过调用业务代码中的 Try、Confirm 和 Cancel 方法，并在每个阶段记录相关的操作日志，来实现分布式事务的一致性

SAGA 模式（长事务模式）

特点：适用于长事务场景。它将长业务流程拆分为一系列本地短事务，通过定义一系列的事务步骤和相对应的补偿操作（回滚操作）来管理事务。适用场景：适用于微服务架构下的复杂业务流程或超长事务（如订单履约、物流调度等），允许一定范围内的最终一致性。

XA 模式

XA 模式是一种基于两阶段提交（Two-Phase Commit）协议的分布式事务模式。在 XA 模式中，Seata 通过与数据库的 XA 事务协议进行交互，实现对分布式事务的管理和协调。XA 模式需要数据库本身支持 XA 事务，并且需要在应用程序中配置相应的 XA 数据源

注意：本文归作者所有，未经作者允许，不得转载

1.什么是微服务

2.目前有哪些流行的微服务解决方案

3.微服务有哪些组件

4.注册中心的作用

5.Eureka、ZooKeeper、Nacos 的区别

6.Nacos配置中心服务发现和配置自动更新原理

7. Feign 怎么实现认证传递

8. Fegin 怎么做负载均衡

9.什么是服务雪崩、服务熔断和服务降级

10.Hystrix 怎么实现服务容错

11.Spring Cloud Gateway 原理

12. Seata支持哪些模式的分布式事务

已有 0 条评论

为您推荐

【冷兔•槽】每日一冷NO.2753

Redis 延时任务

【冷兔•槽】每日一冷NO.2841

java实现给图片添加文字或图片水印

FC模拟器网页版(原创)

【冷兔•槽】每日一冷NO.2749

窗口透明化小工具

从零开始看懂 AI

文章目录

联系方式

最新发布