กรณีใช้งานที่ดีสำหรับ Akka [ปิด]

605

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้

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

ปิดให้บริการใน6 ปีที่ผ่านมา

ฉันได้ยินมามากมายเกี่ยวกับกรอบของAkka (แพลตฟอร์มบริการ Java / Scala) แต่จนถึงตอนนี้ยังไม่เคยเห็นตัวอย่างการใช้งานจริงจำนวนมากที่มันจะดี ดังนั้นฉันจะสนใจที่จะได้ยินเกี่ยวกับสิ่งที่นักพัฒนาใช้มันอย่างประสบความสำเร็จ

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

— StaxMan
แหล่งที่มา

10

การเริ่มต้นจากปัญหาและค้นหาวิธีแก้ปัญหานั้นง่ายกว่าการมีวิธีแก้ปัญหาและมองหาปัญหาที่จะนำไปใช้หรือไม่ ฉันเดาว่าแทนที่จะใช้ RMI แล้ว Akka และนักแสดงดูเหมือนง่ายกว่า / ง่ายกว่าในการเขียนรหัส

— Kennet

67

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

— StaxMan

มีคำถามที่เกี่ยวข้อง แต่เกี่ยวกับการใช้ AKKA สำหรับแอปพลิเคชันที่มีอยู่ + กรณีการใช้งานบางกรณี: stackoverflow.com/questions/16595685/…

— ses

2

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

— 2684301

2

@ user2684301 hmmh ฉันพบว่าคำตอบนั้นไม่ยุติธรรมเลยในแบบของแอปเปิ้ลกับส้ม MQs เป็นหน่วยการสร้างแบบง่าย ๆ (แบบลอจิคัล) ที่น้อยกว่า Akka และฉันจะไม่เปรียบเทียบพวกเขาเคียงข้างกัน แต่ฉันเดาว่าถ้าฉันอ่านมันว่า "เปรียบเทียบกับระบบกระจายที่สร้างขึ้นโดยใช้ JMS เขียนอย่างชัดเจน" แล้วมันก็สมเหตุสมผลดีกว่า

— StaxMan

321

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

Akka ได้ดึงความสนใจไปที่โครงการเหล่านั้นอย่างแท้จริงแม้ว่าเราจะเริ่มต้นเมื่อรุ่น 0.7 (เรากำลังใช้งานสกาล่าด้วยวิธีนี้)

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

