Các mẫu kiến trúc ứng dụng trên AWS

Triển khai Ứng dụng trên AWS

Dunieski Otano

Amazon Web Services Solutions Architect

Gặp gỡ giảng viên của bạn

Giảng viên khóa học Dunieski Otano, AWS Solutions Architect, với khoảng mười năm kinh nghiệm đám mây

Vì sao kiến trúc đúng quan trọng

Sơ đồ quyết định giao diện sáng, nơi một nút chọn kiến trúc phân nhánh thành ba yếu tố: mức ghép nối, trạng thái và truyền thông, phía trên biểu tượng cân cho đánh đổi

Kiến trúc là tập hợp các đánh đổi, không có một đáp án đúng
- Ba câu hỏi định hình mọi lựa chọn:
  - Các thành phần ghép nối chặt đến mức nào?
  - Trạng thái nằm ở đâu?
  - Truyền thông đồng bộ hay bất đồng bộ?
- Chọn mẫu phù hợp với khối lượng công việc, không chạy theo mốt

Hiệu ứng dây chuyền tối thứ Sáu

API thanh toán chậm làm đứng cả quy trình checkout
Mọi dịch vụ đều chờ đồng bộ vào nó
Cách sửa là kiến trúc, không chỉ làm API nhanh hơn

So sánh cạnh nhau giữa dịch vụ ghép nối chặt bị treo và dịch vụ tách rời bằng hàng đợi thông điệp

Chọn kiến trúc quyết định cách triển khai

Sơ đồ so sánh kiến trúc ghép nối chặt dễ vỡ nơi một dịch vụ lỗi lan sang tất cả so với thiết kế bền bỉ nơi bộ đệm hàng đợi cô lập lỗi để dịch vụ khác vẫn phục vụ

Mẫu bạn chọn quyết định ứng dụng mở rộng và thất bại ra sao
- Thiết kế ghép nối chặt sẽ vỡ khi tải tăng
Mẫu đúng giúp triển khai dễ dự đoán
- Cùng mã, hành vi production có thể rất khác

Các mẫu kiến trúc cốt lõi

Monolithic: một khối triển khai, dễ khởi đầu
Microservices: dịch vụ độc lập, triển khai riêng lẻ
Event-driven: thành phần phản ứng sự kiện, không gọi trực tiếp
- Fanout là tiểu mẫu event-driven: một sự kiện tới nhiều bên tiêu thụ

Ba mẫu kiến trúc ứng dụng cạnh nhau: monolithic là một khối xếp chồng, microservices là các dịch vụ triển khai độc lập, và event-driven với bus sự kiện, kèm fanout là tiểu mẫu gửi một sự kiện cho nhiều bên tiêu thụ

Stateful vs stateless

Stateless: không giữ dữ liệu client giữa các yêu cầu
- Bất kỳ instance nào cũng xử lý được mọi yêu cầu
Stateful: instance nhớ tương tác trước đó
Stateless cho phép bạn mở rộng ngang
- Đẩy trạng thái dùng chung lên DynamoDB hoặc ElastiCache

Instance hàm stateless bên trái mà mọi yêu cầu đều có thể tới, so với instance stateful bên phải gắn với một phiên client

Ghép nối chặt vs lỏng

Ghép nối chặt khi bên gọi bị chặn chờ bên được gọi chậm, so với ghép nối lỏng với hàng đợi SQS đệm thông điệp để bên sản xuất tiếp tục làm việc

Ghép nối chặt: bên gọi chờ phản hồi từ bên được gọi
Một dịch vụ chậm làm treo cả chuỗi
Ghép nối lỏng: có hàng đợi Amazon SQS giữa các dịch vụ
Bên sản xuất vẫn chạy dù bên tiêu thụ bị down

Đồng bộ vs bất đồng bộ

Đồng bộ: bên gọi bị chặn và chờ kết quả
Dùng khi bên gọi cần câu trả lời ngay
Bất đồng bộ: bên gọi bàn giao công việc rồi quay về
Dùng cho việc chậm, bùng nổ, hoặc không gấp

Gọi đồng bộ với bên gọi bị chặn tới khi có phản hồi bên trái so với bàn giao bất đồng bộ trả về ngay với xử lý nền bên phải

Mẫu tăng bền bỉ cho gọi bên thứ ba

Retry theo cấp số nhân: chờ lâu dần giữa các lần thử
Circuit breaker: tạm ngừng gọi dịch vụ đang lỗi
Dead-letter queue: đưa vào hàng đợi các thông điệp thất bại lặp lại
Kết hợp chúng; retry tràn lan làm sự cố tệ hơn

Ba mẫu tăng khả năng chịu lỗi: đường cong retry theo cấp số nhân, circuit breaker dừng gọi dịch vụ lỗi, và dead-letter queue thu nhận thông điệp hết số lần retry

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

Triển khai Ứng dụng trên AWS