微服務的十大問題

作者：蘇三 2025-07-22 08:23:19

開發架構

作為工作多年的老司機，我主導過3次微服務重構，見過太多團隊掉進微服務陷阱：拆分時春風得意，運維時步履維艱。某電商平臺從單體拆分為120個微服務后，故障率飆升300%，排障時間從10分鐘惡化到3小時。

前言

作為工作多年的老司機，我主導過3次微服務重構，見過太多團隊掉進微服務陷阱：拆分時春風得意，運維時步履維艱。

某電商平臺從單體拆分為120個微服務后，故障率飆升300%，排障時間從10分鐘惡化到3小時。

這篇文章跟大家一起聊聊微服務中的10個最常見的問題，希望對你會有所幫助。

1.錯誤的拆分問題

典型場景：按代碼包名拆分服務

圖片

后果：

訂單查詢需調用4個服務
接口延遲從50ms→350ms
鏈路追蹤日志爆炸式增長

正確方案：基于業務能力拆分

圖片

拆分原則：

單一職責（一個服務解決一類問題）
團隊自治（2 Pizza Team可獨立交付）
數據自治（服務獨占數據庫）

2.分布式事務問題

錯誤示范：跨服務數據庫操作

@Transactional // 本地事務失效！  
public void createOrder(OrderDTO dto) {  
    // 1.訂單服務寫庫  
    orderService.save(dto);  
    
    // 2.調用庫存服務  
    stockFeignClient.deduct(dto.getSkuId());  
}

后果：訂單創建成功但庫存未扣減 → 超賣事故

解決方案：Saga模式 + 可靠事件

圖片

代碼實現：

@SagaStart  
public void createOrder(OrderDTO dto) {  
    Saga.with("freezeStock", () -> stockClient.freeze(dto))  
        .with("saveOrder", () -> orderService.save(dto))  
        .compensate("saveOrder", () -> orderService.delete(dto.getId()))  
        .compensate("freezeStock", () -> stockClient.unfreeze(dto))  
        .execute();  
}

3.連環雪崩問題

場景復現：服務A → 服務B → 服務C，C超時導致全鏈路崩潰

圖片

防御方案：熔斷+降級+超時

@FeignClient(name = "stock-service",  
  configuration = FeignConfig.class,  
  fallback = StockFallback.class) // 降級類  
public interface StockClient {  
    @GetMapping("/deduct")  
    @TimeLimiter(fallbackMethod = "defaultResult") // 超時控制  
    CompletableFuture<Boolean> deduct(@RequestParam String skuId);  
}  

// 熔斷配置  
circuitBreaker:  
  failureRateThreshold: 50  
  waitDurationInOpenState: 10s  
  slidingWindowSize: 20

4.配置管理混亂問題

反模式：配置文件散落各服務

├── user-service  
│   ├── application-dev.yml  
│   ├── application-prod.yml  
├── order-service  
│   ├── application-dev.yml  
│   └── application-prod.yml

后果：

修改日志級別需重新部署10個服務
生產環境誤用dev配置

正確方案：統一配置中心

圖片

關鍵配置：

spring:  
cloud:
    nacos:
      config:
        server-addr:192.168.1.10:8848
        file-extension:yaml
        shared-configs:
          -data-id:common.yaml# 公共配置

5.日志追蹤碎片化問題

問題現象：

[user-service] 用戶查詢成功 userId=100  
[order-service] 訂單創建失敗 userId=100  
[payment-service] 支付超時 userId=100

痛苦：跨3個日志系統拼湊調用鏈

解決方案：Sleuth+Zipkin全鏈路追蹤

圖片

日志格式：

2023-08-20 14:30 [user-service,7a3b,9f2c] INFO 用戶查詢  
2023-08-20 14:30 [order-service,7a3b,d8e1] ERROR 訂單創建失敗

其中：

7a3b：全局Trace ID
9f2c/d8e1：各服務ID

6.數據庫拆分問題

錯誤操作：服務共用數據庫

圖片

后果：

訂單表鎖阻塞用戶注冊
無法獨立擴縮容

正確設計：數據庫垂直拆分

圖片

分庫分表策略：

// 用戶ID取模分片  
public String determineDatabase(Long userId) {  
    int dbIndex = userId % 4;  
    return "user_db_" + dbIndex;  
}

7.接口兼容性問題

血案：訂單服務升級v2接口，未通知支付服務

圖片

解決方案：三版本策略

/v1/createOrder (舊版)  
/v2/createOrder (新版)  
/v3/createOrder (預發布)

Spring Cloud灰度發布：

spring:  
cloud:
    gateway:
      routes:
        -id:order_v2
          uri:lb://order-service
          predicates:
            -Header=version,v2
          filters:
            -StripPrefix=1

8.持續集成問題

典型問題：120個服務獨立構建 → 流水線擁堵

圖片

優化方案：

分層構建：

圖片

并行構建：

// Jenkinsfile并行配置  
stage('Parallel Build') {  
  parallel {  
      stage('Service A') { steps { sh './build-serviceA.sh' } }  
      stage('Service B') { steps { sh './build-serviceB.sh' } }  
  }  
}

9.監控缺失問題

慘痛教訓：

磁盤寫滿8小時無人察覺
數據庫連接池耗盡導致全站崩潰

監控體系黃金四件套：

圖片

關鍵告警規則：

rules:  
-alert:HighErrorRate
    expr:sum(rate(http_server_requests_errors_total[5m]))>0.5
    for:2m
-alert:DBConnectionExhausted
    expr:db_connections_active>db_connections_max*0.9
    for:1m

10.團隊協作問題

現實困境：

團隊	技術棧	部署方式
用戶組	Java+MySQL	K8s
訂單組	Go+Postgres	VM
支付組	Node+Mongo	Serverless

解決方案：

10.1統一技術公約

RESTful接口規范
錯誤碼全局定義
日志格式標準
健康檢查端點/actuator/health

10.2基礎設施共享

圖片

總結

由此可見，微服務如果用不好問題還是挺多的，需要有豐富的實戰經驗，才能把微服務項目真正的做好。

微服務的三層防御體系：

圖片

微服務的十條軍規：

服務粒度按業務能力而非代碼量
跨服務事務用最終一致性替代強一致
必須配置熔斷超時閾值
配置中心統一管理所有環境參數
全鏈路追蹤ID穿透所有服務
每個服務獨占數據庫
接口版本兼容至少2個迭代
建立分層構建流水線
核心指標監控覆蓋率100%
制定跨團隊技術公約

微服務的本質不是技術升級，而是組織關系的重構。

責任編輯：武曉燕來源：蘇三說技術

微服務重構運維