Khung công việc tích hợp sẵn của Django 6: Ấn tượng đầu tiên của tôi sau khi thử nghiệm

Khi tôi lần đầu tiên nghe nói rằng Django 6 sẽ có một khung công việc gốc, tôi phải thừa nhận rằng tôi đã hoài nghi. Sau nhiều năm vật lộn với cấu hình Celery, xử lý các thiết lập Redis/RabbitMQ và gỡ lỗi các sự cố công nhân bí ẩn, lời hứa về một cái gì đó đơn giản hơn có vẻ gần như quá tốt để trở thành sự thật. Nhưng sau khi dành cả tuần qua để đi sâu vào khung công việc mới, tôi bắt đầu thấy vị trí của nó trong hệ sinh thái Django - và vị trí nó không phù hợp.

Khung công việc mới của Django chính xác là gì?

Khung công việc mới, đã có mặt trong phiên bản alpha của Django 6.0, thể hiện một sự thay đổi cơ bản trong cách Django xử lý công việc nền. Lần đầu tiên, Django cung cấp một cách tích hợp để xác định và xếp hàng đợi các tác vụ cần chạy bên ngoài chu kỳ yêu cầu-phản hồi HTTP.

Khái niệm này cực kỳ đơn giản. Đây là mẫu cơ bản mà tôi đã sử dụng:

from django.core.mail import send_mail
from django.tasks import task

@task
def email_users(emails, subject, message):
    return send_mail(subject, message, None, emails)

Sau khi bạn đã xác định một tác vụ, việc xếp hàng đợi nó rất đơn giản:

email_users.enqueue(
    emails=["[email protected]"],
    subject="Bạn có một tin nhắn",
    message="Xin chào!",
)

Điều khiến tôi ngạc nhiên ngay lập tức là cảm giác tự nhiên của việc này so với việc thiết lập Celery. Không cần phải tạo một ứng dụng Celery riêng biệt, định cấu hình các trình môi giới hoặc quản lý các cài đặt tuần tự hóa phức tạp. Nó chỉ hoạt động - à, kiểu như vậy.

Vấn đề: bạn vẫn cần công nhân

Đây là nơi mọi thứ trở nên thú vị (và có khả năng gây thất vọng cho một số người). Khung công việc của Django xử lý việc tạo và xếp hàng đợi tác vụ, nhưng nó cố tình không cung cấp cơ chế công nhân. Điều này có nghĩa là bạn vẫn cần cơ sở hạ tầng bên ngoài để thực sự thực hiện các tác vụ của mình.

Hai phần phụ trợ tích hợp có trong bản phát hành này chủ yếu dành cho mục đích phát triển và thử nghiệm. Trong môi trường sản xuất, bạn sẽ cần triển khai giải pháp công nhân của riêng mình hoặc tích hợp với các hệ thống xử lý tác vụ hiện có. Quyết định thiết kế này có ý nghĩa khi bạn nghĩ về nó - Django vẫn tập trung vào việc trở thành một khung web hơn là cố gắng giải quyết mọi vấn đề về cơ sở hạ tầng.

So sánh nó với Celery: táo và cam?

Câu hỏi mà mọi người đang hỏi là liệu điều này có thể thay thế Celery hay không. Sau khi thử nghiệm cả hai một cách rộng rãi, tôi nghĩ câu trả lời phức tạp hơn một câu trả lời đơn giản là có hoặc không.

Celery vẫn là nhà vô địch hạng nặng để xử lý tác vụ phân tán phức tạp. Nó cung cấp các tính năng như:

• Nhiều phần phụ trợ môi giới (Redis, RabbitMQ, v.v.)
• Hệ thống định tuyến và ưu tiên phức tạp
• Cơ chế thử lại tích hợp với việc lùi lại theo cấp số nhân
• Xâu chuỗi tác vụ và quy trình làm việc
• Các công cụ giám sát toàn diện

Mặt khác, khung công việc của Django giống như một nền tảng hơn là một giải pháp hoàn chỉnh. Nó hoàn hảo cho các trường hợp sử dụng đơn giản hơn, nơi bạn muốn giảm tải các công việc cơ bản như gửi email hoặc xử lý tải lên mà không cần chi phí cho việc thiết lập Celery đầy đủ.

"Đối với các ứng dụng phức tạp như CMS hoặc hệ thống thương mại điện tử, Celery vẫn là lựa chọn hoàn hảo cho các tác vụ nền. Có thể cấu hình phức tạp hơn các giải pháp thay thế đơn giản hơn, nhưng dự án của bạn sẽ trở nên mạnh mẽ hơn trong tương lai."

