Xây dựng Ứng dụng Bền vững với Hystrix: Fallback, Timeout và hơn thế nữa | Java Spring Roadmap

Lời giới thiệu: Tại sao Sự bền vững lại quan trọng trong Hệ thống Phân tán?

Chào mừng trở lại với series Java Spring Roadmap! Trên hành trình khám phá và làm chủ Spring Framework, chúng ta đã đi qua nhiều chặng đường quan trọng: từ những kiến thức cơ bản về lý do chọn Spring, thuật ngữ cốt lõi, kiến trúc hoạt động, cho đến các chủ đề nâng cao hơn như Dependency Injection, Spring IoC, Spring AOP, Spring MVC, Annotations, Bean Scopes, Bảo mật với Spring Security (bao gồm cả Authentication, RBAC, OAuth2, JWT), và làm quen với Spring Boot thông qua Starters, Autoconfiguration, Actuator, Tomcat nhúng, và cả thế giới dữ liệu với Hibernate/JPA basics, Transactions, JPA Relationships, Entity Lifecycle Events.

Trong môi trường phát triển hiện đại, đặc biệt khi chuyển sang kiến trúc Microservices với sự hỗ trợ của Spring Cloud (chúng ta đã tìm hiểu về Spring Cloud Gateway, Spring Cloud Config, Circuit Breaker cơ bản, và OpenFeign), các ứng dụng của chúng ta ngày càng phụ thuộc vào nhiều dịch vụ và hệ thống bên ngoài (ví dụ: database, dịch vụ API của bên thứ ba, các microservice khác).

Điều gì sẽ xảy ra nếu một trong những dịch vụ đó gặp sự cố? Nó chậm chạp? Nó không phản hồi? Hoặc tệ hơn, nó sập hoàn toàn? Nếu ứng dụng của chúng ta không được thiết kế để xử lý những tình huống này một cách gracefully, một lỗi nhỏ ở một nơi có thể nhanh chóng lan rộng và làm sập toàn bộ hệ thống. Đây chính là lúc khái niệm Sự bền vững (Resilience) trở nên cực kỳ quan trọng.

Sự bền vững trong kiến trúc phần mềm là khả năng của hệ thống phục hồi từ thất bại và vẫn tiếp tục hoạt động ở một mức độ chấp nhận được. Nó không có nghĩa là hệ thống sẽ không bao giờ thất bại, mà là khi thất bại xảy ra, hệ thống có thể:

• Phát hiện lỗi nhanh chóng.
• Ngăn chặn lỗi lan rộng.
• Giảm thiểu ảnh hưởng đến người dùng.
• Phục hồi lại trạng thái hoạt động bình thường một cách tự động (hoặc bán tự động).

Trong bài viết này, chúng ta sẽ tập trung vào một thư viện đã từng rất phổ biến trong hệ sinh thái Spring Cloud Netflix để giúp xây dựng các ứng dụng bền vững: Hystrix. Mặc dù Hystrix hiện tại đã ở chế độ bảo trì và có những lựa chọn thay thế hiện đại hơn như Resilience4j (mà chúng ta đã chạm nhẹ trong bài Xử Lý Thất Bại Với Circuit Breaker Trong Spring Cloud), việc tìm hiểu Hystrix vẫn cực kỳ giá trị vì nó đã phổ biến hóa và định hình các mẫu thiết kế (patterns) quan trọng cho sự bền vững trong môi trường phân tán.

Hãy cùng đi sâu vào Hystrix và cách nó giúp chúng ta xây dựng những ứng dụng mạnh mẽ hơn!

Hystrix là gì và tại sao nó lại quan trọng?

Hystrix là một thư viện mã nguồn mở được phát triển bởi Netflix. Mục đích chính của Hystrix là kiểm soát sự tương tác giữa các thành phần trong hệ thống phân tán bằng cách cung cấp latency (độ trễ) và fault tolerance (khả năng chịu lỗi). Nói cách khác, Hystrix giúp ứng dụng của bạn không bị sập khi một dịch vụ mà nó phụ thuộc vào gặp vấn đề.

Các vấn đề điển hình mà Hystrix giúp giải quyết bao gồm:

