Tổng hợp vai trò của Lambda, SQS, DLQ, S3 và DynamoDB
đồng thời trực tiếp kiểm tra quá trình tin nhắn được gửi lại và cách ly vào DLQ.
Gửi số lượng lớn, tích hợp API bên ngoài, các lô xử lý ngày càng dài. Ngay khi được giao công việc này, một vấn đề không thể giải quyết chỉ bằng cách viết code tốt hơn bắt đầu xuất hiện. Bởi cấu trúc quyết định một yêu cầu sẽ giữ tài nguyên trong bao lâu và cần gửi lại những gì khi đã gửi được khoảng một nửa.
Tốc độ triển khai giờ đây được AI nâng cao. Nút thắt còn lại đã chuyển sang việc phán đoán nên chọn cấu trúc nào và nếu thất bại thì thông báo đó sẽ được chuyển đến đâu. Và nếu chưa từng tận mắt thấy hàng đợi và DLQ thực sự hoạt động, bạn sẽ không thể đưa ra phán đoán này.
Khóa học này đã gói gọn trải nghiệm đó trong 6 bài học, kéo dài 75 phút.
Có ba điểm khác biệt.
Với Docker và LocalStack, bạn khởi chạy SQS · Lambda · S3 · DynamoDB trên môi trường cục bộ. Không cần đăng ký phương thức thanh toán hay thiết lập quyền IAM, bạn có thể bắt đầu thực hành ngay từ bài 1. Hoàn toàn không có khâu nào có thể phát sinh sự cố tính phí.
Thay vì ghi nhớ danh sách tính năng của năm dịch vụ, bạn sẽ lần lượt theo dõi một thông điệp từ khi được phát hành · được tiêu thụ · thất bại · được gửi lại rồi bị cách ly vào DLQ. Trước tiên, hãy vẽ bản đồ vai trò, sau đó di chuyển thông điệp trên bản đồ đó.
Điều gây cản trở là khi chỉ một nửa được gửi đi. Bạn sẽ trực tiếp kiểm tra thông điệp được gửi lại bao nhiêu lần, khi nào bị chuyển vào DLQ và sau đó có thể làm gì.
· Kiến thức cơ bản về Spring Boot — Dành cho những người đã từng tự xây dựng API REST ít nhất một lần
· Tour toàn bộ dịch vụ AWS — Chỉ đề cập đến năm dịch vụ ở trên
· Vận hành production và tối ưu hóa chi phí — nằm ngoài phạm vi của khóa học này
Hãy bắt đầu xem xét tại sao cấu trúc lại sụp đổ chỉ vì số lượng người nhận tăng lên.
Trong cấu trúc này, yêu cầu đi từ controller xuống service rồi gọi API bên ngoài trong một vòng lặp. Số người nhận càng tăng thì thời gian một yêu cầu bị giữ lại cũng tăng tương ứng. Khi nhà cung cấp hoạt động chậm, phản hồi không trả về, và trong khoảng thời gian đó, mỗi yêu cầu sẽ chiếm giữ tài nguyên.
Điều khó khăn hơn còn nằm ở bước tiếp theo. Khi đã gửi được khoảng một nửa, rất khó biết những gì đã gửi thành công; nếu thực hiện lại, tin nhắn sẽ được gửi thêm một lần nữa đến những người đã nhận.
Trong một cấu trúc mà việc thử lại đồng nghĩa với gửi trùng lặp, thì "chạy thêm một lần" không thể là giải pháp.
API chỉ tiếp nhận và phản hồi ngay lập tức. Các yêu cầu dồn dập sẽ được hàng đợi tiếp nhận, sau đó chuyển tiếp theo tốc độ xử lý của phía xử lý. Lỗi được lưu lại theo từng đơn vị.
Trong bài 1 của khóa học, bạn sẽ so sánh hai cấu trúc dựa trên bốn khía cạnh này(thời điểm phản hồi · đơn vị thất bại · chủ thể thử lại · đơn vị mở rộng) và hoàn thành ghi chú so sánh theo dự án của mình.
Vấn đề là nên phân chia vai trò đến mức nào.
Nếu đưa tất cả việc truy vấn, phân chia, gửi và ghi nhận vào một Lambda, chương trình sẽ chạm giới hạn thời gian thực thi, và khi xảy ra lỗi một phần thì sẽ không biết phải khởi động lại từ đâu. Vì việc thử lại sẽ chạy lại toàn bộ quy trình.
Trong bài 2, chúng ta phân chia phạm vi phụ trách của năm dịch vụ và trực tiếp tạo năm thành phần đó thông qua bài thực hành. Tạo queue, DLQ, bucket và bảng, rồi kiểm tra bằng danh sách.
Tệp nội dung và tệp người nhận được tải lên kho lưu trữ, còn trong thông báo chỉ chứa một chuỗi khóa. Trong phần thực hành, bạn sẽ tự mình tải lên và tận mắt xác nhận thông báo chứa gì.
Không dừng lại ở việc giải thích khái niệm, chúng ta sẽ kiểm tra trên màn hình rồi mới chuyển sang phần tiếp theo.
Đã nhận và xử lý nhưng nếu không xóa, sau khi hết thời gian chờ khả năng hiển thị, nó sẽ quay lại với cùng MessageId. Nếu xóa sau khi nhận, dù truy vấn lại cũng sẽ không có gì.
Trong phần thực hành, chúng ta sẽ lần lượt tạo ra hai trường hợp này. Tại đây, hãy xác nhận rằng việc nhận, xử lý và xóa là một bộ thống nhất.
Truyền đạt ít nhất một lần là mặc định. Việc trùng lặp không phải là ngoại lệ mà là điều được giả định, và trách nhiệm quy kết quả về một lần vẫn thuộc về phía xử lý.
Nếu một tin nhắn không thể xử lý thất bại đủ số lần quy định, nó sẽ biến mất khỏi hàng đợi chính và được lưu lại trong DLQ. Trong phần thực hành, bạn sẽ trực tiếp vượt quá giới hạn rồi truy vấn từng hàng đợi trong hai hàng đợi để kiểm tra.
Cuối cùng, hãy xóa các queue, bucket và table đã tạo rồi tắt container. Mục tiêu là nắm vững cả trình tự dọn dẹp khi kết thúc bài thực hành.
Triển khai không phải là phương tiện để xác minh.
Phần thực hành của pre-course này nằm ở bước 3. Nó chạy chỉ với một container Docker và không phát sinh chi phí.
Đồng thời, bạn cũng sẽ thực hành để xác nhận những điều mà môi trường cục bộ không thể phát hiện. Ngay cả khi thay đổi thông tin xác thực thành giá trị không chính xác, môi trường cục bộ vẫn vượt qua như bình thường. Vì vậy, chúng ta không bỏ qua bước 5.
Ngay cả các yêu cầu số lượng lớn cũng được xử lý bằng vòng lặp và lệnh gọi đồng bộ; khi hệ thống chậm đi, trước tiên họ nghĩ đến việc nâng cấp thông số máy chủ.
Giải thích lý do cần tách biệt việc tiếp nhận và xử lý dựa trên thời điểm phản hồi, đơn vị thất bại và chủ thể thực hiện việc thử lại.
Khó diễn đạt sự khác biệt giữa SQS và DLQ bằng câu chữ.
Tôi giải thích bằng màn hình do chính mình xây dựng rằng việc chờ đợi và làm bộ đệm do queue đảm nhiệm, còn việc cách ly các lỗi lặp lại do DLQ đảm nhiệm.
Chỉ xem việc cùng một thông điệp quay lại là một trường hợp ngoại lệ.
Phân biệt rằng việc trùng lặp là điều được mặc định, còn trách nhiệm quy tụ kết quả về một lần vẫn thuộc về phía xử lý.
Các tài nguyên được tạo trong quá trình thực hành đang tích tụ trong tài khoản.
Khi kết thúc phần thực hành, bạn sẽ quen tay với thứ tự xóa.
Nhấp vào để mở rộng nội dung cho biết bạn làm gì trong từng bài học.
Khởi chạy một container và kiểm tra kết nối. Đồng thời, chúng ta cũng sẽ chỉ ra cạm bẫy là container sẽ lập tức thoát nếu bỏ sót tag.
So sánh xử lý yêu cầu và xử lý sự kiện song song. Sản phẩm bàn giao là một bản ghi nhớ so sánh.
Phân chia rõ năm dịch vụ, mỗi dịch vụ đảm nhiệm việc gì và không đảm nhiệm việc gì.
Tóm tắt sáu bước và tiêu chí đạt của từng bước, đồng thời kiểm chứng qua thực hành những điều mà môi trường cục bộ không hỗ trợ.
Đây là phần thực hành cốt lõi và dài nhất.
프리코스가 답하지 않는 질문과 해당 질문에 검증으로 답하는 방법을 짚어봅니다.
Hãy trả lời bằng có hoặc không và đếm điểm. Nếu được 6~7 câu, bạn đã sẵn sàng cho bước tiếp theo; nếu được 5 câu, hãy học lại khóa học tương ứng; nếu được 4 câu trở xuống, hãy xem lại khóa học dự bị một lần nữa.
Bài đánh giá này chỉ kiểm tra những kiến thức cơ bản về AWS serverless. Nếu chưa có kinh nghiệm tự triển khai API bằng Spring Boot thì dù điểm số thế nào, bạn vẫn chưa phù hợp để chuyển sang bước tiếp theo.
Thiết kế và vận hành các hệ thống gửi hơn 10 tỷ tin nhắn mỗi năm và xử lý hàng trăm nghìn sự kiện hành vi người dùng mỗi giây. Tôi là một lập trình viên backend năm thứ hai, đã trải qua mọi giai đoạn từ phát triển ban đầu đến xử lý lưu lượng truy cập lớn tại ba startup.
Các hàng đợi, việc gửi lại và DLQ được đề cập trong khóa học này là những thứ tôi gặp hàng ngày trong thực tế. Phần lớn những gì tôi học được không đến khi mọi thứ vận hành trơn tru, mà là khi chúng sụp đổ.
Tuy nhiên, chúng tôi không sử dụng mã nguồn hay tài liệu nội bộ của công ty. Thay vào đó, chúng tôi tái tạo tình huống tương tự bằng các ví dụ có thể công khai và dữ liệu tổng hợp. Chúng tôi gửi trùng cùng một thông điệp để kiểm tra xem tính bất biến có được đảm bảo hay không, đồng thời thay đổi phản hồi của nhà cung cấp thành 429 và timeout để xem thông lượng được điều chỉnh như thế nào. Chúng tôi cũng trực tiếp chạy trên màn hình quá trình thông điệp bị lỗi được chuyển đến DLQ rồi được xử lý lại.
Bài giảng · kiểm chứng kỹ thuật · hỗ trợ học viên: Khan (Lee Chang-min)
Chương trình học · giáo trình · biên tập: Park Hyun-jun
Đồng sản xuất: Dingco Labs
Làm thế nào để thấy được hệ thống thực sự không sụp đổ, làm thế nào để quy các bản trùng lặp về một lần duy nhất,
và cần làm gì để việc một khách hàng gửi quá nhiều yêu cầu không khiến các khách hàng khác bị bỏ đói.
LocalStack 4.9. Các thẻ latest hoặc stable yêu cầu mã thông báo giấy phép và container sẽ lập tức thoát.Docker và AWS CLI. Bạn không cần tài khoản AWS và cũng không phát sinh chi phí.
