ฉันควรสลับจาก WCF เป็น NserviceBus

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

ตอนนี้เรามีปัญหาหลายอย่างเกี่ยวกับเรื่องนี้ - ส่วนใหญ่เราจะถูกขอให้สนับสนุน "โหมดตัดการเชื่อมต่อ" (เราต้องทนต่อความผิดพลาด) จากสิ่งที่ฉันรู้ไม่มีวิธีง่ายๆในการทำเช่นนี้โดยใช้ WCF stack - เราต้องการดำเนินการบางอย่างและอาจใช้ msmq ฉันดู NServiceBus เมื่อเร็ว ๆ นี้และจากที่ฉันเห็นว่ามันเหมาะสมกับค่าใช้จ่ายอย่างมาก - การยอมรับข้อผิดพลาดสามารถส่งข้อความผ่านอินเทอร์เน็ตผ่านเกตเวย์ http ง่าย ๆ ฯลฯ ฉันรู้ว่ามันเป็นที่ยอมรับในชุมชนและ ฉันสามารถดูสาเหตุจากการมองเข้าไป

ดังนั้นคำถามของฉันคือ ... การใช้ NServiceBus ฟังดูเหมือนความคิดที่สมเหตุสมผลหรือไม่มีใครมีข้อเสนอแนะอื่น ๆ / ประสบการณ์โลกแห่งความจริงที่เกี่ยวข้องกับเรื่องนี้หรือไม่? ฉันเดาว่าฉันกังวลที่จะแนะนำเทคโนโลยีใหม่ที่ฉันรู้ค่อนข้างน้อยและเผชิญปัญหากับสิ่งต่าง ๆ เช่นการรักษาความปลอดภัยการตั้งค่าทุกอย่างในวิธีที่เชื่อถือได้ gotchas ตลอดทาง .. ฉันยังระวัง "ทองคำ - ชุบ "สถาปัตยกรรมและเลือกสิ่งที่มันวาวที่จะจบลงด้วยการใช้งานฉันกับการติดกับ WCF และเพียงแค่ทำให้มันเหมาะกับฉัน ..

ขอบคุณ!

ข้อเสนอแนะของฉันหากคุณต้องการความรวดเร็วเกี่ยวกับเรื่องนี้และต้องการเพียงสิ่งที่ง่ายต่อการดำเนินการที่ทนทาน (ตัดการเชื่อมต่อ) กับ WCF คือดูที่การเชื่อมโยง WCF - MSMQ หากคุณต้องการบางสิ่งในสภาพแวดล้อมขนาดใหญ่ให้ดูที่ nServiceBus

ในใจของฉัน nServiceBus จะเริ่มส่องแสงในสภาพแวดล้อมที่มีขนาดใหญ่ขึ้น ยกตัวอย่างเช่นตัวอย่างต่อไปนี้ (ที่จะเป็นนรกบนโลกด้วย WCF แต่ง่าย ๆ กับ nServiceBus):

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

WCF มีการเชื่อม MSMQ

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

คำแนะนำทั้งสองนี้ใช้ประโยชน์อย่างมากของ MSMQ ดังนั้นโปรดทราบว่า: ไม่เหมือนกับ Apache MQ, RabbitMQ และระบบการจัดคิวอื่น ๆ ที่ได้รับความนิยม MSMQ ไม่ได้เป็นสถาปัตยกรรมคิวแบบโบรกเกอร์ทั่วไป แต่แทนที่จะเป็นคิวแบบกระจาย ซึ่งหมายความว่าหากไคลเอ็นต์ WCF ของคุณส่งข้อความผ่านการขนส่ง MSMQ ในขณะที่ไม่สามารถเชื่อมต่อกับเซิร์ฟเวอร์ระยะไกลที่โฮสต์คิวเครื่องไคลเอนต์จะเข้าคิวข้อความในสิ่งที่เรียกว่า "คิวขาออก" ภายในเครื่องแทน ข้อความจะอยู่ที่นั่นอย่างปลอดภัยจนกว่าจะถึงเวลาดังกล่าวเนื่องจากบริการ MSMQ ของลูกค้าตรวจพบว่าสามารถเชื่อมต่อกับบริการ MSMQ ระยะไกลได้อีกครั้ง ณ จุดนั้นข้อความจะไหลจากไคลเอนต์ไปยังปลายทางปลายทาง

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

หากคุณต้องการการเข้ารหัสและไม่มี ActiveDirectory ในรายการบล็อกนี้Sergey Sorokin ให้รายละเอียดขั้นตอนที่จำเป็นในการเข้ารหัสการสื่อสารของ MSMQ โดยใช้ WCF ที่ไม่มี Active Directory

มันไม่ใช่การแทนที่ 1 ต่อ 1 - หลายครั้งคุณจะใช้ NServiceBus เพื่อป้อนข้อความหรือนำข้อความจากจุดสิ้นสุด WCF

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