เป็นการดีมากในการสร้างแบบจำลองของการจัดการข้อความแบบอะซิงโครนัส ฉันต้องการเขียนระบบการให้บริการ (เว็บ) ในรูปแบบนี้มากกว่าสไตล์อื่น ๆ (คุณเคยลองเขียนบริการเว็บแบบอะซิงโครนัส (ฝั่งเซิร์ฟเวอร์) กับ JAX-WS หรือไม่ ดังนั้นฉันจะบอกว่าระบบใด ๆ ที่ไม่ต้องการที่จะแขวนบนหนึ่งในองค์ประกอบของมันเพราะทุกอย่างจะถูกเรียกว่าโดยใช้วิธีการซิงโครนัสและองค์ประกอบหนึ่งที่ถูกล็อคในบางสิ่งบางอย่าง มีเสถียรภาพมากและโซลูชัน let-it-crash + supervisor สำหรับความล้มเหลวใช้งานได้ดีจริง ๆ ทุกอย่างง่ายต่อการติดตั้งโดยทางโปรแกรมและไม่ยากที่จะทดสอบหน่วย

จากนั้นมีโมดูลเสริมที่ยอดเยี่ยม โมดูล Camel สามารถเสียบเข้ากับ Akka ได้อย่างแท้จริงและทำให้สามารถพัฒนาบริการอะซิงโครนัสได้อย่างง่ายดายด้วยจุดปลายที่กำหนดค่าได้

ฉันมีความสุขมากกับกรอบงานและมันกลายเป็นมาตรฐาน defacto สำหรับระบบเชื่อมต่อที่เราสร้างขึ้น

— Raymond Roestenburg
แหล่งที่มา

14

อะไรคือข้อดีของวิธีนี้เมื่อเปรียบเทียบกับการใช้แบ็กเอนด์การส่งข้อความ (เช่น ActiveMQ) สำหรับการส่งข้อความในความคิดเห็นของคุณ

— magiconair

27

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

— Raymond Roestenburg

26

URL ใหม่สำหรับกรณีศึกษา DBP คือdownloads.typesafe.com/website/casestudies/

— ......

2

การปิด @RaymondRoestenburg เรื่องระบบ MQ และทางเลือกอื่น RabbitMQ ตัวอย่างเช่นถูกสร้างขึ้นในนักแสดงที่ใช้ภาษาโปรแกรม Erlang นั่นเป็นวิธีหนึ่งในการคิดถึงความสัมพันธ์ (และความแตกต่าง) ระหว่างนักแสดงและ MQ ในขณะเดียวกันApache Sparkไม่เป็นผู้ปฏิบัติงานและนักแสดงคิวหรือตาม แต่สามารถใช้กับ Akka: Typesafe แสดงให้เห็นถึงวิธีการใช้จุดประกายการสตรีมด้วย Akka

— Driftcatcher

6

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

— rapt

222

ข้อจำกัดความรับผิดชอบ: ฉันเป็น PO สำหรับ Akka

นอกจากนี้ยังมี smorgasbord พร้อมกันที่ง่ายกว่ามากในการให้เหตุผลและเพื่อให้ถูกต้อง (นักแสดง, ตัวแทน, ดาต้าโฟลว์พร้อมกัน) และการควบคุมพร้อมกันในรูปแบบของ STM

นี่คือตัวอย่างการใช้งานที่คุณอาจพิจารณา:

การประมวลผลธุรกรรม (เกมออนไลน์, การเงิน, สถิติ, การพนัน, โซเชียลมีเดีย, โทรคมนาคม, ... )
- ไต่ระดับ, ขยายออก, ป้องกันความผิด / HA
แบ็กเอนด์บริการ (อุตสาหกรรมใด ๆ แอปใด ๆ )
- บริการส่วนที่เหลือสบู่ cometd ฯลฯ
- ทำหน้าที่เป็นศูนย์กลางข้อความ / เลเยอร์การรวม
- ไต่ระดับ, ขยายออก, ป้องกันความผิด / HA
การใช้งานพร้อมกัน / ขนาน (ในแอพใดก็ได้)
- แก้ไข
- ง่ายต่อการทำงานด้วยและเข้าใจ
- เพียงเพิ่มไหลงในโครงการ JVM ที่คุณมีอยู่ (ใช้ Scala, Java, Groovy หรือ JRuby)
การประมวลผลแบบกลุ่ม (ทุกอุตสาหกรรม)
- บูรณาการอูฐเพื่อเชื่อมโยงกับแหล่งข้อมูลชุด
- นักแสดงแบ่งและพิชิตปริมาณงานแบทช์
ศูนย์กลางการสื่อสาร (โทรคมนาคม, สื่อเว็บ, สื่อเคลื่อนที่)
- ไต่ระดับ, ขยายออก, ป้องกันความผิด / HA
เซิร์ฟเวอร์เกม (เกมออนไลน์การเดิมพัน)
- ไต่ระดับ, ขยายออก, ป้องกันความผิด / HA
BI / ดาต้ามินนิ่ง / จุดประสงค์ทั่วไป
- ไต่ระดับ, ขยายออก, ป้องกันความผิด / HA
แทรกกรณีการใช้งานอื่น ๆ ที่ดีที่นี่

— Viktor คลาง
แหล่งที่มา

10

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

— Martin Konicek

8

@ViktorKlang POs! = หัวหน้าฝ่ายเทคนิค พวกเขาทำงานร่วมกัน แต่มีบทบาทที่แตกต่างกัน

— taylorcressy

79

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

ข้อความสไตล์ Erlang OTP ที่ส่งผ่านไปยัง JVM ทำให้เป็นระบบที่ยอดเยี่ยมสำหรับการพัฒนาระบบแบบเรียลไทม์บนไหล่ของไลบรารีและแอพพลิเคชันเซิร์ฟเวอร์ที่มีอยู่

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

— ลุยอาร์โนลด์
แหล่งที่มา

1

ดังนั้นมันยุติธรรมที่จะบอกว่ามันเป็นกรณีของการร้องขอเวลา (บางส่วน) เวลาแฝงที่เธรดเดี่ยวต่อคำขอจะไม่ดีขึ้น?

— StaxMan

7

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

— เวดอาร์โนลด์

4

สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์เป็นวิธีที่แตกต่างในการคิดเกี่ยวกับปัญหา มันคุ้มค่าที่จะอ่าน Erlang OTP ในการดำเนินการจากแมนนิ่งถ้าคุณคิดเกี่ยวกับการเข้ารหัสใน Akka สิ่งก่อสร้างจำนวนมากใน akka ได้รับอิทธิพลจาก Erlang OTP และหนังสือให้หลักการแก่คุณว่าทำไม Jonas Boner จึงสร้าง akka api ในแบบที่เขาทำ Akka เป็นภูเขาขนาดใหญ่ที่คุณกำลังยืนอยู่! หากนักแสดงของคุณยังคงอยู่กับการเปลี่ยนแปลงสถานะจริง ๆ แล้วคุณต้องการ 10k เขียนบทที่สองอย่างยั่งยืน

— Wade Arnold

8

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

— James

2

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

— Kaan Yy

44

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

บอกกับหัวหน้าของคุณว่าค่าโฮสติ้ง AWS ของคุณลดลง 10 เท่าและมันก็ไม่เป็นเรื่องง่าย! Shh ... อย่าบอกเรื่องนี้กับ Amazon เลย ... :)