Trích dẫn này từ một so sánh gần đây cộng hưởng với kinh nghiệm của tôi. Đối với các dự án cá nhân và công việc khách hàng nhỏ hơn của tôi, khung công việc của Django đang trở thành lựa chọn hàng đầu của tôi. Nhưng đối với các ứng dụng doanh nghiệp có nhu cầu xử lý khối lượng lớn? Celery sẽ không đi đâu cả.

Thiết lập thử nghiệm và những phát hiện ban đầu của tôi

Tôi đã thử nghiệm khung công việc với một vài kịch bản phổ biến:

Thông báo qua email

Ví dụ email ở trên đã hoạt động hoàn hảo trong môi trường phát triển của tôi. Phần phụ trợ ngay lập tức xử lý các tác vụ đồng bộ, điều này là hoàn hảo để thử nghiệm.

Xử lý dữ liệu

Tôi đã tạo các tác vụ để xử lý CSV và tạo báo cáo. Cú pháp decorator giúp bạn dễ dàng chuyển đổi các hàm hiện có:

@task
def process_user_data(user_id):
    # Logic xử lý nặng ở đây
    pass

Bảo trì theo lịch trình

Mặc dù khung công việc của Django không bao gồm lập lịch như Celery Beat, nhưng tôi đã thử nghiệm với các công việc cron để xếp hàng đợi các tác vụ theo các khoảng thời gian cụ thể.

Tùy chọn cấu hình và phụ trợ

Cấu hình diễn ra thông qua cài đặt TASKS trong tệp cài đặt Django của bạn. Khung công việc được thiết kế để có thể mở rộng, vì vậy tôi hy vọng chúng ta sẽ sớm thấy các phần phụ trợ do cộng đồng phát triển cho Redis, hàng đợi cơ sở dữ liệu và các dịch vụ đám mây như AWS SQS.

Điều tôi đánh giá cao là tính linh hoạt - bạn không bị khóa vào một lựa chọn cơ sở hạ tầng cụ thể. Điều này phù hợp với triết lý của Django là cung cấp các giá trị mặc định hợp lý đồng thời cho phép tùy chỉnh.

Những điều thực tế dành cho nhà phát triển Django

Sau một tuần thử nghiệm, đây là lời khuyên của tôi:

Khi nào nên sử dụng các tác vụ Django

• Gửi email và thông báo đơn giản
• Xử lý và tải lên tệp cơ bản
• Chuyển đổi dữ liệu đơn giản
• Môi trường phát triển và thử nghiệm
• Các dự án nơi bạn muốn tránh cơ sở hạ tầng bổ sung

Khi nào nên gắn bó với Celery

• Xử lý tác vụ khối lượng lớn
• Quy trình làm việc và sự phụ thuộc của tác vụ phức tạp
• Nhu cầu giám sát tác vụ và giao diện người dùng quản lý
• Xử lý phân tán trên nhiều máy chủ
• Các công việc nền quan trọng đòi hỏi việc cung cấp được đảm bảo

Chiến lược di chuyển

Nếu bạn hiện đang sử dụng Celery và đang cân nhắc chuyển đổi, tôi khuyên bạn nên bắt đầu từ từ. Xác định các tác vụ nền đơn giản nhất của bạn và di chuyển chúng trước. Giữ Celery cho các quy trình làm việc phức tạp trong khi bạn đánh giá xem khung công việc của Django có đáp ứng nhu cầu của bạn hay không.

Hướng tới tương lai

Việc giới thiệu một khung công việc gốc trong Django 6 có cảm giác như một sự phát triển tự nhiên. Nó lấp đầy khoảng trống cho các nhà phát triển cần xử lý nền cơ bản mà không cần sự phức tạp của một hệ thống hàng đợi tác vụ đầy đủ. Mặc dù nó sẽ không thay thế Celery cho các trường hợp sử dụng phức tạp, nhưng đó là một sự bổ sung đáng hoan nghênh sẽ đơn giản hóa nhiều dự án Django.

Tôi đặc biệt hào hứng xem cộng đồng xây dựng những gì trên nền tảng này. Hệ thống phụ trợ có thể mở rộng có nghĩa là chúng ta có thể sẽ thấy các giải pháp sáng tạo thu hẹp khoảng cách giữa sự đơn giản của Django và sức mạnh của Celery.

Hiện tại, tôi đang tận hưởng sự đơn giản của việc thêm các tác vụ nền vào các dự án Django của mình mà không gặp các vấn đề đau đầu về cấu hình thông thường. Đôi khi, ít hơn thực sự là nhiều hơn.