Các mẫu thiết kế (design patterns) phổ biến trong kiến trúc Microservices.

1. Mẫu API Gateway (Cổng giao tiếp API)

Giải thích: API Gateway đóng vai trò là một lối vào duy nhất cho tất cả các yêu cầu từ phía client (ví dụ: ứng dụng di động, trình duyệt web). Thay vì client gọi trực tiếp đến từng microservice riêng lẻ, nó sẽ gửi yêu cầu đến API Gateway. Gateway sau đó sẽ định tuyến yêu cầu đến dịch vụ phù hợp, đồng thời có thể thực hiện các chức năng chung như xác thực, bảo mật, giới hạn tốc độ, và tổng hợp dữ liệu.

Use Case: Ứng dụng Thương mại điện tử hiển thị trang chi tiết sản phẩm

• Bối cảnh: Một ứng dụng mua sắm trên điện thoại cần hiển thị thông tin đầy đủ của một sản phẩm khi người dùng chọn xem. Thông tin này bao gồm: mô tả sản phẩm, hình ảnh, giá hiện tại, số lượng hàng còn trong kho, và các đánh giá của khách hàng.

• Vấn đề: Trong kiến trúc microservices, các thông tin này nằm rải rác ở các dịch vụ khác nhau: Product Service (thông tin cơ bản), Pricing Service (giá), Inventory Service (tồn kho), và Review Service (đánh giá). Nếu ứng dụng di động phải gọi riêng lẻ 4 dịch vụ này, nó sẽ tốn nhiều thời gian, tốn băng thông mạng và làm tăng độ phức tạp cho phía client.

• Giải pháp áp dụng API Gateway:

  1. Ứng dụng di động chỉ gửi một yêu cầu duy nhất đến API Gateway: GET /api/products/{id}/details.

  2. API Gateway nhận yêu cầu, xác thực người dùng (nếu cần).

  3. Gateway sau đó gửi các yêu cầu song song đến Product Service, Pricing Service, Inventory Service, và Review Service.

  4. Gateway nhận phản hồi từ tất cả các dịch vụ này.

  5. Gateway tổng hợp tất cả thông tin thành một phản hồi JSON duy nhất.

  6. Gateway trả phản hồi tổng hợp này về cho ứng dụng di động.

• Kết quả: Ứng dụng di động chỉ cần thực hiện một cuộc gọi mạng, giảm độ trễ, tiết kiệm pin và băng thông. Logic tổng hợp dữ liệu được ẩn khỏi client.

2. Mẫu Service Discovery (Khám phá Dịch vụ)

Giải thích: Trong môi trường microservices động, các phiên bản (instances) của dịch vụ có thể được tạo mới hoặc hủy bỏ liên tục, dẫn đến địa chỉ IP và cổng của chúng thay đổi thường xuyên. Service Discovery giúp các dịch vụ tự động tìm thấy nhau mà không cần cấu hình cứng địa chỉ IP. Nó thường bao gồm một Service Registry (sổ đăng ký dịch vụ) trung tâm, nơi các dịch vụ đăng ký vị trí của mình.

Use Case: Dịch vụ Đặt hàng gọi Dịch vụ Thanh toán trong môi trường đám mây

• Bối cảnh: Order Service (Dịch vụ Đặt hàng) cần gọi Payment Service (Dịch vụ Thanh toán) để xử lý giao dịch khi khách hàng đặt hàng. Hệ thống chạy trên nền tảng đám mây (ví dụ: Kubernetes) nơi Payment Service có thể có nhiều bản sao (instances) và được tự động mở rộng hoặc thu hẹp.

• Vấn đề: Order Service không thể biết trước địa chỉ IP và cổng của các instance Payment Service đang hoạt động vì chúng thay đổi động. Cấu hình cứng địa chỉ IP là không khả thi.

