Communication Patterns

🤔 แอพไม้จิ้มฟันยันยานอวกาศเขาออกแบบยังไง ?

ในคอร์สนี้เราจะมาดูวิธีการแก้ปัญหาของ Distributed System กัน โดยจะเริ่มอธิบายตั้งแต่ การออกแบบซอฟต์แวร์แบบเด็กอนุบาล ยัน Large Scale Enterprise กัน ซึ่งในบทความนี้จะขอไล่ลำดับความวุ่นวายไปเรื่อยๆ และใช้ร้านอาหารที่ทุกคนเข้าใจได้ในชีวิตประจำวันเป็นตัวอธิบายนะขอรับ

🍚 ร้านอาหารตามสั่ง

เป็นร้านที่ลูกค้าเดินเข้าไปสั่งอาหารกับ "พ่อครัว" แล้วลูกค้าก็ยืนรอให้เขาทำอาหารจนเสร็จตามที่เราเห็นได้ทั่วไป

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

Synchronous คือการไปทำอะไรซักอย่าง แล้วต้องรอจนกว่าจะทำสิ่งนั้นๆเสร็จ โดยที่ไปทำอย่างอื่นต่อไม่ได้ เช่น พ่อครัวไปทำข้าวในครัว ระหว่างที่ทำข้าวอยู่ เขาก็จะแยกร่างมาเดินเสริฟน้ำไม่ได้นั่นเอง

🤕 จุดอ่อนของระบบ

เนื่องจากทั้งระบบต้องพึ่ง พ่อครัว แต่พ่อครัวดันมีคนเดียว ดังนั้นทุกอย่างเลยต้องหยุดรอพ่อครัว เลยทำให้ คอขวด ที่ทำให้ระบบนี้พังก็คือพ่อครัวนั่นเอง

ตัวอย่าง สมมุติว่าพ่อครัวทำอาหาร 1 จาน ต้องใช้เวลาทำราวๆ 10 นาที (รับออเดอร์, เตรียมกับข้าว, ทำกับข้าว, เช็คบิล, เก็บโต๊ะ บลาๆ) นั่นหมายความว่า สุดๆแล้วร้านนี้จะรับทำอาหารได้สูงสุด 6 จาน ต่อ 1 ชั่วโมง นั่นเอง

🩹 การรักษา

จากปัญหาด้านบนงั้น ก็เพิ่มพ่อครัวดิ!! . . . เพื่อให้สามารถทำหลายๆอย่างพร้อมๆกันได้หรือที่เราพูดติดปากกันว่าแบบ Parallel นั่นเอง ซึ่งฟังแล้วก็ดูเหมือนจะง่ายนะ แต่การแก้ปัญหาจริงๆนั้น ถ้าเพิ่มพ่อครัวเพียงอย่างเดียว มันจะนำปัญหาแบบอื่นตามมา ซึ่งในโลกของซอฟต์แวร์ปัญพวกนี้คือสิ่งที่เราจะเจอในการทำ Distributed System นั่นเอง ดังนั้นเราลองดูวิวัฒนาการของร้านหารในรูปแบบถัดไปกันดีกั่ว

🍛 ร้านอาหารตามสั่ง V.2

จากปัญหาด้านบนที่ว่ามาทำให้ร้านต้อง เพิ่มกำลังคน เพื่อให้สามารถทำของหลายๆอย่างพร้อมกันได้ แต่สิ่งแรกที่เราต้องทำคือ การแบ่งงานออกเป็นส่วนๆ เช่น ในครัวก็ต้องแบ่งเป็น โซนทอด โซนย่าง โซนต้ม โซนดูแลรับผิดชอบเรื่องเครื่องเคียง โซนรับผิดชอบเรื่องข้าว บลาๆ เพราะไม่อย่างนั้นเราก็จะมี คนเยอะๆแต่ทุกคนไปกระจุกทำของซ้ำๆกันไม่มีหน้าที่ที่ชัดเจน

