Infrastructure (Infrastructure)

Software architecture มี pattern อยู่ทุกที่ที่ทีมพบ solution ที่ถูกวางบริบทให้เข้ากับปัญหาที่พบได้บ่อย และ pattern เหล่านี้มักจะเชื่อมโยงกับส่วนอื่น ๆ ของ ecosystem ด้วย (ดู Chapter 26 สำหรับการอภิปรายแบบเต็ม)

สถาปนิกใส่ใจเรื่อง coupling ทั้งระหว่าง component, data element, API…และ infrastructure ดังตัวอย่างของ Broker-Domain pattern

Broker-Domain Pattern (Broker-Domain Pattern)

ในหัวข้อนี้ เราจะพิจารณา order-placement workflow เดิม แต่คราวนี้ implement ด้วย event-driven architecture ดังแสดงใน Figure 20-4

An order placement workflow implemented in EDA

Figure 20-4. An order placement workflow implemented in EDA

อย่างที่คุณเห็นมาแล้ว EDA ใช้ event ในการสื่อสารระหว่าง service ดังนั้น event handler ต้อง subscribe ไปยัง service ที่ถูกต้องเพื่อสร้าง workflow event handler ถูก implement ด้วย broker ซึ่งเป็นส่วนหนึ่งของ infrastructure ของ architecture ใน EDA topic หรือ queue มักถูกเป็นเจ้าของโดย ผู้ส่ง เช่น Payment ต้องรู้ address ของ topic เพื่อจะ subscribe เข้าไปได้

ใน Figure 20-5 OrderPlacement “เป็นเจ้าของ” broker ที่ processor ตัวอื่นจะ subscribe เข้ามา กล่าวอีกนัยหนึ่งคือ infrastructure ที่จำเป็นสำหรับ service นี้รวมถึง broker ด้วย ถ้าระบบใช้ broker เดียวสำหรับการสื่อสารทั้งหมด service ทุกตัวก็จะพึ่งพา infrastructure ส่วนเดียวกัน

In event-driven choreography, the topic or queue is typically owned by the sender

Figure 20-5. In event-driven choreography, the topic or queue is typically owned by the sender

infrastructure สำหรับ workflow ที่แสดงใน Figure 20-6 มี broker เดียว หมายความว่า event processor แต่ละตัว “รู้” ว่าจะไปที่ไหนเพื่อ subscribe หา collaborator ของ workflow broker เดียวยังทำให้มีที่เดียวสำหรับ logging, monitoring และ governance อื่น ๆ ด้วย

Using one broker for the entire workflow

Figure 20-6. Using one broker for the entire workflow

อย่างไรก็ตาม เป้าหมายหนึ่งของ distributed architecture คือการปรับปรุง fault tolerance แล้วถ้า broker เดียวใน Figure 20-6 ล่มขึ้นมาล่ะ? workflow ทั้งหมดจะหยุดทำงานทันที ปัญหาที่อาจเกิดขึ้นอีกอย่างคือเรื่อง scale ถ้า message ทั้งหมดต้องผ่าน broker เดียว ก็มีความเสี่ยงที่ broker จะรับภาระหนักเกินไปเมื่อปริมาณ message เพิ่มขึ้น

อีกแนวทางหนึ่งคือ Domain-Broker pattern ซึ่งจัดการ infrastructure ในลักษณะเดียวกับความละเอียด (granularity) ของ domain ลองพิจารณา Figure 20-7

Utilizing the Domain-Broker pattern to assign ownership to infrastructure

Figure 20-7. Utilizing the Domain-Broker pattern to assign ownership to infrastructure

ใน architecture ทางเลือกที่แสดงใน Figure 20-7 service กลุ่มที่เกี่ยวข้องกันแต่ละกลุ่มจะใช้ broker ร่วมกัน ซึ่งสะท้อนการแบ่ง domain โดยรวมของ architecture solution นี้ยังคง discovery ที่ดีไว้ได้ ในขณะที่เพิ่ม fault tolerance, scalability, elasticity และ operational architectural characteristic อื่น ๆ อีกมาก อย่างไรก็ตาม โปรดสังเกตว่า ทั้งสองแนวทางนี้ไม่ใช่ “best practice” trade-off ของ Single-Broker pattern แสดงอยู่ใน Table 20-2

Table 20-2. Single-Broker pattern trade-offs | Advantages | Disadvantages | | --- | --- | | Centralized discovery | Fault tolerance | | Least possible infrastructure | Throughput limits |

Domain-Broker pattern ก็มี trade-off ของตัวเองเช่นกัน แสดงอยู่ใน Table 20-3

Table 20-3. Domain-Broker pattern trade-offs | Advantages | Disadvantages | | --- | --- | | Better isolation | More difficult discovery of queues/topics | | Matches domain boundaries | More infrastructure = more expensive | | More scalable | More moving parts to maintain |

สถาปนิกต้องหาสมดุลระหว่าง discovery กับความจำเป็นในการแยก domain ออกจากกัน ในการตัดสินใจว่า infrastructure pattern แบบไหนเหมาะสมที่สุดสำหรับ ระบบ ของตัวเอง