คำถามติดแท็ก messaging

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

19 asynchronous-programming  message-queue  messaging  akka 

เท่าที่ฉันเข้าใจโมเดล Actor และ Reactive Programming เป็นแนวคิดที่แยกจากกัน นักแสดงนางแบบดูเหมือนจะไม่ตอบสนองกับฉันโดยเนื้อแท้ อย่างไรก็ตามกรอบของ Akka ซึ่งเป็นการนำโมเดลของนักแสดงไปใช้นั้นถูกอธิบายว่าเป็นปฏิกิริยา: "ตรรกะของโปรแกรม Java และ Scala อาศัยอยู่ในวัตถุ Actor ที่มีน้ำหนักเบาซึ่งส่งและรับข้อความในรูปแบบที่ตอบโต้" "เรามีปฏิกิริยา" มันเป็นกรณีของการใช้คำผิดหรือพวกเขาจะถูกต้องสมบูรณ์? มีการนำโมเดลนักแสดง (เช่น Erlang) ไปทำปฏิกิริยาหรือไม่? การสร้างข้อความเป็นการตอบสนองต่อข้อความอื่น ๆ ที่ถือว่ามีปฏิกิริยาเหมือนกันหรือไม่? การอ่านที่เกี่ยวข้องบางส่วนที่มีวิธีการเปรียบเทียบ: StackOverflow: RX กับคิวการส่งข้อความเช่น rabbitmq หรือ zeromq? CS.SE: ฟังก์ชั่นการเขียนโปรแกรมปฏิกิริยาและรูปแบบของนักแสดงสัมพันธ์กันอย่างไร แลมบ์ดาสุดยอด: นักแสดงกับปฏิกิริยาที่เกิดขึ้น

16 messaging  actor-model  akka  reactive 

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

11 enterprise-architecture  messaging  event  command-message