Spring Cloud 高頻面試題詳解（含代碼示例與深度解析）

本文旨在幫助求職者系統性地復習和準備 Spring Cloud 相關面試，涵蓋了從核心組件到高級用法的常見問題，并輔以代碼示例和表格對比，助你輕松拿下面試。

---

1. 什么是 Spring Cloud？它與 Spring Boot 有什么關系？

Spring Cloud 是一套分布式系統解決方案的規范集合，它基于 Spring Boot 提供了快速構建分布式系統中常見模式的工具（例如：配置管理、服務發現、斷路器、智能路由、微代理、控制總線、一次性令牌、全局鎖、領導選舉、分布式會話和集群狀態）。

關系與區別：

• Spring Boot：專注于快速、方便地開發單個微服務，提供了自動配置、起步依賴等特性，簡化了獨立服務的開發。
• Spring Cloud：專注于微服務架構的協調與治理，它將多個 Spring Boot 應用程序整合起來，為它們提供分布式環境下的能力。

簡單比喻：

Spring Boot 像是制造汽車的工廠，能快速造出許多功能獨立的汽車（微服務）。而 Spring Cloud 像是交通管理系統，負責所有汽車之間的通信、調度、交通規則（治理），確保整個交通網絡（微服務系統）有序、可靠地運行。

---

2. 服務發現：Eureka 和 Nacos 的區別與選型？

服務發現是微服務架構的基石，客戶端通過它來定位網絡上的服務實例。

Eureka 示例與原理

1. Eureka Server (服務端)：

# application.yml
server:port: 8761
eureka:instance:hostname: localhostclient:register-with-eureka: false # 自身不注冊到Eurekafetch-registry: false       # 不獲取注冊信息service-url:defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/

2. Eureka Client (客戶端 - 服務提供者)：

# application.yml
spring:application:name: user-service # 應用名稱，以后就用這個名字來調用服務
eureka:client:service-url:defaultZone: http://localhost:8761/eureka/ # 注冊中心的地址

Eureka vs Nacos 對比表

特性	Eureka	Nacos
核心功能	服務注冊與發現	服務注冊與發現、動態配置管理
一致性協議	AP (保證可用性和分區容錯性)	AP + CP 模式切換 (同時滿足一致性和可用性)
健康檢查	Client Beat (客戶端心跳)	Server Beat (服務端主動檢測) / Client Beat
負載均衡	需集成 Ribbon	集成 Ribbon，自身也提供
配置中心	不支持	原生支持，功能強大
管理界面	功能相對簡單	功能豐富，集成配置管理
社區生態	Netflix 已停止維護，進入維護模式	阿里巴巴開源，社區活躍，持續更新

選型建議：

• 老項目或簡單場景：Eureka 足夠。
• 新項目強烈推薦 Nacos：它集注冊中心和配置中心于一體，功能更全面，性能更好，是目前的主流選擇。

---

3. 負載均衡：Ribbon 和 LoadBalancer 的區別？

Spring Cloud 提供了客戶端負載均衡器。

Ribbon (已進入維護模式)

Ribbon 是一個客戶端負載均衡器，通過與服務發現組件（如 Eureka）集成，獲取所有服務實例列表，然后在客戶端采用特定策略（如輪詢、隨機）進行調用。

