EDA (สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์) คืออะไร

สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ (EDA) คืออะไร

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

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

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

เหตุใดสถาปัตยกรรมแบบแยกส่วนจึงมีความสำคัญ

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

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

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

ประโยชน์ของสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ (EDA) คืออะไร

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

เพิ่มขนาดและขัดข้องโดยเป็นอิสระ

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

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

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

พัฒนาด้วยความคล่องตัว

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

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

สร้างระบบขยายได้

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

Event Producer ไม่มีความรู้เกี่ยวกับ Event Consumer ดังนั้นการขยายระบบจึงมีแรงเสียดทานน้อยลง และคุณลักษณะหรือการผสานรวมใหม่ไม่ได้เพิ่มการพึ่งพาที่ทำให้การพัฒนาในอนาคตช้าลง

ลดความซับซ้อน

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

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

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

ในตัวอย่าง บริการรับคำสั่งซื้อสามารถจัดเก็บคำสั่งซื้อที่เข้ามาในปริมาณมากได้โดยการบัฟเฟอร์ข้อความในคิว

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

ตรวจสอบอย่างง่ายดาย

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

ลดต้นทุน

EDA เป็นแบบพุช ดังนั้นทุกอย่างจึงเกิดขึ้นตามคำสั่งเมื่อเหตุการณ์ปรากฏขึ้นในเราเตอร์ ด้วยวิธีนี้ จะไม่ต้องเสียค่าใช้จ่ายสำหรับการสำรวจอย่างต่อเนื่องเพื่อตรวจสอบกิจกรรม ซึ่งหมายความว่าใช้ Network Bandwidth (แบนวิดท์เครือข่าย) น้อยลง ใช้ CPU น้อยลง ความจุกลุ่มอินสแตนซ์ที่ว่างน้อยลง และแฮนด์เชค SSL/TLS น้อยลง

สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ (EDA) ทำงานอย่างไร

ด้านล่างนี้เป็นตัวอย่างของสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ (EDA) สำหรับไซต์อีคอมเมิร์ซ

ไซต์ตัวอย่างนี้แสดงส่วนประกอบหลักของ Event Producers และเหตุการณ์ที่สร้างขึ้น ในสถานการณ์สมมตินี้ Event Router นำเข้าและกรองเหตุการณ์ จากนั้นจะส่งเหตุการณ์อย่างน้อยหนึ่งเหตุการณ์ไปยัง Event Consumers

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

เวิร์กโหลดประเภทใดที่เหมาะกับสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ (EDA)

สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ (EDA) สามารถให้วิธีที่มีประสิทธิภาพในการตอบสนองความต้องการของเวิร์กโหลดที่เพิ่มทรัพยากรได้สูงและมีความพร้อมใช้งานสูง EDA ยังใช้งานได้ดีกับเวิร์กโหลดที่มีรูปแบบการรับส่งข้อมูลที่คาดเดาไม่ได้หรือ "ตรงไป"

สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ (EDA) ปรับปรุงแอปพลิเคชันอย่างไร

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

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

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

กรณีการใช้งานสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ทั่วไป (EDA) มีอะไรบ้าง

การสื่อสารไมโครเซอร์วิสสำหรับเว็บและแบ็กเอนด์มือถือ

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

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

การทำงานอัตโนมัติของขั้นตอนการทำงานทางธุรกิจ

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

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

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

การผสานรวมแอปพลิเคชัน SaaS

ความท้าทายสูงสุดสำหรับสภาพแวดล้อม Software as a Service (SaaS) คือการขาดการมองเห็นกิจกรรมและข้อมูลของผู้ใช้ เพื่อปลดล็อกข้อมูลแบบแยกส่วน สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์สามารถนำเข้าเหตุการณ์ของแอปพลิเคชัน SaaS หรือส่งเหตุการณ์ไปยังแอปพลิเคชัน SaaS ได้ ตัวอย่างเช่น สามารถสร้างมิดเดิลแวร์เพื่อนำเข้าข้อมูลคำสั่งซื้อของพาร์ทเนอร์ที่เข้ามาและส่งคำสั่งซื้อโดยตรงไปยังแอปพลิเคชันประมวลผลคำสั่งซื้อภายในบริษัท

ระบบอัตโนมัติของโครงสร้างพื้นฐาน

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

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

ควรใช้สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ (EDA) เมื่อใด

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

กระบวนการผสานการทำงานระบบที่แตกต่างกัน

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

ข้ามภูมิภาค การจำลองแบบข้อมูลข้ามบัญชี

สามารถใช้ EDA เพื่อประสานงานระบบระหว่างทีมที่ปฏิบัติงานและปรับใช้ใน AWS Region และบัญชีต่างๆ ของ AWS สามารถใช้ Event Router ถ่ายโอนข้อมูลระหว่างระบบ เพื่อพัฒนา เพิ่มทรัพยากร และปรับใช้บริการต่างๆ ได้อย่างอิสระจากทีมอื่นๆ

การตรวจสอบสถานะทรัพยากรและการแจ้งเตือน

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

