Style Characteristics (คุณลักษณะของสไตล์นี้)

การให้คะแนนหนึ่งดาวในตาราง characteristic rating ใน Figure 15-39 หมายความว่า architecture characteristic นั้นๆ ไม่ได้รับการรองรับดีนักในสถาปัตยกรรมนี้ ในขณะที่การให้คะแนนห้าดาวหมายถึงมันเป็นหนึ่งในจุดแข็งที่สุดของสไตล์นั้น คำนิยามของแต่ละ characteristic ที่ระบุใน scorecard สามารถดูได้ใน Chapter 4

Event-driven architecture เป็นสถาปัตยกรรมแบบ technically partitioned เป็นหลัก ในแง่ที่ว่า domain หนึ่งๆ กระจายอยู่ใน event processor หลายตัวและถูกผูกเข้าด้วยกันผ่าน broker, contract (event payload) และ topic การเปลี่ยนแปลง domain หนึ่งๆ มักส่งผลกระทบต่อ event processor และ messaging artifact อื่นๆ หลายตัว ดังนั้น EDA จึงมักไม่ถือว่าเป็น domain partitioned

Figure 15-39. EDA characteristics ratings (คะแนนคุณลักษณะของ EDA)

จำนวน quanta ภายใน EDA อาจแตกต่างกันไปตั้งแต่หนึ่งถึงหลายตัว ขึ้นอยู่กับการโต้ตอบกับฐานข้อมูลภายใน event processor แต่ละตัวและระบบใช้ request-reply processing หรือไม่ แม้การสื่อสารใน EDA จะพึ่งพาการเรียกแบบอะซิงโครนัส แต่ถ้า event processor หลายตัวใช้ instance ฐานข้อมูลเดียวกัน พวกมันทั้งหมดจะถูกรวมอยู่ใน architectural quantum เดียวกัน สิ่งเดียวกันนี้เป็นจริงกับ request-reply processing เช่นกัน แม้การสื่อสารระหว่าง event processor จะยังคงเป็นแบบอะซิงโครนัส แต่ถ้าต้องการการตอบกลับทันทีจาก event consumer มันจะผูก event processor เหล่านั้นเข้าด้วยกันแบบซิงโครนัส สร้างเป็น quantum เดียว

ตัวอย่างเช่น ลองนึกภาพ event processor ตัวหนึ่งส่งคำขอไปยัง event processor อีกตัวเพื่อวางคำสั่งซื้อ event processor ตัวแรกต้องรอ order ID จาก event processor ตัวอื่นก่อนจึงจะดำเนินการต่อได้ ถ้า event processor ตัวที่สอง (ตัวที่วางคำสั่งซื้อและสร้าง order ID) ล่ม event processor ตัวแรกก็ไม่สามารถดำเนินการต่อได้ นั่นหมายความว่าพวกมันเป็นส่วนหนึ่งของ architecture quantum เดียวกันและใช้ architectural characteristic ร่วมกัน แม้ว่าทั้งสองจะกำลังส่งและรับ message แบบอะซิงโครนัสอยู่ก็ตาม

Event-driven architecture ได้คะแนนสูงมาก (4 ถึง 5 ดาว) ในด้าน performance, scalability และ fault tolerance ซึ่งเป็นจุดแข็งหลักของมัน performance ที่สูงเกิดจากการผสมผสานการสื่อสารแบบอะซิงโครนัสกับการประมวลผลแบบขนานสูง scalability ที่สูงเกิดขึ้นได้จากการ load balance ของ event processor ด้วยโปรแกรม (เรียกอีกอย่างว่า competing consumers และ consumer groups ) เมื่อโหลดคำขอเพิ่มขึ้น event processor เพิ่มเติมสามารถถูกเพิ่มเข้าไปด้วยโปรแกรมเพื่อรองรับคำขอที่เพิ่มขึ้น เหตุผลที่เราให้แค่สี่ดาว (แทนที่จะเป็นห้าดาว) เป็นเพราะฐานข้อมูล (ดู Chapter 16 เรื่อง space-based architecture สำหรับตัวอย่างการให้คะแนนห้าดาวในคุณลักษณะเหล่านี้) EDA บรรลุ fault tolerance ได้ผ่าน event processor ที่ decoupled และอะซิงโครนัส ซึ่งให้ eventual consistency และการประมวลผล event workflow ถ้า processor ปลายทางตัวอื่นใช้งานไม่ได้ ตราบใดที่ user interface หรือ event processor ที่ทำคำขอไม่ต้องการการตอบกลับทันที ระบบก็สามารถประมวลผล event นั้นในภายหลังได้

