Akka obsolesce โบรกเกอร์ข้อความ JMS / AMQP หรือไม่ [ปิด]

ฉันใช้เวลาหนึ่งสัปดาห์ในการดำน้ำลึกเข้าไปในเอกสาร Akkaและในที่สุดก็เข้าใจว่าระบบของนักแสดงคืออะไรและปัญหาที่พวกเขาแก้ไข

ความเข้าใจของฉัน(และประสบการณ์กับ) โบรกเกอร์ข้อความ JMS / AMQP ดั้งเดิมคือพวกเขามีตัวตนเพื่อให้สิ่งต่อไปนี้:

• การประมวลผลแบบอะซิงโครนัสระหว่างผู้ผลิตและผู้บริโภค และ
• การรับประกันการส่งข้อความรวมถึงการคงอยู่การลองใหม่และการย้อนกลับ

แต่ Akka ไม่ได้ให้สิ่งนี้โดยไม่มีโครงสร้างพื้นฐานที่จำเป็นและค่าใช้จ่ายในการดำเนินงานทั้งหมดหรือไม่

• ใน Akka การสื่อสารของนักแสดงทั้งหมดไม่ตรงกันและไม่ปิดกั้น และ
• ใน Akka SupervisorStrategiesมีอยู่เพื่อบรรลุการลองใหม่อีกครั้งทางเลือกและการเพิ่มระดับ นักแสดงสามารถกำหนดค่าให้คงอยู่กับร้านค้าแทบทุกประเภทหากเป็นข้อกำหนดเช่นกัน

นี่ทำให้ฉันสงสัยว่า: หากแอปของฉันใช้ Akka ฉันจำเป็นต้องนำโบรกเกอร์ JMS / AMQP (เช่น ActiveMQ, RabbitMQ, Kafka) เข้ามาในรูปภาพหรือไม่? กล่าวอีกนัยหนึ่งเคยมีกรณีการใช้งานที่แอพที่ใช้ Akka ใหม่จะรับประกันการเปิดตัวของกลุ่มโบรกเกอร์ JMS / AMQP ใหม่หรือไม่ ทำไมหรือทำไมไม่?

อาร์กิวเมนต์เดียวอาจเป็นได้ว่าแอป Akka ของฉันอาจต้องรวมเข้ากับระบบอื่น แต่ในกรณีนั้นโมดูลAkka-Camelช่วยให้ Akka สามารถเจาะลึกเข้าไปในรายการความสามารถในการรวมที่ครบถ้วนสมบูรณ์ของ Camel (TCP, FTP, ZeroMQ, รายการต่อไปเรื่อย ๆ ... )

คิด?

นักแสดงนางแบบ

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

Akka เป็นเฟรมเวิร์กที่ใช้โมเดลนักแสดงและช่วยให้คุณสร้างระบบนักแสดงพร้อมโครงสร้างพื้นฐานและฟีเจอร์ทั้งหมดที่สร้างขึ้นแล้ว (เช่นการใช้ JQuery แทนจาวาสคริปต์)

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

ระบบข้อความคือแอพพลิเคชั่นที่สามารถส่งและรับข้อความ มีหลากหลายตั้งแต่คิวพื้นฐานไปจนถึงซอฟต์แวร์องค์กรขนาดใหญ่ที่มีหัวข้อ pub / sub, persistence และคุณสมบัติอื่น ๆ แต่เป้าหมายสุดท้ายเหมือนกัน บันทึกบางไบต์และเรียกคืนอีกครั้งในภายหลังด้วยการสั่งซื้อบางประเภท กรณีการใช้งานหลักในวันนี้คือการแยกระบบออกและอนุญาตให้ทำการประมวลผลแบบอะซิงโครนัสตามกำหนดเวลาหรือความเร็วที่แตกต่างกัน RabbitMQ, NATS, Kafka เป็นต้นเป็นตัวอย่างของระบบข้อความทั้งหมด

การเปรียบเทียบ

โมเดล Actor และเฟรมเวิร์ก Akka เป็นเครื่องมือระดับต่ำที่เป็นวิธีที่ยอดเยี่ยมในการสร้างแอปพลิเคชันเช่นคิวข้อความ

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

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

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

มีคำตอบที่ยอดเยี่ยมเกี่ยวกับ SO เกี่ยวกับนักแสดงรุ่นเดียวกันกับการส่งข้อความ: /programming/5693346/when-to-use-actors-instead-of-messaging-solutions-suchutions-suchtion-much-as หรือ TIBCO