— piotrga
แหล่งที่มา

3

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

— piotrga

8

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

— StaxMan

38

เรากำลังใช้ Akka ในโครงการ Telco ขนาดใหญ่ (น่าเสียดายที่ฉันไม่สามารถเปิดเผยรายละเอียดได้มากมาย) นักแสดง Akka ได้รับการปรับใช้และเข้าถึงจากระยะไกลผ่านเว็บแอปพลิเคชัน ด้วยวิธีนี้เรามีโมเดล RPC ที่ง่ายขึ้นโดยใช้ Google Protobuffer และเราได้รับความเท่าเทียมในการใช้ Akka Futures จนถึงตอนนี้โมเดลนี้ทำงานได้อย่างยอดเยี่ยม One note: เรากำลังใช้ Java API

— Luciano Fiandesio
แหล่งที่มา

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

— Aktau

ดูเหมือนว่าจะสามารถจัดการได้อย่างง่ายดายเช่นเดียวกับที่ไม่มี Akka

— Erik Kaplun

1

TDC เป็น บริษัท Telco ในกรณีของ Fiaddesio

— Roman Kagan

37

หากคุณสรุปเซิร์ฟเวอร์แชทในระดับหนึ่งคุณจะได้รับคำตอบ

Akka จัดให้มีระบบการส่งข้อความที่คล้ายกับความคิด "ปล่อยให้ผิดพลาด" ของ Erlang

ตัวอย่างคือสิ่งที่ต้องการระดับความทนทานและความน่าเชื่อถือที่แตกต่างกันของการส่งข้อความ:

เซิร์ฟเวอร์แชท
เลเยอร์เครือข่ายสำหรับ MMO
ปั๊มข้อมูลทางการเงิน
ระบบแจ้งเตือนสำหรับ iPhone / มือถือ / แอพอะไรก็ได้
เซิร์ฟเวอร์ REST
อาจเป็นสิ่งที่คล้ายกับ WebMachine (เดา)

สิ่งที่ดีเกี่ยวกับ Akka คือตัวเลือกที่ใช้ในการคงอยู่การใช้งาน STM เซิร์ฟเวอร์ REST และการป้องกันความผิดพลาด

อย่ารำคาญกับตัวอย่างของเซิร์ฟเวอร์แชทลองคิดว่ามันเป็นตัวอย่างของโซลูชันบางประเภท

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

(เขียนด้วยประสบการณ์เพียงการดูวิดีโอและเล่นกับแหล่งที่มาฉันไม่ได้ใช้อะไรเลยโดยใช้ akka)

— tylerweir
แหล่งที่มา

2

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

— StaxMan

อยากทราบว่าเซิร์ฟเวอร์ REST เหมาะกับที่นี่อย่างไร คุณกำลังพูดถึงมันในบริบทของเซิร์ฟเวอร์ async สไตล์ Node.js หรือไม่? ขอบคุณที่แบ่งปันตัวอย่างกรณีการใช้งาน ฉันพบว่ามีประโยชน์

