ชุมชนเทคโนโลยีกำลังหารือกันอย่างกระตือรือร้นเกี่ยวกับข้อดีและข้อเสียของแนวทางต่างๆ ในการจัดตารางงาน หลังจากทีมพัฒนาแห่งหนึ่งได้แบ่งปันเส้นทางการเดินทางจาก cron jobs ที่กระจัดกระจายไปสู่ตัวจัดตารางงานแบบรวมศูนย์ การสนทนานี้เผยให้เห็นรูปแบบทั่วไปในการพัฒนาซอฟต์แวร์ที่ทีมงานมักพบว่าตัวเองกำลังสร้างโซลูชันแบบกำหนดเองที่ค่อยๆ พัฒนาไปสู่ความซับซ้อนของเฟรมเวิร์กที่มีอยู่แล้ว
ปัญหาระหว่างการสร้างเองกับการซื้อ
นักพัฒนาหลายคนเผชิญกับความท้าทายที่คุ้นเคยเมื่อเครื่องมือที่มีอยู่รู้สึกว่าง่ายเกินไปหรือซับซ้อนเกินไปสำหรับความต้องการของพวกเขา การสนทนานี้เน้นให้เห็นว่าทีมงานมักเริ่มต้นด้วย cron jobs พื้นฐาน จากนั้นสร้างตัวจัดตารางแบบกำหนดเองเพื่อแก้ไขข้อจำกัด แต่กลับพบปัญหาเดียวกันที่เฟรมเวิร์กที่มีอยู่แล้วถูกออกแบบมาเพื่อแก้ไข นักพัฒนาที่มีประสบการณ์คนหนึ่งกล่าวถึงการพัฒนาที่หลีกเลี่ยงไม่ได้ที่โซลูชันง่ายๆ จะค่อยๆ สะสมฟีเจอร์จนกระทั่งสะท้อนความซับซ้อนของเฟรมเวิร์กที่มีอยู่
คอมโพเนนต์ของ Custom Task Scheduler
| คอมโพเนนต์ | วัตถุประสงค์ | การใช้งาน |
|---|---|---|
| ตาราง ScheduledTasks | จัดเก็บงานส่วนกลาง | ตารางฐานข้อมูลที่มีสถานะ เวลาประทับ และข้อมูล payload |
| Cron job | ตัวกระตุ้นการทำงาน | ทำงานทุกนาทีเพื่อประมวลผลงานที่ถึงกำหนด |
| SQS consumer | ตัวประมวลผลงาน | จัดการการทำงานจริงของงาน |
| ประเภท Payload | คำจำกัดความของงาน | PUBLISH_EVENT, SEND_EMAIL เป็นต้น |
ทางเลือก Cloud-Native ได้รับความสนใจ
สมาชิกชุมชนหลายคนสนับสนุนการใช้ประโยชน์จากโซลูชันของผู้ให้บริการคลาวด์แทนการสร้างระบบแบบกำหนดเอง AWS, Google Cloud และแพลตฟอร์มอื่นๆ เสนอบริการจัดตารางงานที่ผ่านการทดสอบแล้ว ซึ่งให้การรับประกันความน่าเชื่อถือและขนาดระดับโลก Kubernetes cron jobs ก็ปรากฏเป็นตัวเลือกกึ่งกลางที่ได้รับความนิยม โดยเสนอความน่าเชื่อถือมากกว่า cron พื้นฐานในขณะที่หลีกเลี่ยงความซับซ้อนของเฟรมเวิร์กเวิร์กโฟลว์แบบเต็มรูปแบบ
โซลูชันการจัดตารางงานทางเลือก
- บริการคลาวด์: AWS EventBridge , Google Cloud Scheduler
- โซลูชันคอนเทนเนอร์: Kubernetes CronJobs
- คิวข้อความ: RabbitMQ พร้อมข้อความที่ล่าช้า
- เฟรมเวิร์กเวิร์กโฟลว์: Temporal.io , Apache Airflow
- ระบบคิวงาน: Sidekiq , Celery , Faktory , Beanstalkd
- การจัดการบริการ: systemd , daemontools , s6
วิวัฒนาการการจัดการ Daemon
การสนทนาทางเทคนิคที่น่าสนใจเกิดขึ้นเกี่ยวกับเหตุผลที่นักพัฒนามักเลือก cron jobs มากกว่าบริการที่ทำงานอย่างต่อเนื่อง การสนทนาย้อนกลับไปถึงแนวทางปฏิบัตินี้จากข้อจำกัดทางประวัติศาสตร์ในเครื่องมือจัดการ daemon แม้ว่าโซลูชันการจัดการบริการที่เหมาะสมจะมีอยู่ตั้งแต่ปี 1990 เครื่องมือสมัยใหม่อย่าง systemd ได้ปรับปรุงความน่าเชื่อถือของบริการที่ทำงานระยะยาวอย่างมีนัยสำคัญ ทำให้เป็นทางเลือกที่เป็นไปได้มากกว่าสำหรับ cron jobs แบบเป็นระยะ
มันเป็นภูมิปัญญาพื้นบ้าน ที่เกิดจากคนรุ่นต่อรุ่นที่ไม่มีการจัดการ daemon ที่เหมาะสม แม้ว่าเครื่องมือดังกล่าวจะมีอยู่ตั้งแต่ปี 1990
คำแนะนำเฟรมเวิร์กเริ่มปรากฏขึ้น
ชุมชนแนะนำโซลูชันที่มีอยู่แล้วหลายตัวสำหรับทีมที่ต้องจัดการกับความต้องการการจัดตารางที่ซับซ้อน เครื่องมืออย่าง Temporal.io, RabbitMQ พร้อมข้อความที่ล่าช้า และระบบคิวงานต่างๆ เช่น Sidekiq, Celery และ Faktory ถูกกล่าวถึงเป็นทางเลือกที่เป็นผู้ใหญ่ เฟรมเวิร์กเหล่านี้มักเสนอฟีเจอร์เช่นการลองใหม่ การตรวจสอบ และความพร้อมใช้งานสูงที่โซลูชันแบบกำหนดเองมักประสบปัญหาในการนำไปใช้อย่างน่าเชื่อถือ
บทสรุป
การสนทนานี้สะท้อนแนวโน้มที่กว้างขึ้นในการพัฒนาซอฟต์แวร์ที่ทีมงานต้องสร้างสมดุลระหว่างความเรียบง่ายของโซลูชันแบบกำหนดเองกับความแข็งแกร่งของเฟรมเวิร์กที่มีอยู่แล้ว แม้ว่าการสร้างตัวจัดตารางงานแบบกำหนดเองสามารถตอบสนองความต้องการเฉพาะหน้าและให้ประสบการณ์การเรียนรู้ที่มีค่า แต่ฉันทามติของชุมชนแนะนำว่าทีมงานควรพิจารณาอย่างรอบคอบว่าบริการคลาวด์ที่มีอยู่หรือเฟรมเวิร์กโอเพนซอร์สอาจตอบสนองความต้องการระยะยาวได้ดีกว่า สิ่งสำคัญคือการรู้จักเมื่อไหร่ที่โซลูชันง่ายๆ เพียงพอ และเมื่อไหร่ที่ถึงเวลาใช้เครื่องมือที่ครอบคลุมมากขึ้นก่อนที่การเพิ่มฟีเจอร์จะทำให้ระบบแบบกำหนดเองใช้งานยาก
อ้างอิง: Replacing cron jobs with a centralized task scheduler