Hatchet แพลตฟอร์มจัดการงานเบื้องหลังที่สร้างบน PostgreSQL ได้เปิดตัวรุ่น v1 อย่างเป็นทางการแล้ว แพลตฟอร์มนี้มีเป้าหมายเพื่อแก้ไขปัญหาทั่วไปที่นักพัฒนาเผชิญเมื่อต้องจัดการงานเบื้องหลังในระดับใหญ่ โดยนำเสนอทางเลือกให้กับระบบคิวงานแบบดั้งเดิมอย่าง Celery หรือ BullMQ รวมถึงเครื่องมือจัดการเวิร์กโฟลว์อย่าง Temporal และ Airflow
งานเบื้องหลังเป็นสิ่งจำเป็นสำหรับแอปพลิเคชันสมัยใหม่ ช่วยลดภาระงานจากเว็บเซิร์ฟเวอร์และทำให้มั่นใจว่าการทำงานที่สำคัญจะเสร็จสมบูรณ์แม้ในช่วงที่มีการเข้าชมสูง ในขณะที่นักพัฒนาหลายคนเริ่มต้นด้วยคิวอย่างง่ายที่ใช้ Redis หรือ RabbitMQ แต่วิธีแก้ปัญหาเหล่านี้มักจะยากต่อการดีบักและตรวจสอบเมื่อแอปพลิเคชันมีความซับซ้อนมากขึ้น
สถาปัตยกรรมบน PostgreSQL ที่มีความสามารถในการขยายตัวที่น่าประทับใจ
ทีม Hatchet ได้ทำการเปลี่ยนแปลงสถาปัตยกรรมที่สำคัญในรุ่น v1 โดยเปลี่ยนจากรูปแบบ FOR UPDATE SKIP LOCKED ที่ใช้กันทั่วไปในคิวที่ใช้ PostgreSQL ตามที่นักพัฒนากล่าว วิธีนี้ไม่สามารถขยายได้ดีเกิน 25,000 คิวรีต่อวินาที โดยเฉพาะเมื่อต้องจัดการกับเวิร์กเกอร์จำนวนมากและมีงานคงค้างจำนวนมาก
เดิมทีเราได้รวมตารางเวิร์กโฟลว์บางส่วนกับตารางการตรวจสอบของเรา... ตารางนี้ใช้ UUID เป็นคีย์หลัก เพราะเราต้องการใช้ UUID ผ่าน API แทนที่จะใช้ ID แบบเพิ่มขึ้นอัตโนมัติ UUID เหล่านี้ทำให้เกิดปัญหาในภายหลังเมื่อพยายามลบข้อมูลเป็นชุดและป้องกันการบวมของดัชนี
ทีมได้นำการปรับปรุงประสิทธิภาพหลายอย่างมาใช้ รวมถึงการแยกตารางตรวจสอบออกจากตารางคิวเพื่อป้องกันปัญหาเช่นตารางที่บวมเกินไป การบัฟเฟอร์การอ่านและเขียนเพื่อลดภาระของฐานข้อมูล และการเปลี่ยนตารางที่มีปริมาณสูงให้ใช้คอลัมน์ identity แทน UUID การเปลี่ยนแปลงเหล่านี้ช่วยปรับปรุงประสิทธิภาพและความเสถียรภายใต้โหลดที่หนักอย่างมีนัยสำคัญ
รูปแบบการทำงานที่ยืดหยุ่น
Hatchet รองรับรูปแบบการทำงานหลายรูปแบบ เพื่อตอบสนองความต้องการของนักพัฒนาที่แตกต่างกัน แพลตฟอร์มนี้นำเสนอทั้งคิวงานแบบดั้งเดิมสำหรับงานเบื้องหลังอย่างง่ายและการจัดการเวิร์กโฟลว์ที่ซับซ้อนมากขึ้นผ่านกราฟแบบ directed acyclic graphs (DAGs) และรูปแบบการทำงานแบบถาวร
สำหรับนักพัฒนาที่มาจากระบบเช่น Celery หรือ SQS, Hatchet มีฟังก์ชันคิวที่คุ้นเคยพร้อมการตรวจสอบที่ดีขึ้น สำหรับผู้ที่ต้องการเวิร์กโฟลว์ที่ซับซ้อนมากขึ้น แพลตฟอร์มนี้รองรับการสร้างงานย่อยและรูปแบบการทำงานแบบถาวรคล้ายกับเวิร์กโฟลว์และกิจกรรมของ Temporal
ผู้ใช้รายหนึ่งเน้นย้ำว่าการรองรับ Pydantic แบบเต็มรูปแบบใน SDK v1 เป็นข้อได้เปรียบหลักสำหรับนักพัฒนาที่เปลี่ยนจาก Celery โดยระบุว่าความปลอดภัยของประเภทข้อมูลช่วยปรับปรุงประสบการณ์ของนักพัฒนาอย่างมาก การผสมผสานระหว่าง SDK ของ Python และ TypeScript ยังช่วยให้มีความยืดหยุ่นมากขึ้นในการใช้งาน โดยยังมีการรองรับ Go ด้วย
คุณสมบัติหลักของ Hatchet
- คิว: คิวงานที่ทนทานสำหรับการดำเนินงานที่เชื่อถือได้
- รองรับภาษาโปรแกรมมิ่ง: SDK สำหรับ Python, TypeScript และ Go
- การจัดการงาน: รองรับ DAGs (Directed Acyclic Graphs)
- การควบคุมการทำงาน: ตรรกะเงื่อนไขและการแยกสาขา
- การกำหนดเวลา: การดำเนินงานตามเวลาที่กำหนด
- การจัดการการทำงานพร้อมกัน: การควบคุมการทำงานพร้อมกันแบบไดนามิก
- การจำกัดอัตรา: ควบคุมอัตราการดำเนินงาน
- การตรวจสอบ: แดชบอร์ดเว็บแบบเรียลไทม์
- ตัวเลือกการติดตั้ง: บริการคลาวด์หรือติดตั้งเอง
วิธีการติดตั้ง
- Hatchet Cloud: บริการที่มีการจัดการ
- Hatchet Lite: ตัวเลือกการติดตั้งเองแบบรวมชุด
- Docker Compose: การติดตั้งแบบหลายคอนเทนเนอร์
- Kubernetes: มี Helm chart ให้ใช้งาน
จุดเปรียบเทียบ
- เทียบกับ Temporal: เน้นนักพัฒนาแอปพลิเคชันมากกว่าการจัดการเวิร์กโฟลว์
- เทียบกับคิวงาน (BullMQ, Celery): การตรวจสอบที่ดีกว่า การดำเนินงานที่ทนทานมากกว่า
- เทียบกับแพลตฟอร์ม DAG (Airflow, Prefect, Dagster): มุ่งเน้นความต้องการของแอปพลิเคชันมากกว่าไปป์ไลน์ข้อมูล
- เทียบกับ Cloud Tasks: มีความสามารถในการจัดการที่ซับซ้อนมากกว่าแต่มีการรองรับ webhook ที่คล้ายกัน
ประสบการณ์นักพัฒนาและการตรวจสอบ
Hatchet ให้ความสำคัญอย่างมากกับการสังเกตการณ์และประสบการณ์ของนักพัฒนา ไม่เหมือนกับระบบคิวงานหลายระบบที่การตรวจสอบจะกลายเป็นความท้าทายเมื่อขยายขนาด Hatchet แยกโครงสร้างพื้นฐานการตรวจสอบออกจากตารางคิว ช่วยให้นักพัฒนาสามารถสืบค้นทั้งคิวที่ใช้งานอยู่และข้อมูลงานในอดีตโดยไม่ทำให้ประสิทธิภาพลดลง
แพลตฟอร์มนี้มีแดชบอร์ดเว็บแบบเรียลไทม์ที่ให้การมองเห็นที่ดีขึ้นเมื่อเทียบกับเครื่องมืออย่าง Flower ของ Celery การเน้นที่การตรวจสอบนี้แก้ไขจุดที่เป็นปัญหาทั่วไปที่ผู้ใช้ยกขึ้นมา - การทำความเข้าใจว่าเกิดอะไรขึ้นเมื่องานล้มเหลวและวิธีการดีบักปัญหาอย่างมีประสิทธิภาพ
ผู้ใช้บางรายได้สังเกตเห็นข้อบกพร่องในแดชบอร์ดและเอกสาร แม้ว่าทีมดูเหมือนจะตอบสนองต่อข้อเสนอแนะ การแยกการตรวจสอบออกจากตารางคิวยังช่วยให้มีตัวเลือกในการเรียกใช้การตรวจสอบบนฐานข้อมูลที่แยกออกมาโดยสิ้นเชิงหากจำเป็น ซึ่งให้ความยืดหยุ่นเพิ่มเติมสำหรับการใช้งานในระดับสูง
ตัวเลือกการปรับใช้และการบูรณาการ
Hatchet มีให้บริการทั้งในรูปแบบบริการคลาวด์และโซลูชันที่โฮสต์เอง สำหรับการโฮสต์เอง ทีมจัดเตรียมตัวเลือก hatchet-lite ที่รวมบริการภายในทั้งหมด รวมถึงตัวเลือกการปรับใช้ที่ซับซ้อนมากขึ้นผ่าน Docker Compose และ Helm charts สำหรับ Kubernetes
แพลตฟอร์มนี้ยังรองรับเวิร์กเกอร์แบบ webhook ซึ่งช่วยให้งานสามารถเรียกใช้ HTTP endpoints แทนที่จะต้องใช้เวิร์กเกอร์ที่ทำงานเป็นเวลานาน วิธีนี้ให้ความยืดหยุ่นคล้ายกับบริการเช่น Google Cloud Tasks แม้ว่าผู้ใช้บางรายจะสังเกตว่าฟังก์ชันนี้ดูเหมือนจะมีเอกสารที่ไม่โดดเด่นเท่ากับคุณสมบัติอื่น ๆ
ในขณะที่ Hatchet มุ่งเน้นไปที่นักพัฒนา Python, TypeScript และ Go ทีมกำลังติดตามคำขอสำหรับ SDK ภาษาเพิ่มเติม สถาปัตยกรรมของแพลตฟอร์มที่ใช้ gRPC สำหรับการสื่อสารของเวิร์กเกอร์อาจนำเสนอความท้าทายสำหรับการบูรณาการ API โดยตรงโดยไม่ใช้ SDK อย่างเป็นทางการ
ในขณะที่การจัดการงานเบื้องหลังยังคงเป็นองค์ประกอบสำคัญของสถาปัตยกรรมแอปพลิเคชันสมัยใหม่ วิธีการของ Hatchet ในการรวมความน่าเชื่อถือของ PostgreSQL กับคุณสมบัติการจัดการขั้นสูงทำให้เป็นตัวเลือกที่น่าสนใจสำหรับทีมพัฒนาที่ต้องการขยายความสามารถในการประมวลผลเบื้องหลัง
อ้างอิง: Run Background Tasks at Scale