Hơn cả những kiến thức cơ bản: Tăng cường độ ổn định cho Microservices với Resilience4j và Spring Boot

Sự hỗn loạn tiềm ẩn của các hệ thống phân tán

Trong kiến trúc monolith, một lệnh gọi phương thức là chuyện nội bộ. Nó hoạt động hoặc không. Microservices lại đưa vào một biến số hỗn loạn: mạng (network). Khi Service A gọi Service B, bạn phải phụ thuộc vào tình trạng mất gói tin (packet loss), lỗi DNS và các thread pool bị quá tải. Nếu Service A chờ đợi vô hạn một dependency đang bị chậm, các luồng (threads) của nó sẽ bị chiếm dụng. Chỉ trong vài phút, toàn bộ cluster của bạn có thể bị ngưng trệ. Đây không chỉ là một bug; đó là lỗi dây chuyền (cascading failure) có thể phá hủy mục tiêu uptime 99.9% của bạn.

Sau khi chuyển đổi nhiều hệ thống lưu lượng lớn từ Netflix Hystrix (hiện đã bị ngừng hỗ trợ), đội ngũ của tôi nhận thấy Resilience4j là lựa chọn vượt trội. Đây là một thư viện nhẹ được xây dựng cho Java 8 và lập trình hàm (functional programming). Nó cung cấp một “lưới an toàn” cần thiết để đảm bảo rằng một dịch vụ đang gặp trục trặc không trở thành gánh nặng cho toàn hệ thống. Trong môi trường production của chúng tôi, việc áp dụng các pattern này đã giảm tỷ lệ lỗi gián đoạn gần 40% trong các đợt cao điểm.

Thiết lập hệ sinh thái Resilience4j

Việc tích hợp rất đơn giản. Mặc dù Resilience4j có thể hoạt động như một thư viện độc lập, nhưng Spring Boot starter là lựa chọn tối ưu cho hầu hết các đội ngũ. Nó cho phép bạn quản lý cấu hình thông qua application.yml thay vì viết cứng logic vào các bean.

Thêm các phụ thuộc sau vào pom.xml của bạn. Lưu ý rằng dependency AOP là bắt buộc; nếu không có nó, các annotation sẽ không thể kích hoạt.

<dependency>
    <groupId>io.github.resilience4j</groupId>
    <artifactId>resilience4j-spring-boot3</artifactId>
    <version>2.1.0</version>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-aop</artifactId>
</dependency>

AOP cho phép thư viện can thiệp vào các lệnh gọi phương thức của bạn. Nó bao bọc logic nghiệp vụ bằng các decorator có khả năng phục hồi mà không làm cho mã nguồn của bạn trở nên rối rắm với các khối try-catch.

Cấu hình thực tế: Các thiết lập thực tiễn

Cấu hình mặc định hiếm khi đủ cho môi trường production. Bạn cần cân bằng giữa độ nhạy và sự ổn định. Hãy cùng xem cách cấu hình ba trụ cột của khả năng phục hồi (resiliency).

1. Circuit Breaker (Bộ ngắt mạch)

Hãy coi đây như một chiếc cầu chì thông minh. Khi tỷ lệ lỗi đạt đến một mức phần trăm nhất định, mạch sẽ “mở” (open). Tất cả các cuộc gọi tiếp theo sẽ thất bại ngay lập tức (fail fast). Điều này giúp dịch vụ phía dưới (downstream service) có cơ hội để “thở” và phục hồi thay vì tiếp tục bị dồn dập bởi các yêu cầu mới.

resilience4j.circuitbreaker:
  instances:
    inventoryService:
      registerHealthIndicator: true
      slidingWindowSize: 20
      permittedNumberOfCallsInHalfOpenState: 5
      slidingWindowType: COUNT_BASED
      minimumNumberOfCalls: 10
      waitDurationInOpenState: 30s
      failureRateThreshold: 50

Trong ví dụ này, chúng ta xem xét 20 cuộc gọi gần nhất. Nếu từ 10 cuộc gọi trở lên thất bại (50%), mạch sẽ ngắt. Tôi khuyên dùng waitDurationInOpenState ít nhất là 30 giây. Các khoảng thời gian ngắn thường dẫn đến tình trạng “chập chờn” (flapping), nơi mạch đóng và mở quá nhanh, không đủ thời gian để hệ thống thực sự phục hồi.

2. Smart Retry với Exponential Backoff

