Communication Patterns
🤔 แอพไม้จิ้มฟันยันยานอวกาศเขาออกแบบยังไง ?
Last updated
🤔 แอพไม้จิ้มฟันยันยานอวกาศเขาออกแบบยังไง ?
Last updated
ในคอร์สนี้เราจะมาดูวิธีการแก้ปัญหาของ Distributed System กัน โดยจะเริ่มอธิบายตั้งแต่ การออกแบบซอฟต์แวร์แบบเด็กอนุบาล ยัน Large Scale Enterprise กัน ซึ่งในบทความนี้จะขอไล่ลำดับความวุ่นวายไปเรื่อยๆ และใช้ร้านอาหารที่ทุกคนเข้าใจได้ในชีวิตประจำวันเป็นตัวอธิบายนะขอรับ
เป็นร้านที่ลูกค้าเดินเข้าไปสั่งอาหารกับ "พ่อครัว" แล้วลูกค้าก็ยืนรอให้เขาทำอาหารจนเสร็จตามที่เราเห็นได้ทั่วไป
ถ้าเปรียบกับโลกของซอฟต์แวร์แล้วก็คือ แอพที่เด็กหัดเขียนโปรแกรมใหม่ๆชอบทำกัน และทุกอย่างของระบบนี้ต้องพึ่ง พ่อครัว
เท่านั้น เพราะตั้งแต่การจดเมนู เสริฟน้ำ เดินไปเข้าครัว ยกอาหารมาให้ คิดเงิน เก็บโต๊ะ บลาๆ และเนื่องจากมีพ่อครัวคนเดียว ดังนั้นทุกอย่างเลยเป็น Synchronous ทั้งระบบเลย
Synchronous คือการไปทำอะไรซักอย่าง แล้วต้องรอจนกว่าจะทำสิ่งนั้นๆเสร็จ โดยที่ไปทำอย่างอื่นต่อไม่ได้ เช่น พ่อครัวไปทำข้าวในครัว ระหว่างที่ทำข้าวอยู่ เขาก็จะแยกร่างมาเดินเสริฟน้ำไม่ได้นั่นเอง
เนื่องจากทั้งระบบต้องพึ่ง พ่อครัว
แต่พ่อครัวดันมีคนเดียว ดังนั้นทุกอย่างเลยต้องหยุดรอพ่อครัว เลยทำให้ คอขวด
ที่ทำให้ระบบนี้พังก็คือพ่อครัวนั่นเอง
ตัวอย่าง สมมุติว่าพ่อครัวทำอาหาร 1 จาน ต้องใช้เวลาทำราวๆ 10 นาที (รับออเดอร์, เตรียมกับข้าว, ทำกับข้าว, เช็คบิล, เก็บโต๊ะ บลาๆ) นั่นหมายความว่า สุดๆแล้วร้านนี้จะรับทำอาหารได้สูงสุด 6 จาน ต่อ 1 ชั่วโมง นั่นเอง
จากปัญหาด้านบนงั้น ก็เพิ่มพ่อครัวดิ!! . . . เพื่อให้สามารถทำหลายๆอย่างพร้อมๆกันได้หรือที่เราพูดติดปากกันว่าแบบ Parallel นั่นเอง ซึ่งฟังแล้วก็ดูเหมือนจะง่ายนะ แต่การแก้ปัญหาจริงๆนั้น ถ้าเพิ่มพ่อครัวเพียงอย่างเดียว มันจะนำปัญหาแบบอื่นตามมา ซึ่งในโลกของซอฟต์แวร์ปัญพวกนี้คือสิ่งที่เราจะเจอในการทำ Distributed System นั่นเอง ดังนั้นเราลองดูวิวัฒนาการของร้านหารในรูปแบบถัดไปกันดีกั่ว
จากปัญหาด้านบนที่ว่ามาทำให้ร้านต้อง เพิ่มกำลังคน เพื่อให้สามารถทำของหลายๆอย่างพร้อมกันได้ แต่สิ่งแรกที่เราต้องทำคือ การแบ่งงานออกเป็นส่วนๆ เช่น ในครัวก็ต้องแบ่งเป็น โซนทอด โซนย่าง โซนต้ม โซนดูแลรับผิดชอบเรื่องเครื่องเคียง โซนรับผิดชอบเรื่องข้าว บลาๆ เพราะไม่อย่างนั้นเราก็จะมี คนเยอะๆแต่ทุกคนไปกระจุกทำของซ้ำๆกันไม่มีหน้าที่ที่ชัดเจน
การเพิ่มกำลังในโลกของซอฟต์แวร์มีหลากหลายวิธี แต่ทุกวิธีนั้นมีหัวใจหลักเดียวกันคือ 💖 การแบ่งง่านออกเป็นส่วนๆ เช่นกัน เพราะจากเดิมที่ระบบทำงานเป็น Synchronous มันจะเริ่มกลายเป็น ระบบ Asynchronous แล้วนั่นเอง ตามรูปด้านล่าง
Asynchronous คือการทำอะไรซักอย่าง แต่ไม่ต้องรอจนให้มันเสร็จ ก็สามารถไปทำอย่างอื่นต่อได้ เช่น คนรับออเดอร์เดินไปบอกพ่อครัวว่าลูกค้าสั่งอะไรเสร็จ ก็สามารถกลับมารับออเดอร์ต่อได้เลย โดยไม่ต้องรอให้พ่อครัวทำอาหารนั้นๆจนเสร็จนั่นเอง (จำง่ายๆคือมันตรงข้ามกับ synchronous งุยล่ะ)
ในโลกของซอฟต์แวร์ถ้าเราแบ่งงานออกเป็นส่วนๆได้ เราก็จะสามารถขยายความสามารถได้โดยการทำ Scaling แบบต่างๆ แต่ปัญหาที่แท้จริงของมันคือ งานแต่ละส่วนจะคุยกันรู้เรื่องได้ยังไง? เช่น ครัวต้มอาหารจะรู้ได้ยังไงว่าเมื่อทำเสร็จต้องส่งต่อไปให้ครัวทอดหรือครับปิ้ง? หรือไม่จำเป็นต้องส่ง? หรือเมื่อทำเครื่องดื่มเสร็จมันจะต้องเอาไปวางคู่กับอาหารจานไหน? เนื่องจากที่เราเปลี่ยนระบบกลายเป็น Asynchronous เลยทำให้งานแต่ละส่วนมันทำโดยไม่ต้องรอกันได้ ดังนั้นปัญหาที่ตามมาคือ การคุยกันของแต่ละเซอร์วิสนั่นเอง (Service Communication Problems) ซึ่งถ้าเราไม่จัดการกับเรื่องนี้ เราจะรู้ได้ไงว่าออเดอร์นั้นๆเสร็จหรือยัง?
ตัวอย่าง สมมุติว่าลูกค้ากดปุ่มสั่งซื้อสินค้าและจ่ายเงินเสร็จ แต่ระบบเราเป็นแค่คนกลาง เลยต้องส่งบิล ส่งออเดอร์ไปยังร้านค้าต่างๆ แต่เราไม่สามารถตอบลูกค้าได้ว่าสถานะการสั่งซื้อเป็นยังไง แล้วลูกค้าจะ happy กับระบบเราหรือเปล่า?
ปัญหาเกิดจากการแยกส่วนรับผิดชอบกัน ดังนั้นวิธีการแก้ปัญหาคือ ควมคุมการสื่อสาร ระหว่างแต่ละ module นั่นเอง ซึ่งในทางเทคนิคเราเรียกเรื่องพวกนี้ว่า การทำ Messaging หรือการทำ Communication นั่นเอง
จากที่เล่าไปทั้งหมดเราก็จะมาดูรูปแบบต่างๆในการควมคุมการสื่อสาร หรือที่เราเรียกกันว่า Communication Patterns กันดีกั่วขอรับ ตามหัวข้อด้านล่างเบย
สั่งอาหารคุยตัวต่อตัว
ใบสั่งอาหาร Request & Response
ตะโกนเอา Event base
หัวหน้าเชฟ Orchestration
ใจเย็นนะโยมนะ คอร์สนี้กำลังค่อยๆเขียนอยู่ แมวน้ำมีเวลาว่างเมื่อไหร่ก็จะมาอัพเดทเรื่อยๆ แต่ถ้าไม่อยากพลาดบทความใหม่ๆก็เข้าไปกดติดตามได้จากลิงค์นี้เบย Facebook Blog: Mr.Saladpuk กดไลค์ด้วยจะดีมากเลยขอรับ 😍