— software.wikipedia

24

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

คำถามของ Akka นั้นยิ่งกว่า 'สิ่งที่คุณทำไม่ได้กับ Akka' ความสามารถในการรวมเข้ากับเฟรมเวิร์กที่มีประสิทธิภาพ, นามธรรมที่ทรงพลังและทุกแง่มุมของการยอมรับข้อผิดพลาดทำให้เป็นชุดเครื่องมือที่ครอบคลุมมาก

— rossputin
แหล่งที่มา

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

— StaxMan

6

จากมุมมองส่วนตัวเป็นระดับที่ยกระดับซึ่ง Akka นำมาสู่ตารางที่ฉันชอบที่สุด จากมุมมองขององค์กรมันเป็นความสามารถในการรวม ต้องทำมาหากินและ Akka ครอบคลุมธุรกิจและความสุขทั้งสองอย่าง :-) ดีมาก

— rossputin

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

— surfmuggle

24

คุณสามารถใช้ Akka สำหรับสิ่งต่าง ๆ มากมาย

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

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

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

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

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

และตั้งแต่ Google Reader ปิดตัวลงฉันเริ่มด้วยโปรแกรมอ่าน RSS โดยใช้ Akka แน่นอน มันคือทั้งหมดที่เกี่ยวกับบริการห่อหุ้มสำหรับฉัน โดยสรุป: ตัวแบบนักแสดงนั้นเป็นสิ่งที่คุณควรนำมาใช้ก่อนและ Akka เป็นกรอบที่น่าเชื่อถือมากที่ช่วยให้คุณสามารถนำไปใช้กับผลประโยชน์มากมายที่คุณจะได้รับระหว่างทาง

— Joa Ebert
แหล่งที่มา

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

— surfmuggle

18

เราใช้ Akka กับปลั๊กอินอูฐในการกระจายการวิเคราะห์ของเราและแนวโน้มการประมวลผลสำหรับtwimpact.com เราต้องประมวลผลระหว่าง 50 ถึง 1,000 ข้อความต่อวินาที นอกเหนือจากการประมวลผลแบบมัลติโหนดกับอูฐแล้วมันยังใช้เพื่อกระจายงานบนโปรเซสเซอร์เดียวให้กับพนักงานหลายคนเพื่อประสิทธิภาพสูงสุด ทำงานได้ค่อนข้างดี แต่ต้องการความเข้าใจเกี่ยวกับวิธีจัดการกับความแออัด

— Matthias L. Jugel
แหล่งที่มา

คุณใช้ความทนทานต่อความผิดปกติของ Akka ด้วยหรือไม่

— Erik Kaplun

Spark Streaming เป็นอย่างไรถ้าเรามีสิทธิ์เข้าถึงคลัสเตอร์ Spark?

— skjagini

18

ฉันลองใช้มือกับ Akka (Java api) สิ่งที่ฉันพยายามคือการเปรียบเทียบรูปแบบการทำงานพร้อมกันของนักแสดง Akka กับแบบจำลองการทำงานพร้อมกันของ Java แบบธรรมดา (คลาส java.util.concurrent)

กรณีการใช้งานเป็นแผนที่มาตรฐานที่เรียบง่ายลดการใช้งานของจำนวนตัวอักษร ชุดข้อมูลเป็นชุดของสตริงที่สร้างแบบสุ่ม (ความยาว 400 ตัวอักษร) และคำนวณจำนวนสระในตัว

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

การสังเกต: จนถึงขนาดกลางโหลด (~ 50000 อินพุตสตริง) ผลลัพธ์ที่ได้เปรียบเทียบได้แตกต่างกันเล็กน้อยในการทำซ้ำที่แตกต่างกัน อย่างไรก็ตามเมื่อฉันเพิ่มการโหลดเป็น ~ 100,000 มันจะหยุดการแก้ปัญหา Java ฉันกำหนดค่าโซลูชัน Java ด้วย 20-30 เธรดภายใต้เงื่อนไขนี้และล้มเหลวในการวนซ้ำทั้งหมด

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

ดังนั้นสำหรับฉันดูเหมือนว่า Akka จะปรับขนาดได้ดีกว่าโซลูชันแบบมัลติเธรด Java แบบดั้งเดิม และเหตุผลอาจเป็นเพราะความมหัศจรรย์ของ Scala

