Cách quản lý API không đồng bộ của bạn với DynamoDB Streams

Khả năng phản hồi là một trong những thông số quan trọng nhất cho sự thành công của bất kỳ ứng dụng web nào. Xử lý không đồng bộ là giải pháp để đạt được khả năng phản hồi này. Yêu cầu máy chủ từ trình duyệt phải trả về ngay lập tức, mà không cần chờ hoàn tất. Luồng dữ liệu phải được thiết kế theo cách không phụ thuộc vào phản hồi ngay lập tức từ máy chủ.

Có một số mẫu kiến ​​trúc để thực hiện điều này nhưng một vấn đề lớn với xử lý không đồng bộ là xử lý lỗi. Làm sao khách hàng biết được nếu yêu cầu không thành công? Chúng ta không nên mất dữ liệu trong quá trình này. Trên thực tế, một dịch vụ fire and forget không thể để xảy ra lỗi. Ngay cả khi quá trình xử lý không thành công vì một lý do nào đó, dữ liệu vẫn phải đến được DB.

DynamoDB Streams cung cấp một giải pháp tuyệt vời cho vấn đề này. Hãy cùng xem thử.

Tại sao nên sử dụng DynamoDB Streams?

DynamoDB Streams tạo ra một luồng sự kiện chảy vào một mục tiêu — Lambda hoặc Kinesis. Chúng ta có thể kích hoạt một hàm Lambda bằng các sự kiện như vậy để có thể xử lý dữ liệu này. Cuộc gọi API đến có thể trực tiếp đổ dữ liệu vào DynamoDB bằng cách sử dụng tích hợp dịch vụ cổng API. Điều này đảm bảo thời gian phản hồi rất thấp trong API. Chúng ta có thể cấu hình DynamoDB Streams để gọi một hàm Lambda có thể xử lý cuộc gọi API đến.

Chúng tôi có một lợi thế ở đây; dữ liệu đã có sẵn trong DB của chúng tôi trước khi chúng tôi bắt đầu xử lý nó. Ngay cả khi quá trình xử lý hạ lưu không thành công, dữ liệu vẫn có sẵn trong DB. Trong trường hợp không mong muốn xảy ra lỗi chèn/cập nhật DB, bản thân API sẽ trả về lỗi và máy khách sẽ có thể xử lý được.

Vì vậy, với DynamoDB Streams, chúng ta có được cả hai lợi thế: thời gian phản hồi thấp và khả năng phục hồi lỗi. Hãy thử triển khai điều này trong tài khoản AWS của chúng ta .

Mã hàm Lambda cho lệnh gọi không đồng bộ

Bắt đầu bằng cách tạo một hàm Lambda , rất đơn giản. Chỉ cần vào bảng điều khiển Lambda và tạo một hàm Lambda mới. Tôi sẽ gọi nó là StreamProcessor (bạn có thể chọn bất kỳ tên nào khác mà bạn thích). Thêm mã bên dưới:

Vai trò IAM cho Lambda

Hàm Lambda này phải có đủ quyền để hoạt động trên các luồng của DynamoDB, cùng với quyền cập nhật. Để có được quyền này, hãy tạo một vai trò IAM mới.

Cùng với các quyền Lambda thông thường, hãy bao gồm mã bên dưới cho các quyền DB:

Bảng DynamoDB

Tiếp theo, chúng ta tạo bảng trong DynamoDB. Bảng này phải có khóa chính, ID. Trên tab “Exports & Streams”, hãy nhấp vào “Enable DynamoDB Streams” (không phải “Kinesis streams”).

Cùng với đó, thêm các trình kích hoạt Lambda vào luồng. Nhấp vào “Create Trigger” và chọn hàm Lambda mà chúng ta đã tạo ở trên. Và điều đó thiết lập luồng cộng với trình kích hoạt. Tiếp theo, hãy chuyển đến tab “Additional Settings”. Ở đó, chúng ta có thể bật TTL (thời gian tồn tại) như bên dưới.

Thao tác này sẽ thiết lập bảng DynamoDB cho chúng ta.

Cổng API

Cuối cùng, chúng ta đến API Gateway để tạo API mà máy khách có thể gọi. Ở đây, chúng ta cấu hình API Gateway để thêm yêu cầu vào bảng cơ sở dữ liệu, chúng ta thực hiện bằng cách sử dụng tích hợp dịch vụ AWS của API Gateway. Hãy cùng làm việc trên đó.

Tạo một REST API mới trên API gateway. Thêm phương thức Put vào đó. Tích hợp yêu cầu với DynamoDB như sau:

Và thêm điều này vào mẫu ánh xạ JSON .

Đối với mỗi lệnh gọi API, lệnh này sẽ thêm một mục mới vào bảng và ID yêu cầu sẽ là khóa. Lệnh chèn này sẽ kích hoạt hàm Lambda và xử lý trước.

Lợi ích của DynamoDB Streams

Bạn có thể hỏi, "Tại sao không gọi trực tiếp Lambda từ API Gateway?" Có hai lý do. Đầu tiên và quan trọng nhất là thời gian phản hồi nhanh hơn. Thêm trực tiếp dữ liệu từ API Gateway vào DynamoDB nhanh hơn nhiều so với việc gọi Lambda. Điều này có nghĩa là ứng dụng khách hàng sẽ thấy phản hồi cực nhanh.

Thứ hai, khả năng phục hồi và xử lý lỗi trở nên phức tạp khi chúng ta gọi Lambda trực tiếp từ API gateway. Chúng ta phải làm gì nếu Lambda bị lỗi giữa chừng? Chúng ta có thử lại cùng một API không? Chúng ta có gọi một API khác để khắc phục thiệt hại không? Đây là quá nhiều thông tin tình báo để chuyển đến máy khách. Tốt nhất là máy chủ tự quản lý các vấn đề này.

Tóm lại, điều này có nghĩa là máy khách có thể đổ dữ liệu vào DynamoDB và có thể yên tâm rằng dữ liệu của họ sẽ được máy chủ chấp nhận và xử lý. Dữ liệu sẽ không bị mất vì nó đã có trong DB. Sau đó, quá trình xử lý và xử lý lỗi sẽ được bản địa hóa trên máy chủ, dẫn đến kiến ​​trúc tổng thể sạch hơn.