SAGA Pattern trong Microservices

Tìm ra bài viết này chắc hẳn anh em đã biết về microservices, concept của micro services chia các service nhỏ để scale và quản lý, nhưng nó lại phát sinh vấn đề về sự nhất quán của dữ liệu giữa các micro services, đó là lý do tui viết bài về SAGA Pattern cho anh em.

SAGA pattern Anh em yên tâm, nhức đầu sẽ theo cấp độ. Cứ nhức đầu dần thôi à =)))

Vậy SAGA pattern là gì? Bằng các nào nó có thể quản lý và đảm bảo được sự nhất quán dữ liệu giữa các micro services?

Tất cả sẽ được trình bày rõ trong bài viết này.

Microservices concept thì nhiều anh em biết rồi, nhưng SAGA pattern thì ít

Bắt đầu thôi anh em. Luôn là định nghĩa.

1. Saga Pattern là gì?

The Saga design pattern is a way to manage data consistency across microservices in distributed transaction scenarios. A saga is a sequence of transactions that updates each service and publishes a message or event to trigger the next transaction step. If a step fails, the saga executes compensating transactions that counteract the preceding transactions.

Saga design pattern là cách quản lý sự thống nhất của dữ liệu giữa các microservices trong các kịch bản việc giao dịch là phân tán (distributed). SAGA là một chuỗi các giao dịch cập nhật giữa các service và publish thông báo hoặc trigger các bước transaction. Nếu một bước thất bại, SAGA sẽ thực hiện giao dịch tương tự để khoả lấp cho các transactions trước đó

Ôi lạy chúa cái định nghĩa đọc thôi đã thấy khó hiểu. Để tóm tắt lại cho anh em, đơn giản thì có 2 ý:

  • SAGA Pattern là pattern đảm bảo tính nhất quán của dữ liệu (bằng các quản lý transactions) giữa các microservices khác nhau.
  • Vì là hệ thống phân tán nên mỗi ông có thể xử lý một phần (nằm trên một transactions), nếu một cái bị fail thì SAGA lúc này có thể thực hiện một transactions thay thế bù vào cái transactions bị fail đó.

SAGA pattern Phân tán (distributed) nghĩa là chia rỏ và nằm rải rác nhiều nơi. Kiến trúc này có thể apply cho cả hệ thống, database,…

  Phát triển phần mềm theo kiến trúc microservice
  Thiết kế service có tải ghi cao không gây tranh chấp tài nguyên

2. Giải pháp

Về mặt ý tưởng, mỗi micro services khi nhận được yêu cầu thực hiện transactions, bản thân micro services đó sẽ thực hiện transactions tại chính services đó. Sau khi đã thực hiện xong, theo hướng của SAGA Pattern, services đó sẽ publish một thông báo (message) hoặc một events (sự kiện).

Từ thông báo hoặc sự kiện đó sẽ biết được transactions nào nên được thực hiện tiếp.

SAGA pattern

Như hình phía trên, Order Services sau khi thực hiện transactions tại service sẽ publish message hoặc event để biết kế tiếp sẽ phải thực hiện transactions tại Customer Service.

Customer Services sau đó publish tiếp để biết cần phải quay lại Order Service để thực hiện tiếp transactions.

Tuyển dụng lập trình viên Frontend lương cao tại đây!

3. Hai cách quản lý

Theo như concept này, có 2 cách để SAGA có thể quản lý được transactions:

  • Thứ nhất là Choreography (Vũ đạo), ở đây anh em hiểu là vũ công cũng được, vì người nào múa người đó. Cái này như ví dụ phía trên, mỗi transactions tự quản lý transactions nào sẽ cần được thực hiện kế tiếp, ông nào lo ông đó.
  • Thứ hai là Orchestration (Ban nhạc), ban nhạc thì anh em biết rồi, có ông nhạc trưởng ban nhạc mới chơi nhạc được. Cách số hai này hướng tới một ông có thể điều phối, tức là hết transactions ở ông Order Service sẽ qua Customer Services, cái này ông điều phối lo.