การเพิ่มกำลังในโลกของซอฟต์แวร์มีหลากหลายวิธี แต่ทุกวิธีนั้นมีหัวใจหลักเดียวกันคือ 💖 การแบ่งง่านออกเป็นส่วนๆ เช่นกัน เพราะจากเดิมที่ระบบทำงานเป็น Synchronous มันจะเริ่มกลายเป็น ระบบ Asynchronous แล้วนั่นเอง ตามรูปด้านล่าง

Asynchronous คือการทำอะไรซักอย่าง แต่ไม่ต้องรอจนให้มันเสร็จ ก็สามารถไปทำอย่างอื่นต่อได้ เช่น คนรับออเดอร์เดินไปบอกพ่อครัวว่าลูกค้าสั่งอะไรเสร็จ ก็สามารถกลับมารับออเดอร์ต่อได้เลย โดยไม่ต้องรอให้พ่อครัวทำอาหารนั้นๆจนเสร็จนั่นเอง (จำง่ายๆคือมันตรงข้ามกับ synchronous งุยล่ะ)

🤕 จุดอ่อนของระบบ

ในโลกของซอฟต์แวร์ถ้าเราแบ่งงานออกเป็นส่วนๆได้ เราก็จะสามารถขยายความสามารถได้โดยการทำ Scaling แบบต่างๆ แต่ปัญหาที่แท้จริงของมันคือ งานแต่ละส่วนจะคุยกันรู้เรื่องได้ยังไง? เช่น ครัวต้มอาหารจะรู้ได้ยังไงว่าเมื่อทำเสร็จต้องส่งต่อไปให้ครัวทอดหรือครับปิ้ง? หรือไม่จำเป็นต้องส่ง? หรือเมื่อทำเครื่องดื่มเสร็จมันจะต้องเอาไปวางคู่กับอาหารจานไหน? เนื่องจากที่เราเปลี่ยนระบบกลายเป็น Asynchronous เลยทำให้งานแต่ละส่วนมันทำโดยไม่ต้องรอกันได้ ดังนั้นปัญหาที่ตามมาคือ การคุยกันของแต่ละเซอร์วิสนั่นเอง (Service Communication Problems) ซึ่งถ้าเราไม่จัดการกับเรื่องนี้ เราจะรู้ได้ไงว่าออเดอร์นั้นๆเสร็จหรือยัง?

ตัวอย่าง สมมุติว่าลูกค้ากดปุ่มสั่งซื้อสินค้าและจ่ายเงินเสร็จ แต่ระบบเราเป็นแค่คนกลาง เลยต้องส่งบิล ส่งออเดอร์ไปยังร้านค้าต่างๆ แต่เราไม่สามารถตอบลูกค้าได้ว่าสถานะการสั่งซื้อเป็นยังไง แล้วลูกค้าจะ happy กับระบบเราหรือเปล่า?

🩹 การรักษา

ปัญหาเกิดจากการแยกส่วนรับผิดชอบกัน ดังนั้นวิธีการแก้ปัญหาคือ ควมคุมการสื่อสาร ระหว่างแต่ละ module นั่นเอง ซึ่งในทางเทคนิคเราเรียกเรื่องพวกนี้ว่า การทำ Messaging หรือการทำ Communication นั่นเอง

🧭 เนื้อหาทั้งหมดของคอร์สนี้

จากที่เล่าไปทั้งหมดเราก็จะมาดูรูปแบบต่างๆในการควมคุมการสื่อสาร หรือที่เราเรียกกันว่า Communication Patterns กันดีกั่วขอรับ ตามหัวข้อด้านล่างเบย

สั่งอาหารคุยตัวต่อตัว
ใบสั่งอาหาร Request & Response
ตะโกนเอา Event base
หัวหน้าเชฟ Orchestration

Previousการลบข้อมูล NextDesign Patterns

Last updated 4 years ago

Was this helpful?