• Giải pháp áp dụng Service Discovery:

  1. Khi các instance của Payment Service khởi động, chúng tự động đăng ký địa chỉ IP và cổng của mình với Service Registry (ví dụ: Netflix Eureka hoặc HashiCorp Consul).

  2. Khi Order Service cần gọi Payment Service, nó hỏi Service Registry: "Cho tôi địa chỉ của dịch vụ Thanh toán".

  3. Service Registry trả về danh sách các địa chỉ IP và cổng của các instance Payment Service đang hoạt động.

  4. Order Service chọn một địa chỉ (thường sử dụng thuật toán cân bằng tải phía client) và thực hiện cuộc gọi trực tiếp đến instance đó.

• Kết quả: Các dịch vụ có thể giao tiếp với nhau một cách linh hoạt và tin cậy ngay cả khi cơ sở hạ tầng mạng thay đổi liên tục. Việc mở rộng hoặc thu hẹp quy mô dịch vụ trở nên dễ dàng.

3. Mẫu Circuit Breaker (Cầu dao ngắt mạch)

Giải thích: Circuit Breaker là một pattern giúp ngăn chặn lỗi dây chuyền (cascading failures) trong hệ thống phân tán. Nó hoạt động giống như một cầu dao điện trong nhà. Khi một dịch vụ mà bạn đang gọi bị lỗi hoặc phản hồi quá chậm liên tục, Circuit Breaker sẽ "ngắt mạch", chặn các cuộc gọi tiếp theo đến dịch vụ đó trong một khoảng thời gian. Đ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 dịch vụ gọi bị treo hoặc quá tải tài nguyên.

Use Case: Hệ thống Ngân hàng xử lý giao dịch trong giờ cao điểm

• Bối cảnh: Một hệ thống ngân hàng có Transaction Service (Dịch vụ Giao dịch) gọi đến Fraud Detection Service (Dịch vụ Phát hiện Gian lận) để kiểm tra mỗi giao dịch trước khi phê duyệt.

• Vấn đề: Trong giờ cao điểm (ví dụ: ngày Black Friday), lượng giao dịch tăng đột biến. Fraud Detection Service bị quá tải và bắt đầu phản hồi rất chậm hoặc trả về lỗi timeout. Nếu Transaction Service cứ tiếp tục gửi yêu cầu và chờ đợi, các luồng (threads) xử lý của nó sẽ bị chiếm dụng hết, dẫn đến toàn bộ hệ thống giao dịch bị chậm hoặc sập (lỗi dây chuyền).

• Giải pháp áp dụng Circuit Breaker:

  1. Transaction Service sử dụng thư viện Circuit Breaker (ví dụ: Resilience4j hoặc Hystrix) để bao bọc các cuộc gọi đến Fraud Detection Service.

  2. Khi Circuit Breaker phát hiện tỷ lệ lỗi hoặc timeout từ Fraud Detection Service vượt quá một ngưỡng nhất định (ví dụ: 50% lỗi trong 10 giây), nó chuyển sang trạng thái Open (Ngắt).

  3. Ở trạng thái Open, mọi cuộc gọi tiếp theo từ Transaction Service đến Fraud Detection Service sẽ bị chặn ngay lập tức mà không cần gửi đi. Transaction Service sẽ nhận được một phản hồi lỗi nhanh chóng hoặc một giá trị mặc định (ví dụ: "Tạm thời không thể kiểm tra gian lận, vui lòng thử lại sau" hoặc phê duyệt giao dịch với hạn mức thấp hơn).

  4. Sau một khoảng thời gian định trước, Circuit Breaker chuyển sang trạng thái Half-Open và cho phép một vài yêu cầu đi qua để kiểm tra xem Fraud Detection Service đã phục hồi chưa.

• Kết quả: Hệ thống giao dịch chính không bị sập do lỗi của dịch vụ phụ thuộc. Tài nguyên được giải phóng, và trải nghiệm người dùng được duy trì (dù có thể ở mức độ giảm cấp) thay vì chờ đợi vô vọng.

