และมีบ้างไหม? สำหรับฉันแล้ว MB รู้จักทั้งผู้ติดตามและผู้เผยแพร่โฆษณาและทำหน้าที่เป็นสื่อกลางโดยแจ้งให้สมาชิกทราบเมื่อมีข้อความใหม่ ๆ ในทางกลับกัน MQ เป็นรูปแบบ "ดึง" มากกว่าที่ผู้บริโภคดึงข้อความออกจากคิว

ฉันอยู่นอกเส้นทางที่นี่หรือไม่?

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

BUSกับคิวเป็นจริงค่อนข้างเป็นแนวคิดเดิมมากที่สุดเมื่อเร็ว ๆ นี้เกิดจากระบบเช่น IBM MQ และ Tibco Rendezvous MQ เดิมเป็นระบบ 1: 1 ซึ่งเป็นคิวในการแยกระบบต่างๆ

ตรงกันข้าม Tibco คือ (ขายเป็น) กระดูกสันหลังของการส่งข้อความซึ่งคุณสามารถมีผู้เผยแพร่และสมาชิกหลายคนในหัวข้อเดียวกัน

อย่างไรก็ตามทั้งสองอย่าง (และผลิตภัณฑ์คู่แข่งที่ใหม่กว่า) สามารถเล่นในพื้นที่ของกันและกันได้ในทุกวันนี้ ทั้งสองสามารถตั้งค่าให้ขัดจังหวะเช่นเดียวกับการสำรวจข้อความใหม่ ทั้งสองเป็นสื่อกลางในการโต้ตอบระหว่างระบบต่างๆ

อย่างไรก็ตามวลีข้อความคิวยังใช้สำหรับข้อความภายในด้ายภายในปั๊มและชอบและในบริบทนี้การใช้งานที่แตกต่างกันแน่นอน หากคุณนึกถึงปั๊มข้อความ Windows แบบคลาสสิกนี่เป็นรูปแบบการดึงที่คุณอธิบายมากกว่า แต่จริงๆแล้วมันเป็นแอพภายในมากกว่าแอพระหว่างแอพหรือระหว่างกล่อง

บัสข้อความ

ข้อความบัสเป็นโครงสร้างพื้นฐานการส่งข้อความที่จะช่วยให้ระบบต่าง ๆ ในการสื่อสารผ่านชุดที่ใช้ร่วมกันของอินเตอร์เฟซ ( รถบัสข้อความ )

ที่มา: EIP

คิวข้อความ

แนวคิดพื้นฐานของคิวข้อความเป็นเรื่องง่ายๆ:

• สอง (หรือมากกว่า) กระบวนการสามารถแลกเปลี่ยนข้อมูลผ่านทางเข้าถึงคิวข้อความระบบทั่วไป

• กระบวนการส่งจะวางข้อความผ่านโมดูลการส่งผ่านข้อความ (OS) ไปยังคิวซึ่งกระบวนการอื่นสามารถอ่านได้

ที่มา: Dave Marshall

แหล่งที่มาของภาพ

ความแตกต่าง

คิวข้อความมีกฎFIFO ( เข้าก่อนออกก่อน ) ในขณะที่ในMessage Busไม่มี

สรุป

ทั้งสองLOOKเช่นทำชนิดเดียวกันในการทำงาน - การส่งผ่านข้อความระหว่างสองโปรแกรม หรือ โมดูล หรือ การเชื่อมต่อ หรือ ระบบ หรือ กระบวนการยกเว้นความแตกต่างเล็ก ๆ ของFIFO

มีความเบลอของเส้นแบ่งระหว่างแนวคิดทั้งสองนี้เนื่องจากผลิตภัณฑ์บางอย่างรองรับคุณลักษณะที่ก่อนหน้านี้เป็นของหมวดหมู่เดียวหรือหมวดหมู่อื่น (เช่น Azure Service Bus รองรับทั้งสองแนวทาง)

คิว

คิวข้อความจะรับข้อความจากแอปพลิเคชันและทำให้สามารถใช้งานได้กับแอปพลิเคชันอื่น ๆ อย่างน้อยหนึ่งรายการในลักษณะเข้าก่อนออกก่อน (FIFO) ในสถานการณ์ทางสถาปัตยกรรมหลายอย่างหากแอปพลิเคชัน A ต้องการส่งการอัปเดตหรือคำสั่งไปยังแอปพลิเคชัน B และ C สามารถตั้งค่าคิวข้อความแยกกันสำหรับ B และ C A จะเขียนข้อความแยกกันไปยังแต่ละคิวและแต่ละแอปพลิเคชันที่อ้างอิงจะอ่านจาก คิวของตัวเอง (ข้อความจะถูกลบออกเมื่อถูกยกเลิกการจัดคิว) ไม่จำเป็นต้องมี B และ C เพื่อให้ A ส่งการอัปเดต คิวข้อความแต่ละคิวจะคงอยู่ดังนั้นหากแอปพลิเคชันรีสตาร์ทแอปพลิเคชันจะเริ่มดึงออกจากคิวเมื่อกลับมาออนไลน์ สิ่งนี้ช่วยทำลายการพึ่งพาระหว่างระบบที่พึ่งพาและสามารถเพิ่มความยืดหยุ่นในการปรับขนาดและความทนทานต่อข้อผิดพลาดให้กับแอปพลิเคชัน

รถบัส