// 在 RestTemplate 上使用 @LoadBalanced 注解即可開啟 Ribbon
@Configuration
public class RestTemplateConfig {@Bean@LoadBalanced // 這個注解讓 RestTemplate 具有了客戶端負載均衡的能力public RestTemplate restTemplate() {return new RestTemplate();}
}// 使用時直接使用服務名代替IP地址
@Service
public class UserService {@Autowiredprivate RestTemplate restTemplate;public User findOrderByUserId(Long userId) {// 直接使用服務名 "order-service"，Ribbon 會將其解析為實際地址并負載均衡String url = "http://order-service/orders/" + userId;return restTemplate.getForObject(url, User.class);}
}

Spring Cloud LoadBalancer (官方新標準)

由于 Ribbon 停止維護，Spring Cloud 官方推出了 LoadBalancer 作為其替代品。

如何使用：

1. 引入依賴 (通常包含在 spring-cloud-starter-loadbalancer 中)
2. 同樣的代碼：上述 RestTemplate 的代碼無需改動，只需移除 Ribbon 依賴，引入 LoadBalancer 依賴即可無縫切換。
3. 支持 Reactive：完美支持 WebClient 進行響應式編程。

// 使用 WebClient + LoadBalancer
@Service
public class UserService {@Autowiredprivate WebClient.Builder webClientBuilder;public Mono<User> findOrderByUserId(Long userId) {return webClientBuilder.build().get().uri("http://order-service/orders/" + userId) // 使用服務名.retrieve().bodyToMono(User.class);}
}

結論：

• 新項目務必使用 Spring Cloud LoadBalancer，它是官方欽定的未來。
• 老項目如果使用 Ribbon，建議規劃遷移。

---

4. 服務調用：Feign 和 OpenFeign？

Feign 是一個聲明式的 Web Service 客戶端，它的目的是讓編寫 Java HTTP 客戶端變得更簡單。使用 Feign 時，只需要創建一個接口并加上注解即可。

OpenFeign 是 Spring Cloud 在 Feign 的基礎上支持了 Spring MVC 注解，并整合了 Ribbon 和 Eureka（現在主要是 LoadBalancer），從而大大簡化了服務間調用的開發。

示例：如何用 OpenFeign 優雅地調用服務

1. 添加依賴：spring-cloud-starter-openfeign

2. 啟動類開啟 Feign：

   @SpringBootApplication
   @EnableFeignClients // 開啟 Feign 客戶端功能
   public class Application {public static void main(String[] args) {SpringApplication.run(Application.class, args);}
   }
   

3. 聲明接口：

   // 聲明這是一個 Feign 客戶端，并指定要調用的服務名
   @FeignClient(name = "order-service")
   public interface OrderServiceClient {// 定義接口方法，就像在寫 Spring MVC 的 Controller 一樣@GetMapping("/orders/{orderId}") // 映射 order-service 中的接口路徑Order getOrderById(@PathVariable("orderId") Long orderId);@PostMapping("/orders")Order createOrder(@RequestBody Order order);
   }
   

4. 像調用本地服務一樣使用：

