Design pattern

Mô hình Saga trong Giao dịch Phân tán của Kiến trúc Microservice

Thương Phạm

18/05/2025

7 Min Read

73 Views

0 Comments

Trong kiến trúc microservice hiện đại, việc xử lý giao dịch phân tán là một trong những thách thức phức tạp và phổ biến nhất. Khác với các hệ thống đơn khối (monolithic) truyền thống nơi toàn bộ dữ liệu và nghiệp vụ được xử lý tập trung trong một cơ sở dữ liệu duy nhất, hệ thống microservice chia nhỏ ứng dụng thành nhiều dịch vụ độc lập, mỗi dịch vụ có cơ sở dữ liệu riêng và thường giao tiếp thông qua API hoặc message queue. Chính sự phân tán này làm cho việc duy trì tính nhất quán dữ liệu trở nên khó khăn, đặc biệt trong các giao dịch liên quan đến nhiều dịch vụ. Đây là lúc mô hình Saga trở thành một giải pháp quan trọng và hiệu quả.

Saga là gì?

Trước khi đi sâu vào định nghĩa, cần hiểu rằng bài toán đảm bảo tính nhất quán dữ liệu trong hệ thống phân tán đã được nghiên cứu và giải quyết bằng nhiều mô hình khác nhau. Một trong những giải pháp truyền thống là Two-Phase Commit (2PC), vốn sử dụng một coordinator để đảm bảo tất cả các bên tham gia giao dịch đều commit hoặc rollback cùng lúc. Tuy nhiên, 2PC có nhược điểm lớn là khó mở rộng, dễ bị khóa tài nguyên và phụ thuộc mạnh vào tính sẵn sàng của các thành phần tham gia.

Saga ra đời như một giải pháp thay thế nhẹ hơn và thân thiện hơn với kiến trúc microservice. Thay vì dùng một giao dịch toàn cục, Saga chia nhỏ thành các giao dịch cục bộ (local transactions), mỗi giao dịch này sẽ thực hiện trong phạm vi một dịch vụ. Nếu có lỗi xảy ra, hệ thống sẽ thực hiện các hành động bù trừ (compensating transactions) để khôi phục trạng thái dữ liệu.

Saga là một mẫu thiết kế (design pattern) dùng để quản lý các giao dịch phân tán thông qua chuỗi các giao dịch cục bộ (local transactions). Thay vì cố gắng duy trì tính toàn vẹn dữ liệu bằng một giao dịch phân tán phức tạp theo kiểu 2PC (Two-Phase Commit), Saga chia nhỏ giao dịch tổng thể thành các bước riêng biệt. Mỗi bước là một giao dịch cục bộ được thực thi bởi một microservice và có thể hoàn tác bằng một hành động bù trừ nếu xảy ra lỗi ở bất kỳ giai đoạn nào sau đó.

Mô hình này tuân theo nguyên tắc eventual consistency – tức là tính nhất quán dữ liệu cuối cùng sẽ được đảm bảo, thay vì nhất quán tức thì như trong ACID.

Các khái niệm chính trong mô hình Saga

• Giao dịch cục bộ (Local Transactions): Là những thao tác dữ liệu thực hiện trong phạm vi một dịch vụ, đảm bảo tính toàn vẹn cục bộ.
• Hành động bù trừ (Compensating Transactions): Là hành động ngược lại nhằm khôi phục trạng thái dữ liệu nếu một bước nào đó trong chuỗi giao dịch thất bại.
• Cơ chế điều phối (Coordination): Là cách thức tổ chức và thực thi các bước trong Saga, gồm hai hình thức phổ biến: Choreography và Orchestration.

Các hình thức điều phối Saga

Một trong những yếu tố quan trọng khi triển khai Saga là lựa chọn hình thức điều phối phù hợp. Dưới đây là bảng so sánh giữa hai hình thức phổ biến: Choreography và Orchestration.

1. Choreography – Điều phối phi tập trung (dựa trên sự kiện)

Sơ đồ mô tả:

Order Service
    |
    |---> (1) OrderCreated Event ---+
                                   |
                            Payment Service
                                   |
                 +----------------+-----------------+
                 |                                    |
         (2) PaymentCompleted Event           (Fail) PaymentFailed Event
                 |                                    |
          Inventory Service                      Order Service (Compensate)
                 |
        (3) InventoryReserved Event

Trong mô hình này, không có một trung tâm điều phối chính. Thay vào đó, mỗi dịch vụ sẽ lắng nghe sự kiện được phát ra từ dịch vụ trước đó và quyết định thực hiện hành động tiếp theo. Đây là hình thức điều phối phân tán, nhẹ, và dễ mở rộng.

Ưu điểm:

• Dễ mở rộng theo chiều ngang.
• Không cần dịch vụ trung tâm điều phối.
• Phù hợp với hệ thống có ít bước giao dịch.

Nhược điểm:

• Khó theo dõi toàn bộ luồng Saga.
• Dễ phát sinh lỗi khó phát hiện nếu không giám sát tốt.

Ví dụ:

1. Dịch vụ Đặt hàng tạo đơn và phát OrderCreated.
2. Dịch vụ Thanh toán lắng nghe sự kiện này, tiến hành thanh toán, sau đó phát PaymentCompleted.
3. Dịch vụ Kho tiếp tục lắng nghe PaymentCompleted, đặt giữ hàng và phát InventoryReserved.

2. Orchestration – Điều phối tập trung (dựa trên lệnh)

