# Communication Patterns ในคอร์สนี้เราจะมาดูวิธีการแก้ปัญหาของ **Distributed System** กัน โดยจะเริ่มอธิบายตั้งแต่ **การออกแบบซอฟต์แวร์แบบเด็กอนุบาล ยัน Large Scale Enterprise** กัน ซึ่งในบทความนี้จะขอไล่ลำดับความวุ่นวายไปเรื่อยๆ และใช้ร้านอาหารที่ทุกคนเข้าใจได้ในชีวิตประจำวันเป็นตัวอธิบายนะขอรับ ## 🍚 ร้านอาหารตามสั่ง > เป็นร้านที่ลูกค้าเดินเข้าไปสั่งอาหารกับ "พ่อครัว" แล้วลูกค้าก็ยืนรอให้เขาทำอาหารจนเสร็จตามที่เราเห็นได้ทั่วไป ถ้าเปรียบกับโลกของซอฟต์แวร์แล้วก็คือ **แอพที่เด็กหัดเขียนโปรแกรมใหม่ๆชอบทำกัน** และทุกอย่างของระบบนี้ต้องพึ่ง `พ่อครัว` เท่านั้น เพราะตั้งแต่การจดเมนู เสริฟน้ำ เดินไปเข้าครัว ยกอาหารมาให้ คิดเงิน เก็บโต๊ะ บลาๆ และเนื่องจากมีพ่อครัวคนเดียว ดังนั้นทุกอย่างเลยเป็น **Synchronous ทั้งระบบเลย** ![เป็นทุกอย่างให้เธอแหล๊วว \~ 🎵](/files/-MEBlJWTQ5JXqJKX1OKw) {% hint style="info" %} **Synchronous**\ คือการไปทำอะไรซักอย่าง แล้วต้องรอจนกว่าจะทำสิ่งนั้นๆเสร็จ โดยที่ไปทำอย่างอื่นต่อไม่ได้ เช่น พ่อครัวไปทำข้าวในครัว ระหว่างที่ทำข้าวอยู่ เขาก็จะแยกร่างมาเดินเสริฟน้ำไม่ได้นั่นเอง {% endhint %} ### 🤕 จุดอ่อนของระบบ เนื่องจากทั้งระบบต้องพึ่ง **`พ่อครัว`** แต่พ่อครัวดันมีคนเดียว ดังนั้นทุกอย่างเลยต้องหยุดรอพ่อครัว เลยทำให้ **`คอขวด`** ที่ทำให้ระบบนี้พังก็คือพ่อครัวนั่นเอง > **ตัวอย่าง**\ > สมมุติว่าพ่อครัวทำอาหาร 1 จาน ต้องใช้เวลาทำราวๆ 10 นาที (รับออเดอร์, เตรียมกับข้าว, ทำกับข้าว, เช็คบิล, เก็บโต๊ะ บลาๆ) นั่นหมายความว่า **สุดๆแล้วร้านนี้จะรับทำอาหารได้สูงสุด 6 จาน ต่อ 1 ชั่วโมง** นั่นเอง ### 🩹 การรักษา จากปัญหาด้านบนงั้น **ก็เพิ่มพ่อครัวดิ!!** . . . เพื่อให้สามารถทำหลายๆอย่างพร้อมๆกันได้หรือที่เราพูดติดปากกันว่าแบบ **Parallel** นั่นเอง ซึ่งฟังแล้วก็ดูเหมือนจะง่ายนะ แต่การแก้ปัญหาจริงๆนั้น **ถ้าเพิ่มพ่อครัวเพียงอย่างเดียว มันจะนำปัญหาแบบอื่นตามมา** ซึ่งในโลกของซอฟต์แวร์ปัญพวกนี้คือสิ่งที่เราจะเจอในการทำ **Distributed System** นั่นเอง ดังนั้นเราลองดูวิวัฒนาการของร้านหารในรูปแบบถัดไปกันดีกั่ว ## **🍛 ร้านอาหารตามสั่ง V.2** > จากปัญหาด้านบนที่ว่ามาทำให้ร้านต้อง **เพิ่มกำลังคน** เพื่อให้สามารถทำของหลายๆอย่างพร้อมกันได้ แต่สิ่งแรกที่เราต้องทำคือ การแบ่งงานออกเป็นส่วนๆ เช่น ในครัวก็ต้องแบ่งเป็น โซนทอด โซนย่าง โซนต้ม โซนดูแลรับผิดชอบเรื่องเครื่องเคียง โซนรับผิดชอบเรื่องข้าว บลาๆ เพราะไม่อย่างนั้นเราก็จะมี คนเยอะๆแต่ทุกคนไปกระจุกทำของซ้ำๆกันไม่มีหน้าที่ที่ชัดเจน การเพิ่มกำลังในโลกของซอฟต์แวร์มีหลากหลายวิธี แต่ทุกวิธีนั้นมีหัวใจหลักเดียวกันคือ 💖 **การแบ่งง่านออกเป็นส่วนๆ** เช่นกัน เพราะจากเดิมที่ระบบทำงานเป็น Synchronous มันจะเริ่มกลายเป็น **ระบบ Asynchronous** แล้วนั่นเอง ตามรูปด้านล่าง ![](/files/-MEBwn3sqgUkiZcXn9Tf) {% hint style="info" %} **Asynchronous**\ คือการทำอะไรซักอย่าง แต่ไม่ต้องรอจนให้มันเสร็จ ก็สามารถไปทำอย่างอื่นต่อได้ เช่น คนรับออเดอร์เดินไปบอกพ่อครัวว่าลูกค้าสั่งอะไรเสร็จ ก็สามารถกลับมารับออเดอร์ต่อได้เลย โดยไม่ต้องรอให้พ่อครัวทำอาหารนั้นๆจนเสร็จนั่นเอง (จำง่ายๆคือมันตรงข้ามกับ synchronous งุยล่ะ) {% endhint %} ### 🤕 จุดอ่อนของระบบ ในโลกของซอฟต์แวร์ถ้าเราแบ่งงานออกเป็นส่วนๆได้ เราก็จะสามารถขยายความสามารถได้โดยการทำ Scaling แบบต่างๆ แต่ปัญหาที่แท้จริงของมันคือ **งานแต่ละส่วนจะคุยกันรู้เรื่องได้ยังไง?** เช่น ครัวต้มอาหารจะรู้ได้ยังไงว่าเมื่อทำเสร็จต้องส่งต่อไปให้ครัวทอดหรือครับปิ้ง? หรือไม่จำเป็นต้องส่ง? หรือเมื่อทำเครื่องดื่มเสร็จมันจะต้องเอาไปวางคู่กับอาหารจานไหน? เนื่องจากที่เราเปลี่ยนระบบกลายเป็น Asynchronous เลยทำให้งานแต่ละส่วนมันทำโดยไม่ต้องรอกันได้ ดังนั้นปัญหาที่ตามมาคือ **การคุยกันของแต่ละเซอร์วิสนั่นเอง (Service Communication Problems)** ซึ่งถ้าเราไม่จัดการกับเรื่องนี้ **เราจะรู้ได้ไงว่าออเดอร์นั้นๆเสร็จหรือยัง?** > **ตัวอย่าง**\ > สมมุติว่าลูกค้ากดปุ่มสั่งซื้อสินค้าและจ่ายเงินเสร็จ แต่ระบบเราเป็นแค่คนกลาง เลยต้องส่งบิล ส่งออเดอร์ไปยังร้านค้าต่างๆ แต่เราไม่สามารถตอบลูกค้าได้ว่าสถานะการสั่งซื้อเป็นยังไง แล้วลูกค้าจะ happy กับระบบเราหรือเปล่า? ### 🩹 การรักษา ปัญหาเกิดจากการแยกส่วนรับผิดชอบกัน ดังนั้นวิธีการแก้ปัญหาคือ **ควมคุมการสื่อสาร ระหว่างแต่ละ module** นั่นเอง ซึ่งในทางเทคนิคเราเรียกเรื่องพวกนี้ว่า การทำ **Messaging** หรือการทำ **Communication** นั่นเอง ## 🧭 เนื้อหาทั้งหมดของคอร์สนี้ จากที่เล่าไปทั้งหมดเราก็จะมาดูรูปแบบต่างๆในการควมคุมการสื่อสาร หรือที่เราเรียกกันว่า **Communication Patterns** กันดีกั่วขอรับ ตามหัวข้อด้านล่างเบย * สั่งอาหารคุยตัวต่อตัว * ใบสั่งอาหาร Request & Response * ตะโกนเอา Event base * หัวหน้าเชฟ Orchestration {% hint style="success" %} **ใจเย็นนะโยมนะ**\ คอร์สนี้กำลังค่อยๆเขียนอยู่ แมวน้ำมีเวลาว่างเมื่อไหร่ก็จะมาอัพเดทเรื่อยๆ แต่ถ้าไม่อยากพลาดบทความใหม่ๆก็เข้าไปกดติดตามได้จากลิงค์นี้เบย [**Facebook Blog: Mr.Saladpuk**](https://www.facebook.com/mr.saladpuk) กดไลค์ด้วยจะดีมากเลยขอรับ 😍 {% endhint %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://www.saladpuk.com/beginner-1/communication-patterns.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.