ทำไมสถาปัตยกรรมที่อิงกับ Message Queue ถึงได้รับความนิยมน้อยลงในช่วงนี้?
(news.ycombinator.com)- จนถึงช่วงต้นทศวรรษ 2010 ยังมีการพูดถึงการสร้างระบบกระจายแบบอิง MQ กันมาก แต่ช่วงนี้แทบไม่ค่อยเห็นบทความแล้ว
- มีทฤษฎีที่พอนึกออกอยู่ไม่กี่ข้อดังนี้ ไม่รู้ว่าเป็นหนึ่งในนี้หรือมีมุมมองอื่นอย่างไรบ้าง
- Redis จัดการได้แทบทุกกรณีรวมถึงแคชด้วย จนการดูแล message broker แยกต่างหากไม่ค่อยมีประโยชน์อีกต่อไป ส่วน Kafka ก็ไปอยู่ในระดับใหญ่มากจริง ๆ
- DB (ถ้ามองแบบกว้าง ๆ) เก่งขึ้นมากในการจัดการงานขนาดใหญ่ จนงานแบบ "ชั่วคราว" ถูกย้ายไปจัดการในที่เก็บข้อมูลหลัก
- ผู้คนพบว่าสถาปัตยกรรมแบบอิง MQ ไม่ได้ทำงานดีอย่างที่คาดไว้ จึงหันไปใช้วิธีอื่น
- หรือจริง ๆ แล้วเทคโนโลยี MQ เข้าสู่ช่วงเติบโตเต็มที่แล้ว เลยไม่ได้น่าสนใจพอให้คนเขียนถึง แต่ก็ยังถูกใช้อย่างแพร่หลาย
hnthrowaway_99
- สถาปัตยกรรม "ยอดนิยม" จำนวนมากในช่วงปลายยุค 2000 ถึงต้นยุค 2010 สุดท้ายก็หายไปหลังจากคนตระหนักว่า "คุณไม่ใช่ Google และบริษัทของคุณไม่มีวันเป็น Google"
- ในช่วงนั้นมีแรงปรารถนาอย่างมากที่จะ "สร้างระบบแบบเดียวกับที่บริษัทยักษ์ใหญ่ที่ประสบความสำเร็จสร้าง"
- แต่หลังจากนั้นคนจำนวนมากก็เริ่มตระหนักว่า 99% ของบริษัทไม่จำเป็นต้องมีความซับซ้อนแบบนั้น
- เมื่อฮาร์ดแวร์และฐานข้อมูลมาตรฐานดีขึ้นมาก บริษัทที่ต้องใช้ "Scalability Trick" แบบนี้ก็ยิ่งน้อยลงเรื่อย ๆ
- เกณฑ์ของผมสำหรับคำถามว่า "มีเหตุผลอะไรไหมที่เราไม่ทำทั้งหมดนี้ด้วย Postgres?" วันนี้สูงกว่าเมื่อ 10 ปีก่อนมาก
- ความเห็นตอบกลับในคอมเมนต์นี้
- ตอนนี้มี single machine ที่ใหญ่กว่ามากและใช้งานได้ในราคาสมเหตุสมผล แต่ก่อนต้องใช้คลัสเตอร์ขนาดเล็ก ตอนนี้ระบบเดียวก็รองรับ workload ได้หลากหลายมากขึ้นแล้ว
- พูดตรง ๆ ผมเองเคยมีส่วนร่วมในหลายโปรเจ็กต์ที่ Google ซึ่งทำเพื่อลดการใช้คิวออกไป ดังนั้นอาจไม่ใช่แค่ "ความนิยมลดลง" ด้วยซ้ำ
biglain
- จะฟังดูประชดหน่อย แต่ผมคิดว่าสถาปัตยกรรม MQ และการเขียนบล็อกเกี่ยวกับมันเป็น "Resume Driven Development" มากกว่า ทั้งที่งานจริงยังไม่จำเป็นต้องขยายเกิน monolith และรันบนโน้ตบุ๊กเครื่องเดียวได้ด้วยซ้ำ
- คนกลุ่มนี้น่าจะเป็นพวกเดียวกับที่สร้างหายนะแบบ microservice ที่ทำให้ต้องจ่ายค่า AWS เดือนละเป็นหลักแสนแบบฝันร้าย
- และตอนนี้คนที่ "ให้ความสำคัญกับการสะสมผลงานทางเทคนิคมากกว่าการแก้ปัญหาทางธุรกิจจริงอย่างเป็นรูปธรรม" ก็กำลังปั่นกระแส AI และเขียนบล็อกเกี่ยวกับมันอยู่
tuckerconnelly
- ช่วงหลังผมเพิ่งย้ายจาก microservices กลับไป monolith เพราะมันซับซ้อนเกินไปและมีโค้ดซ้ำเยอะมาก ถ้าไม่มี microservices ความจำเป็นของ message queue ก็ลดลง
- สำหรับงาน asynchronous ผมเคยใช้ RabbitMQ ในโปรเจ็กต์หนึ่ง แต่รู้สึกว่า มันเก่าและออกแบบเกินความจำเป็นมาก
- และเครื่องมือรอบ ๆ มันหลายตัว (เช่น Celery) ก็ไม่ได้ดีเท่าเครื่องมือยุคใหม่ที่สร้างรอบ redis (bullmq)
- สำหรับกระบวนการหลายขั้นแบบ DAG ผมชอบรวมทุกอย่างไว้ใน job ใหญ่ตัวเดียว หรือไม่ก็แบ่งเป็น job จำนวนน้อยเท่าที่ทำได้
- ถ้าต้องใช้ DAG จริง ๆ ก็มีเครื่องมือที่ทำมาเพื่อสิ่งนี้โดยเฉพาะอย่าง Airflow แต่ได้ยินมาว่าดีบักปัญหาได้ยาก จึงควรหลีกเลี่ยงถ้าเป็นไปได้
- ผมคิดว่าสถาปัตยกรรม multi-node ของ Redis ซับซ้อนเกินเหตุและมีปัญหาเรื่องการสเกล ผมเลยยังยึด single node อยู่ แต่การทำ sharding แบบ manual สำหรับผมก็โอเคและใช้งานได้ดี
- คอมเมนต์ของ kypro ต่อโพสต์นี้
- จากประสบการณ์ของผม monolith ไม่ได้ลดความซับซ้อน แต่มันแค่ย้ายความซับซ้อนไปอีกที่หนึ่ง
- ปัญหาใหญ่ที่สุดของ monolith คือเรื่องที่ concerns ระหว่างโดเมนต่าง ๆ ไม่ได้ถูกแยกอย่างชัดเจนและเป็นรูปธรรม ทำให้เมื่อเวลาผ่านไป codebase ของ monolith มักกลายเป็นสปาเกตตีโค้ดที่เชื่อมโยงกันยุ่งเหยิงอย่างมาก
- โดยเฉพาะเมื่อสร้างโปรเจ็กต์ขนาดใหญ่ร่วมกับนักพัฒนาจำนวนมาก และมีนักพัฒนาหลายคนที่ไม่ได้เข้าใจความซับซ้อนของโดเมนทั้งหมดของโค้ดที่ตนแตะต้อง ก็ยิ่งเป็นเช่นนั้น
- monolith เหมาะกับโปรเจ็กต์ขนาดเล็กที่มีนักพัฒนาไม่มาก แต่ถ้าไม่ใช่แบบนั้น ส่วนใหญ่ภายในไม่กี่ปีก็มักจะเสียใจที่สร้าง monolith ขึ้นมา
- และผมก็ไม่เห็นด้วยเรื่องจุดที่มีโค้ดซ้ำด้วย ถ้าใช้ภาษาเดียวกันและแชร์แพ็กเกจระหว่างโปรเจ็กต์ได้ ผมไม่เข้าใจว่าทำไมมันถึงเป็นปัญหาใหญ่นัก
- อย่างไรก็ตาม ระหว่างที่ทำงานกับ microservices ผมไม่เคยเจอปัญหาเหล่านี้เลย
- และผมก็อยากตั้งคำถามด้วยว่า microservices โดยเฉลี่ยซับซ้อนกว่า monolith จริงหรือไม่
- สิ่งที่ผมชอบที่สุดในสถาปัตยกรรม microservices คือการที่แต่ละ microservice เข้าใจง่ายและร่วมพัฒนาได้ง่ายเพียงใด
- สถาปัตยกรรมและการ provision ของ microservices อาจซับซ้อนกว่า แต่ในมุมของนักพัฒนาที่ทำงานกับแต่ละ service แล้ว มันทำงานได้ง่ายกว่า monolith มาก
democracy
- ผมคิดว่ามุมมองนี้น่าจะถูกต้อง: "เทคโนโลยี MQ เข้าสู่ช่วงเติบโตเต็มที่แล้ว เลยไม่ได้น่าสนใจพอให้คนเขียนถึง แต่ก็ยังถูกใช้อย่างแพร่หลาย"
- สถาปัตยกรรมที่อิงกับ messaging ยังได้รับความนิยมมาก
- ความเห็นในโพสต์นี้
- casper14 : เห็นด้วย มันกลายเป็นเพียงเครื่องมือชิ้นหนึ่งไปแล้ว เหมือนกับที่ไม่มีใครเขียนถึงวิธีใช้ virtual machine บนคลาวด์อีกต่อไป
- bwhaley : นี่แหละคำตอบ ระบบกระจายเกือบทุกระบบที่รันในระดับใหญ่ ล้วนใช้ message queue ในระดับหนึ่งแน่นอน
- ipsum2 : นี่น่าจะใช่ แต่ก่อนโพสต์เรื่อง rewrite Angular เป็น React ได้รับความนิยม แต่ตอนนี้ทุกคนแค่ใช้ React กันไปเลย หรือไม่ก็เขียนเรื่อง rewrite React เป็น Vue แทน
busterarm
- ผมจะให้คำตอบที่อาจไม่ค่อยมีคนชอบนัก
- คิว, สตรีม และ Pub/Sub เป็นแนวคิดที่วิศวกรส่วนใหญ่ยังเข้าใจไม่ดี
- ไม่รู้ว่าเมื่อไรควรใช้ ไม่รู้วิธีใช้ให้ถูก และเอาไปใช้ผิดงานด้วย
- ผมยังทำงานกับทั้งหมดที่กล่าวมาข้างต้นอยู่ (SQS/SNS/RabbitMQ/Kafka/Google Pub/Sub)
- ผมทำงานอยู่ที่บริษัทที่จ้างเฉพาะวิศวกรที่ "เก่งมาก" จากมหาวิทยาลัยระดับท็อป 3-4 แห่งในอเมริกาเหนือ และเกือบทุกคนเป็นงานแรกของตัวเอง
- วิศวกรของเราทำเรื่องบ้าคลั่งแบบนี้มาแล้ว:
- โยนข้อความขนาด 100MB จำนวนหลายหมื่นรายการเข้า RabbitMQ ในเวลาอันสั้น แล้วสงสัยว่าทำไมมันถึงระเบิด
- ส่งข้อความขนาดค่อนข้างใหญ่ผ่าน RabbitMQ เป็นประจำ ทั้งที่มีคำเตือนไม่ให้ทำแบบนี้เต็มไปหมด
- เริ่มโปรเจ็กต์ใหม่บน RabbitMQ เวอร์ชันล่าสุดของปี 2024 แล้วพยายามใช้ classic queue
- สร้าง quorum queue โดยไม่มีนโยบาย replication หรือพูดง่าย ๆ คือไม่ทำอะไรเลยเพื่อให้มี HA
- เปิดคลัสเตอร์ออกสู่อินเทอร์เน็ตทั้งที่ผู้ใช้แอดมินยังเป็น guest/guest
- สถาปนิกระดับสูงที่สุดขององค์กรประกาศรูปแบบสถาปัตยกรรมใหม่ จัดประชุมทั้งองค์กรและเดโมให้ดู
- ยกย่องคุณธรรม/แพตเทิร์นใหม่ที่ให้เอาข้อความใส่คิว แล้วสร้าง backchannel เพื่อให้ consumer ตัวที่สองมาประมวลผลข้อความในคิวแบบ on-demand ได้ (ซึ่งทำให้มันไม่ใช่คิวอีกต่อไป)
- และไม่มีใครเลยนอกจากผมที่พูดว่า "ทำไมถึงเอาข้อความที่ต้องประมวลผลตามลำดับมาใส่คิว?" แล้วสุดท้าย 'แพตเทิร์น' นั้นก็ถูกใช้งานจริง!
- ใช้ Kafka เป็น message queue หลักโดยปริยาย
- ส่งข้อมูลจาก data center กลางไปยัง data center ที่กระจายทั่วโลก พร้อมทั้งใส่ global lock บน object และทำทุกอย่างจนกว่าแต่ละปลายทางจะยืนยันว่าได้รับ object ที่อัปเดตแล้ว ทั้งที่ข้อมูลนี้ถูกส่งมาพร้อมกับ AJAX request แต่ก็ยังอ้างว่ากระบวนการนี้เป็น asynchronous
- สุดท้ายผู้คนก็ยังทำงานได้ดีอยู่แม้ไม่จำเป็นต้องทำอะไรยิ่งใหญ่นัก ดังนั้นเครื่องมือจึงถูกใช้ผิด ใช้เกิน และใช้ไม่เต็มประสิทธิภาพ
- ถ้าที่ไหนใช้งานมันได้ดี คุณก็คงไม่ค่อยได้ยินเรื่องราวจากที่นั่นหรอก
- ข้อเท็จจริงสำคัญ: องค์กรของเรามี microservices มากกว่า 30 ตัวต่อวิศวกร 1 คน ได้โปรดฆ่าผมที ผมยอมกลายเป็น Kurt Cobain ตามตัวอักษรดีกว่าไปทำงานในองค์กรอื่นที่มี microservices หลายพันตัวใน monorepo ขนาดยักษ์
- ความเห็นในโพสต์นี้
- zug_zug : ถ้าจะสนับสนุนทฤษฎีนี้ด้วยข้อมูลจริง
- ผมเคยทำงานที่สตาร์ตอัปในนิวยอร์กซึ่งใช้ Akka (ระบบคิวแบบ event-driven ของ Scala)
- ทำไมถึงใช้? เพราะผู้จัดการจากที่ทำงานเก่าบอกว่าวิธีนี้เคย "ช่วยบริษัทไว้" ตอนที่ "ทุกอย่างช้าไปหมด" แล้วจึงบังคับใช้ในที่ทำงานใหม่ด้วยหรือเปล่า?
- งานที่ต้องใช้คิวจริง ๆ คืออะไร? ก็แค่แสดง 401k ของพนักงานผ่านเว็บไซต์ ให้พวกเขาปรับสัดส่วนสินทรัพย์ และส่งอีเมลวันละไม่กี่ร้อยฉบับเท่านั้น
- และอย่างที่คาด คนแทบไม่เคยล็อกอินเข้าเว็บไซต์ 401k เลย
- หลังจากทำงานที่นั่นราวหนึ่งปี ผมก็พบว่าเซิร์ฟเวอร์ถูกตั้งค่าผิดมาตลอด และโดยพื้นฐานแล้วมี concurrency สำหรับ web request เท่ากับ 0
- (ไม่มีใครรู้เพราะ production server แค่ 2 เครื่องก็รองรับทราฟฟิกทั้งหมดที่ต้องการได้อยู่แล้ว)
- สุดท้ายก็ถอด Akka ออก เพราะมันเพิ่มความซับซ้อนที่ไม่จำเป็นและเกินจำเป็น
- เดือนที่แล้วบริษัทนี้เพิ่งระดมทุนอีกรอบพร้อมตัวเลือก cash-out ซึ่งแปลว่ามูลค่าคงเพิ่มขึ้น และดูเหมือนว่าก็ยังไปได้ดีอยู่
- scary-size : ฟังดูไม่เหมือนบริษัทที่จ้างเฉพาะวิศวกร "เก่งมาก" เลยนะ?
- roncesvalles : ดูเหมือนจะไม่มีกระบวนการ design review และถ้าเป็นผม ผมจะเลือกจ้างนักพัฒนาที่มีประสบการณ์ 2-5 ปีจากมหาวิทยาลัยที่ไม่ดังมากกว่าคนจบมหาวิทยาลัยชื่อดังเสียอีก ช่วง 5 ปีแรกของอาชีพคือช่วงที่วิศวกรซอฟต์แวร์เรียนรู้และเติบโตมากอย่างมหาศาล อาจมากกว่ารวมช่วงที่เหลือของอาชีพด้วยซ้ำ
- zug_zug : ถ้าจะสนับสนุนทฤษฎีนี้ด้วยข้อมูลจริง
burutthrow
- ผมคิดว่า MQ กลายเป็นของที่มีมาตรฐานทั่วไปไปพอสมควรแล้ว
- ถ้าซื้อ Confluent, RedPanda หรือ MSK แบบบริการ คุณก็ไม่จำเป็นต้องดูแล Kafka เอง
- Change Data Capture (CDC) ก็ดีมากและกลายเป็นกระแสหลักแล้ว การเขียนข้อมูลลง RDBMS แล้วจับการเปลี่ยนแปลงเพื่อกระจายต่อไปยังระบบอื่นนั้นทำได้ค่อนข้างง่าย
- ตัวอย่างเช่น message queue เป็นเพียง backbone ที่ระบบ CDC ใช้ส่งข้อความเท่านั้น ดังนั้นแพตเทิร์นนี้จึงทำให้ผู้คนไม่ค่อยเขียนเรื่อง Kafka กันแล้ว
- สถาปัตยกรรมลักษณะนี้ยังมีอยู่ชัดเจน และตอบโจทย์ข้อจำกัดขององค์กรส่วนใหญ่
- ถ้ามีคิวแบบเขียนครั้งเดียวอ่านหลายครั้งอย่าง Kafka ก็สามารถใช้เปิดเผย API ให้กับส่วนอื่นขององค์กรได้ หลายบริษัทใช้แพตเทิร์นนี้เพื่อแบ่งปันและผสมใช้ข้อมูลระหว่างหลายทีม
- ทีมเล็กที่ถือครอง microservices จำนวนมากอาจดูเหมือนพวกพัฒนาเพื่อเรซูเม่ แต่ ในบริษัทที่มีวิศวกรมากกว่า 100 คน แพตเทิร์นนี้ก็สมเหตุสมผล
angarg12
- MQ เป็นเครื่องมือชิ้นหนึ่งในกล่องเครื่องมือของระบบกระจาย และมันยอดเยี่ยมเมื่อใช้ถูกจังหวะ
- ถ้าทฤษฎีของคุณถูกจริง ผมคิดว่าน่าจะเป็นข้อนี้: "คนมักเขียนบล็อกถึงของใหม่ ๆ ที่ดูว้าวมากกว่า"
- โดยส่วนตัวผมใช้คิวในดีไซน์อยู่เสมอ โดยเฉพาะเวลาส่งข้อมูลระหว่างระบบที่ต่างกันและมีการแยกตัวออกจากกันสูง
- ความเจ็บปวดอย่างเดียวที่ผมเคยเจอคือ ตอนที่ระบบ upstream เติมข้อมูลย้อนหลัง 7 วันเข้ามา ทำให้คิวตันด้วยคำขอเก่าจำนวนมาก
- ถ้าปล่อยให้รันตามปกติ มันคงใช้เวลามากกว่า 100 ชั่วโมงกว่าจะประมวลผลข้อมูลทั้งหมด และ latency ของข้อมูลใหม่ก็จะพุ่งสูงมากด้วย
- ทางแก้คือเคลียร์คิวด้วยมือ แล้วเติมข้อมูลล่าสุดที่ขาดไปกลับเข้าไปด้วยมือ
- ต้องระวังขนาดคิวที่ไม่ถูกจำกัด แต่ผมก็ยังคิดว่ามันเป็นเครื่องมือที่ยอดเยี่ยม
rossdavidh
- MQ บน Gartner Hype Cycle ตอนนี้
- ผ่าน 'Peak of inflated expectations' มาแล้ว
- ผ่าน 'trough of disillusionment' มาแล้ว
- และกำลังขึ้นสู่ 'Slope of Enlightenment' หรืออาจถึงขั้น 'plateau of productivity' แล้ว
robertclaus
- น่าสนใจมากที่คอมเมนต์ว่า "เห็นได้ชัดว่าเราทุกคนยังใช้ message queue และ worker กันอยู่ เพียงแค่ไม่ได้เขียนถึงมัน" กลับถูกกลบไปอยู่ข้างหลังการถกเถียงเรื่อง microservices และ scalability จริงจัง
- วิศวกรจูเนียร์ที่มาอ่านคอมเมนต์นี้อาจเข้าใจผิดได้ว่า เดี๋ยวนี้เราไม่ควรโยนงานคำนวณหนักจาก web server ไปให้ worker แล้ว
pm90
- จำนวนบล็อกโพสต์เกี่ยวกับมันลดลงเพราะ เทคโนโลยีนี้กลายเป็นเรื่องน่าเบื่อแล้ว
- ซึ่งเป็นเรื่องดี ตัวอย่างเช่นเอกสารทางการของ RabbitMQ ดีขึ้นมากและมีประโยชน์มาก
- ผู้คนใช้งานมันเป็นเครื่องมือหลักเหมือนที่ใช้ Postgres/MySQL
- และก็ไม่ต้องใช้เทคนิคมหัศจรรย์อะไรในการออกแบบสถาปัตยกรรมด้วย
- ผมรักซอฟต์แวร์ที่น่าเบื่อ "I love boring software"
slowmovintarget
- สถาปัตยกรรมแบบนี้ส่วนใหญ่เคยรันอยู่ใน data center ขององค์กร
- หลังจากย้ายขึ้นคลาวด์และหันไปสร้างบริการขนาดเล็กแบบ stateless (พร้อมการมาของ SPA) ความจำเป็นของระบบ event-driven แบบหลายขั้นตอนที่ซับซ้อนก็ลดลง
- ตัวอย่างเช่นบน AWS ใช้แค่ SQS กับ SNS เล็กน้อย หรือบางกรณีใช้ Kinesis ก็พอแล้ว ที่นี่ MQ ไม่ได้เป็นศูนย์กลางของการออกแบบอีกต่อไป
- สถาปัตยกรรมแบบอิง MQ เหมาะกับการประมวลผลข้อมูล แต่ไม่เหมาะกับเว็บไซต์เชิงโต้ตอบ และถ้าคนส่วนใหญ่กำลังสร้างเว็บไซต์เชิงโต้ตอบ ก็ดูเหมือนจะไม่มีทางเลือกมากนัก
- ผมยังออกแบบ event system สำหรับงานประมวลผลข้อมูลอยู่ (โดยเฉพาะข้อมูลธุรกิจแบบ immutable ที่อาจมีข้อเท็จจริงใหม่เข้ามา หรือเคย "ผิด" หรือควรจะรู้ข้อมูลบางอย่างตั้งแต่เวลาก่อนหน้า)
- แต่สำหรับแอปส่วนใหญ่แล้ว... ไม่จำเป็น
mannyv
- แบ็กเอนด์ทั้งหมดของเราอิงกับคิว
- ถ้าเป็นงาน asynchronous และไม่ต้องการ response time ที่เร็วมาก ก็ใช้คิวได้เลย มันง่าย เสถียร และคิวสามารถขับ Lambda ได้
- นอกจากนี้การใช้คิวยังทำให้เก็บ metrics และข้อมูลประสิทธิภาพได้ง่ายขึ้นด้วย
- ตอนโหลดสูง คิวอาจพองไปถึงระดับหลายล้านข้อความ แล้วค่อย ๆ ลดลงตามเวลา
- หรือจะสร้าง Lambda หลายร้อยตัวตามต้องการเพื่อประมวลผลข้อความทั้งหมดก็ได้
vishnugupta
- จากประสบการณ์ของผม MQ ถูกซ่อนอยู่หลัง abstraction มากกว่า ไม่ได้หายไปไหน
- ตัวอย่างเช่นคิวสำหรับ SQS + polling กลายเป็นกระบวนการที่เรียกเซิร์ฟเวอร์น้อยลง มี message queue อยู่ที่ไหนสักแห่ง เพียงแต่ไม่ได้ถูกเปิดเผยออกมา
- AWS SNS ซึ่งเป็น abstraction ที่สูงกว่า SQS อีกขั้น ก็มีความสามารถมากขึ้นมากจนแทบใช้แทน SQS ได้แล้ว
- อีกทั้ง streaming ก็กลายเป็นเทคโนโลยีที่เสถียรมากแล้ว ดังนั้น use case ที่เคยใช้ คิวเป็นท่อสำหรับสตรีม จึง ย้ายไปใช้ระบบ streaming โดยเฉพาะ กันมากขึ้น
memset
- อาจเป็นเพราะ Lambda (cloud functions) ได้รับความนิยมมากขึ้นและหลายแพลตฟอร์มก็รองรับแล้ว
- เมื่อคุณใส่อะไรลงในคิว สุดท้ายก็ต้องมีคนดึงมันออกไปประมวลผลอยู่ดี แต่ Lambda ทำสิ่งนี้ได้ใน invocation เดียว และไม่ต้องรันหรือสเกล worker เองด้วย
- ผมคิดว่า Kafka ยังได้รับความนิยมต่อไป เพราะมันถูกใช้เป็นที่เก็บข้อมูลชั่วคราว และมี ecosystem ขนาดใหญ่สำหรับการเก็บรวบรวมจาก stream
- โดยส่วนตัวผมใช้คิวเยอะมาก และกำลังสร้างทางเลือกโอเพนซอร์สของ SQS อยู่ ก็เลยสงสัยว่าทางเลือกโอเพนซอร์สของ Lambda จะมีประโยชน์ด้วยไหม
liampulles
- "ตอนนี้เทคโนโลยี MQ เติบโตเต็มที่แล้ว เลยไม่ได้น่าสนใจพอให้คนเขียนถึง แต่ก็ยังถูกใช้อย่างแพร่หลาย"
- นี่แหละถูกต้อง ผมคิดว่า use case ง่าย ๆ ของการสื่อสารแบบ asynchronous ที่ใช้ Pub/Sub แบบเรียบง่ายนั้นมีประโยชน์มาก และก็ไม่ได้ใช้งานยากเกินไป
- พวกเรา (ในฐานะชุมชนนักพัฒนา) ผ่านยุคของ event sourcing, เครือข่ายที่ซับซ้อน และการสร้างระบบให้ใหญ่เกินจำเป็นมาแล้ว กล่าวคือ เราผ่าน hype cycle มาแล้ว
- ทีมของเราใช้ NATS สำหรับทั้ง Pub/Sub แบบ asynchronous และ Request/Response แบบ synchronous
- มันเป็นโมเดลแบบ command-based และเรามีตาราง log ขนาดใหญ่ที่เก็บทุกข้อความที่เราส่ง
- schema และการใช้งานข้อความเหล่านี้เป็นเรื่องภายในทีมของเรา และจะถูกลบออกจาก NATS หลังใช้งาน
- เราใช้ at-least-once delivery และคาดหวังว่า message handler จะมีคุณสมบัติ idempotent
- เคยมีปัญหาข้อหนึ่งหรือสองข้อที่เกิดจากการตั้งค่า NATS ผิดจนทำให้ข้อความถูก replay หรือข้อความหายไป แต่โดยรวมแล้วประสบความสำเร็จมาก และทีมเรามีนักพัฒนาเพียง 3 คน
- สำหรับผมมันคล้าย Kubernetes ถ้ายึดแค่แก่นหลักและไม่พยายามฉลาดเกินไป มันก็ทำงานได้ดี
11 ความคิดเห็น
มีบางสถานการณ์ที่เหมาะสมกับการใช้คิว แต่สำหรับขนาดระบบและรูปแบบการใช้งานส่วนใหญ่ การใช้คิวหรือทำงานเป็นคลัสเตอร์มักเพิ่มความซับซ้อนขึ้น โดยในแง่ประสิทธิภาพก็ไม่ได้มีข้อดีมากนักเสมอไป โครงสร้างที่ซับซ้อนซึ่งบริษัทใหญ่ ๆ ออกแบบมาเพื่อการขยายระบบและรองรับข้อมูลขนาดมหาศาล และมักนำมาอวดกันนั้น อาจไม่มีวันมาถึงจุดที่เหมาะกับระบบของเราก็ได้
แม้เทคโนโลยีใหม่และสถาปัตยกรรมที่ดูเท่จะมีเสน่ห์ในเชิงเทคนิค แต่ก็จำเป็นต้องพิจารณาปัญหาในโลกความเป็นจริงเพื่อเลือกโซลูชันที่เหมาะสม ในกรณีส่วนใหญ่ก็ไม่ได้มีข้อมูลจำนวนมากให้ประมวลผล และหลายครั้ง PostgreSQL ก็สามารถจัดการได้
พวกเราตระหนักถึงปัญหานี้ และกำลังพัฒนา DB ที่สามารถประมวลผลข้อมูลระดับ TB บน single node ได้ด้วยโครงสร้างที่เรียบง่าย แม้จะพูดอย่างระมัดระวังอยู่บ้าง แต่ก็ขอแนะนำให้ลองพิจารณาเป็นอีกหนึ่งตัวเลือก
ทำให้ข้อมูลคำพิพากษาอยู่ในสภาพที่ค้นหาได้อย่างรวดเร็ว
แม้โดยทั่วไปแนวทางแบบเชิงลำดับขั้นตอนจะเข้าใจได้ง่าย แต่แนวทางแบบ MQ มักไม่ทำให้เห็นภาพได้ทันที หรืออาจเข้าใจโครงสร้างได้ยาก ผมคิดว่าโดยทั่วไปในบริษัทมักมีกรณีที่ระดับความรู้ของแต่ละคนไม่ได้เท่ากัน และถ้าใช้ MQ ด้วยความรู้ที่ไม่ถูกต้อง ในจังหวะแบบนี้มันก็ดูจะกลายเป็นนรกได้ครับ.
ผมคิดว่านี่ไม่ใช่ปัญหาเฉพาะของ MQ เท่านั้น แต่เป็นปัญหาที่มักเกิดขึ้นเสมอเมื่อเทคโนโลยีส่วนใหญ่ที่ต้องอาศัยความรู้ในระดับหนึ่งถูกนำมาใช้โดยไม่มีการให้ความรู้โดยรวมที่เพียงพอ.
PHP แทบจะเรียกได้ว่า MQ เป็นสิ่งจำเป็น...
จี๊ดเลย!
ตอนนี้กำลังทำ Toy Project ที่มีคำว่า Quee อยู่ในชื่อพอดีครับ
พูดตามตรง ถ้าจะให้บริการแค่ภายในประเทศเราเอง 99% ผมว่าทั้งหมดนี้ก็ไม่จำเป็นครับ..
สิ่งสำคัญอาจไม่ใช่ขอบเขตของบริการ แต่เป็นลักษณะของบริการ/ต้องพิจารณาความคุ้มค่าด้านต้นทุนมากแค่ไหน มากกว่าหรือเปล่า?
อาจเป็นเพราะกระบวนการตัดสินใจมีลักษณะเป็นลำดับชั้นในแนวดิ่ง จึงทำให้แนวทางแบบ “procedural” ได้รับความนิยมมากกว่าหรือถูกมองว่าเหมาะสมกว่าหรือเปล่าครับ?
ถ้าแต่ละแผนกและทีมมีโครงสร้างที่หลวมและแยกตัวกันพอสมควร สถาปัตยกรรมที่ไม่ยึดตามขั้นตอนตายตัวอาจทำงานได้ราบรื่นกว่า และจึงทำให้การประยุกต์ใช้คิวลักษณะนี้ทำงานได้ดีกว่าหรือไม่ กำลังสงสัยอยู่ครับ
ดูเหมือนว่า "การพัฒนาที่ขับเคลื่อนด้วยเรซูเม่" จะเป็นคีย์เวิร์ดที่อธิบายกระแสนิยมแบบนี้ได้ดีนะครับ
โห คมจัดเลยนะ การพัฒนาที่ขับเคลื่อนด้วยเรซูเม่สินะ..
มีของคู่กันด้วยคือ การพัฒนาที่ขับเคลื่อนด้วยการมโนเกินจริง