บัสข้อความหรือบัสบริการเป็นวิธีสำหรับหนึ่งแอปพลิเคชัน (หรือมากกว่า) ในการสื่อสารข้อความกับแอปพลิเคชันอื่นอย่างน้อยหนึ่งรายการ อาจไม่มีการรับประกันการสั่งซื้อก่อนเข้า - ออกก่อนและสมาชิกของรถบัสสามารถเดินทางไปมาได้โดยที่ผู้ส่งข้อความไม่ทราบ ดังนั้นแอปพลิเคชัน A สามารถเขียนเพื่อสื่อสารการอัปเดตสถานะไปยังแอปพลิเคชัน B ผ่านบัสข้อความ ต่อมามีการเขียนแอปพลิเคชัน C ซึ่งจะได้ประโยชน์จากการอัปเดตเหล่านี้ แอปพลิเคชัน C สามารถกำหนดค่าให้ฟังบัสข้อความและดำเนินการตามการอัปเดตเหล่านี้ได้เช่นกันโดยไม่ต้องอัปเดตแอปพลิเคชัน A ต่างจากคิวที่แอปพลิเคชันที่ส่งจะเพิ่มข้อความลงในทุกคิวอย่างชัดเจนบัสข้อความจะใช้การเผยแพร่ / สมัครสมาชิกรุ่น มีการเผยแพร่ข้อความไปยังรถบัสและแอปพลิเคชันใด ๆ ที่สมัครรับข้อความประเภทนั้นจะได้รับ

แหล่งที่มา

ความแตกต่างหลักที่ยังไม่ได้กล่าวถึงอย่างชัดเจนในคำตอบอื่น ๆ คือบัสข้อความอนุญาตให้มีสมาชิกหลายคนในขณะที่คิวจะยกเลิกการจัดคิวรายการทีละรายการกับสิ่งที่ฟังคิว หากคุณต้องการให้ผู้ฟังหลายคนเห็นรายการเดียวกันที่ออกจากคิวคุณต้องจัดการด้วยตัวเองรถบัสบริการจะทำสิ่งนี้ให้คุณทันที

วิธีที่ฉันเห็นมันอยู่ที่คิวข้อความสร้างข้อความบัส ไคลเอนต์ (เช่นโหนด) สามารถฟังบัสข้อความได้ นี่เป็นเรื่องจริงโดยเฉพาะอย่างยิ่งสำหรับกรณีที่คุณมีข้อความกระจายเสียง MQ ผ่าน UDP กล่าวคือเป็นการส่งข้อความไปยังที่อยู่ที่ออกอากาศ / หลายผู้รับโดยไม่ทราบหรือสนใจว่าใครจะได้รับ สำหรับคำอธิบายเพิ่มเติมในเชิงลึกของสถานการณ์นี้คุณสามารถตรวจสอบบทความนี้

Service Bus เป็นคำที่ใช้ทั่วไปมากกว่าคิวข้อความ

MQ เป็น FIFO ที่เรียบง่าย แต่มีวิธีที่ซับซ้อนกว่าในการนำ Service Bus มาใช้นั่นคือ Event Hub ซึ่งเป็น "ศูนย์กลาง" ขนาดใหญ่สำหรับจัดการข้อความ นอกเหนือจากฟังก์ชั่นที่จัดทำโดย MQ แล้วยังช่วยให้สามารถจัดเก็บข้อความ (และด้วยเหตุนี้การใช้สมาชิกหลายคน) เป็นต้น

บัสข้อความเป็นรูปแบบการกระจายแบบ 1 ต่อกลุ่ม ปลายทางในโมเดลนี้มักเรียกว่าหัวข้อหรือหัวเรื่อง ข้อความที่เผยแพร่เดียวกันนี้จะได้รับจากสมาชิกที่บริโภคทั้งหมด คุณยังสามารถเรียกสิ่งนี้ว่าโมเดล 'การออกอากาศ' คุณสามารถคิดว่าหัวข้อเทียบเท่ากับ Subject ในรูปแบบการออกแบบ Observer สำหรับการคำนวณแบบกระจาย ผู้ให้บริการบัสข้อความบางรายเลือกใช้สิ่งนี้เป็น UDP แทน TCP ได้อย่างมีประสิทธิภาพ สำหรับการส่งข้อความของหัวข้อคือ 'fire-and-forget' - หากไม่มีใครฟังข้อความก็จะหายไป หากนั่นไม่ใช่สิ่งที่คุณต้องการคุณสามารถใช้ 'การสมัครสมาชิกที่ทนทาน'

คิวข้อความคือปลายทางของข้อความแบบ 1 ต่อ 1 ข้อความจะได้รับจากผู้รับเพียงรายเดียว (โปรดทราบ: การใช้สมาชิกอย่างสม่ำเสมอสำหรับ 'ไคลเอนต์หัวข้อและผู้รับสำหรับคิวไคลเอ็นต์เพื่อหลีกเลี่ยงความสับสน) ข้อความที่ส่งไปยังคิวจะถูกเก็บไว้ในดิสก์หรือหน่วยความจำจนกว่าจะมีคนมารับหรือหมดอายุ ดังนั้นคิว (และการสมัครสมาชิกที่ทนทาน) จึงจำเป็นต้องมีการจัดการพื้นที่เก็บข้อมูลที่ใช้งานได้คุณต้องคิดถึงผู้บริโภคที่ช้า

ในสภาพแวดล้อมส่วนใหญ่ฉันจะโต้แย้งหัวข้อเป็นทางเลือกที่ดีกว่าเพราะคุณสามารถเพิ่มส่วนประกอบเพิ่มเติมได้ตลอดเวลาโดยไม่ต้องเปลี่ยนสถาปัตยกรรม ส่วนประกอบที่เพิ่มเข้ามาอาจเป็นการตรวจสอบการบันทึกการวิเคราะห์และอื่น ๆ คุณไม่มีทางรู้เลยว่าในช่วง 1 ปี 5 ปี 10 ปีจะเป็นอย่างไร การเปลี่ยนแปลงเป็นสิ่งที่หลีกเลี่ยงไม่ได้กอดมัน :-)