Phối hợp dịch vụ và quản lý trạng thái

Phát triển ứng dụng trên AWS

Ricardo Sueiras

Principal Technologist

Phối hợp dịch vụ

 

• Nhiều dịch vụ phải phối hợp để hoàn tất một quy trình.
• Cần có chiến lược phối hợp.
• Hai cách tiếp cận: orchestration và choreography.

Orchestration

 

• Một bộ điều phối trung tâm điều khiển luồng công việc.
• Orchestrator kiểm soát thứ tự và quyết định dịch vụ chạy tiếp theo.
• Hữu ích cho retry, logic điều kiện, và xử lý lỗi.
• Trên AWS: triển khai bằng Step Functions qua Lambda, ECS, DynamoDB.

Orchestration

 

• Logic quy trình nằm tập trung nên dễ gỡ lỗi và giám sát.
• Đánh đổi: tạo ra một phụ thuộc trung tâm.

Choreography

• Không có bộ điều khiển trung tâm.
• Dịch vụ phản ứng độc lập theo sự kiện.
• Mỗi dịch vụ lắng nghe sự kiện liên quan và xử lý phần việc của mình.
• Không dịch vụ nào cần biết toàn bộ quy trình.
• Tăng độ kết nối lỏng lẻo và khả năng mở rộng.

 

Choreography

• Trên AWS: EventBridge, SNS, SQS.
• Khả năng mở rộng rất cao.
• Đánh đổi: khó hiểu và khó gỡ lỗi khi quy trình lớn dần.

 

Kiến trúc hướng sự kiện

• Dịch vụ giao tiếp bằng cách phát và tiêu thụ sự kiện.
• Thúc đẩy kết nối lỏng lẻo giữa các dịch vụ.
• Tăng khả năng mở rộng.
• Cho phép xử lý sự kiện song song.
• Dịch vụ mới có thể đăng ký mà không cần sửa dịch vụ hiện có.

 

Kiến trúc hướng sự kiện

 

• Các đánh đổi khi triển khai EDA:
• Thiết kế cho tính nhất quán cuối cùng.
• Triển khai idempotency.
• Xử lý lỗi phức tạp hơn.

Idempotency

 

• Chạy cùng một thao tác nhiều lần vẫn cho cùng kết quả.
• Nguyên tắc then chốt trong hệ thống bất đồng bộ và hướng sự kiện.
• Hệ phân tán có thể gửi trùng sự kiện (retry, lỗi mạng, xử lý lại).
• Giữ đúng đắn và độ tin cậy của hệ thống.

Dead letter queues

 

• Quản lý lỗi trong giao tiếp bất đồng bộ.
• Cô lập các thông điệp "độc" gây lỗi.
• Sau nhiều lần retry thất bại, thông điệp sẽ vào DLQ.
• Luồng xử lý chính vẫn tiếp tục chạy.

Dead letter queues

• Dùng khi thứ tự thông điệp không quá quan trọng.
• Bỏ qua với hệ không quan trọng, chấp nhận mất dữ liệu đôi lúc.
• Tránh dùng khi phải giữ nguyên thứ tự thông điệp.

 

Quản lý trạng thái

• Quản lý trạng thái là cốt lõi của ứng dụng cloud native.
• Trạng thái là dữ liệu được giữ giữa các lần tương tác.
• Lưu trạng thái cục bộ trên máy chủ hạn chế khả năng mở rộng và khả năng chịu lỗi.

 

Quản lý trạng thái

• Quản lý trạng thái có các đánh đổi tùy thứ bạn xây dựng.
• Trạng thái bên ngoài cải thiện mở rộng và chịu lỗi.
• Chi phí: độ trễ và độ phức tạp tăng thêm.
• Cần cân nhắc: tính nhất quán, bộ đệm (caching), và mẫu truy cập dữ liệu.

 

Stateful

 

• Dữ liệu phiên được giữ trên máy chủ.
• Yêu cầu phải định tuyến đến đúng cùng một instance (sticky sessions).
• Hạn chế linh hoạt khi mở rộng.
• Nếu instance hỏng, phiên sẽ mất.

Stateless

 

• Mỗi yêu cầu được xử lý độc lập.
• Không lưu trạng thái trên máy chủ.
• Trạng thái nằm ở hệ thống bên ngoài.
• Cách tiếp cận ưu tiên cho ứng dụng cloud native.
• Bất kỳ instance nào cũng xử lý được mọi yêu cầu, nên mở rộng ngang rất đơn giản.

Cùng luyện tập nào!

Phát triển ứng dụng trên AWS