Communication Styles (รูปแบบการสื่อสาร)

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

Figure E-1. รูปแบบต่างๆ ของการสื่อสารระหว่างไมโครเซอร์วิส พร้อมตัวอย่างเทคโนโลยีที่ใช้นำไปปฏิบัติ

ด้วยการสื่อสารแบบ request-response ไมโครเซอร์วิสตัวหนึ่งส่งคำขอไปยังไมโครเซอร์วิสปลายทางและคาดหวังการตอบกลับ ด้วย synchronous request-response เราจะคาดหวังว่าการตอบกลับจะกลับมาที่ instance ของไมโครเซอร์วิสที่ส่งคำขอนั้นไป ด้วย asynchronous request-response การตอบกลับสามารถกลับมาที่ instance อื่นของไมโครเซอร์วิสต้นทางได้

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

ไมโครเซอร์วิสตัวหนึ่งอาจสื่อสารผ่านมากกว่าหนึ่งโปรโตคอลได้ ตัวอย่างเช่น ใน Figure E-2 เราเห็นไมโครเซอร์วิส Shipping ให้บริการ REST interface สำหรับปฏิสัมพันธ์แบบ request-response ซึ่งยังยิง event ออกมาเมื่อมีการเปลี่ยนแปลงเกิดขึ้นด้วย

Figure E-2. ไมโครเซอร์วิสตัวหนึ่งที่เปิดเผยฟังก์ชันการทำงานผ่าน REST API และ topic

การทำงานร่วมกันแบบ event-driven ทำให้สร้างสถาปัตยกรรมที่ loosely coupled มากขึ้นได้ง่ายขึ้น แต่ก็ต้องใช้ความพยายามมากขึ้นในการเข้าใจว่าระบบกำลังทำงานอย่างไร การสื่อสารประเภทนี้มักต้องใช้เทคโนโลยีเฉพาะทาง เช่น message broker ซึ่งอาจทำให้เรื่องซับซ้อนขึ้นไปอีก ถ้าคุณสามารถใช้ managed message broker ได้ นั่นจะช่วยลดต้นทุนของระบบประเภทนี้ได้

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