ถ้าฉันสามารถสร้างโมเดลโดเมนปัญหาเป็นข้อความที่ขับเคลื่อนด้วยเหตุการณ์ส่งผ่านฉันคิดว่า Akka เป็นตัวเลือกที่ดีสำหรับ JVM

ทดสอบกับ: Java เวอร์ชัน: 1.6 IDE: Eclipse 3.7 Windows Vista 32 บิต 3GB ram โปรเซสเซอร์ Intel Core i5 ความเร็วสัญญาณนาฬิกา 2.5 GHz

โปรดทราบว่าโดเมนปัญหาที่ใช้สำหรับการทดสอบสามารถถกเถียงกันได้และฉันพยายามที่จะยุติธรรมเท่าที่ความรู้เกี่ยวกับ Java ของฉันอนุญาต :-)

— sutanu dalui
แหล่งที่มา

3

"ฉันสามารถแบ่งปันรหัสกับทุกคนที่สนใจจะมีการตรวจสอบข้าม" ฉันต้องการถ้าคุณไม่รังเกียจ

— n1r3

3

ฉันต้องการรหัสคุณสามารถโพสต์ลิงค์ github ได้ไหม?

— Gautam

ขอขอบคุณสำหรับความสนใจของคุณ. น่าเสียดายที่ฉันมีปัญหาในการตั้งค่า repit GitHub หากคุณสามารถให้อีเมลของฉันกับฉันฉันสามารถส่งรหัสแหล่งที่มา และเสียใจที่ตอบกลับช้า!

— sutanu dalui

@sutanudalui คุณยังมีรหัสอีกไหมถ้าเป็นเช่นนั้นฉันจะสามารถแบ่งปันอีเมลได้หรือไม่?

— Jay

16

เราใช้ Akka ในการพูดโต้ตอบระบบ ( primetalk ) ทั้งภายในและภายนอก ในการเรียกใช้ช่องสัญญาณโทรศัพท์จำนวนมากพร้อมกันบนโหนดคลัสเตอร์เดียวจำเป็นต้องมีเฟรมเวิร์กมัลติเธรดบางตัว Akka ใช้งานได้สมบูรณ์แบบ เรามีฝันร้ายก่อนหน้านี้ที่มี java-concurrency และด้วย Akka มันก็เหมือนกับการแกว่ง - มันใช้งานได้ง่าย แข็งแกร่งและเชื่อถือได้ 24 * 7 ไม่หยุด

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

ที่จะทำให้การเชื่อมโยงของสัญญาณที่ซับซ้อนในการประมวลผลที่เราใช้SynapseGrid มันมีประโยชน์ในการตรวจสอบเวลารวบรวมของ DataFlow ในระบบของนักแสดงที่ซับซ้อน

— Arseniy Zhizhelev
แหล่งที่มา

14

ฉันเพิ่งนำตัวอย่างย่อแผนที่ซึ่งเป็นที่ยอมรับใน Akka: จำนวน Word มาใช้ ดังนั้นจึงเป็นกรณีใช้งานหนึ่งของ Akka: ประสิทธิภาพที่ดีขึ้น เป็นการทดลองนักแสดงของJRuby และ Akkaมากกว่าสิ่งอื่น ๆ แต่ก็แสดงให้เห็นว่า Akka ไม่ใช่ Scala หรือ Java เท่านั้น: ใช้ได้กับทุกภาษาที่อยู่ด้านบนของ JVM

— Daniel Ribeiro
แหล่งที่มา

คุณรู้หรือไม่ว่าอะไรที่ทำให้ประสิทธิภาพดีขึ้น (และเปรียบเทียบกับทางเลือกอื่น) นั่นเป็นเพราะการใช้ JRuby บน JVM (เทียบกับ Ruby native), scalalibiliy เนื่องจากไม่มีการปิดกั้น I / O หรืออย่างอื่น?

— StaxMan

2

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

— Daniel Ribeiro

ฉันเพิ่งติดตั้งแผนที่เพื่อลดขนาดตัวอย่างเช่นกัน แต่มันก็แค่ vanilla java github.com/chaostheory/jibenakka

— chaostheory