แนวทางปฏิบัติที่ดีที่สุดสำหรับการจัดการการสื่อสารระหว่างแบบอะซิงโครนัส?


10

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

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

ยิ่งยากขึ้นคือความจริงที่ว่าเมื่อล้มเหลวในการส่งการแจ้งเตือนเกตเวย์จะพยายามส่งการแจ้งเตือนทุก ๆ 15 นาทีเป็นเวลาหลายชั่วโมง

ฉันแก้ไขมันโดยใช้บันทึกฐานข้อมูลของธุรกรรมที่ค้างอยู่จากนั้นตรวจสอบความสำเร็จและความล้มเหลวจากการส่งคืนรวมทั้งฟังการหน่วงเวลาสำหรับการแจ้งเตือนและการจัดการธุรกรรม ...

ยากพอสมควร!

แต่สิ่งนี้จะต้องได้รับการแก้ไขเป็นพันล้านครั้งก่อนดังนั้นวิธีปฏิบัติที่ดีที่สุดคืออะไร?

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

คำแนะนำหนังสือ / บทความจะดีมาก

ขอบคุณล่วงหน้า!

คำตอบ:


13

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

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

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

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

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.