EDA ได้คะแนนค่อนข้างต่ำในด้าน simplicity และ testability โดยรวม ส่วนใหญ่เนื่องมาจาก event flow ที่ไม่กำหนดแน่นอนและ dynamic ของมัน ใน request-based model flow ที่กำหนดแน่นอนนั้นค่อนข้างง่ายที่จะทดสอบ เพราะเส้นทางและผลลัพธ์โดยทั่วไปเป็นที่รู้กันอยู่แล้ว แต่กับ event-driven model ไม่ใช่แบบนั้น บางครั้งสถาปนิกก็ไม่รู้เลยว่า event processor จะตอบสนองต่อ event แบบ dynamic อย่างไร หรือจะสร้าง message อะไรออกมา สิ่งเหล่านี้เรียกว่า nondeterministic workflow “event tree diagram” ของระบบเหล่านี้อาจซับซ้อนอย่างมาก สร้างสถานการณ์ได้เป็นร้อยหรือแม้แต่พันแบบ ทำให้ยากมากที่จะ govern และทดสอบ

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

ข้อเสียของ EDA รวมถึงความยากในการควบคุม workflow โดยรวมที่เกี่ยวข้องกับ initiating event หนึ่งๆ การประมวลผล event เป็นไปแบบ dynamic มากเนื่องจากเงื่อนไขที่เปลี่ยนแปลงตลอดเวลา และยากที่จะรู้ว่า business transaction ที่อิงตาม initiating event นั้นเสร็จสมบูรณ์แล้วเมื่อไร

Error handling ก็เป็นความท้าทายใหญ่กับ EDA เช่นกัน เพราะโดยทั่วไปแล้วจะไม่มี mediator คอยตรวจสอบหรือควบคุม business transaction (ยกเว้นกับ mediator topology) ถ้าเกิดความล้มเหลวขึ้น service อื่นๆ จะไม่รู้ตัวเลยว่าเกิดการล่ม business process ที่อิงตาม initiating event นั้นจะติดค้างและไม่สามารถดำเนินต่อไปได้โดยไม่มีการแทรกแซงบางอย่างทั้งแบบอัตโนมัติหรือด้วยมือ แม้ในขณะที่กระบวนการอื่นๆ ทั้งหมดจะยังคงดำเนินต่อไปโดยไม่สนใจ error นั้นเลยก็ตาม ตัวอย่างเช่น ถ้า event processor Payment ในระบบสั่งซื้อของเราล่มและไม่ทำงานที่ได้รับมอบหมายเสร็จสิ้น event processor Inventory ก็ยังคงปรับปรุงสต็อกต่อไป และ event processor ปลายทางอื่นๆ ทั้งหมดก็จะตอบสนองราวกับว่าทุกอย่างเรียบร้อยดี

การ restart business transaction (recoverability) นั้นยากมากที่จะทำใน EDA เนื่องจากการกระทำอื่นๆ ได้ถูกดำเนินการแบบอะซิงโครนัสผ่านการประมวลผลของ initiating event ไปแล้ว หลายครั้งจึงเป็นไปไม่ได้เลยที่จะส่ง initiating event นั้นซ้ำอีกครั้ง

Choosing Between Request-Based and Event-Based Models (การเลือกระหว่างโมเดล Request-Based กับ Event-Based)

โมเดลแบบ request-based และแบบ event-based ต่างก็เป็นแนวทางที่ใช้งานได้จริงสำหรับการออกแบบระบบซอฟต์แวร์ อย่างไรก็ตาม การเลือกโมเดลที่ถูกต้องเป็นสิ่งสำคัญต่อความสำเร็จ เราแนะนำให้เลือกโมเดลแบบ request-based สำหรับคำขอที่มีโครงสร้างชัดเจนและขับเคลื่อนด้วยข้อมูล (เช่น การดึงข้อมูลโปรไฟล์ลูกค้า) เมื่อความสำคัญอยู่ที่ความแน่นอนและการควบคุม workflow เราแนะนำให้เลือกโมเดลแบบ event-based สำหรับ event ที่ขับเคลื่อนด้วยการกระทำและมีความยืดหยุ่น ซึ่งต้องการ responsiveness และ scale ระดับสูง พร้อมการประมวลผลของผู้ใช้ที่ซับซ้อนและ dynamic

การเข้าใจ trade-off ของโมเดล event-based ก็ช่วยในการตัดสินใจว่าอะไรเหมาะสมที่สุดด้วย Table 15-2 แสดงข้อดีและข้อเสียของโมเดล event-based ของ EDA

Table 15-2. Trade-offs of the event-driven model (Trade-Off ของโมเดล Event-Driven) | Advantages over request-based | Trade-offs | | --- | --- | | Better response to dynamic user content | Only supports eventual consistency | | Better scalability and elasticity | Less control over processing flow | | Better agility and change management | Less certainty over outcome of event flow | | Better adaptability and extensibility | Difficult to test and debug | | Better responsiveness and performance | | | Better real-time decision making | | | Better reaction to situational awareness | |