# Phục hồi ứng dụng trong Microservices (Resilience in Microservices) ## 1. Giới thiệu Trong môi trường Microservices, việc phục hồi ứng dụng là một vấn đề quan trọng. Một số vấn đề có thể xảy ra như: một số service không hoạt động, mạng không ổn định, lỗi xảy ra khi gọi service khác, ... Để giải quyết vấn đề này, chúng ta cần phải xây dựng một hệ thống có khả năng phục hồi khi xảy ra lỗi. Để giải quyết vấn đề này, chúng ta cần phải xây dựng một hệ thống có khả năng phục hồi khi xảy ra lỗi. Có một số cách để giải quyết vấn đề này như: Circuit Breaker, Retry, Timeout, Bulkhead, ... Trong bài viết này, chúng ta sẽ tìm hiểu về các cách giải quyết vấn đề phục hồi ứng dụng trong môi trường Microservices. Công cụ sử dụng: `Resilience4j` - một thư viện Java giúp xây dựng các cơ chế phục hồi ứng dụng. [Resilience4j](https://resilience4j.readme.io/docs/getting-started-6) ## 2. Circuit Breaker `Circuit Breaker` là một cơ chế giúp hệ thống `tự động ngắt kết nối` tới một `service` khi service đó `gặp lỗi`. Khi service bị lỗi, `Circuit Breaker` sẽ ngắt kết nối tới service đó và trả về một giá trị mặc định hoặc báo lỗi. Khi service đã được sửa, `Circuit Breaker` sẽ mở lại kết nối tới service đó. Lợi ích của `Circuit Breaker`: - `Fail fast`: Nhận biết lỗi nhanh chóng và ngắt kết nối tới service đó. - `Fail gracefully`: Làm giảm áp lực cho service khác khi service đó gặp lỗi. - `Recovery seamlessly`: Khi service đã được sửa, `Circuit Breaker` sẽ mở lại kết nối tới service đó. ### 2.1. 3 trạng thái của Circuit Breaker Trong `Resilience4j`, `Circuit Breaker` có 3 trạng thái: - `CLOSED`: Khi `Circle Breaker` mới bắt đầu, nó sẽ ở trạng thái `CLOSED`. Trong trạng thái này, `Circuit Breaker` sẽ cho phép gọi tới service từ các request của client. - `OPEN`: Khi service gặp lỗi, ví dụ tỷ lệ lỗi vượt quá một ngưỡng nào đó, `Circuit Breaker` sẽ chuyển sang trạng thái `OPEN`. Trong trạng thái này, `Circuit Breaker` sẽ ngắt kết nối tới service và trả về một giá trị mặc định hoặc báo lỗi. - `HALF_OPEN`: Sau một khoảng thời gian, `Circuit Breaker` sẽ chuyển sang trạng thái `HALF_OPEN`. Trong trạng thái này, `Circuit Breaker` sẽ thử kết nối tới service và cho phép 1 số lượng `request từ client` nhất định. Dần dần tăng lên, nếu tỷ lệ lỗi ở dưỡi ngưỡng cho phép, `Circuit Breaker` sẽ chuyển sang trạng thái `CLOSED`. Nếu kết nối không thành công, `Circuit Breaker` sẽ về lại trạng thái `OPEN`. ### 2.2. Cài đặt Circuit Breaker Để cài đặt `Circuit Breaker` với `Resilience4j`, trước hết chúng ta phải có `Gateway` để quản lý các request từ client. Sau đó, chúng ta cài đặt `Circuit Breaker` cho các service mà `Gateway` gọi tới. >Cách cài đặt `Spring Cloud Gateway` đã được trình bày trong bài `26. Giao tiếp từ bên ngoài vào trong Microsevices` #### 2.2.1. Cài đặt Circuit Breaker trong `Gateway` Cần cài đặt `dependency` của `Resilience4j` trong `pom.xml`: > Lưu ý: Do `Gateway` sử dụng `Spring WebFlux` nên cần cài đặt `circuitbreaker-reactor-resilience4j` thay vì `circuitbreaker-resilience4j`. ```xml org.springframework.cloud spring-cloud-starter-circuitbreaker-reactor-resilience4j ``` Cấu hình `Circuit Breaker` trong `application.yml` của `Gateway Service`: >application.yml ```yml ... ### Cấu hình mặc định cho tất cả các Circuit Breaker resilience4j: circuitbreaker: configs: default: sliding-window-size: 10 # So luong request ma circuit breaker se kiem tra de xem service co bi loi hay khong permitted-number-of-calls-in-half-open-state: 2 # So luong request cho phep khi service dang trong trang thai half-open, de kiem tra service co hoat dong lai hay khong failure-rate-threshold: 50 # Ty le loi cho phep cua service, neu ty le loi > 50% thi circuit breaker OPEN wait-duration-in-open-state: seconds: 10 # Thoi gian cho phep service chuyen sang HALF-OPEN de kiem tra lai service tu khi circuit breaker chuyen sang OPEN ### Cấu hình cho từng Circuit Breaker cụ thể, với tên được đặt trong `route()` của `Gateway service`, sẽ trình bày ở phần sau resilience4j: circuitbreaker: instances: # Cấu hình cho từng Circuit Breaker cụ thể service1: # Ten cua circuit breaker sliding-window-size: 10 # So luong request ma circuit breaker se kiem tra de xem service co bi loi hay khong permitted-number-of-calls-in-half-open-state: 2 # So luong request cho phep khi service dang trong trang thai half-open, de kiem tra service co hoat dong lai hay khong failure-rate-threshold: 50 # Ty le loi cho phep cua service, neu ty le loi > 50% thi circuit breaker OPEN wait-duration-in-open-state: seconds: 10 # Thoi gian cho phep service chuyen sang HALF-OPEN de kiem tra lai service tu khi circuit breaker chuyen sang OPEN ``` Tiếp theo, thêm 1 số cầu hình của `Circuit Breaker` vào trong bộ lọc `filter` của `Spring Cloud Gateway`, để kiểm tra service có bị lỗi hay không: >Application.java ```java @SpringBootApplication public class Application { public static void main(String[] args) { Application.run(Application.class, args); } @Bean public RouteLocator customRouteLocator(RouteLocatorBuilder builder) { return builder.routes() .route("service1", r -> r.path("/service1/**") .filters(f -> f.circuitBreaker(c -> c.setName("service1") // Ten cua circuit breaker .setFallbackUri("forward:/contactSupport") // Duong dan khi service bi loi, đã được định nghĩa trong Controller ) ) .uri("http://localhost:8081")) .build(); } } ``` Sau khi chạy lần lượt `Config Server`, `Euroka Server`, `Service con`, `Gateway`, truy cập vào đường dẫn đại diện cho `Gateway` (ví dụ: `http://localhost:8072/actuator`) để kiểm tra các route của `circuit breaker`. - `http://localhost:8072/actuator/circuitbreakers`: Hiển thị tất cả các `Circuit Breaker` của `Gateway` và trạng thái của chúng. ```json { "circuitBreakers": { "accountsCircuitBreaker": { "failureRate": "-1.0%", // Tỷ lệ lỗi của service "slowCallRate": "-1.0%", // Tỷ lệ gọi service chậm "failureRateThreshold": "50.0%", // Ngưỡng tỷ lệ lỗi "slowCallRateThreshold": "100.0%", // Ngưỡng tỷ lệ gọi service chậm "bufferedCalls": 1, // Số lượng request đã gọi tới service "failedCalls": 0, // Số lượng request gọi tới service bị lỗi "slowCalls": 0, // Số lượng request gọi tới service chậm "slowFailedCalls": 0, // Số lượng request gọi tới service chậm bị lỗi "notPermittedCalls": 0, // Số lượng request không được phép gọi tới service "state": "CLOSED" // Trạng thái của Circuit Breaker } } } ``` - `http://localhost:8072/actuator/circuitbreakerevent/{name_circuitBreaker}`: Hiển thị tất cả các sự kiện của `Circuit Breaker` với tên `name_circuitBreaker`. ```json { "circuitBreakerEvents": [ { "circuitBreakerName": "accountsCircuitBreaker", // Tên của Circuit Breaker "type": "SUCCESS", // Loại sự kiện (SUCCESS, ERROR, IGNORED_ERROR, STATE_TRANSITION) // SUCCESS: Khi request gọi tới service thành công // ERROR: Khi request gọi tới service bị lỗi // IGNORED_ERROR: Khi request gọi tới service bị lỗi nhưng không được xuất ra // STATE_TRANSITION: Khi trạng thái của Circuit Breaker thay đổi (VD: OPEN -> HALF_OPEN) "creationTime": "2024-07-15T01:38:51.070389700+07:00[Asia/Saigon]", // Thời gian tạo sự kiện "errorMessage": null, // Thông báo lỗi "durationInMs": 277, // Thời gian thực hiện request "stateTransition": null // Trạng thái chuyển đổi } ] } ``` Tiếp theo, chúng ta sẽ khai báo đường dẫn `forward:/contactSupport` trong `Controller` để trả về một giá trị mặc định hoặc báo lỗi khi service bị lỗi: >Controller.java ```java @RestController public class CircuitBreakerController { @GetMapping("/contactSupport") Mono contactSupport() { return Mono.just("Service is not available. Please contact support."); } // Trong đó, Object Mono là một kiểu dữ liệu của Reactor, giúp xử lý bất đồng bộ trong Spring WebFlux, với Gateway thì sử dụng Mono // Mono.just() là một phương thức tạo một Mono với giá trị được truyền vào } ``` Như vậy, khi service bị lỗi, `Circuit Breaker` sẽ forward request tới đường dẫn `/contactSupport` và trả về giá trị `Service is not available. Please contact support.` #### 2.2.2. Cài đặt Circuit Breaker trong `Service` con (Chỉ trong `Service 1` giao tiếp với các service khác qua `OpenFeign`) Cài đặt `dependency` của `Resilience4j` trong `pom.xml`, **Lưu ý** dependency này phải được cài đặt trong `Service` con giao tiếp với các service khác qua `OpenFeign`, và khác với `Gateway`, không phải là `circuitbreaker-reactor-resilience4j` mà là `circuitbreaker-resilience4j`: ```xml org.springframework.cloud spring-cloud-starter-circuitbreaker-resilience4j ``` Cấu hình `Circuit Breaker` trong `application.yml` của `Service` con: >application.yml ```yml spring: cloud: openfeign: circuitbreaker: enabled: true # Cho phép sử dụng circuit breaker cho Feign client ## Circuit Breaker Configuration mặc định cho tất cả các Feign Client resilience4j: circuitbreaker: configs: default: sliding-window-size: 10 # So luong request ma circuit breaker se kiem tra de xem service co bi loi hay khong permitted-number-of-calls-in-half-open-state: 2 # So luong request cho phep khi service dang trong trang thai half-open, de kiem tra service co hoat dong lai hay khong failure-rate-threshold: 50 # Ty le loi cho phep cua service, neu ty le loi > 50% thi circuit breaker OPEN wait-duration-in-open-state: seconds: 10 # Thoi gian cho phep service chuyen sang HALF-OPEN de kiem tra lai service tu khi circuit breaker chuyen sang OPEN ## Circuit Breaker Configuration cho từng Feign Client cụ thể, tên Circuit Breaker sẽ được lấy trong params `name` trong @FeignClient resilience4j: circuitbreaker: instances: # Cấu hình cho từng Circuit Breaker cụ thể loans: # Ten cua circuit breaker sliding-window-size: 10 # So luong request ma circuit breaker se kiem tra de xem service co bi loi hay khong permitted-number-of-calls-in-half-open-state: 2 # So luong request cho phep khi service dang trong trang thai half-open, de kiem tra service co hoat dong lai hay khong failure-rate-threshold: 50 # Ty le loi cho phep cua service, neu ty le loi > 50% thi circuit breaker OPEN wait-duration-in-open-state: seconds: 10 # Thoi gian cho phep service chuyen sang HALF-OPEN de kiem tra lai service tu khi circuit breaker chuyen sang OPEN ``` Sau đó, cấu hình `Circuit Breaker` cho `Feign Client` trong `Service` con: - Tạo 1 `Bean` của `FeignClient` implement `Feign Client` để trả về `Fallback` khi service bị lỗi (Lưu ý phải tắt `fallback` của bên `Gateway` thì mới có thể sử dụng `fallback` của `Service` con): >LoansFallback.java ```java @Component // Đánh dấu đây là một Bean public class LoansFallback implements LoansClient { // implement Feign Client @Override // Override phương thức của Feign Client public ResponseEntity fetchLoanDetails(String correlationId, String mobileNumber) { // Logic code để xử lý khi service bị lỗi hoặc trả về null return null; // Method fallback sẽ trả về null, cache, hoặc giá trị mặc định trong database nếu như service loans không hoạt động } } ``` - Cấu hình `Feign Client` để chỉ đến class `Fallback` trong `Service` con: >LoansClient.java ```java @FeignClient(name = "loans", fallback = LoansFallback.class) // fallback = LoansFallback.class: chỉ đến class Fallback trong Service con // name = "loans": Tên của service cần gọi public interface LoansClient { @GetMapping("/loans/{correlationId}/{mobileNumber}") ResponseEntity fetchLoanDetails(@PathVariable String correlationId, @PathVariable String mobileNumber); } ``` Như vậy, khi service `loans` bị lỗi, `Feign Client` sẽ gọi tới class `LoansFallback` để xử lý, trả về giá trị của phương thức `fetchLoanDetails` trong class `LoansFallback`. ## 3. Cấu hình `Http timeout` trong `Gateway` với `Resilience4j circuit breaker` Trong môi trường Microservices, việc cấu hình `Http timeout` là một vấn đề quan trọng. Khi gọi tới một service khác, nếu service đó không trả về kết quả trong thời gian quy định, `Circuit Breaker` sẽ ngắt kết nối tới service đó và trả về một giá trị mặc định hoặc báo lỗi. Nếu không cấu hình `Http timeout`, `Circuit Breaker` sẽ không thể ngắt kết nối tới service đó khi service đó không trả về kết quả trong thời gian quy định. Nó sẽ rơi vào trạng thái chờ vô hạn và gây ra hiện tượng `Thread Blocking`. Để cấu hình `Http timeout` trong `Gateway` với `Resilience4j circuit breaker`, chúng ta cần có 2 cách sau: - **Cách 1:** Cấu hình `Http timeout` với toàn bộ `routes` trong `application.yml` của `Gateway server`: ```yml spring: cloud: gateway: httpclient: connect-timeout: 10000 # Thời gian tối đa để kết nối tới service (10 giây) response-timeout: 5s # Thời gian tối đa để nhận kết quả từ service (5 giây) ``` - **Cách 2:** Cấu hình `Http timeout` với từng `route` trong `filter` của `Gateway Server`: >Application.java ```java @SpringBootApplication public class Application { .... @Bean public RouteLocator customRouteLocator(RouteLocatorBuilder routeBuilder){ return routeLocatorBuilder.routes() // Tạo ra các route .route(p -> p.path("/didan/accounts/**") // Đường dẫn của route .filters(f -> f.rewritePath("/didan/accounts/(?.*)", "/${remaining}") // Rewrite đường dẫn .addRequestHeader("X-TIME", LocalTime.now().toString()) // Thêm header vào request .metadata(RESPONSE_TIMEOUT_ATTR, 200) // Cấu hình Http timeout cho route, thời gian tối đa để nhận kết quả từ service (200ms) .metadata(CONNECT_TIMEOUT_ATTR, 200) // Cấu hình Http timeout cho route, thời gian tối đa để kết nối tới service (200ms) ) ) .build(); } } ``` > Lưu ý: Nếu trong `filter` của `Gateway` thêm cấu hình `circutBreaker` vào `1 route` nào đó, thì `service của route đó` sẽ sử dụng `Http timeout` mặc định của `filter` chứ không phải của `application.yml` hay `metadata` của filter. > Nếu cầu hình trong `metadata` của `filter` với các giá trị là `âm` thì có nghĩa sẽ tắt `Http timeout` cho `route` đó và khi nếu có lỗi xảy ra, `Circuit Breaker` sẽ không thể ngắt kết nối tới service đó mà sẽ rơi vào trạng thái chờ vô hạn. ## 4. Custom `Response Time` cho `Circuit Breaker` (Mặc định là 1s) Trong `Resilience4j`, `Circuit Breaker` có một `Response Time` mặc định là `1s`. Nếu `Response Time` của service vượt quá `1s`, `Circuit Breaker` sẽ ngắt kết nối tới service đó và trả về một giá trị mặc định hoặc báo lỗi. Vì vậy, ví dụ để kết hợp giữa `Circle Breaker` và `Http timeout`, chúng ta cần cấu hình `Response Time` cho `Circuit Breaker` sao cho `Response Time` lớn hơn `Http timeout`. Ví dụ: Nếu `Http timeout` là `2s`, thì `Response Time` của `Circuit Breaker` cần phải lớn hơn `2s`. Để cấu hình `Response Time` cho `Circuit Breaker`, chúng ta cần tạo 1 `Bean` trong `Gateway Server`: >Application.java ```java import org.springframework.cloud.client.circuitbreaker.Customizer; @SpringBootApplication public class Application { .... @Bean public Customizer globalCustomConfiguration() { return factory -> factory.configureDefault(id -> new Resilience4JConfigBuilder(id) .timeLimiterConfig(TimeLimiterConfig.custom().timeoutDuration(Duration.ofSeconds(3)).build()) // Cấu hình Response Time cho Circuit Breaker (3s) .circuitBreakerConfig(CircuitBreakerConfig.ofDefaults()) // Còn lại các cấu hình khác lấy mặc định .build()); } } ``` ## 5. Retry Pattern (`Mô hình thử lại`) `Retry Pattern` là một mô hình giúp hệ thống `thử lại` một số lần khi gọi tới service khác gặp lỗi về `kết nối mạng`, `lỗi từ service`, `lỗi từ database`, `exception`, ... Khi service gặp lỗi, `Retry Pattern` sẽ thử lại một số lần nào đó trước khi báo lỗi. Dưới đây là 1 số `key components` và những thứ cần xem xét khi triển khai `Retry Pattern`: 1. **`Retry Logic`**: Xác định `thời điểm` và `số lần thử lại` một thao tác. Điều này `dựa` trên các yếu tố như `mã lỗi`, `ngoại lệ` hoặc `trạng thái phản hồi`. 2. **`Backoff Strategy`**: Xác định `chiến lược trì hoãn` việc thử lại để `tránh` làm `quá tải` hệ thống. Chiến lược này có thể `liên quan` đến việc `tăng dần độ trễ` giữa mỗi lần thử lại, được gọi là `thời gian chờ theo cấp số nhân`. 3. **`Circuit Breaker Integration`**: `Kết hợp` với `Circuit Breaker` nếu một số lần thử lại nhất định không thành công liên tiếp, `Circuit` sẽ chuyển sang `OPEN` và `ngăn chặn` việc thử lại. 4. **`Idempotent Operations`**: `Đảm bảo` rằng hoạt động `thử lại` là `bình thường` và `an toàn` khi thực hiện rất nhiều lần mà không gây ra `tác dụng phụ` hoặc `hoạt động trùng lặp`. ### 5.1. Cấu hình `Retry Pattern` với `Resilience4j` ở `Gateway Server` Để cấu hình `Retry Pattern` với `Resilience4j` ở `Gateway Server`, chúng ta cần thêm các lệnh `retry`,... sau vào `filter` của `Gateway`: >Application.java ```java @SpringBootApplication public class Application { .... @Bean public RouteLocator customRouteLocator(RouteLocatorBuilder routeBuilder){ return routeLocatorBuilder.routes() // Tạo ra các route .route(p -> p .path("/didan/accounts/**") // Đường dẫn của route .filters(f -> f .rewritePath("/didan/accounts/(?.*)", "/${remaining}") // Rewrite đường dẫn .addRequestHeader("X-TIME", LocalTime.now().toString()) // Thêm header vào request .retry(retryConfig -> retryConfig .setRetries(4) // Sử dụng Retry, thử lại 4 lần nếu lần đầu không thành công .setMethods(HttpMethod.GET) // Chỉ thử lại với method GET .setBackoff(Duration.ofMillis(100), Duration.ofMillis(1000), 2, true) // Thời gian giữa các lần thử lại // param 1 - firstBackoff: thời gian mà gateway sẽ chờ trước khi thử lại lần đầu tiên // param 2 - maxBackoff: thời gian tối đa mà gateway sẽ chờ trước khi thử lại lần cuối cùng, nếu vượt quá thì sẽ trả về lỗi (ngăn chặn việc cấp số nhân lên vô hạn) // param 3 - factor: hệ số tăng thời gian giữa các lần thử lại (backoff = backoff * factor) // param 4 - basedOnPreviousValue: true - dựa trên giá trị thời gian giữa các lần thử lại trước đó, // false - dựa trên giá trị thời gian giữa lần thử lại đầu tiên và lần thử lại thứ 2 )) ) .build(); } } ``` Như vậy, ví dụ khi gọi tới service `didan/accounts` gặp lỗi, `Gateway` sẽ thử lại 3 lần tiếp theo với `method GET` và `thời gian giữa các lần thử lại` là: - Lần đầu gọi api, chờ service không phản hồi trong 2s (`Http timeout`) là `2s`, sau đó gateway sẽ chờ `100ms` trước khi thử lại lần 1. Tổng thời gian là `2.1s`. - Lần 1 gọi api, chờ service không phản hồi trong 2s (`Http timeout`) là `2s`, sau đó gateway sẽ chờ `100ms * 2 (factor) = 200ms` trước khi thử lại lần 2. Tổng thời gian là `2.1s + 2.2s = 4.3s`. - Lần 2 gọi api, chờ service không phản hồi trong 2s (`Http timeout`) là `2s`, sau đó gateway sẽ chờ `200ms * 2(factor) = 400ms` trước khi thử lại lần 3. Tổng thời gian là `4.3s + 2.4s = 6.7s`. - Lần 3 gọi api, chờ service không phản hồi trong 2s (`Http timeout`) là `2s`, sau đó gateway sẽ chờ `400ms * 2(factor) = 800ms` trước khi thử lại lần 4. Tổng thời gian là `6.7s + 2.8s = 9.5s`. > Vì `maxBackoff` là `1000ms` và tối đa thời gian thử lại là `4 lần`, nhưng sau khi thực hiện lần thứ 3, thời gian đã là `9.5s` < `10s`. Nên sau lần thử lại thứ 3, nếu service vẫn không phản hồi, `Gateway` sẽ trả về lỗi. Vì nếu thử lại lần thứ 4, thời gian giữa các lần thử lại sẽ vượt quá `1000ms`. ### 5.2. Cấu hình `Retry Pattern` với `Resilience4j` ở `Service` con Lợi thế khi cấu hình `Retry Pattern` ở `Service` con là có thể `tùy chỉnh` `Retry Pattern` cho từng `service` mà không ảnh hưởng đến các `service` khác. Chúng ta cũng có thê trả lại 1 `backup` hoặc `giá trị mặc định` nếu service không phản hồi sau một số lần thử lại. Để cấu hình `Retry Pattern` với `Resilience4j` ở `Service` con, chúng ta cần làm các bước sau: 1. Thêm Annotation `@Retry` vào `Controller` của `Service` con, với `name` là tên của `Retry`, `fallbackMethod` là phương thức `fallback` khi service không phản hồi sau một số lần thử lại: > Controller.java ```java ... @Retry(name = "getContactInfo", fallbackMethod = "getContactInfoFallback") @GetMapping("contact-info") public ResponseEntity getContactInfo() { return ResponseEntity .status(HttpStatus.OK) .body(contactInfoDto); } ``` 2. Tạo phương thức `fallback` trong `Controller` của `Service` con, phương thức này sẽ trả về `backup` hoặc `giá trị mặc định` khi service không phản hồi sau một số lần thử lại. > Lưu ý, phương thức `fallback` phải có `signature` giống với phương thức gốc, **chỉ khác** ở chỗ `tên method`, `params` của method có thêm tham số `Throwable` để xử lý lỗi và không có `annotation method HTTP`: > Controller.java ```java ... public ResponseEntity getContactInfo() { return ResponseEntity .status(HttpStatus.OK) .body("Service is not available. Please contact support."); } ``` 3. Cấu hình `Retry Pattern` trong `application.yml` của `Service` con: > application.yml ```yml ## Cấu hình Retry Pattern ở chế độ mặc định cho tất cả fallback method retry resilience4j.retry: configs: default: max-attempts: 3 # Số lần thử lại khi gọi service bị lỗi wait-duration: 500 # Thời gian chờ giữa các lần thử lại (500 nanos = 0.5s) enable-exponential-backoff: true # Cho phép sử dụng exponential backoff, cấp số nhân sau mỗi lần thử lại exponential-backoff-multiplier: 2.0 # Cấp số nhân sau mỗi lần thử lại (2.0 = 2 lần) ignore-exceptions: - java.lang.NullPointerException # Bỏ qua exception nếu gặp exception này, sẽ nhảy vào fallback method luôn mà không thử lại retry-exceptions: - java.util.concurrent.TimeoutException # Sẽ thử lại nếu gặp exception này (TimeoutException) ## Cấu hình Retry Pattern cho từng service cụ thể, với tên được đặt trong @Retry của Controller của Service con resilience4j.retry: instances: # Cấu hình cho từng Retry Pattern cụ thể getContactInfo: # Tên của Retry Pattern max-attempts: 3 # Số lần thử lại khi gọi service bị lỗi wait-duration: nanos: 500 # Thời gian chờ giữa các lần thử lại (500 nanos = 0.5s) enable-exponential-backoff: true # Cho phép sử dụng exponential backoff, cấp số nhân sau mỗi lần thử lại exponential-backoff-multiplier: 2.0 # Cấp số nhân sau mỗi lần thử lại (2.0 = 2 lần) ignore-exceptions: - java.lang.NullPointerException # Bỏ qua exception nếu gặp exception này, sẽ nhảy vào fallback method luôn mà không thử lại retry-exceptions: - java.util.concurrent.TimeoutException # Sẽ thử lại nếu gặp exception này (TimeoutException) ``` > Lưu ý: Nếu cấu hình `max-attempts` là `3` trong `Service` con, thì sẽ thực hiện tổng cộng chỉ `3 lần` để gọi `api` chính, nếu vẫn lỗi, thì lần thứ 4 nó sẽ gọi `methid fallback`. > Lưu ý: Cấu hình `wait-duration` trong `Service` con phải nhỏ hơn `response timeout` của `circuit breaker` trong `Gateway` để tránh bị `circut breaker` setFallbck trước khi `retry` hoàn thành do `timeout` ở `Service con` đã lớn hơn `timeout` ở `Gateway`. Để khắc phục, xem phần **## 4. Custom `Response Time` cho `Circuit Breaker` (Mặc định là 1s)**. ## 6. Rate Limiter Pattern (`Mô hình giới hạn tốc độ`) `Rate Limiter Pattern` trong microservices là mẫu thiết kế giúp `kiểm soát` và `giới hạn tốc độ` request gửi đến service hoặc API. Nó được sử dụng để `ngăn chặn lạm dụng`, `bảo vệ tài nguyên` hệ thống và `đảm bảo sử dụng` dịch vụ một cách `hợp lý`. Trong kiến trúc microservice, nhiều dịch vụ có thể phụ thuộc vào nhau và đưa ra yêu cầu liên lạc. Tuy nhiên, các yêu cầu không bị hạn chế và không được kiểm soát có thể dẫn đến suy giảm hiệu suất, cạn kiệt tài nguyên và các cuộc tấn công từ chối dịch vụ (DoS) tiềm ẩn. `Rate Limiter Pattern` cung cấp một cơ chế để thực thi các giới hạn về tốc độ của các yêu cầu gửi đến. Việc triển khai `Rate Limiter Pattern` giúp `bảo vệ` microservices khỏi bị choáng ngợp bởi các yêu cầu quá mức hoặc độc hại. Nó đảm bảo tính ổn định, hiệu suất và tính khả dụng của hệ thống đồng thời cung cấp quyền truy cập có kiểm soát vào các tài nguyên. Bằng cách thực thi các giới hạn tỷ lệ, `Rate Limiter Pattern` giúp duy trì một môi trường công bằng và đáng tin cậy cho cả nhà cung cấp dịch vụ và người tiêu dùng. Khi `người dùng vượt quá số lượng yêu cầu được phép` trong khung thời gian được chỉ định, mọi yêu cầu bổ sung sẽ bị từ chối với trạng thái `HTTP 429 - Quá nhiều yêu cầu`. Giới hạn cụ thể được thực thi dựa trên chiến lược đã chọn, chẳng hạn: - `Giới hạn yêu cầu trên mỗi phiên`: Số lượng yêu cầu tối đa mà một người dùng có thể gửi trong một phiên. - `Giới hạn yêu cầu trên địa chỉ IP`: Số lượng yêu cầu tối đa mà một địa chỉ IP có thể gửi trong một khoảng thời gian nhất định. - `Giới hạn yêu cầu đối với người dùng hoặc đối tượng thuê`: Số lượng yêu cầu tối đa mà một người dùng hoặc đối tượng thuê có thể gửi trong một khoảng thời gian nhất định. >Mục tiêu chính là duy trì tính khả dụng của hệ thống cho tất cả người dùng, đặc biệt là trong những hoàn cảnh khó khăn. Điều này thể hiện bản chất của khả năng phục hồi. Ngoài ra, `Rate Limiter Pattern` có lợi cho việc cung cấp dịch vụ cho người dùng dựa trên cấp độ đăng ký của họ. Ví dụ: giới hạn tỷ lệ riêng biệt có thể được xác định cho người dùng cơ bản, cao cấp và doanh nghiệp. Để triển khai `Rate Limiter Pattern` trong `Spring Cloud Gateway`, chúng ta sẽ thực hiện với `Redis Rate Limiter` và sau đây là các bước. ### 6.1. Cài đặt `dependency` của `Redis Reactive` trong `Gateway Server` ```xml org.springframework.boot spring-boot-starter-data-redis-reactive ``` ### 6.2. Tạo `Bean` trong `Gateway Server` để cấu hình `Rate Limiter` Chúng ta có 3 tham số của `RedisRateLimiter` cần cấu hình: - `defaultReplenishRate`: Số lần request được phép thực hiện (số lượng tokens được thêm vào thùng bucket) trong 1s (cho biết tốc độ lấp đầy bucket). - `defaultBurstCapacity`: Số lượng tokens tối đa mà bucket có thể chứa (cho biết dung lượng của bucket), (nếu bằng 0 thì sẽ không có request nào được phép truy cập). Sau 1s, bucket sẽ tăng số tokens theo `defaultReplenishRate`. - `defaultRequestedTokens`: Giá mà mỗi 1 request phải trả để truy cập vào hệ thống (mặc định là 1 tokens). >Application.java ```java @SpringBootApplication ... // Rate Limiter @Bean public RedisRateLimiter redisRateLimiter() { return new RedisRateLimiter(1, 1, 1); // param 1 - defaultReplenishRate: số lần request được phép thực hiện (số lượng tokens được thêm vào thùng bucket) trong 1s (cho biết tốc độ lấp đầy bucket) // param 2 - defaultBurstCapacity: số lượng tokens tối đa mà bucket có thể chứa (cho biết dung lượng của bucket), (nếu bằng 0 thì sẽ không có request nào được phép truy cập) // param 3 - defaultRequestedTokens: giá mà mỗi 1 request phải trả để truy cập vào hệ thống (mặc định là 1 tokens), // tokens sẽ được lấy từ bucket đã được định size ở burstCapacity, cứ sau 1s thì burstCapacity sẽ được thêm số tokens theo replenishRate // Ví dụ: param 1 = 1, param 2 = 60, param 3 = 60 => Khi thực hiện 1 request, sẽ trừ 60 tokens từ bucket, sau 1s thì bucket sẽ thêm 1 tokens => 60s sau mới thực hiện request tiếp theo } ``` ### 6.3. Cấu hình chiến lược `KeyResolver` cho `Rate Limiter` trong `Gateway Server` `KeyResolver` là một chiến lược giúp xác định `key` để `Rate Limiter` sử dụng để xác định `thông tin` của `request` (VD: `IP`, `User`, `Session`, `Token`, `...). Chúng ta có thể sử dụng `KeyResolver` để xác định `key` dựa trên `IP`, `User`, `Session`, `Token`, `... hoặc bất kỳ thông tin nào khác). Ví dụ theo `user`: >Application.java ```java @SpringBootApplication ... // Tạo Bean KeyResolver để tạo chiến lược rate limiter, ví dụ theo user @Bean KeyResolver userKeyResolver() { return exchange -> Mono.justOrEmpty(exchange.getRequest().getHeaders().getFirst("user")) // Lấy ra user từ headers, tạo chiến lược rate limiter theo user .defaultIfEmpty("annoymous"); // Nếu không có user thì mặc định là annoymous (không xác định) // Dùng Mono vì trong Gateway là Reactor, mọi thứ đều là bất đồng bộ, Mono giúp xử lý bất đồng bộ và trả về một giá trị } ``` ### 6.5. Áp dụng `Rate Limiter` cho `Route` trong `Gateway Server` Để áp dụng `Rate Limiter` cho `Route` trong `Gateway Server`, chúng ta cần thêm `filter` vào `Route` với `rate limiter` và `key resolver` đã cấu hình ở trên: >Application.java ```java @SpringBootApplication ... @Bean public RouteLocator customRouteLocator(RouteLocatorBuilder routeBuilder){ return routeLocatorBuilder.routes() .route(p -> p .path("/didan/accounts/**") // Đường dẫn của route .filters(f -> f .rewritePath("/didan/accounts/(?.*)", "/${remaining}") .addRequestHeader("X-TIME", LocalTime.now().toString()) .requestRateLimiter(c -> c .setKeyResolver(userKeyResolver()) // Áp dụng chiến lược KeyResolver cho Rate Limiter .setRateLimiter(redisRateLimiter())) // Áp dụng Rate Limiter cho Route )) .build(); } ``` ### 6.4. Cấu hình `Redis` cho `Rate Limiter` trong `Gateway Server` #### 6.4.1. Cài đặt `Redis` trong `Docker` ```sh docker run -d --name redis -p 6379:6379 redis ``` #### 6.4.2. Cấu hình `Redis` trong `application.yml` của `Gateway Server` >application.yml ```yml spring: data: redis: connect-timeout: 2s # Thời gian kết nối tới Redis host: localhost # Địa chỉ IP của Redis port: 6379 # Cổng của Redis timeout: 1s # Thời gian timeout khi gửi request tới Redis ``` ### 6.5 Cài `Apache Bench` để giả lập tạo ra `nhiều request` gửi đến `Gateway` [Apahe Bench](https://www.apachelounge.com/download/#google_vignette) là một công cụ giúp tạo ra `nhiều request` gửi đến `Gateway` để kiểm tra `Rate Limiter` hoạt động như thế nào. Hương dẫn cài đặt `Apache Bench`, tham khảo trên mạng. ### 6.6. Kiểm tra `Rate Limiter` hoạt động - Chạy tất cả các `service` và `Gateway`. - Mở `cmd` trong và chạy lệnh sau để tạo ra `nhiều request` gửi đến `Gateway`: ```sh ./ab -n 10 -c 2 -v 3 http://localhost:8080/didan/accounts/api/fetch ``` Trong đó: - `-n 10`: Số lượng request gửi đến `Gateway` trong 1s. - `-c 2`: Số lượng request gửi đến `Gateway` cùng 1 lúc. - `-v 3`: Hiển thị chi tiết thông tin của request. ## 6.7. Cấu hình `Rate Limiter` cho `Service` con (Tách riêng với `Gateway`) Lợi thế khi cấu hình `Rate Limiter` ở `Service` con là có thể `tùy chỉnh` cho từng `service` mà không ảnh hưởng đến các `service` khác. Chúng ta cũng có thê trả lại 1 `backup` hoặc `giá trị mặc định` nếu service không phản hồi sau một số lần thử lại. Để cấu hình `Rate Limter` với `Resilience4j` ở `Service` con, chúng ta cần làm các bước sau: 1. Thêm Annotation `@RateLimiter` vào `Controller` của `Service` con, với `name` là tên của `RateLimiter`, `fallbackMethod` là phương thức `fallback` khi service không phản hồi sau một số lần thử lại: > Controller.java ```java ... @RateLimiter(name = "getContactInfo", fallbackMethod = "getContactInfoFallback") @GetMapping("contact-info") public ResponseEntity getContactInfo() { return ResponseEntity .status(HttpStatus.OK) .body(contactInfoDto); } ``` 2. Tạo phương thức `fallback` trong `Controller` của `Service` con, phương thức này sẽ trả về `backup` hoặc `giá trị mặc định` khi service vượt quá `Rate Limiter`. > Lưu ý, phương thức `fallback` phải có `signature` giống với phương thức gốc, **chỉ khác** ở chỗ `tên method`, `params` của method có thêm tham số `Throwable` để xử lý lỗi và không có `annotation method HTTP`: > Controller.java ```java ... public ResponseEntity getContactInfo() { return ResponseEntity .status(HttpStatus.OK) .body("Service is not available. Please contact support."); } ``` 3. Cấu hình `Rate` trong `application.yml` của `Service` con: > application.yml ```yml ## Cấu hình Rate Limiter cho tất cả fallback method rate limiter resilience4j.ratelimiter: configs: default: limit-for-period: 1 # Số lần request cho phép trong 1 khoảng thời gian limit-refresh-period: 5000 # Khoảng thời gian reset lại số lần request cho phép (5s) timeout-duration: 1000 # Thời gian chờ cho mỗi request (1s), nếu request không trả về kết quả trong thời gian này, sẽ nhảy về fallback method ## Cấu hình Rate Limiter cho từng service cụ thể, với tên được đặt trong @RateLimiter của Controller của Service con resilience4j.ratelimiter: instances: # Cấu hình cho từng Rate Limiter cụ thể getContactInfo: # Tên của Rate Limiter limit-for-period: 1 # Số lần request cho phép trong 1 khoảng thời gian limit-refresh-period: 5000 # Khoảng thời gian reset lại số lần request cho phép (5s) timeout-duration: 1000 # Thời gian chờ cho mỗi request (1s), nếu request không trả về kết quả trong thời gian này, sẽ nhảy về fallback method ``` ## 7. Aspect Order (`Thứ tự thực thi Aspect`) Mặc định, trong `Resilience4j`, `Aspect` sẽ thực thi theo `thứ tự` sau: 1. `Retry`: Thực hiện `thử lại` khi gặp lỗi. 2. `Circuit Breaker`: Thực hiện `ngắt kết nối` khi gặp lỗi. 3. `Rate Limiter`: Thực hiện `giới hạn tốc độ` khi request vượt quá mức cho phép. 4. `Time Limiter`: Thực hiện `giới hạn thời gian` cho mỗi request. 5. `Bulkhead`: Thực hiện `ngăn vách` cho mỗi request, mỗi luồng `api` để giảm tải cho hệ thống. 6. `Function`: Thực hiện `xử lý` cho mỗi request. Tuy nhiên, chúng ta có thể `điều chỉnh` thứ tự thực thi của `Aspect` bằng cách `cấu hình` trong `application.yml` với thuộc tính `resilience4j.{tên_pattern}.{(tên_Pattern)AspectOrder}: {số thứ tự}`. >VD: application.yml ```yml resilience4j: circuitbreaker: circuitBreakerAspectOrder: 1 retry: retryAspectOrder: 2 ``` ## 8. Tạo file `Docker Compose` để chạy `Resilience4j` và `Gateway Server` + `Microservices` + `Config Server` + `Eureka Server` Tham khảo cách tạo `Image` và thiết lập các cấu hình ở phần `22. Build Image Spring Boot.md` và ở phần `## 5. Tạo Docker Compose cho `Spring Cloud Config Server` + `Service` con` của `24. Spring Cloud Config.md` > Lưu ý: Cần phải bật `Liveness State` và `Readiness State` trong các `Service con` để `Gateway Server` phụ thuộc vào và có thể gọi được các `Service con`. Tránh bị `timeout` khi `Gateway Server` gọi các `Service con`. >docker-compose.yml ```yml services: redis: image: "redis" container_name: redis-ms ports: - "6379:6379" healthcheck: test: ["CMD-SHELL", "redis-cli ping | grep PONG"] # Kiểm tra sức khỏe của Redis Server bằng cách gửi lệnh ping interval: 10s retries: 10 networks: - didan configserver: image: "dannguyenmessi/configserver:v1" container_name: configserver-ms ports: - "8071:8071" healthcheck: test: "curl --fail --silent localhost:8071/actuator/health/readiness | grep UP || exit 1" interval: 10s timeout: 5s retries: 10 start_period: 10s deploy: resources: limits: memory: 700m networks: - didan eurekaserver: image: "dannguyenmessi/eurekaserver:v1" container_name: eurekaserver-ms ports: - "8070:8070" depends_on: configserver: condition: service_healthy healthcheck: test: "curl --fail --silent localhost:8070/actuator/health/readiness | grep UP || exit 1" interval: 10s timeout: 5s retries: 10 start_period: 10s deploy: resources: limits: memory: 700m networks: - didan environment: SPRING_APPLICATION_NAME: "eurekaserver" SPRING_PROFILES_ACTIVE: default SPRING_CONFIG_IMPORT: configserver:http://configserver:8071/ accounts: image: "dannguyenmessi/accounts:v1" container_name: accounts-ms ports: - "8080:8080" healthcheck: test: "curl --fail --silent localhost:8080/actuator/health/readiness | grep UP || exit 1" interval: 10s timeout: 5s retries: 10 start_period: 10s depends_on: configserver: condition: service_healthy eurekaserver: condition: service_healthy deploy: resources: limits: memory: 700m networks: - didan environment: SPRING_APPLICATION_NAME: "accounts" SPRING_PROFILES_ACTIVE: default SPRING_CONFIG_IMPORT: configserver:http://configserver:8071/ EUREKA_CLIENT_SERVICEURL_DEFAULTZONE: http://eurekaserver:8070/eureka/ loans: image: "dannguyenmessi/loans:v1" container_name: loans-ms ports: - "8090:8090" healthcheck: test: "curl --fail --silent localhost:8090/actuator/health/readiness | grep UP || exit 1" interval: 10s timeout: 5s retries: 10 start_period: 10s depends_on: configserver: condition: service_healthy eurekaserver: condition: service_healthy deploy: resources: limits: memory: 700m networks: - didan environment: SPRING_APPLICATION_NAME: "loans" SPRING_PROFILES_ACTIVE: default SPRING_CONFIG_IMPORT: configserver:http://configserver:8071/ EUREKA_CLIENT_SERVICEURL_DEFAULTZONE: http://eurekaserver:8070/eureka/ loans1: image: "dannguyenmessi/loans:v1" container_name: loans-ms1 ports: - "8091:8090" healthcheck: test: "curl --fail --silent localhost:8090/actuator/health/readiness | grep UP || exit 1" interval: 10s timeout: 5s retries: 10 start_period: 10s depends_on: configserver: condition: service_healthy eurekaserver: condition: service_healthy deploy: resources: limits: memory: 700m networks: - didan environment: SPRING_APPLICATION_NAME: "loans" SPRING_PROFILES_ACTIVE: default SPRING_CONFIG_IMPORT: configserver:http://configserver:8071/ EUREKA_CLIENT_SERVICEURL_DEFAULTZONE: http://eurekaserver:8070/eureka/ cards: image: "dannguyenmessi/cards:v1" container_name: cards-ms ports: - "9000:9000" healthcheck: test: "curl --fail --silent localhost:9000/actuator/health/readiness | grep UP || exit 1" interval: 10s timeout: 5s retries: 10 start_period: 10s depends_on: configserver: condition: service_healthy eurekaserver: condition: service_healthy deploy: resources: limits: memory: 700m networks: - didan environment: SPRING_APPLICATION_NAME: "cards" SPRING_PROFILES_ACTIVE: default SPRING_CONFIG_IMPORT: configserver:http://configserver:8071/ EUREKA_CLIENT_SERVICEURL_DEFAULTZONE: http://eurekaserver:8070/eureka/ gatewayserver: image: "dannguyenmessi/gatewaysever:v1" container_name: gatewayserver-ms ports: - "8072:8072" deploy: resources: limits: memory: 700m networks: - didan environment: SPRING_APPLICATION_NAME: "gatewayserver" SPRING_PROFILES_ACTIVE: default SPRING_CONFIG_IMPORT: configserver:http://configserver:8071/ EUREKA_CLIENT_SERVICEURL_DEFAULTZONE: http://eurekaserver:8070/eureka/ SPRING_DATA_REDIS_HOST: redis depends_on: accounts: condition: service_healthy loans: condition: service_healthy loans1: condition: service_healthy cards: condition: service_healthy redis: condition: service_healthy networks: didan: driver: "bridge" ```

Microservices Spring Boot: Phục hồi các services trong môi trường Microservices