• Các dịch vụ phụ thuộc chậm chạp: Một dịch vụ bên ngoài phản hồi quá lâu, làm tắc nghẽn các luồng (threads) trong ứng dụng của bạn, dẫn đến tài nguyên bị cạn kiệt và toàn bộ ứng dụng trở nên không phản hồi.
• Các dịch vụ phụ thuộc gặp lỗi liên tục: Một dịch vụ bị lỗi và trả về lỗi cho mọi yêu cầu. Việc tiếp tục gửi yêu cầu đến dịch vụ bị lỗi này chỉ làm lãng phí tài nguyên và có thể làm trầm trọng thêm vấn đề cho dịch vụ đó.
• Thất bại lan truyền (Cascading failures): Lỗi ở một dịch vụ lan truyền sang các dịch vụ khác phụ thuộc vào nó, cuối cùng làm sập một phần hoặc toàn bộ hệ thống.

Hystrix giải quyết những vấn đề này bằng cách triển khai các mẫu thiết kế (design patterns) cho sự bền vững, nổi bật nhất là Circuit Breaker (Bộ ngắt mạch).

Các Khái niệm Cốt lõi của Hystrix

Hystrix xoay quanh một số khái niệm và mẫu thiết kế chính:

1. Hystrix Command

Mọi tương tác với dịch vụ phụ thuộc (như gọi API, truy vấn database) cần được đóng gói (wrap) trong một đối tượng HystrixCommand (hoặc HystrixObservableCommand cho các tương tác bất đồng bộ). Điều này cho phép Hystrix quản lý việc thực thi, áp dụng các cơ chế như timeout, circuit breaker và fallback.

Trong Spring Cloud Netflix, chúng ta thường không cần tạo HystrixCommand thủ công mà sử dụng annotation @HystrixCommand trên các phương thức cần bảo vệ.

2. Timeout (Thời gian chờ)

Một trong những nguyên nhân phổ biến gây ra thất bại lan truyền là do các cuộc gọi bị chậm hoặc bị treo. Hystrix áp dụng một cơ chế timeout cho mỗi HystrixCommand. Nếu cuộc gọi không hoàn thành trong khoảng thời gian cấu hình, Hystrix sẽ ngắt cuộc gọi và thực hiện logic xử lý lỗi (ví dụ: gọi fallback).

Điều này đảm bảo rằng các tài nguyên (như luồng) không bị chiếm dụng mãi mãi bởi một cuộc gọi chậm, giải phóng chúng để xử lý các yêu cầu khác.

3. Fallback (Phương án dự phòng)

Khi một HystrixCommand gặp lỗi (ví dụ: do timeout, ngoại lệ, bộ ngắt mạch đang mở), Hystrix có thể thực thi một phương thức “fallback” thay thế. Phương thức fallback này nên trả về một giá trị mặc định, một phản hồi cached, hoặc một ngoại lệ đặc biệt để ứng dụng gọi không bị sập và vẫn có thể tiếp tục hoạt động (có thể với chức năng bị giảm bớt).

Fallback là một cách hiệu quả để giảm thiểu tác động của lỗi dịch vụ phụ thuộc đối với trải nghiệm người dùng.

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

Chúng ta đã nói về Circuit Breaker trong bài Xử Lý Thất Bại Với Circuit Breaker Trong Spring Cloud. Hystrix là một trong những thư viện phổ biến nhất triển khai mẫu thiết kế này.

Cách hoạt động cơ bản của bộ ngắt mạch Hystrix:

• CLOSED (Đóng): Các yêu cầu đi qua như bình thường. Hystrix theo dõi tỷ lệ lỗi.
• OPEN (Mở): Nếu tỷ lệ lỗi vượt quá ngưỡng cấu hình trong một khoảng thời gian nhất định, bộ ngắt mạch sẽ chuyển sang trạng thái OPEN. Khi ở trạng thái OPEN, Hystrix sẽ chặn ngay lập tức tất cả các yêu cầu đến dịch vụ phụ thuộc này mà không cần thực sự gọi nó. Thay vào đó, nó sẽ gọi fallback ngay lập tức. Điều này giúp dịch vụ bị lỗi có thời gian phục hồi và ngăn chặn ứng dụng của bạn lãng phí tài nguyên gửi yêu cầu đến một dịch vụ chắc chắn sẽ lỗi.
• HALF-OPEN (Nửa mở): Sau một khoảng thời gian chờ (sleep window) được cấu hình, bộ ngắt mạch chuyển sang trạng thái HALF-OPEN. Hystrix cho phép một số lượng nhỏ yêu cầu đi qua để kiểm tra xem dịch vụ phụ thuộc đã phục hồi chưa. Nếu các yêu cầu này thành công, bộ ngắt mạch chuyển về trạng thái CLOSED. Nếu chúng vẫn thất bại, nó quay lại trạng thái OPEN.