Fanout และการประมวลผลแบบขนาน

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

รูปแบบสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ทั่วไป (EDA) คืออะไร

ฟังก์ชันระยะสั้นมากมาย

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

การประมวลผลแบบออนดีมานด์แทนแบทช์

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

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

กระบวนการกู้คืนการหยุดชะงัก

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

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

สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ (EDA) มีอุปสรรคอะไรบ้าง

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

เวลาแฝงที่แปรผันได้

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

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

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

Eventual consistency

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

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

DynamoDB มีการอ่านค่าที่สอดคล้องกันในระดับสูง บางครั้งมีเวลาแฝงที่สูงขึ้น และยังสามารถรองรับธุรกรรมเพื่อช่วยรักษาความสอดคล้องกันของข้อมูล

สามารถใช้ฐานข้อมูลแบบเชิงสัมพันธ์สำหรับคุณสมบัติที่ต้องการลักษณะแบบ ACID แม้ว่าฐานข้อมูลเชิงสัมพันธ์ใดๆ จะเพิ่มทรัพยากรได้น้อยกว่าที่เก็บข้อมูล NoSQL

คืนค่าให้ผู้โทร

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

ในหลายกรณี การคืนค่ามีความสำคัญน้อยกว่าการรับประกันความสำเร็จหรือความล้มเหลวของการประมวลผลเหตุการณ์ คุณลักษณะที่ทำให้แน่ใจได้ว่าการประมวลผลเหตุการณ์อาจมีความสำคัญมากกว่าการส่งกลับค่าไปยังผู้โทร

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

การแก้จุดบกพร่องระหว่างบริการและฟังก์ชันต่าง ๆ

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

Orchestration (การควบคุมระบบ)

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

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

บริการใดของ AWS ที่ใช้สถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ (EDA)

บริการของ AWS มักสร้างหรือใช้เหตุการณ์ ทำให้ง่ายต่อการสร้างโซลูชันด้วยสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์ (EDA)

นอกจากนี้ บริการต่างๆ เช่น Amazon EventBridge Amazon SNS Amazon SQS และ AWS Step Functions รวมถึงคุณสมบัติที่ช่วยให้ลูกค้าเขียนโค้ดต้นแบบน้อยลงและสร้าง EDA ได้เร็วขึ้น

Amazon EventBridge

คุณสามารถใช้ Amazon EventBridge เพื่อสร้าง Event Bus สำหรับแอปพลิเคชันที่ขับเคลื่อนด้วยเหตุการณ์ตามขนาดได้โดยใช้เหตุการณ์จากแอปพลิเคชัน SaaS บริการอื่นๆ ของ AWS หรือแอปพลิเคชันที่กำหนดเอง

EventBridge ใช้กฎเพื่อกำหนดเส้นทางเหตุการณ์จากแหล่งที่มาของเหตุการณ์ไปยังเป้าหมายที่แตกต่างกัน เป้าหมายอาจรวมถึงบริการของ AWS เช่น AWS Lambda Step Functions และ Amazon Kinesis หรือตำแหน่งข้อมูล HTTP ใดๆ ผ่านปลายทาง EventBridge API

การผสานรวมที่เป็นที่นิยมสำหรับกรณีการใช้งาน EDA คือ Step Functions ซึ่งเหตุการณ์จะทริกเกอร์ขั้นตอนการทำงานเฉพาะ

AWS Step Functions

AWS Step Functions ประกอบด้วย Workflow Studio ซึ่งเป็นตัวออกแบบขั้นตอนการทำงานภาพแบบ low-code ที่ผู้สร้างใช้เพื่อจัดเตรียมบริการต่างๆ ของ AWS สามารถใช้ Workflow Studio เพื่อสร้างแอปพลิเคชันแบบกระจาย ทำให้ IT และกระบวนการทางธุรกิจเป็นแบบอัตโนมัติ และสร้างไปป์ไลน์ข้อมูลและแมชชีนเลิร์นนิงโดยใช้บริการ AWS

Amazon SNS

เราขอแนะนำให้ใช้ Amazon Simple Notification Service (Amazon SNS) เพื่อสร้างแอปพลิเคชันที่ตอบสนองต่ออัตราการโอนถ่ายข้อมูลสูงและเวลาแฝงต่ำที่เผยแพร่โดยแอปพลิเคชัน ไมโครเซอร์วิส หรือบริการของ AWS คุณยังสามารถใช้ Amazon SNS สำหรับแอปพลิเคชันที่ต้องการ Fanout ที่สูงมากไปยังตำแหน่งข้อมูลนับพันหรือล้านได้

Amazon SQS

Amazon Simple Queue Service (Amazon SQS) ให้บริการคิวโฮสต์ที่ปลอดภัย คงทน และพร้อมใช้งาน ซึ่งคุณสามารถใช้เพื่อรวมและแยกระบบซอฟต์แวร์และส่วนประกอบแบบกระจาย Amazon SQS นำเสนอโครงสร้างทั่วไป เช่น คิวข้อความที่ส่งไม่สำเร็จ และแท็กการจัดสรรต้นทุน