SmoothMQ - โซลูชันทดแทน SQS แบบ Drop-in ที่สร้างบน SQLite

 (github.com/poundifdef)
13 คะแนน โดย GN⁺ 2024-07-01 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นบริการแบบ Drop-In ที่สามารถทดแทน SQS ได้โดยตรง ช่วยยกระดับประสบการณ์ของนักพัฒนาอย่างมาก
  • มี UI ที่ใช้งานได้จริง พร้อมความสามารถด้านการมองเห็น การติดตาม การตั้งเวลาข้อความ และการจำกัดอัตรา
  • สามารถรันอินสแตนซ์ SQS ส่วนตัวได้บนทุกคลาวด์
  • ดีพลอยเป็นไบนารี Go เดี่ยว และใช้งานได้จากไคลเอนต์ SQS เดิม
  • UI รันที่ :3000 และเซิร์ฟเวอร์ที่เข้ากันได้กับ SQS รันที่ :3001
  • รองรับการทำงานร่วมกับไคลเอนต์ SQS ของทุกภาษา
    • Python 
      • import boto3  
# เปลี่ยนแค่ endpoint_url เท่านั้น  
sqs = boto3.client("sqs", ..., endpoint_url="http://localhost:3001";)  
sqs.send_message(QueueUrl="...", MessageBody="hello world")
      • ทำงานร่วมกับ Celery ได้อย่างราบรื่นด้วย
      • app = Celery("tasks", broker_url="sqs://...@localhost:3001")

ความเห็นของ GN⁺

  • SmoothMQ ขยายความสามารถของ SQS เพื่อมอบประสบการณ์ที่ดีกว่าให้กับนักพัฒนา
  • มีความยืดหยุ่นสูงเพราะสามารถรันอินสแตนซ์ส่วนตัวได้โดยไม่ผูกติดกับคลาวด์ใดคลาวด์หนึ่ง
  • สามารถใช้ไคลเอนต์ SQS เดิมได้ทันที จึงมีต้นทุนในการย้ายระบบต่ำ
  • สามารถจัดการคิวและข้อความได้ง่ายผ่าน UI ทำให้การปฏิบัติการมีประสิทธิภาพสูง
  • เมื่อนำเทคโนโลยีใหม่มาใช้ ควรพิจารณาความเข้ากันได้กับระบบเดิมอย่างรอบคอบ

บทความที่เกี่ยวข้อง

3 ความคิดเห็น

 
aer0700 2024-07-02

ดูเหมือนว่า SQLite กับ Postgres ก็น่าจะยังถูกใช้อยู่แม้อีก 10 ปีข้างหน้า ส่วน Redis ก็เคยคิดว่าน่าจะเป็นแบบนั้นเหมือนกัน แต่ช่วงนี้ก็ไม่แน่ใจแล้วครับ
 
superwoou 2024-07-02

ทุกวันนี้ใช้ตัวไหนกันแทน Redis ครับ?
 
GN⁺ 2024-07-01
ความคิดเห็นจาก Hacker News

  • ไอเดียในการใช้งานเทคโนโลยี k8s, kubernetes, cloud native, self-hosted, edge-enabled ในราคาประหยัดนั้นยอดเยี่ยม

    • เคยใช้ rq และ minio บน k8s มาหลายปี และช่วงหลังมานี้กำลังจับตา SQLite ในฐานะทางเลือกทดแทน
    • เน้นย้ำความสำคัญของ personal cloud และมองว่าไม่เหมาะที่จะเอาหลายอย่างไปจัดการบน public cloud
    • เป็นไปได้อย่างยิ่งที่เซ็นเซอร์ BTLE จะสื่อสารกับ Apple Watch ได้โดยตรง
    • การต้องวิ่งผ่านคลาวด์ไม่ได้ให้ประโยชน์ และควรแก้ไขเรื่องนี้ในเครื่องมือรุ่นถัดไป

  • ชี้ว่า SQLite ทำงานบนเซิร์ฟเวอร์เดี่ยว และแม้จะใช้ได้ในกรณีส่วนใหญ่ แต่ก็ไม่อาจเชื่อถือได้ 100%

    • หากเซิร์ฟเวอร์คิวล่ม SQS ก็มีแนวโน้มสูงที่จะยังทำงานต่อได้
    • ในกรณีที่ดีที่สุดมันอาจใช้งานได้ แต่คงไม่ให้ความน่าเชื่อถือเทียบเท่า SQS

  • หากไม่นับเรื่องสเกลและเบนช์มาร์ก นี่เป็นเครื่องมือที่มีประโยชน์สำหรับโมดูลทดสอบฟังก์ชัน/ยูนิตที่ใช้ SQS

  • ตั้งเป้าเป็นระบบคิวแบบโฮสต์ โดยมุ่งให้ถูกกว่า SQS โดยไม่ต้องแลกกับประสิทธิภาพ

    • ตั้งเป้าจะประสบความสำเร็จในระบบคิวเหมือนที่ Backblaze และ Minio ทำได้ในตลาด S3

  • ชอบการเขียนบริการที่เข้ากันได้กับ AWS API และกล่าวถึงโปรเจ็กต์ Dyna53

  • หากใช้ LocalStack ก็สามารถใช้ SQS และบริการ AWS อื่น ๆ อีกมากมายสำหรับการทดสอบ/พัฒนาได้ โดยมีเอกสารที่ดีและเป็นโอเพนซอร์ส

  • ชอบโปรเจ็กต์ที่สร้างทางเลือก self-hosted แบบเรียบง่ายสำหรับบริการยอดนิยม

    • คาดว่าจะทำงานร่วมกับ Litestream ได้โดยไม่มีปัญหาใหญ่ และน่าจะยอดเยี่ยมในฐานะระบบคิวชั่วคราวโดยไม่ต้องปรับแต่ง backend storage

  • ข้อเสนอแนะอย่างรวดเร็วเกี่ยวกับโครงสร้างโปรเจ็กต์:

    • เสนอให้ย้าย struct ทั้งหมดจากไดเรกทอรี models/ ไปไว้ที่ไดเรกทอรีราก
    • แบบนี้ผู้ใช้แพ็กเกจจะสามารถใช้ชื่อสั้นและสะอาดอย่าง q.Message และ q.Queue ได้ และยังหลีกเลี่ยงการชนกันของชื่อหากผู้ใช้มีแพ็กเกจ "models" ของตัวเอง

  • กล่าวถึง ElasticMQ โดยใช้มันเพื่อจำลอง SQS ในสภาพแวดล้อม Docker

  • ถามว่าทำไมถึงปิดการรองรับ foreign key แต่ยังใช้งานมันอยู่ในสคีมาฐานข้อมูล

    • คอมเมนต์ "TODO: check for errors" และส่วนที่ดูเหมือนปิดการตรวจสอบข้อจำกัด foreign key ทำให้ลังเลที่จะลองใช้งาน