# Communication Patterns

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

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

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

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

![เป็นทุกอย่างให้เธอแหล๊วว \~ 🎵](https://479516123-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lm0_idNbY6k1lwp6hm4%2F-MEBi13eq1yMmftpjRl6%2F-MEBlJWTQ5JXqJKX1OKw%2Fimage.png?alt=media\&token=7b67098b-3ead-4d0d-b345-c8196c66a10a)

{% hint style="info" %}
**Synchronous**\
คือการไปทำอะไรซักอย่าง แล้วต้องรอจนกว่าจะทำสิ่งนั้นๆเสร็จ โดยที่ไปทำอย่างอื่นต่อไม่ได้ เช่น พ่อครัวไปทำข้าวในครัว ระหว่างที่ทำข้าวอยู่ เขาก็จะแยกร่างมาเดินเสริฟน้ำไม่ได้นั่นเอง
{% endhint %}

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

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

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

### 🩹 การรักษา

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

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

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

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

![](https://479516123-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lm0_idNbY6k1lwp6hm4%2F-MEBtqIQwds7hcL39ggo%2F-MEBwn3sqgUkiZcXn9Tf%2Fimage.png?alt=media\&token=447ace71-db28-44db-9700-e37448d259df)

{% 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 %}