ข้อดีของระบบ“ การส่งข้อความ” กับระบบ“ ตามเหตุการณ์”

คำถามของฉันมาจากมุมมองที่ค่อนข้างไม่มีการศึกษา

ข้อดีของระบบ "การส่งข้อความ " คืออะไรเทียบกับระบบ " ตามเหตุการณ์ "

ทำไมหนึ่งจะเลือกหนึ่งมากกว่าอีก? จุดแข็งและจุดอ่อนของพวกเขาคืออะไร

ฉันต้องการที่จะรู้ไม่เพียง แต่ "ในทางทฤษฎี" แต่ยัง "ในทางปฏิบัติ"

แก้ไข:

ปัญหาเฉพาะ :

ฉันต้องการสร้างระบบขององค์ประกอบปลั๊กอินที่ทำงานเป็นบริการขนาดเล็ก (แต่ละงานมีภารกิจเล็ก ๆ และให้ข้อมูลบางส่วน)

บริการสามารถ:

• เป็นเลเยอร์เพื่อให้เอาต์พุตของบริการหนึ่งสามารถทำหน้าที่เป็นหนึ่งในอินพุตไปยังอีกบริการหนึ่ง
• มีลำดับชั้นการกักกันเพื่อให้บริการหนึ่งสามารถถูกควบคุมได้โดยไม่ต้องมีความสัมพันธ์อินพุต - เอาท์พุตเฉพาะดังที่กล่าวไว้ในประโยคก่อนหน้า

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

ฉันสามารถให้รายละเอียดเพิ่มเติมหากยังไม่เพียงพอ

หลังจากดูรอบ ๆ แล้ว สิ่งนี้และนี่อาจอธิบายสถานการณ์ของฉันได้ดีขึ้น

ดูเหมือนว่ามันจะเหมาะกับสถานการณ์ของฉัน: http://akka.io/

จากประสบการณ์ของฉันความแตกต่างเฉพาะอย่างเดียวคือในระบบส่งข้อความส่วนใหญ่ผู้ส่งข้อความจะรับรู้ (และมักจะประกาศ) ว่าใครเป็นผู้รับข้อความ

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

เห็นได้ชัดว่ามีกรณีของการทำเกลียวที่ Telastyn กล่าวถึงการใช้งานเหตุการณ์ของ C # แต่คุณยังสามารถสร้างรูปแบบ pub / sub ของคุณเองที่ดำเนินการกับเธรดที่แตกต่างกัน

นี่คือแอปเปิ้ลและส้ม:

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

ระบบส่งข้อความสามารถขับเคลื่อนด้วยเหตุการณ์ที่สร้างและส่งข้อความ นี่คือการออกแบบการดำเนินการอย่างหมดจด

ทั้งสองนั้นไม่ได้เกิดร่วมกัน

ตัวอย่าง: คุณสามารถใช้การออกแบบที่ขับเคลื่อนด้วยเหตุการณ์ในภาษาใดก็ได้ซึ่งอาจเป็นสภาพแวดล้อมการส่งข้อความเช่นเดียวกับใน Erlang

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

ในฐานะที่เป็นคนจำนวนมากได้ชี้ให้เห็น "การส่งข้อความ" และ "ตามเหตุการณ์" ไม่ดีพอที่จะหลีกเลี่ยงความคลุมเครือ

ข้อดีของระบบ "การส่งข้อความ" คืออะไรเทียบกับระบบ "ตามเหตุการณ์"

การส่งข้อความ

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

สถาปัตยกรรมประเภทนี้ดีมากสำหรับระบบที่ผู้ผลิตและผู้บริโภครู้จักกันดี ผู้ผลิตข้อความรู้ว่าใครจะต้องได้รับหรือผู้บริโภคจะต้องรู้ว่าใครจะได้รับข้อความ

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

ตามเหตุการณ์

อีกระบบหนึ่งที่ฉันเชื่อว่าคุณกำลังคิดเมื่อคุณพูดถึงระบบ "ตามเหตุการณ์" คือสิ่งที่วัตถุยก "เหตุการณ์" โดยไม่ทราบว่าใคร (ถ้าใคร) จะตอบสนองต่อมัน

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

โดยทั่วไประบบเหล่านี้ยอดเยี่ยมมากโดยที่คุณไม่ทราบว่าความสัมพันธ์ระหว่างผู้บริโภคและผู้ผลิตและที่คุณคาดหวังว่าความสัมพันธ์จะเป็นแบบไดนามิก

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

ตัวอย่างเช่นสมมติว่าเงื่อนไข A กิจกรรมที่ยกมาซึ่งปกติทำให้เกิดการตอบสนอง RA วัตถุที่ทำให้เกิดการตอบสนอง RA เพียงแค่ลงทะเบียนเพื่อรับเหตุการณ์ EA และดำเนินการกับมันเมื่อมันมาถึง ตอนนี้สมมติว่าเราต้องการเพิ่มคำตอบใหม่ให้กับ EA ที่เรียกว่า RA_1 ในการทำเช่นนี้เราเพียงแค่เพิ่มวัตถุใหม่ที่มองหา EA และสร้างการตอบสนอง RA_1

นี่คือตัวอย่างบางส่วน (โดยใช้คำศัพท์ของคุณ):

• "การส่งข้อความ" : เจ้านายของคุณบอกให้คุณกรอกใบบันทึกเวลาของคุณ
• "ผลักดันเหตุการณ์" : ฝ่ายเลขานุการส่งอีเมลถึงทุกคนเพื่อเตือนพวกเขาว่ากำหนดเวลาของพวกเขาในวันนี้

ใน SOA คุณมีแนวคิดของข้อความคำสั่งและข้อความเหตุการณ์ มีความจำเป็นสำหรับทั้งคู่

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

ในทางกลับกันข้อความเหตุการณ์ไม่มีการเชื่อมต่อเชิงพฤติกรรมระหว่างผู้ส่ง / ผู้รับเนื่องจากผู้ส่งไม่มีความคิดว่าผู้รับจะทำอย่างไรกับข้อความ มันไม่รู้ด้วยซ้ำว่าใครสมัครรับข้อมูลกิจกรรม

สำหรับพื้นหลังเพิ่มเติมคุณสามารถอ่านไซต์รถบริการของฉันได้ที่นี่: http://www.servicebus.co.za

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

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

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

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

โดยส่วนตัวแล้วฉันจะเลือกข้อความที่ส่งผ่านเหตุการณ์ยกเว้นในกรณีที่เหตุการณ์บังคับให้คุณเช่นการเขียนโปรแกรม Windows GUI เป็นต้น