Sơ đồ mô tả:

           +--------------------+
           |   Orchestrator     |
           +--------------------+
                   |
                   v
          (1) Send CreateOrder Command
                   |
                   v
            Order Service
                   |
                   v
          (2) Return Success / Failure
                   |
        +----------+----------+
        |                     |
     Success              Failure
        |                     |
        v                     v
(3) Send ProcessPayment   (6) Send CancelOrder
        |                     |
        v                     v
  Payment Service         Order Service
        |                     |
        v                     v
(4) Return Success     (7) Order Cancelled
        |
        v
(5) Send ReserveInventory
        |
        v
  Inventory Service

Trong mô hình orchestration, một dịch vụ trung tâm (gọi là orchestrator) sẽ điều phối luồng hoạt động của toàn bộ Saga. Orchestrator sẽ lần lượt gửi lệnh đến từng dịch vụ và đợi phản hồi để thực hiện bước tiếp theo hoặc bù trừ khi xảy ra lỗi.

Ưu điểm:

• Dễ kiểm soát, dễ debug.
• Có thể áp dụng business logic phức tạp.
• Dễ mở rộng với retry, timeout và giám sát.

Nhược điểm:

• Tạo điểm nghẽn nếu orchestrator quá tải.
• Tăng độ phụ thuộc giữa các dịch vụ và orchestrator.

Ví dụ:

1. Orchestrator gửi lệnh CreateOrder đến dịch vụ Đặt hàng.
2. Khi nhận được phản hồi thành công, orchestrator tiếp tục gửi ProcessPayment đến dịch vụ Thanh toán.
3. Nếu ProcessPayment thất bại, orchestrator sẽ gửi CancelOrder để hoàn tác đơn hàng ban đầu.

Ưu điểm của mô hình Saga

• Đảm bảo tính nhất quán mà không cần khoá phân tán hoặc các giao dịch toàn cục.
• Cho phép các dịch vụ hoạt động độc lập và giữ được tính phân tán.
• Dễ dàng tích hợp với các hệ thống message broker để truyền sự kiện.
• Phù hợp với các hệ thống lớn, có luồng nghiệp vụ phức tạp, kéo dài.

Thách thức khi áp dụng Saga

• Thiết kế hành động bù trừ phức tạp, đôi khi không khả thi nếu thao tác không thể đảo ngược.
• Khó kiểm soát nếu có nhiều nhánh hoặc vòng lặp trong Saga.
• Cần cơ chế retry, timeout và xử lý idempotent chặt chẽ.
• Khó kiểm thử do tính chất phi đồng bộ và phân tán.

Một số lưu ý quan trọng khi triển khai Saga

Khi triển khai mô hình Saga trong hệ thống microservice, việc đảm bảo tính ổn định, nhất quán và khả năng phục hồi của hệ thống là vô cùng quan trọng. Dưới đây là một số lưu ý giúp bạn triển khai hiệu quả hơn:

• Đảm bảo tính idempotent: Mỗi hành động trong Saga nên có khả năng thực thi lặp lại mà không gây ra tác dụng phụ. Điều này đặc biệt quan trọng trong trường hợp xảy ra retry hoặc timeout.
• Ghi log chi tiết theo từng bước: Bao gồm thông tin về thời gian bắt đầu/kết thúc, dữ liệu đầu vào/đầu ra, và trạng thái của mỗi bước trong Saga. Việc này giúp việc theo dõi, phân tích và xử lý sự cố dễ dàng hơn.
• Sử dụng cơ chế retry có kiểm soát: Áp dụng chiến lược “retry with exponential backoff” kết hợp với circuit breaker để hạn chế ảnh hưởng từ lỗi tạm thời và ngăn việc tái thử gây quá tải hệ thống.
• Triển khai hệ thống giám sát phân tán (distributed tracing): Kết hợp các công cụ như OpenTelemetry, Jaeger, Zipkin hoặc Elastic APM để theo dõi toàn bộ luồng thực thi của Saga trong môi trường phân tán.
• Kiểm thử kịch bản lỗi kỹ lưỡng: Mô phỏng và xử lý các tình huống như mất kết nối, lỗi timeout, hoặc thất bại trong hành động bù trừ để đảm bảo hệ thống hoạt động ổn định khi gặp sự cố.

Khi nào nên dùng Saga?

Saga không phải là giải pháp vạn năng, nhưng rất phù hợp trong các trường hợp sau:

• Giao dịch liên quan nhiều microservice và không thể dùng giao dịch phân tán.
• Các quy trình nghiệp vụ dài, phức tạp, cần rollback một phần.
• Hệ thống yêu cầu mở rộng linh hoạt, không muốn ràng buộc giữa các dịch vụ.
• Cần thiết kế theo hướng eventual consistency thay vì nhất quán tức thì.

Kết luận

Mô hình Saga mang lại một giải pháp mạnh mẽ và linh hoạt để xử lý giao dịch phân tán trong kiến trúc microservice. Nó giúp cân bằng giữa tính nhất quán và khả năng mở rộng, đồng thời hỗ trợ tốt các luồng nghiệp vụ dài hơi và nhiều bước. Tuy nhiên, để triển khai thành công, cần có chiến lược rõ ràng về thiết kế, giám sát, kiểm thử và lựa chọn công cụ phù hợp. Việc hiểu rõ sự khác biệt giữa choreography và orchestration cũng sẽ giúp bạn chọn đúng mô hình phù hợp với yêu cầu cụ thể của hệ thống.