   @Service
   public class UserService {// 直接注入 Feign 客戶端接口@Autowiredprivate OrderServiceClient orderServiceClient;public User getUserWithOrders(Long userId) {User user = userRepository.findById(userId);// 直接調用接口方法，Feign 會幫你處理HTTP請求、負載均衡、服務發現等所有底層細節List<Order> orders = orderServiceClient.getOrdersByUserId(userId);user.setOrders(orders);return user;}
   }
   

核心優勢：接口化、聲明式的調用，極大地提高了開發效率，使代碼更清晰、更易于維護。

---

5. 服務容錯：Hystrix 和 Sentinel 的區別？

在分布式環境中，避免服務出現雪崩效應是重中之重。這就是服務容錯組件的作用。

Hystrix (已停止維護)

Hystrix 通過斷路器 (Circuit Breaker) 模式來實現容錯。

• 熔斷：當失敗率達到閾值，斷路器打開，所有請求直接失敗，不再調用實際服務。
• 降級：服務熔斷或資源不足時，提供一種備選方案（fallback），返回一個托底數據。

@RestController
public class OrderController {@Autowiredprivate OrderServiceClient orderServiceClient;// 使用 @HystrixCommand 指定降級方法@GetMapping("/user/{userId}/orders")@HystrixCommand(fallbackMethod = "getOrdersFallback")public List<Order> getOrders(@PathVariable Long userId) {return orderServiceClient.getOrdersByUserId(userId);}// 降級方法public List<Order> getOrdersFallback(Long userId) {return Collections.emptyList(); // 返回空列表作為托底數據}
}

Sentinel (阿里開源，目前主流)

Sentinel 功能更強大，不僅支持熔斷降級，還支持流量控制、系統自適應保護、實時監控等。

對比表：

特性	Hystrix	Sentinel
核心焦點	斷路器 (熔斷器)	流量控制、熔斷降級、系統保護
配置方式	代碼注解為主	控制臺動態配置，規則可持久化
擴展性	一般	豐富 SPI 擴展接口
實時監控	簡單的監控界面	功能強大的實時監控和控制臺
規則持久化	不支持	支持多種數據源（如Nacos, Apollo）

結論：

• 新項目強烈推薦使用 Sentinel，功能更全面，控制臺更友好，配置更靈活。
• Hystrix 已停止維護，僅為遺留系統存在。

---

6. API 網關：Spring Cloud Gateway vs Zuul？

API 網關是所有微服務的流量入口，負責路由、過濾、鑒權、限流等。

Zuul 1.x (Netflix，基于阻塞IO，已淘汰)

Spring Cloud Gateway (官方推薦，基于響應式)

Spring Cloud Gateway 基于 WebFlux 響應式編程模型，性能更高，功能更強。

核心概念：

• Route (路由)：定義匹配條件和轉發目標。
• Predicate (斷言)：匹配 HTTP 請求的條件（如路徑、方法、頭信息）。
• Filter (過濾器)：處理請求和響應的邏輯（如添加請求頭、鑒權、限流）。

配置示例：

spring:cloud:gateway:routes:- id: user_route # 路由IDuri: lb://user-service # 目標服務地址，lb:// 表示從注冊中心負載均衡predicates:- Path=/api/user/** # 斷言：路徑匹配filters:- StripPrefix=1 # 過濾器：去掉路徑中的第一個前綴（/api）- AddRequestHeader=X-Request-color, blue # 添加請求頭

結論：

• 無條件選擇 Spring Cloud Gateway，它是官方未來，性能優越，功能持續更新。Zuul 1.x 已徹底淘汰。

---

7. 分布式配置中心：Spring Cloud Config 和 Nacos？

集中管理所有微服務在不同環境下的配置文件。

Spring Cloud Config

• Server端：從 Git、SVN 等倉庫拉取配置。
• Client端：從 Server 端獲取配置。
• 缺點：配置變更后，需要手動通過 Spring Cloud Bus 消息總線刷新所有客戶端，流程繁瑣。

Nacos Config

作為配置中心，Nacos 的優勢巨大：

1. 開箱即用：與注冊中心一體，無需額外部署。
2. 動態刷新：通過 @RefreshScope 注解，客戶端能自動監聽配置變化并刷新，無需手動觸發 Bus。
3. 管理界面：提供友好的 Web UI 管理配置。
4. 多環境與灰度：支持命名空間 (Namespace) 和數據ID (Data ID) 進行環境隔離和灰度發布。

使用示例：

1. 添加依賴：spring-cloud-starter-alibaba-nacos-config

2. 在 bootstrap.yml 中配置 Nacos Server 地址：

   spring:application:name: user-servicecloud:nacos:config:server-addr: localhost:8848file-extension: yaml # 指定配置格式為yamlnamespace: dev # 指定命名空間（用于環境隔離）
   

3. 在 Controller 中使用 @Value 并開啟自動刷新：

   @RestController
   @RefreshScope // 這個注解是關鍵，允許動態刷新配置
   public class UserController {@Value("${user.config.title:默認標題}") // 冒號后面是默認值private String title;@GetMapping("/title")public String getTitle() {return this.title;}
   }
   

結論：

• Nacos 在配置中心方面完勝 Spring Cloud Config，是其完美的替代品，極大地簡化了分布式配置的復雜度。

---

總結

組件類別	過去式 (Netflix 體系)	現在與未來 (主流選擇)
服務發現	Eureka	Nacos
負載均衡	Ribbon	Spring Cloud LoadBalancer
服務調用	Feign	OpenFeign
服務容錯	Hystrix	Sentinel
API網關	Zuul 1.x	Spring Cloud Gateway
配置中心	Spring Cloud Config	Nacos

---