SAGA pattern Các khái niệm trong lập trình nếu có tên đều có concept giống với thực tế. Anh em cố gắng liên tưởng tí là sẽ hiểu concept

Ngoài ra cách hiểu theo ví dụ thực tế như thế này sẽ nhớ rất lâu. Rất khó quên, anh em nên luyện tập nhớ theo kiểu này nha.

Rồi đi vào từng cái với hình ảnh minh hoạ cho dễ hiểu hơn.

4. Choreography-based saga

Như đã giải thích sơ với anh em ở phía trên, Choreography trong SAGA Pattern theo concept ông nào lo ông đấy.

SAGA pattern

SAGA Pattern mà cụ thể là Choreography thường được áp dụng cho các sàn giao dịch thương mại điện tử. Như ví dụ trên đây:

  • 1. Đầu tiên khi anh em đặt hàng, ông Order Service nhận được một POST request /orders. Lúc này đơn hàng ở trạng thái PENDING.
  • 2. Sau khi đơn hàng đã xong, services này đẩy ra một event là order created.
  • 3. Customer Service nhận được event (hoặc nó trigger events) này, xử lý thanh toán liên quan tới thẻ tín dụng của khách
  • 4. Sau khi đã xong nó sẽ publish lại một event hoặc message cho ông Order biết để approver hoặc reject đơn hàng của khách.

Đơn giản, dễ hiểu. Services nào tự lo, tự xử lý cái event của riêng mình, cần ông nào thì publish ra cho ông đó xài.

4.1 Ưu nhược điểm

Về ưu nhược điểm của Choreography chắc anh em nào code nhiều sẽ đoán ra được. Đầu tiên là ưu điểm:

  • Mẫu này đơn giản, dễ hiểu nên có thể apply nhanh chóng cho các business nhỏ
  • Do services nào handle event, message của services đó nên có thể implement nhanh chóng

Về nhược điểm thì lúc có nhiều hơn events sẽ khiến logic trở nên phức tạp và khó kiểm soát.

5. Orchestration-based saga

Orchestration trong SAGA Pattern thì ngược với Choreography. Chỗ này các micro services không tự handle event mà tập trung lại ở ông Message Broker. Ông này đóng vai trò như người điều phối trong dàn nhạc.

Event nào tới, event nào đi đều phải thông qua ổng, ông điều tới điều lui

SAGA pattern

Giải thích cho hình vẽ phía trên:

  • 1. Anh em cũng nhận được order từ POST request, trạng thái order lúc này vẫn là PENDING.
  • 2. Microservices vẫn đẩy event ra là nhận được order, nhưng nó không cần biết services nào sẽ xử lý tiếp theo, chỉ việc đẩy lên message brokers
  • 3. Ông message broker lúc này gửi tới Customer Services là xử lý credit đi.
  • 4. Ông Customer services xử lý
  • 5. Đẩy lại lên message broker về đơn hàng thanh toán thành công hay thất bại
  • 6. Message broker đẩy lại cho Order service xử tiếp

5.1 Ưu nhược điểm

Về ưu điểm thì Orchestration thích hợp cho các mô hình kinh doanh phức tạp. Cần phải quản lý và xử lý liên quan nhiều giữa các micro services. Trường hợp có thêm services hoặc thêm event, message cũng không quá phức tạp

Về nhược điểm thì có 2 nhược điểm rõ ràng là:

  • Tốn effort để manage và xử lý với message broker. Cái kia chỉ viết logic publish message hoặc event ngay trong services.
  • Signle point of failure -> Ông message broker mà ngủm thì toàn bộ ngủm theo. Cái này không đúng với concept của microservice. Một cái ngủm các cái khác vẫn hoạt động.

6. Tham khảo

Chỉ một bài viết này e là chưa đủ với SAGA Pattern, hẹn anh em ở phần hai, đi sâu hơn và ví dụ sử dụng cho từng loại.

Cảm ơn anh em đã đọc bài – Thank you for your time – Happy coding!

Tác giả: Kiên Nguyễn

Xem thêm: 

Xem thêm các vị trí IT Job hấp dẫn trên TopDev