Node.js evented system แตกต่างจากรูปแบบนักแสดงของ Akka อย่างไร?

ฉันทำงานด้วยNode.jsมาระยะหนึ่งแล้วและคิดว่าตัวเองค่อนข้างดีกับ Java แต่ฉันเพิ่งค้นพบAkkaและสนใจรูปแบบนักแสดงของมันทันที (จากสิ่งที่ฉันเข้าใจ)

ตอนนี้สมมติว่าทักษะ JavaScript ของฉันเทียบเท่ากับทักษะ Scala / Java ของฉันฉันต้องการมุ่งเน้นไปที่การใช้งานได้จริงของทั้งสองระบบ โดยเฉพาะอย่างยิ่งในแง่ของบริการเว็บ

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

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

ฉันทำงานกับแอพพลิเคชั่นมากมายที่จัดการกับตรรกะทางธุรกิจที่ซับซ้อนและฉันคิดว่าถึงเวลาแล้วที่จะต้องข้ามไปที่หนึ่ง โดยเฉพาะอย่างยิ่งการอัปเกรดแอปพลิเคชัน Struts และ C # แบบเดิม

อย่างไรก็ตามการหลีกเลี่ยงสงครามศักดิ์สิทธิ์ทั้งสองระบบมีความแตกต่างกันอย่างไร? ดูเหมือนทั้งสองจะมุ่งไปสู่เป้าหมายเดียวกัน สถาปัตยกรรม "บำบัดตนเอง" ของ Akka อาจมีข้อได้เปรียบ

แก้ไข

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

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

ความสำคัญอีกประการหนึ่งคือ Akka มีระบบสำหรับจัดการความล้มเหลวอย่างมีแบบแผน (โดยให้นักแสดงแต่ละคนดูแลโดยผู้ปกครองซึ่งเป็นข้อบังคับ) ในขณะที่ Node.js อาศัยข้อตกลงสำหรับผู้เขียนในการส่งผ่านเงื่อนไขข้อผิดพลาดจากการโทรกลับไปยังการโทรกลับ ปัญหาพื้นฐานคือระบบอะซิงโครนัสไม่สามารถใช้แนวทางมาตรฐานของข้อยกเว้นที่ใช้โดยระบบที่ใช้สแต็กแบบซิงโครนัสได้เนื่องจากโค้ด "การโทร" จะย้ายไปทำงานที่ต่างกันเมื่อเกิดข้อผิดพลาดของการโทรกลับ การจัดการข้อผิดพลาดในระบบทำให้มีโอกาสมากขึ้นที่แอปพลิเคชันที่สร้างขึ้นบนระบบนั้นจะมีประสิทธิภาพ

ข้างต้นไม่ได้หมายความว่าจะละเอียดถี่ถ้วนฉันแน่ใจว่ามีความแตกต่างมากกว่านี้มาก

ฉันยังไม่ได้ใช้ Akka แต่ดูเหมือนว่ามันจะเหมือน erlang แต่ใน java ใน erlang กระบวนการทั้งหมดเป็นเหมือนนักแสดงใน Akka มีกล่องจดหมายคุณสามารถส่งข้อความระหว่างกันคุณมีหัวหน้างาน ฯลฯ

Node.js ใช้การทำงานพร้อมกันแบบร่วมมือกัน นั่นหมายความว่าคุณมีภาวะพร้อมกันเมื่อคุณอนุญาต (ตัวอย่างเช่นเมื่อคุณเรียกการดำเนินการ io หรือเหตุการณ์อะซิงโครนัสบางอย่าง) เมื่อคุณมีการทำงานที่ยาวนาน (การคำนวณบางอย่างในวงยาว) บล็อกทั้งระบบ

Erlang ใช้การสลับงานล่วงหน้า เมื่อคุณมีลูปยาวระบบสามารถหยุดชั่วคราวเพื่อเรียกใช้การดำเนินการอื่นและดำเนินการต่อหลังจากนั้นสักครู่ สำหรับ Node.js ที่ทำงานพร้อมกันจำนวนมากนั้นดีถ้าคุณดำเนินการสั้น ๆ เท่านั้น ทั้งสองรองรับลูกค้านับล้าน: http://blog.caustik.com/2012/08/19/node-js-w1m-concurrent-connections/ http://blog.whatsapp.com/index.php/2012/01/ 1 ล้านเป็นอย่างนั้น 2011 /

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

ฉันไม่แน่ใจว่านี่เป็นการเปรียบเทียบที่ยุติธรรมในการวาด ฉันอ่านเพิ่มเติมว่า "ระบบอิงเหตุการณ์เปรียบเทียบกับโมเดลนักแสดงอย่างไร" Nodejs สามารถรองรับนางแบบนักแสดงได้เช่นเดียวกับที่ Scala ทำใน Akka หรือ C # ทำใน Orleans ในความเป็นจริงลองดูnactorดูเหมือนว่าจะมีคนลองใช้อยู่แล้ว

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

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

ฝากติดตามละครด้วยนะครับ มันเป็นการนำรูปแบบนักแสดง nodejs อื่น