Bộ ngắt mạch là xương sống của Hystrix, giúp hệ thống tự động thích ứng với các vấn đề của dịch vụ phụ thuộc.

5. Bulkhead (Vách ngăn)

Mẫu Bulkhead lấy cảm hứng từ thiết kế của thân tàu. Nếu một khoang tàu bị thủng, các vách ngăn sẽ giới hạn thiệt hại chỉ trong khoang đó, ngăn nước lan ra toàn bộ tàu. Trong phần mềm, Bulkhead nghĩa là cô lập các cuộc gọi đến các dịch vụ phụ thuộc khác nhau để một dịch vụ bị lỗi không làm tiêu hao hết tài nguyên (như luồng) và ảnh hưởng đến khả năng gọi các dịch vụ khỏe mạnh khác.

Hystrix triển khai Bulkhead bằng cách sử dụng các nhóm luồng (thread pools) riêng biệt hoặc Semaphore cho từng HystrixCommand hoặc một nhóm các Command. Nếu nhóm luồng cho một dịch vụ bị cạn kiệt, nó sẽ không ảnh hưởng đến các nhóm luồng khác.

6. Request Caching và Request Collapsing (Nâng cao)

Hystrix còn hỗ trợ caching kết quả yêu cầu để tránh gọi dịch vụ phụ thuộc nhiều lần với cùng một tham số trong cùng một ngữ cảnh (ví dụ: trong cùng một request HTTP). Request Collapsing cho phép gộp nhiều yêu cầu riêng lẻ đến cùng một dịch vụ thành một yêu cầu batch duy nhất, giảm tải cho mạng và dịch vụ phụ thuộc.

Tích hợp Hystrix với Spring Boot và Spring Cloud Netflix

Để sử dụng Hystrix trong ứng dụng Spring Boot, chúng ta cần thêm dependency và cấu hình đơn giản.

Thêm Dependency

Nếu bạn đang sử dụng Spring Cloud Netflix, bạn chỉ cần thêm starter Hystrix:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>

Đảm bảo bạn đã khai báo Spring Cloud Dependency Management trong file POM của mình.

Kích hoạt Hystrix

Thêm annotation @EnableHystrix vào lớp cấu hình Spring Boot chính của bạn:

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.hystrix.EnableHystrix;

@SpringBootApplication
@EnableHystrix // Kích hoạt Hystrix
public class YourApplication {

    public static void main(String[] args) {
        SpringApplication.run(YourApplication.class, args);
    }
}

Triển khai Fallback với @HystrixCommand

Cơ chế phổ biến nhất để sử dụng Hystrix trong Spring là sử dụng annotation @HystrixCommand trên phương thức gọi dịch vụ phụ thuộc.

Ví dụ cơ bản về Fallback

Giả sử bạn có một service gọi một dịch vụ bên ngoài để lấy thông tin sản phẩm:

import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand;
import org.springframework.stereotype.Service;
import org.springframework.web.client.RestTemplate;

@Service
public class ProductService {

    private final RestTemplate restTemplate;

    public ProductService(RestTemplate restTemplate) {
        this.restTemplate = restTemplate;
    }

    @HystrixCommand(fallbackMethod = "getDefaultProduct")
    public String getProductDetails(String productId) {
        // Giả sử đây là cuộc gọi đến dịch vụ bên ngoài
        String url = "http://external-product-service/products/" + productId;
        return restTemplate.getForObject(url, String.class);
    }

    // Phương thức fallback
    public String getDefaultProduct(String productId) {
        // Trả về dữ liệu mặc định khi cuộc gọi chính thất bại
        System.out.println("Falling back to default product for ID: " + productId);
        return "{ \"id\": \"" + productId + "\", \"name\": \"Default Product\", \"price\": 0 }";
    }
}

Trong ví dụ này:

• Phương thức getProductDetails được bảo vệ bởi @HystrixCommand.
• Nếu getProductDetails gặp bất kỳ lỗi nào (như ngoại lệ, timeout, hoặc bộ ngắt mạch mở), Hystrix sẽ tự động gọi phương thức getDefaultProduct.
• Phương thức fallback (getDefaultProduct) phải có cùng chữ ký phương thức (số lượng và kiểu tham số, kiểu trả về) với phương thức chính, hoặc có thêm tham số cuối cùng là Throwable để biết lỗi gì đã xảy ra.

Xử lý Ngoại lệ trong Fallback

Bạn có thể thêm tham số Throwable vào phương thức fallback để biết nguyên nhân lỗi:

    // Phương thức fallback với thông tin lỗi
    public String getDefaultProduct(String productId, Throwable t) {
        System.err.println("Error getting product details for ID: " + productId + ". Cause: " + t.getMessage());
        // Có thể trả về dữ liệu mặc định hoặc throw một ngoại lệ khác
        return "{ \"id\": \"" + productId + "\", \"name\": \"Default Product (Fallback)\", \"price\": 0, \"error\": \"" + t.getMessage() + "\" }";
    }

Cấu hình Timeout

Timeout là một cấu hình mặc định của Hystrix. Nếu bạn không cấu hình gì, Hystrix sẽ sử dụng giá trị mặc định (thường là 1000 ms). Bạn có thể tùy chỉnh timeout bằng cách sử dụng thuộc tính commandProperties trong @HystrixCommand.

import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand;
import com.netflix.hystrix.contrib.javanica.annotation.HystrixProperty;
import org.springframework.stereotype.Service;
import org.springframework.web.client.RestTemplate;

@Service
public class ProductService {

    private final RestTemplate restTemplate;

    public ProductService(RestTemplate restTemplate) {
        this.restTemplate = restTemplate;
    }

    @HystrixCommand(
        fallbackMethod = "getDefaultProduct",
        commandProperties = {
            @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "3000") // Cấu hình Timeout 3000ms (3 giây)
        }
    )
    public String getProductDetails(String productId) {
        String url = "http://external-product-service/products/" + productId;
        return restTemplate.getForObject(url, String.class);
    }

    public String getDefaultProduct(String productId) {
        System.out.println("Falling back due to timeout or error for ID: " + productId);
        return "{ \"id\": \"" + productId + "\", \"name\": \"Default Product\", \"price\": 0 }";
    }
}

Trong ví dụ này, nếu cuộc gọi đến dịch vụ sản phẩm mất hơn 3 giây, Hystrix sẽ ngắt nó và gọi phương thức getDefaultProduct.

Circuit Breaker Hoạt động như thế nào với @HystrixCommand

Khi bạn sử dụng @HystrixCommand, cơ chế Circuit Breaker được tích hợp sẵn và hoạt động tự động. Bạn có thể cấu hình các ngưỡng để điều chỉnh hành vi của nó.

Các thuộc tính cấu hình Circuit Breaker chính

Bộ ngắt mạch có nhiều thuộc tính cấu hình trong @HystrixProperty, ví dụ:

• circuitBreaker.requestVolumeThreshold: Số lượng yêu cầu tối thiểu trong một khoảng thời gian (rolling window) để Hystrix bắt đầu tính toán tỷ lệ lỗi và quyết định mở mạch.
• circuitBreaker.errorThresholdPercentage: Ngưỡng tỷ lệ lỗi (tính bằng phần trăm) mà khi vượt qua, bộ ngắt mạch sẽ chuyển sang trạng thái OPEN.
• circuitBreaker.sleepWindowInMilliseconds: Thời gian (tính bằng ms) mà bộ ngắt mạch ở trạng thái OPEN trước khi chuyển sang HALF-OPEN để kiểm tra.
• metrics.rollingStats.timeInMilliseconds: Khoảng thời gian (tính bằng ms) mà Hystrix thu thập dữ liệu để tính toán tỷ lệ lỗi và các thống kê khác.
• metrics.rollingStats.numBuckets: Số lượng “thùng” (bucket) trong khoảng thời gian rolling stats window.

Ví dụ cấu hình Circuit Breaker

