Spring Cloud
Spring Cloud
QA
Nginx 与 Spring Cloud Gateway 的区别
核心区别如下。
| 对比维度 | Nginx | Spring Cloud Gateway |
|---|---|---|
| 定位 | 通用反向代理/负载均衡服务器，支持静态资源、TCP/UDP转发 | 专为微服务设计的API网关，深度集成Spring生态 |
| 主要场景 | 基础设施层流量管理（负载均衡、SSL终止、缓存） | 微服务内部动态路由、鉴权、限流等业务逻辑处理 |
| 协议支持 | HTTP/HTTPS、TCP/UDP、WebSocket | 主要支持HTTP/HTTPS（如REST API、WebSocket） |
| 配置方式 | 静态配置文件（nginx.conf），需重载生效 | 代码（Java DSL）或YAML/Properties，支持动态更新（如结合Nacos/Eureka） |
| 动态能力 | 依赖外部工具（如Consul Template）或Lua脚本实现动态服务发现 | 原生支持服务注册中心，自动感知微服务实例变化 |
| 性能 | 更高（基于C语言，事件驱动模型，适合高并发） | 较低（基于Java Netty），但业务逻辑处理更灵活 |
| 扩展性 | 通过模块或Lua脚本扩展（如OpenResty） | 原生Java扩展（Spring插件体系，支持自定义过滤器、路由规则） |
| 核心功能 | 负载均衡、缓存、压缩、SSL/TLS、访问控制 | 动态路由、熔断（Hystrix）、限流（Redis）、重试、鉴权（OAuth2/JWT） |
| 生态系统 | 独立于应用框架，支持多语言后端 | 深度集成Spring Cloud（Eureka、Config Server）、Spring Security等 |
| 典型使用层级 | 全局入口网关（如K8s Ingress）、四层/七层代理 | 微服务应用层网关（API聚合、业务逻辑拦截） |
| 适用技术栈 | 与任意后端（Java/Python/Go等）搭配 | 适合Java微服务技术栈（Spring Boot/Cloud） |
| 商业支持 | 开源版功能基础，商业版（NGINX Plus）提供高级功能（如API管理） | 完全开源，依赖Spring生态的商业支持（如VMware Tanzu） |
| 代理方式支持 | 支持正向、反向代理 | 支持反向代理和局限性的正向代理 |
了解 SpringCloud 吗，说一下他和 SpringBoot 的区别
Spring Boot 是用于构建单个 Spring 应用的框架，而 Spring Cloud 则是用于构建分布式系统中的微服务架构的工具，Spring Cloud 提供了服务注册与发现、负载均衡、断路器、网关等功能。
两者可以结合使用，通过 Spring Boot 构建微服务应用，然后用 Spring Cloud 来实现微服务架构中的各种功能。
用过哪些微服务组件？
微服务常用的组件。 * 注册中心：注册中心是微服务架构最核心的组件。它起到的作用是对新节点的注册与状态维护，解决了「如何发现新节点以及检查各节点的运行状态的问题」。微服务节点在启动时会将自己的服务名称、IP、端口等信息在注册中心登记，注册中心会定时检查该节点的运行状态。注册中心通常会采用心跳机制最大程度保证已登记过的服务节点都是可用的。 * 负载均衡，负载均衡解决了「如何发现服务及负载均衡如何实现的问题」，通常微服务在互相调用时，并不是直接通过IP、端口进行访问调用。而是先通过服务名在注册中心查询该服务拥有哪些节点，注册中心将该服务可用节点列表返回给服务调用者，这个过程叫服务发现，因服务高可用的要求，服务调用者会接收到多个节点，必须要从中进行选择。因此服务调用者一端必须内置负载均衡器，通过负载均衡策略选择合适的节点发起实质性的通信请求。 * 服务通信：服务通信组件解决了「服务间如何进行消息通信的问题」，服务间通信采用轻量级协议，通常是HTTP RESTful风格。但因为RESTful风格过于灵活，必须加以约束，通常应用时对其封装。例如在SpringCloud中就提供了Feign和RestTemplate两种技术屏蔽底层的实现细节，所有开发者都是基于封装后统一的SDK进行开发，有利于团队间的相互合作。 * 配置中心：配置中心主要解决了「如何集中管理各节点配置文件的问题」，在微服务架构下，所有的微服务节点都包含自己的各种配置文件，如jdbc配置、自定义配置、环境配置、运行参数配置等。要知道有的微服务可能可能有几十个节点，如果将这些配置文件分散存储在节点上，发生配置更改就需要逐个节点调整，将给运维人员带来巨大的压力。配置中心便由此而生，通过部署配置中心服务器，将各节点配置文件从服务中剥离，集中转存到配置中心。一般配置中心都有UI界面，方便实现大规模集群配置调整。 * 集中式日志管理：集中式日志主要是解决了「如何收集各节点日志并统一管理的问题」。微服务架构默认将应用日志分别保存在部署节点上，当需要对日志数据和操作数据进行数据分析和数据统计时，必须收集所有节点的日志数据。那么怎么高效收集所有节点的日志数据呢？业内常见的方案有ELK、EFK。通过搭建独立的日志收集系统，定时抓取各节点增量日志形成有效的统计报表，为统计和分析提供数据支撑。 * 分布式链路追踪：分布式链路追踪解决了「如何直观的了解各节点间的调用链路的问题」。系统中一个复杂的业务流程，可能会出现连续调用多个微服务，我们需要了解完整的业务逻辑涉及的每个微服务的运行状态，通过可视化链路图展现，可以帮助开发人员快速分析系统瓶颈及出错的服务。 * 服务保护：服务保护主要是解决了「如何对系统进行链路保护，避免服务雪崩的问题」。在业务运行时，微服务间互相调用支撑，如果某个微服务出现高延迟导致线程池满载，或是业务处理失败。这里就需要引入服务保护组件来实现高延迟服务的快速降级，避免系统崩溃。 
- SpringCloud Alibaba 中使用 Alibaba Nacos 组件实现注册中心，Nacos 提供了一组简单易用的特性集，可快速实现动态服务发现、服务配置、服务元数据及流量管理。
- SpringCloud Alibaba 使用 Nacos 服务端均衡实现负载均衡，与 Ribbon 在调用端负载不同，Nacos 是在服务发现的同时利用负载均衡返回服务节点数据。
- SpringCloud Alibaba 使用 Netflix Feign 和 Alibaba Dubbo 组件来实现服务通行，前者与 SpringCloud 采用了相同的方案，后者则是对自家的 RPC 框架 Dubbo 也给予支持，为服务间通信提供另一种选择。
- SpringCloud Alibaba 在 API 服务网关组件中，使用与 SpringCloud 相同的组件，即：SpringCloud Gateway。
- SpringCloud Alibaba 在配置中心组件中使用 Nacos 内置配置中心，Nacos 内置的配置中心，可将配置信息存储保存在指定数据库中。
- SpringCloud Alibaba 在原有的 ELK 方案外，还可以使用阿里云日志服务（LOG）实现日志集中式管理。
- SpringCloud Alibaba 在分布式链路组件中采用与 SpringCloud 相同的方案，即：Sleuth/Zipkin Server。
- SpringCloud Alibaba 使用 Alibaba Sentinel 实现系统保护，Sentinel 不仅功能更强大，实现系统保护比 Hystrix 更优雅，而且还拥有更好的 UI 界面。
负载均衡有哪些算法
- 简单轮询：将请求按顺序分发给后端服务器上，不关心服务器当前的状态，比如后端服务器的性能、当前的负载。
- 加权轮询：根据服务器自身的性能给服务器设置不同的权重，将请求按顺序和权重分发给后端服务器，可以让性能高的机器处理更多的请求。
- 简单随机：将请求随机分发给后端服务器上，请求越多，各个服务器接收到的请求越平均。
- 加权随机：根据服务器自身的性能给服务器设置不同的权重，将请求按各个服务器的权重随机分发给后端服务器。
- 一致性哈希：根据请求的客户端 ip、或请求参数通过哈希算法得到一个数值，利用该数值取模映射出对应的后端服务器，这样能保证同一个客户端或相同参数的请求每次都使用同一台服务器。
- 最小活跃数：统计每台服务器上当前正在处理的请求数，也就是请求活跃数，将请求分发给活跃数最少的后台服务器。
如何实现一直均衡给一个用户？
可以通过「一致性哈希算法」来实现，根据请求的客户端 ip、或请求参数通过哈希算法得到一个数值，利用该数值取模映射出对应的后端服务器，这样能保证同一个客户端或相同参数的请求每次都使用同一台服务器。
介绍一下服务熔断
服务熔断是应对微服务雪崩效应的一种链路保护机制，类似股市、保险丝。
比如说，微服务之间的数据交互是通过远程调用来完成的。服务A调用服务，服务B调用服务c，某一时间链路上对服务C的调用响应时间过长或者服务C不可用，随着时间的增长，对服务C的调用也越来越多，然后服务C崩溃了，但是链路调用还在，对服务B的调用也在持续增多，然后服务B崩溃，随之A也崩溃，导致雪崩效应。
服务熔断是应对雪崩效应的一种微服务链路保护机制。例如在高压电路中，如果某个地方的电压过高，熔断器就会熔断，对电路进行保护。同样，在微服务架构中，熔断机制也是起着类似的作用。当调用链路的某个微服务不可用或者响应时间太长时，会进行服务熔断，不再有该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。
所以，服务熔断的作用类似于我们家用的保险丝，当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用。
在 Spring Cloud 框架里，熔断机制通过 Hystrix 实现。Hystrix 会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是 5 秒内 20 次调用失败，就会启动熔断机制。
介绍一下服务降级
服务降级一般是指在服务器压力剧增的时候，根据实际业务使用情况以及流量，对一些服务和页面有策略的不处理或者用一种简单的方式进行处理，从而释放服务器资源的资源以保证核心业务的正常高效运行。
服务器的资源是有限的，而请求是无限的。在用户使用即并发高峰期，会影响整体服务的性能，严重的话会导致宕机，以至于某些重要服务不可用。故高峰期为了保证核心功能服务的可用性，就需要对某些服务降级处理。可以理解为舍小保大。
服务降级是从整个系统的负荷情况出发和考虑的，对某些负荷会比较高的情况，为了预防某些功能（业务场景）出现负荷过载或者响应慢的情况，在其内部暂时舍弃对一些非核心的接口和数据的请求，而直接返回一个提前准备好的 fallback（退路）错误处理信息。这样，虽然提供的是一个有损的服务，但却保证了整个系统的稳定性和可用性。