4. Mẫu Saga (Quản lý giao dịch phân tán)

Giải thích: Trong microservices, mỗi dịch vụ có cơ sở dữ liệu riêng, làm cho việc quản lý các giao dịch trải dài qua nhiều dịch vụ (distributed transactions) trở nên khó khăn vì không thể sử dụng chuẩn ACID (Atomicity, Consistency, Isolation, Durability) truyền thống. Pattern Saga giải quyết vấn đề này bằng cách chia một giao dịch kinh doanh lớn thành một chuỗi các giao dịch cục bộ nhỏ hơn. Mỗi giao dịch cục bộ cập nhật cơ sở dữ liệu của một dịch vụ và kích hoạt giao dịch tiếp theo thông qua sự kiện (event) hoặc tin nhắn. Nếu một bước thất bại, Saga sẽ thực hiện các giao dịch bù trừ (compensating transactions) để hoàn tác các thay đổi đã thực hiện ở các bước trước đó, đảm bảo tính nhất quán cuối cùng (eventual consistency) của dữ liệu.

Use Case: Quy trình Đặt vé máy bay trực tuyến

• Bối cảnh: Một quy trình đặt vé máy bay bao gồm 3 bước chính được xử lý bởi các dịch vụ khác nhau:

  1. Booking Service: Giữ chỗ trên chuyến bay.

  2. Payment Service: Thực hiện trừ tiền từ thẻ của khách hàng.

  3. Notification Service: Gửi email xác nhận vé và thông tin chuyến bay.

• Vấn đề: Cả 3 bước này phải cùng thành công hoặc cùng thất bại để đảm bảo tính nhất quán dữ liệu. Ví dụ, nếu thanh toán thành công nhưng không gửi được email xác nhận, hệ thống sẽ ở trạng thái không nhất quán. Không thể sử dụng giao dịch cơ sở dữ liệu phân tán (như 2PC) vì hiệu năng kém và ghép nối chặt chẽ các dịch vụ.

• Giải pháp áp dụng Saga (Kiểu Choreography - Điều phối dựa trên sự kiện):

  1. Bước 1: Khách hàng yêu cầu đặt vé. Booking Service tạo một bản ghi đặt chỗ với trạng thái "PENDING" và phát ra sự kiện BookingCreated.

  2. Bước 2: Payment Service lắng nghe sự kiện BookingCreated, thực hiện trừ tiền.

     • Nếu thành công, nó phát ra sự kiện PaymentProcessed.

     • Nếu thất bại (ví dụ: thẻ hết tiền), nó phát ra sự kiện PaymentFailed.

  3. Bước 3 (Kịch bản thành công):

     • Notification Service lắng nghe PaymentProcessed, gửi email, và phát ra sự kiện NotificationSent.

     • Booking Service lắng nghe NotificationSent và cập nhật trạng thái đặt chỗ thành "CONFIRMED".

  4. Bước 4 (Kịch bản thất bại - Giao dịch bù trừ):

     • Giả sử Payment Service thành công nhưng Notification Service bị lỗi khi gửi email. Notification Service sẽ phát ra sự kiện NotificationFailed.

     • Payment Service lắng nghe NotificationFailed và thực hiện giao dịch bù trừ: hoàn lại tiền cho khách hàng. Sau đó phát ra sự kiện PaymentRefunded.

     • Booking Service lắng nghe PaymentRefunded (hoặc PaymentFailed từ bước 2) và thực hiện giao dịch bù trừ: hủy bỏ việc giữ chỗ và cập nhật trạng thái thành "CANCELLED".

• Kết quả: Hệ thống đảm bảo tính nhất quán cuối cùng của dữ liệu. Nếu có bất kỳ lỗi nào xảy ra, các hành động đã thực hiện sẽ được hoàn tác một cách có trật tự, tránh tình trạng dữ liệu bị sai lệch giữa các dịch vụ.