@HystrixCommand(
    fallbackMethod = "getDefaultProduct",
    commandProperties = {
        @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "3000"),
        @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10"), // Cần ít nhất 10 requests trong rolling window
        @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "50"), // Mở mạch nếu tỷ lệ lỗi >= 50%
        @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds", value = "5000"), // Mạch mở trong 5 giây trước khi thử lại
        @HystrixProperty(name = "metrics.rollingStats.timeInMilliseconds", value = "10000"), // Thống kê trong 10 giây gần nhất
        @HystrixProperty(name = "metrics.rollingStats.numBuckets", value = "10") // Chia 10 giây thành 10 bucket (mỗi bucket 1 giây)
    }
)
public String getProductDetails(String productId) {
    // ... (logic gọi dịch vụ)
    String url = "http://external-product-service/products/" + productId;
    return restTemplate.getForObject(url, String.class);
}

Với cấu hình trên, nếu trong 10 giây gần nhất có ít nhất 10 yêu cầu đến getProductDetails và 50% hoặc hơn trong số đó thất bại (do timeout, ngoại lệ…), Hystrix sẽ mở bộ ngắt mạch. Sau đó, trong 5 giây tiếp theo, mọi yêu cầu đến phương thức này sẽ bị chặn ngay lập tức và gọi fallback.

Bulkhead và Isolation Strategies

Hystrix cung cấp hai chiến lược cô lập (isolation strategies) để triển khai Bulkhead:

1. Thread Pool Isolation (Cô lập bằng nhóm luồng)

Mặc định, Hystrix sử dụng Thread Pool Isolation. Mỗi nhóm HystrixCommand (được xác định bởi groupKey hoặc mặc định theo tên class) được gán một nhóm luồng riêng. Kích thước của nhóm luồng này có thể được cấu hình.

@HystrixCommand(
    fallbackMethod = "getDefaultProduct",
    groupKey = "ProductServiceGroup", // Nhóm Command
    commandProperties = {
        @HystrixProperty(name = "execution.isolation.strategy", value = "THREAD") // Mặc định, nhưng có thể khai báo rõ
    },
    threadPoolProperties = {
        @HystrixProperty(name = "coreSize", value = "10") // Kích thước nhóm luồng là 10
    }
)
public String getProductDetails(String productId) {
    // ...
}

Ưu điểm: Cách ly tốt nhất. Một dịch vụ bị chậm sẽ không làm tắc nghẽn các luồng của ứng dụng gọi, vì nó chỉ chiếm dụng luồng trong nhóm luồng riêng của Hystrix cho dịch vụ đó.
Nhược điểm: Tốn tài nguyên (overhead) cho việc chuyển đổi ngữ cảnh giữa các luồng.

2. Semaphore Isolation (Cô lập bằng Semaphore)

Thay vì sử dụng nhóm luồng, Semaphore Isolation giới hạn số lượng yêu cầu đồng thời đến một Command bằng cách sử dụng một bộ đếm Semaphore.

@HystrixCommand(
    fallbackMethod = "getDefaultProduct",
    commandProperties = {
        @HystrixProperty(name = "execution.isolation.strategy", value = "SEMAPHORE"),
        @HystrixProperty(name = "execution.isolation.semaphore.maxConcurrentRequests", value = "20") // Giới hạn 20 yêu cầu đồng thời
    }
)
public String getProductDetails(String productId) {
    // ...
}

Ưu điểm: Ít tốn tài nguyên hơn Thread Pool. Thích hợp cho các cuộc gọi có độ trễ thấp và đáng tin cậy (ví dụ: gọi internal service, truy cập cache).
Nhược điểm: Không cung cấp khả năng timeout ở cấp độ luồng thực thi (vì nó chạy trên luồng của ứng dụng gọi), và không cô lập hoàn toàn luồng. Nếu dịch vụ phụ thuộc bị treo mà không trả về, luồng gọi vẫn bị block.

Lựa chọn chiến lược phụ thuộc vào đặc điểm của dịch vụ phụ thuộc. Thread Pool là lựa chọn an toàn và phổ biến hơn cho các dịch vụ bên ngoài hoặc không đáng tin cậy.

Tổng hợp các Thuộc tính cấu hình HystrixCommand

Dưới đây là bảng tóm tắt một số thuộc tính cấu hình phổ biến nhất cho @HystrixCommand mà chúng ta đã thảo luận:

Bạn có thể cấu hình các thuộc tính này ở cấp Command (như ví dụ trên) hoặc ở cấp global trong application.yml/application.properties để áp dụng cho tất cả các Hystrix Commands.

Giám sát với Hystrix Dashboard (Netflix)

Một phần quan trọng của Hystrix (trong hệ sinh thái Netflix) là Hystrix Dashboard. Nó cung cấp giao diện trực quan để theo dõi trạng thái của các Hystrix Commands: số lượng yêu cầu, tỷ lệ thành công/thất bại, trạng thái bộ ngắt mạch, latency, v.v. Mặc dù việc thiết lập Hystrix Dashboard yêu cầu một chút công sức (thường cần kết hợp với Turbine để gom dữ liệu từ nhiều instance), nó là một công cụ mạnh mẽ để hiểu hành vi bền vững của ứng dụng bạn.

Hystrix và Lựa chọn thay thế hiện đại

Như đã đề cập, Hystrix hiện đang trong chế độ bảo trì và không còn được phát triển tích cực. Spring Cloud đã chuyển sang hỗ trợ các thư viện resilience hiện đại hơn, trong đó nổi bật là Resilience4j. Resilience4j cũng triển khai các mẫu thiết kế tương tự như Circuit Breaker, Rate Limiter (Giới hạn tốc độ), Retry (Thử lại), Bulkhead và Fallback, nhưng với cách tiếp cận dựa trên Function Programming và nhẹ nhàng hơn.

Vậy tại sao chúng ta vẫn học về Hystrix?

• Hiểu biết về mẫu thiết kế: Hystrix đã làm rất tốt việc phổ biến các mẫu thiết kế cho sự bền vững. Việc hiểu Hystrix giúp bạn nắm vững các khái niệm cốt lõi (Circuit Breaker, Fallback, Timeout, Bulkhead) mà sau này bạn sẽ gặp lại trong Resilience4j và các thư viện khác.
• Hệ thống cũ: Nhiều hệ thống microservices hiện có vẫn đang sử dụng Hystrix. Hiểu Hystrix là cần thiết để bảo trì và phát triển các hệ thống này.
• Nền tảng cho các thư viện mới: Resilience4j và các thư viện resilience khác thường kế thừa và cải tiến dựa trên những kinh nghiệm từ Hystrix. Nắm vững Hystrix giúp việc học các thư viện mới dễ dàng hơn.

Vì vậy, đừng coi bài viết này chỉ là về một thư viện cũ. Hãy coi nó là bài học về các nguyên tắc thiết kế cho sự bền vững, được minh họa bằng một thư viện đã từng rất có ảnh hưởng.

Kết luận

Trong thế giới hệ thống phân tán và microservices, sự bền vững không còn là một tùy chọn mà là một yêu cầu bắt buộc. Khả năng chống chọi lại sự cố của các dịch vụ phụ thuộc là chìa khóa để duy trì hoạt động ổn định và cung cấp trải nghiệm tốt cho người dùng.

Hystrix, với các cơ chế Timeout, Fallback, Circuit Breaker và Bulkhead, cung cấp một bộ công cụ mạnh mẽ để xây dựng các ứng dụng Java Spring bền vững. Mặc dù có những lựa chọn thay thế hiện đại hơn, việc nắm vững các nguyên tắc và cách triển khai của Hystrix sẽ trang bị cho bạn kiến thức nền tảng vững chắc về resilience patterns.

Trên hành trình Java Spring Roadmap, việc tìm hiểu về các khía cạnh hoạt động của hệ thống phân tán như Resilience là bước đi tự nhiên sau khi làm quen với việc kết nối và tương tác giữa các dịch vụ.

Hãy thử nghiệm Hystrix (hoặc Resilience4j) trong các dự án của bạn để cảm nhận rõ hơn sức mạnh của sự bền vững. Đừng ngại thất bại trong môi trường phát triển, vì đó là cách tốt nhất để học cách hệ thống của bạn phản ứng và làm thế nào để làm cho nó mạnh mẽ hơn!

Hẹn gặp lại các bạn trong những bài viết tiếp theo của series, khi chúng ta sẽ tiếp tục khám phá những khía cạnh thú vị khác của Java Spring Framework và hệ sinh thái Spring Cloud!