Cuộc thảo luận gần đây về khả năng sẵn sàng cho môi trường sản xuất của async Django đã làm dấy lên một cuộc tranh luận sôi nổi trong cộng đồng lập trình viên, đặc biệt tập trung vào khía cạnh gây tranh cãi về việc đánh dấu hàm (function coloring) trong các triển khai bất đồng bộ. Mặc dù async Django hứa hẹn cải thiện hiệu suất cho các hoạt động I/O-bound, phản hồi từ cộng đồng cho thấy những lo ngại sâu sắc hơn về các lựa chọn kiến trúc trong lập trình bất đồng bộ hiện đại.
 |
|---|
| So sánh hiệu suất giữa Django-REST và các view async của Ninja làm nổi bật tác động của khả năng async |
Tranh cãi về đánh dấu hàm
Cộng đồng phát triển đã bày tỏ những lo ngại đáng kể về việc triển khai đánh dấu hàm bất đồng bộ trong các framework hiện đại, bao gồm cả Django. Đánh dấu hàm đề cập đến yêu cầu phải đánh dấu rõ ràng các hàm là async/await trong toàn bộ mã nguồn. Lựa chọn thiết kế này đã trở thành một vấn đề gây tranh cãi, với nhiều lập trình viên cho rằng nó tạo ra độ phức tạp không cần thiết và gánh nặng nhận thức.
Tôi thấy việc học Python bất đồng bộ rất khó khăn trong nhiều tháng cho đến khi tôi có được một mô hình tư duy trực quan về luồng mã bất đồng bộ và sau đó mọi thứ bắt đầu trở nên rõ ràng. Tôi chỉ nghĩ về async như là việc song song hóa thời gian chờ.
Tranh luận về mô hình Threading
Một phần đáng kể của cuộc thảo luận xoay quanh việc lựa chọn giữa các mô hình đồng thời khác nhau. Trong khi async/await đã trở nên nổi bật, đặc biệt là trong các ứng dụng tập trung vào AI, một số lập trình viên ủng hộ các phương pháp thay thế như green threads hoặc các mô hình threading truyền thống. Cuộc tranh luận trở nên gay gắt hơn khi Python đang hướng tới threading không GIL và máy tính tiếp tục thêm nhiều lõi, đặt ra câu hỏi liệu lập trình bất đồng bộ có phải là giải pháp tối ưu cho mọi tình huống hay không.
Giải pháp thay thế Sans-IO
Một góc nhìn thú vị xuất hiện từ cộng đồng đề xuất một cách tiếp cận hoàn toàn khác: mô hình sans-IO. Mô hình kiến trúc này đề xuất tách biệt các hoạt động I/O khỏi logic cốt lõi, cho phép các thư viện độc lập với phương thức điều phối I/O. Cách tiếp cận này sẽ cho phép các nhà phát triển lựa chọn phương thức I/O ưa thích mà không bị ràng buộc vào một mô hình đồng thời cụ thể.
Cân nhắc hiệu suất trong thực tế
Kinh nghiệm của cộng đồng với async Django trong môi trường sản xuất cho thấy một bức tranh có nhiều khía cạnh. Trong khi các triển khai bất đồng bộ có thể cải thiện đáng kể hiệu suất cho các hoạt động I/O-bound, đặc biệt là trong các khối lượng công việc AI với các cuộc gọi API kéo dài, những lợi ích này đi kèm với một số điều kiện. Những cải thiện về hiệu suất được nhận thấy rõ nhất trong các ứng dụng chủ yếu là bất đồng bộ, trong khi các codebase kết hợp đồng bộ/bất đồng bộ có thể thực sự thấy hiệu suất giảm do chi phí chuyển đổi ngữ cảnh.
Những điểm quan trọng cần xem xét khi triển khai Django bất đồng bộ:
- Yêu cầu hỗ trợ bất đồng bộ đầy đủ trong toàn bộ codebase
- Chi phí hiệu năng khoảng 1ms cho việc chuyển đổi giữa đồng bộ/bất đồng bộ
- Yêu cầu máy chủ web ASGI ( Daphne hoặc Uvicorn )
- Cần middleware tương thích bất đồng bộ
- Phù hợp nhất với các tác vụ giới hạn bởi I/O
Kết luận
Cuộc tranh luận xung quanh async Django phản ánh một cuộc thảo luận rộng lớn hơn trong cộng đồng phát triển phần mềm về sự đánh đổi giữa các mô hình đồng thời khác nhau. Mặc dù lập trình bất đồng bộ mang lại những lợi ích rõ ràng cho một số trường hợp sử dụng nhất định, đặc biệt là trong các ứng dụng nặng về AI, phản hồi từ cộng đồng cho thấy việc triển khai đánh dấu hàm hiện tại có thể cần được suy nghĩ lại để giảm độ phức tạp và cải thiện trải nghiệm cho nhà phát triển.
Nguồn tham khảo: Is async django ready for prime time?