Các phong cách kiến trúc và mẫu giao tiếp

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

Ricardo Sueiras

Principal Technologist

Giảng viên của bạn

Mẫu kiến trúc là gì?

 

 

 

• Giải pháp có thể lặp lại cho một vấn đề thường gặp.
• Mẫu giúp bạn ghép các dịch vụ AWS với nhau.
• Kiến trúc quyết định ứng dụng hoạt động thế nào khi tải cao.
• Có vài mẫu kiến trúc bạn cần biết.

Monolith (nguyên khối)

 

 

 

 

• Một khối đơn, ghép nối chặt chẽ.
• Một mã nguồn, một lần triển khai.
• Ban đầu phát triển đơn giản.
• Khó mở rộng: phải mở rộng tất cả cùng lúc.

Microservices

 

 

• Dịch vụ nhỏ, độc lập: mỗi dịch vụ phụ trách một năng lực nghiệp vụ.
• Triển khai, mở rộng, cập nhật từng dịch vụ độc lập.
• Đánh đổi: vận hành phức tạp hơn và phải quản lý giao tiếp giữa dịch vụ.

Serverless

• Không quản lý hạ tầng, chỉ có mã và cấu hình.
• Xây dựng bằng cách ghép các dịch vụ AWS quản lý sẵn.
• AWS lo cấp phát, mở rộng và bảo trì.
• Đánh đổi: giới hạn thời gian chạy, khởi động lạnh, phụ thuộc nhà cung cấp.
• Gần như không có chi phí vận hành và tự động mở rộng.

 

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

• Các thành phần giao tiếp bằng sự kiện, không gọi trực tiếp.
• Sự kiện ghi lại điều đã xảy ra (đặt hàng, nhận thanh toán, gửi hàng).
• Bên tạo phát ra sự kiện.
• Bên tiêu thụ đăng ký những sự kiện họ quan tâm.

 

Hệ thống ghép nối chặt và lỏng

• Ứng dụng cloud hiện đại gồm nhiều dịch vụ.
• Các dịch vụ phải giao tiếp và phối hợp để hoàn thành công việc.
• Giao tiếp đồng bộ ghép nối chặt.
• Giao tiếp bất đồng bộ ghép nối lỏng.

Giao tiếp đồng bộ

 

• Một dịch vụ gửi yêu cầu và chờ phản hồi.
• Bên gọi bị chặn cho đến khi có phản hồi hoặc hết thời gian chờ.
• Dễ triển khai và hiểu.
• Ghép nối chặt: chậm hoặc lỗi hạ nguồn có thể lan truyền.
• Giảm thiểu bằng timeout, retry và circuit breaker.

Mẫu: request/response

• Xương sống của hầu hết giao diện ứng dụng.
• Hành vi dễ dự đoán.
• Phản hồi tức thì cho người dùng.

Giao tiếp bất đồng bộ

 

• Bên gửi không chờ phản hồi.
• Gửi thông điệp hoặc sự kiện rồi tiếp tục xử lý.
• Bên nhận xử lý thông điệp độc lập.
• Ghép nối lỏng: mở rộng và chịu lỗi tốt hơn.
• Xử lý tốt đột biến lưu lượng và mất kết nối cục bộ.
• Thách thức: thông điệp trùng lặp, thứ tự, nhất quán cuối cùng.

Mẫu: tách ghép bằng hàng đợi

• Bên sản xuất gửi thông điệp vào hàng đợi.
• Bên tiêu thụ tự kéo và xử lý thông điệp.
• Ngăn lỗi lan truyền dây chuyền.
• Bên sản xuất và tiêu thụ mở rộng độc lập.

 

Mẫu: hàng đợi worker

• Nhiều worker kéo thông điệp từ một hàng đợi.
• Xử lý thông điệp song song.
• Cho phép mở rộng ngang và thông lượng cao hơn.
• Không đảm bảo thứ tự thông điệp.

Mẫu: publish/subscribe

• Publisher gửi thông điệp vào chủ đề SNS.
• Nhiều subscriber nhận cùng một thông điệp.
• Phát sóng thời gian thực đến nhiều bên tiêu thụ.

 

Mẫu: fan-out

• Một thông điệp được gửi đồng thời tới nhiều bên tiêu thụ.
• Dùng rộng rãi trong kiến trúc hướng sự kiện.
• Hữu ích khi nhiều dịch vụ cần phản ứng với cùng một sự kiện.

Thứ tự thông điệp

• Một số tác vụ phải xử lý thông điệp theo đúng thứ tự.
• Amazon SQS FIFO và Kinesis hỗ trợ xử lý có thứ tự.
• Thứ tự nghiêm ngặt làm giảm thông lượng.
• Cân bằng giữa tính đúng đắn và khả năng mở rộng.

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

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