Lộ trình
Amazon Web ServicesAssociateTuần 4: Tối ưu & vận hànhBài 25 / 30

Ngày 25: Kiến trúc microservices

Thời lượng: 45 phút
Mục tiêu: 2 nhiệm vụ chính
Tiến độ lộ trình
aws-saa-c03ngày 25
hoàn thành25 / 30 bài
Bối cảnh bài học

Thiết kế microservices với service boundary, synchronous/asynchronous communication, data ownership và failure isolation.

đọc hiểuthực hànhcheckpoint
Bài giảng hôm nay

Học hiểu, rồi mới thực hành

Thiết kế microservices với service boundary, synchronous/asynchronous communication, data ownership và failure isolation.

Bắt đầu đọc bài giảng

Nhiệm vụ bài học hôm nay

  • Tìm hiểu SQS, SNS, EventBridge
  • Thiết kế sơ đồ kiến trúc decoupled với SQS
Instructor walkthrough

Bài giảng chi tiết: từ bài toán đến bằng chứng

Scenario xuyên suốt

Một monolith cần scale phần catalog khác phần order, nhưng tách service tùy tiện sẽ tạo distributed transaction và coupling. Bài học tập trung vào boundary và operational cost.

01Đọc bài toán

Xác định actor, workload, constraint và trạng thái cuối cần đạt.

02Vẽ luồng / boundary

Chỉ ra request, dependency, identity và failure domain trước khi chọn công cụ.

03Chọn và thực hành

Thay đổi nhỏ nhất trong lab cô lập; command nào cũng phải nói rõ nó kiểm tra điều gì.

04Kiểm chứng / recovery

Đối chiếu trạng thái thực tế, tạo một failure variant và ghi cách hoàn tác.

Cách nối lý thuyết với thực tế
  • Service boundary nên theo business capability/data ownership, không chỉ theo bảng database.
  • API sync cần timeout/retry/circuit behavior; async cần queue/event/idempotency/DLQ.
  • Mỗi service ownership dữ liệu có trade-off consistency và reporting.
  • Microservices tăng deploy autonomy nhưng tăng observability, networking, testing và operations.

Microservices là trade-off

Tách service phải bắt đầu từ business capability/data ownership. Ghi sync/async, timeout, retry, idempotency và source of truth.

Bài tập

Thiết kế catalog/order/payment/notification. Với mỗi boundary ghi deploy/scaling/security/observability và failure mode. Cuối cùng viết điều kiện giữ monolith để tránh chia nhỏ vì phong trào.

Bài giảng chuyên sâu

Microservices: boundary trước service count

Tách theo business capability và data ownership, không theo bảng database. Sync API cần timeout/retry/circuit behavior; async cần queue/event, idempotency và DLQ. Service autonomy tăng nhưng kéo theo network, observability, contract testing, deployment và distributed failure. Monolith vẫn phù hợp khi boundary chưa rõ hoặc team chưa chịu được overhead.

Bài tập: phân tích catalog/order/payment/notification, ghi owner, source of truth, sync/async và failure. Failure drill: downstream chậm, duplicate payment event và schema incompatibility; recovery phải tránh side effect lặp.

Terminal reference

Command list và cách dùng

Chạy từng lệnh theo đúng thứ tự. Trước các lệnh có thể tạo hoặc thay đổi tài nguyên, hãy kiểm tra profile, account và region.

Commands · read-only checkpoints
aws sts get-caller-identity --profile study
aws configure list --profile study
Hands-on lab

Thực hành theo scenario

Tách commerce monolith thành catalog/order/payment/notification, ghi owner/data/API/event và failure behavior. Chọn sync/async cho từng interaction, thêm timeout/retry/idempotency. Không triển khai cluster thật cho bài design.

Evidence checkpoint

Kiểm chứng kết quả

Không coi lệnh chạy thành công là đủ. Hãy đối chiếu output với trạng thái mong đợi:

  • Boundary có lý do business/data.
  • Mỗi call có timeout/retry/error behavior.
  • Không dùng distributed transaction mù quáng.
  • Nêu operational overhead và khi nào giữ monolith.
Transfer to exam / production

Bẫy thường gặp và trade-off

Microservices không mặc định tốt hơn monolith; scenario cần team autonomy/independent scaling/deploy và chấp nhận complexity mới nên chọn.

Checkpoint · 3 phút

Kiểm tra nhanh

Câu hỏi: Rủi ro chính khi tách nhiều service nhưng giữ database dùng chung là gì?

Kết thúc bài

Checklist trước khi sang Ngày 2