Communication (การสื่อสาร)

architecture pattern จำนวนมาก รวมถึง communication pattern มาจาก event-driven architecture และ นำไปใช้ได้กับ distributed architecture ใด ๆ ก็ตามที่สื่อสารกันผ่าน message และ/หรือ event เช่นที่ได้พูดถึง ใน Chapter 15 และ 18 อันที่จริง คุณได้เห็นตัวอย่างของการสื่อสารในแต่ละบทเหล่านั้นมาแล้ว—เราแค่ยังไม่ได้ระบุว่ามันคือ pattern อะไรกันแน่ เพราะสถาปนิกมักจะ implement pattern โดยไม่รู้ตัว ท้ายที่สุดแล้ว pattern ก็คือ solution สำหรับ ปัญหาที่พบได้ทั่วไป

Orchestration Versus Choreography (Orchestration เทียบกับ Choreography)

ลองพิจารณา communication pattern สองแบบที่คุณเคยเห็นมาแล้วทั้งใน “Mediated Event-Driven Architecture” และ “Choreography and Orchestration” นั่นคือ choreography และ orchestration ซึ่งสรุปไว้ใน Figure 20-2

Figure 20-2. Orchestration and choreography in a microservices architecture

ใน isomorphic workflow ที่แสดงใน Figure 20-2 domain service สี่ตัว (Service A ถึง D) ต้องร่วมมือกันเพื่อสร้าง workflow ในกรณี orchestration จะมี service แยกต่างหากอีกตัวหนึ่งที่ทำหน้าที่เป็นผู้ประสานงานของ workflow เรียกว่า orchestrator

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

สังเกตว่าตอนที่เราอธิบาย trade-off ของ mediation และ orchestration เราได้พูดถึงประเด็นเดียวกันหลาย อย่าง เราจะสรุปข้อดีไว้ตรงนี้

Centralized workflow (Workflow แบบรวมศูนย์)

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

Error handling (การจัดการ Error)

การจัดการ error ซึ่งเป็นส่วนสำคัญของ domain workflow หลายตัว จะได้รับความช่วยเหลือจากการมี state owner ของ workflow

Recoverability (ความสามารถในการกู้คืน)

เพราะ orchestrator คอยตรวจสอบ state ของ workflow ถ้า domain service หนึ่งหรือหลายตัวเกิด outage ระยะสั้น สถาปนิกสามารถเพิ่ม logic ให้ retry ได้

State management (การจัดการ State)

การมี orchestrator ทำให้ state ของ workflow สามารถ query ได้ และเป็นที่เก็บ transient state สำหรับ workflow อื่น ๆ ได้ด้วย

ข้อเสียโดยทั่วไปของ orchestration ได้แก่

Responsiveness (การตอบสนอง)

การสื่อสารทั้งหมดต้องผ่าน orchestrator ซึ่งมีศักยภาพที่จะสร้าง throughput bottleneck ที่ส่งผลเสีย ต่อ responsiveness ได้

Fault tolerance (ความทนทานต่อความล้มเหลว)

แม้ orchestration จะช่วยเพิ่ม recoverability ให้ domain service แต่ก็สร้าง single point of failure ให้กับ workflow ด้วยเช่นกัน ซึ่งแก้ไขได้ด้วย redundancy แต่ก็เพิ่มความซับซ้อนขึ้นด้วยเช่นกัน

Scalability (ความสามารถในการขยายขนาด)

รูปแบบการสื่อสารนี้ scale ได้ไม่ดีเท่า choreography เพราะ orchestrator เพิ่มจุดประสานงานเข้ามาอีก ซึ่งลด parallelism ที่เป็นไปได้ลง

Service coupling (Service Coupling)

การมี orchestrator ตรงกลางทำให้เกิด coupling ที่แน่นขึ้นระหว่างมันกับ domain component ซึ่งบางครั้งก็จำเป็น แต่ก็ไม่ค่อยเป็นที่นิยมใน microservices architecture

ในทำนองเดียวกัน เราได้พูดถึง choreography ทั้งใน microservices และ event-driven architecture มาแล้ว trade-off ของ workflow แบบ choreographed ได้แก่

Responsiveness (การตอบสนอง)

รูปแบบการสื่อสารนี้มีจุดคอขวดจุดเดียวน้อยกว่า จึงเปิดโอกาสให้เกิด parallelism ได้มากกว่า

Scalability (ความสามารถในการขยายขนาด)

การไม่มีจุดประสานงานอย่าง orchestrator ทำให้ scale แบบอิสระได้มากขึ้น

Fault tolerance (ความทนทานต่อความล้มเหลว)

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

Service decoupling (Service Decoupling)

ไม่มี orchestrator หมายถึง coupling ที่น้อยลง

ข้อเสียของรูปแบบการสื่อสารแบบ choreography ได้แก่

Distributed workflow (Workflow แบบกระจาย)

การไม่มีเจ้าของ workflow ทำให้การจัดการ error และเงื่อนไขขอบเขตอื่น ๆ ยากขึ้น

State management (การจัดการ State)

การไม่มีตัวเก็บ state แบบรวมศูนย์ทำให้การจัดการ state อย่างต่อเนื่องเป็นเรื่องยาก

Error handling (การจัดการ Error)

การจัดการ error ยากขึ้นเมื่อไม่มี orchestrator เพราะ domain service ต้องมีความรู้เกี่ยวกับ workflow มากขึ้น

Recoverability (ความสามารถในการกู้คืน)

ความสามารถในการกู้คืนจะยากขึ้นเมื่อไม่มี orchestrator ที่คอย retry และแก้ไขปัญหาอื่น ๆ

pattern ทั้งสองนี้เป็นตัวอย่างที่ดีของความแตกต่างระหว่าง style กับ pattern distributed architecture ใด ๆ ก็สามารถใช้ communication pattern เหล่านี้ได้ และสถาปนิกควรเข้าใจวิธีประเมิน trade-off ของมัน อย่าลืมกฎข้อที่สองของ Software Architecture ของเราที่ว่า คุณไม่สามารถทำ trade-off analysis แค่ครั้งเดียวแล้วจบได้ pattern เหล่านี้ยังแสดงให้เห็นด้วยว่า pattern ทั่วไปมีอยู่ทุกที่ ซึ่งเป็นเหตุผลว่าทำไมมันถึงพบได้บ่อย