Không phải lỗi nào cũng nghiêm trọng. Lỗi 503 Service Unavailable có thể chỉ là một sự cố tạm thời. Tuy nhiên, việc thử lại (retry) ngay lập tức có thể dẫn đến “cơn bão retry” (retry storm). Điều này xảy ra khi hàng nghìn client cùng thử lại tại cùng một mili giây, vô tình tạo ra một cuộc tấn công DDoS vào chính server của bạn.

resilience4j.retry:
  instances:
    inventoryService:
      maxAttempts: 3
      waitDuration: 500ms
      enableExponentialBackoff: true
      exponentialBackoffMultiplier: 2
      retryExceptions:
        - org.springframework.web.client.HttpServerErrorException
        - java.io.IOException

Cấu hình này giúp giãn cách các lần thử lại. Lần retry đầu tiên xảy ra sau 500ms, lần thứ hai sau 1000ms. Cách tiếp cận so le này là yếu tố sống còn để khôi phục sức khỏe hệ thống trong các sự kiện có độ đồng thời cao.

3. Rate Limiter (Bộ giới hạn tốc độ)

Trong khi Circuit Breaker bảo vệ bạn khỏi các dịch vụ khác, Rate Limiter bảo vệ bạn khỏi chính mình — hoặc từ phía client. Hãy sử dụng nó để ngăn chặn một vòng lặp lỗi từ phía frontend tiêu tốn toàn bộ tài nguyên backend của bạn.

resilience4j.ratelimiter:
  instances:
    inventoryService:
      limitForPeriod: 100
      limitRefreshPeriod: 1s
      timeoutDuration: 0

Ở đây, chúng ta cho phép 100 request mỗi giây. Bằng cách đặt timeoutDuration là 0, chúng ta yêu cầu hệ thống từ chối lưu lượng dư thừa ngay lập tức. Việc chờ đợi trong hàng đợi thường chỉ làm dịch chuyển điểm nghẽn lên phía trên của luồng xử lý.

Triển khai và Thứ tự Annotation

Áp dụng các pattern này đơn giản là thêm annotation vào lớp Service hoặc Client của bạn. Tuy nhiên, thứ tự thực thi là cực kỳ quan trọng. Theo mặc định, Resilience4j áp dụng Retry bao quanh Circuit Breaker.

@Service
public class InventoryClient {

    @CircuitBreaker(name = "inventoryService", fallbackMethod = "getInventoryFallback")
    @Retry(name = "inventoryService")
    @RateLimiter(name = "inventoryService")
    public String checkStock(String productId) {
        return restTemplate.getForObject("/api/stock/" + productId, String.class);
    }

    public String getInventoryFallback(String productId, Exception e) {
        // Ghi log lỗi: Dịch vụ kho không khả dụng cho sản phẩm {}. Lỗi: {}
        logger.error("Inventory service unavailable for product {}. Error: {}", productId, e.getMessage());
        return "Không xác định được tình trạng tồn kho";
    }
}

Nếu Retry nằm ở lớp ngoài, nó sẽ thử gọi ba lần trước khi Circuit Breaker kịp ghi nhận một lỗi duy nhất. Đây thường là điều bạn mong muốn. Nó đảm bảo rằng mạch chỉ ngắt khi nhiều lần thử lại đã thất bại trên các request khác nhau.

Khả năng quan sát: Đừng vận hành trong bóng tối

Một bộ ngắt mạch bị ngắt trong im lặng là cơn ác mộng đối với DevOps. Bạn phải hiển thị các sự kiện này lên hệ thống giám sát. Resilience4j tích hợp sẵn với Spring Boot Actuator và Micrometer.

Hiển thị các endpoint cần thiết trong cấu hình của bạn:

management:
  endpoints:
    web:
      exposure:
        include: health, metrics, resilience4jevents
  health:
    circuitbreakers: enabled

Sau khi được kích hoạt, bạn có thể đẩy các chỉ số (metrics) này vào Prometheus. Hãy tìm kiếm resilience4j_circuitbreaker_state. Trong Grafana, tôi luôn thiết lập cảnh báo (alert) để kích hoạt nếu một mạch ở trạng thái “Open” trong hơn 5 phút. Điều này thường cho thấy một sự cố nghiêm trọng ở dịch vụ phía dưới cần sự can thiệp thủ công.

Xây dựng hệ thống bền bỉ là việc chấp nhận rằng thất bại là điều không thể tránh khỏi. Bằng cách kết hợp ba pattern này, bạn biến một kiến trúc mong manh thành một kiến trúc mạnh mẽ. Các dịch vụ của bạn sẽ vẫn đứng vững ngay cả khi mạng lưới bên dưới đang gặp sự cố.