Styles of Microservice Communication (รูปแบบการสื่อสารของ Microservice)

ใน Figure 4-1 เราเห็นภาพรวมของ model ที่ผมใช้คิดเกี่ยวกับรูปแบบ communication ต่าง ๆ model นี้ไม่ได้ตั้งใจให้ครอบคลุมทุกอย่าง (ผมไม่ได้พยายามนำเสนอ grand unified theory ของ inter-process communication ที่นี่) แต่มันให้ภาพรวมระดับสูงที่ดีสำหรับการพิจารณารูปแบบ communication ต่าง ๆ ที่ใช้กันมากที่สุดใน microservice architecture

Figure 4-1. รูปแบบต่าง ๆ ของ inter-microservice communication พร้อมตัวอย่างเทคโนโลยีที่ implement แต่ละแบบ

เราจะดูองค์ประกอบต่าง ๆ ของ model นี้ในรายละเอียดในอีกสักครู่ แต่ก่อนอื่นผมขอสรุปคร่าว ๆ ก่อน:

Synchronous blocking

microservice เรียกไปยังอีก microservice หนึ่งและ block การทำงานเพื่อรอ response

Asynchronous nonblocking

microservice ที่ยิง call ออกไปสามารถทำงานต่อได้เลยไม่ว่า call นั้นจะถูกรับหรือไม่ก็ตาม

Request-response

microservice ส่ง request ไปยังอีก microservice หนึ่งเพื่อขอให้ทำบางอย่าง และคาดหวังที่จะได้รับ response แจ้งผลลัพธ์

Event-driven

microservice ยิง event ออกมา ซึ่ง microservice อื่น ๆ จะ consume และตอบสนองตามนั้น microservice ที่ยิง event ไม่รู้เลยว่ามี microservice ตัวไหนบ้าง (ถ้ามี) ที่ consume event ที่มันยิงออกไป

Common data

ไม่ค่อยถูกมองว่าเป็นรูปแบบ communication แต่ microservice ทำงานร่วมกันผ่าน shared data source

เวลาใช้ model นี้ช่วยทีมตัดสินใจเลือกแนวทางที่เหมาะสม ผมใช้เวลามากในการทำความเข้าใจ context ที่พวกเขากำลังทำงานอยู่ ความต้องการของพวกเขาในเรื่อง reliable communication, latency ที่ยอมรับได้ และปริมาณ communication ล้วนมีส่วนในการตัดสินใจเลือกเทคโนโลยี แต่โดยทั่วไปแล้วผมมักเริ่มจากการตัดสินใจว่ารูปแบบ request-response หรือ event-driven collaboration เหมาะสมกว่ากันสำหรับสถานการณ์นั้น ๆ ถ้าผมกำลังมองไปที่ request-response ทั้ง synchronous และ asynchronous implementation ก็ยังเป็นตัวเลือกที่มีให้ ดังนั้นผมมี ตัวเลือกที่สอง ต้องตัดสินใจ แต่ถ้าเลือก event-driven collaboration style ตัวเลือกในการ implement จะจำกัดอยู่แค่ nonblocking asynchronous เท่านั้น

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

Mix and Match (ผสมผสานและจับคู่)

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

ด้วยเหตุนี้ มาดูรูปแบบ communication ต่าง ๆ เหล่านี้ในรายละเอียดกันต่อ