# Azure Service Fabric

ในคอร์สนี้เราจะมาสอนการสร้าง **Microservices Architecture** ทั้งในเครื่องตัวเองและบนคลาว์กันดูบ้างว่ามันจะเป็นยังไง โดยในคอร์สนี้เราจะพามาเล่นคลาว์ของฝั่ง Microsoft ที่ชื่อว่า Azure และเราจะสร้างตัว microservices ไว้กับตัวที่มีชื่อว่า **Service Fabric** ที่ออกแบบมารองรับการทำงานของ architecture นี้โดยเฉพาะครับ

{% hint style="success" %}
**แนะนำให้อ่าน**\
ในบทความนี้เราจะพาเล่นคลาว์กัน แต่ถ้าเพื่อนๆยังไม่เคยลองเล่นคลาว์ของ Microsoft เลยก็สามารถเข้าไปลองเล่นได้ที่คอร์ส [👶 Microsoft Azure 101](https://saladpuk.gitbook.io/learn/cloud/azure101) หรือถ้ายังไม่รู้เลยว่าคลาว์คืออะไรก็สามารถเข้าไปศึกษาได้จากบทความนี้เลยครับ [👶 Cloud พื้นฐาน](https://saladpuk.gitbook.io/learn/basic/cloud101)
{% endhint %}

## 🤔 Service Fabric คือไร

เวลาที่เราจะสร้างแอพที่ **อึด ถึก ทน** โดยเฉพาะอย่าง Microservices Architecture แล้วละก็ มันจะมีหลายเรื่องเลยที่เราจะต้องไปลงมือจัดการด้วยตัวเอง แต่เดี๋ยวก่อนถ้าเราใช้ Service Fabric แล้วล่ะก็ ชีวิตของเราก็จะสบายขึ้น เพราะเจ้า Service Fabric มันจะรับผิดชอบดูแลให้เอง ดังนั้น Developer ก็มีหน้าที่แค่ลงมือเขียนแอพตามที่ตัวเองถนัด โดยไม่ต้องสนใจ Infrastructure ต่างๆเลย แถมของที่ได้ยังเป็นสิ่งที่เรียกว่า **Reliable Microservices & Containers** อีกด้วย

![](/files/-Lu0r80_h5YOPXui46sX)

## 🤔 ขอตัวอย่างแบบแจ่มๆหน่อย

เพื่อความรวดเร็วและเห็นภาพผมขอโชว์เป็น Video ด้านล่างนะ ซึ่งผมเขียนเป็นเกมปิงปอง โดยมีผู้เล่น 2 ฝั่ง และมีการคุยกันผ่าน Board game โดยทั้งหมดนี่ผมเขียนไว้ใน Service Fabric ซึ่งมันก็จะรับปิงปองไปเรื่อยๆ แล้วผมก็จะลองแกล้งทำให้เซิฟเวอร์ล่มดู แล้วมาดูกันว่ามันจะเกิดอะไรขึ้นกับแอพที่อยู่บน Service Fabric

{% embed url="<https://youtu.be/gQDOuVaLAhk>" %}

จากในตัวอย่างก็คือสิ่งที่เรียกว่า **Reliable Microservices** นั่นเอง ซึ่งปรกติถ้าเราอยากให้แอพของเราทำงานได้ต่อได้แม้ว่าเซิฟเวอร์จะล่มไปก็ตาม เราจะต้องมีการออกแบบทำ infrastructure อีกเยอะเลย ซึ่งโค้ดที่เราเขียนกันโดยปรกติมันจะทำแบบนี้ไม่ได้ แต่ข้อดีในการทำบน Service Fabric ก็คือ เราสามารถทำให้การเขียนโค้ดแบบเดิมๆของเรามีความสามารถในลักษณะนี้ได้นั่นเอง

## 🤔 ทำไมเซิฟล่มแล้วทำงานต่อได้ ?

### 😢 ปัญหา

ก่อนที่จะไปอธิบายว่ามันเกิดแบบนี้ได้ยังไง ผมขออธิบายก่อนว่าโดยปรกติถ้าเราเขียนโค้ดโดยไม่ได้ออกแบบเพื่อป้องกันเรื่องเซิฟเวอร์ล่ม มันจะเกิดสิ่งที่เรีกยว่า **Single point of failure** นั่นเอง เช่น เรามีแอพ 3 ตัวต่อไปที่ database ก้อนเดียวกันตามรูป

![](/files/-LpqjWHlo8xC0s3vAo6k)

เจ้าแอพทั้ง 3 ตัวนี้ก็ทำงานตามปรกติไม่มีปัญหาอะไร จนกระทั่งตัว Database ที่มันต่อไปเกิดล่มด้วยสาเหตุอะไรก็แล้วแต่ (รวมถึงการทำ maintenance ด้วยนะ) ซึ่งผลที่ตามมาคือเจ้าแอพทั้ง 3 ตัวมันก็จะทำงานต่อไม่ได้นั่นเอง แม้ว่าตัวมันเองจะไม่ได้ล่มก็ตาม (เพราะมันไปดำเนินการต่างๆกับ database ไม่ได้ไงล่ะ)

![](/files/-LrcVkU6xB04Xk2VvsMk)

จากที่ว่ามานี่แหละคือสิ่งที่เรียกว่า **Single point of failure**

{% hint style="success" %}
**Single point of failure**\
คืออาการของระบบที่ **เมื่อมีของบางอย่างพัง มันจะทำให้ระบบของเราใช้งานไม่ได้ทั้งหมดเลย** โดยไม่สนใจว่ามันจะเป็นเรื่องเล็กน้อยแค่ไหนก็ตาม เปรียบเทียบง่ายๆ ถ้าหัวใจคนเราหยุดเต้น แม้ว่าอวัยวะทุกอย่างเราจะทำงานได้เป็นปรกติ สุดท้ายก็ไม่รอดอยู่ดีนั่นเอง
{% endhint %}

### 😄 การแก้ปัญหา

ปรกติเราจะต้องจัดการเรื่องของ Infrastructure & Architecture เพื่อแก้ปัญหาเรื่องพวกนี้ เพื่อจะได้รับมือเมื่อมันล่ม เช่นการทำ Microservices เพราะแบบง่ายสุดมันก็จะตายแค่ service ของมันตัวเดียวเท่านั้น ส่วน service อื่นๆก็อาจจะใช้ **Default value strategy** ไปแก้ขัดระหว่างที่มันติดต่อหา service ที่ล่มไม่ได้นั่นเอง

![](/files/-LrKXRw5UBmk5vP78rrj)

แต่ทั้งหมดนี่เราไม่ต้องทำแบบนี้ก็ได้ เพราะเจ้า **Service Fabric** เขาจัดการเรื่องเหล่านี้ให้เราทั้งหมดแล้ว อีกทั้งเราไม่ต้องใช้ Database อีกต่อไปเลยก็ได้นะ โดยสิ่งที่ service fabric ทำให้เราคือเขามีการเก็บข้อมูลต่างๆลงสิ่งที่เรียกว่า **Reliable Collection** ซึ่งมันจะมีการทำ Caching ต่างๆ และเขามี SDK รองรับ เพื่อสุดท้ายก็จะเขียนลง Disk ต่อ ดังนั้นขอบอกเลยว่า มันเร็วกว่าการไปต่อ Database เสียอีก

![](/files/-Lpr2vAYa4qOhvYE1l-A)

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

![](/files/-LqRkoAzwm2DaQwXqZFG)

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

![](/files/-LshaYERTCcCsIHO-0yN)

## 💡 Monitoring

อีกหนึ่งในความยากเวลาที่เราทำงานกับ **Cluster** ก็คือการบริหารจัดการ service ต่างๆที่อยู่ข้างใน เช่นมันล่มหรือเปล่า จะอัพเกรด-ดาวเกรดเวอร์ชั่นดีไหม หรืออะไรก็ตามแต่ ใน Service Fabric เขาก็เตรียมของพวกนี้ให้เราใช้งานเรียบร้อยแล้วโดยที่เราไม่ต้องไปยุ่งอะไรมันเลย ด้วยสิ่งที่เรียกว่า **Service Fabric Explorer** นั่นเอง เช่นตัวเกมปิงปองในวีดีโอ มันก็จะมี service อยู่ข้างในทั้งหมด 4 ตัว และมีการคุยกันตามรูป

![](/files/-LnIM4VmHs7Pd-L3xzOf)

ซึ่งเจ้าตัว Service Fabric Explorer ก็จะทำหน้าที่คอยให้เราดูแลควบคุม services ต่างๆนั้นอีกทีตามที่ผมโชว์ในวีดีโอนั่นเอง

![](/files/-LrnSquhynMfDjFSC9rP)

## 💡 Any OS, Any Cloud

ทั้งหมดที่ว่ามาเราสามารถเล่น Service Fabric บนเครื่องตัวเอง หรือบนคลาว์เจ้าไหนก็ได้ แถมจะใช้ OS อะไรก็ได้ตามความต้องการเลย

![https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-overview](/files/-LnFRr4zDF_ljWWdjJzF)

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

{% hint style="info" %}
คอร์สนี้กำลังค่อยๆเขียนอยู่ ซึ่งจะค่อยๆทยอยอัพเดทลงตรงนี้เรื่อยๆ ส่วนใครที่ไม่อยากพลาดอัพเดทคอร์สนี้หรืออยากรับบทความใหม่ๆ สามารถเข้าไปกด Like เพื่อรับข่าวสารใหม่ๆจาก [**Facebook Blog: Mr.Saladpuk**](https://www.facebook.com/mr.saladpuk) ได้นะครับ 😍
{% endhint %}

{% content-ref url="/pages/-Lu0Fxj1Wef9s-LjIJbE" %}
[สร้าง Service Fabric กัน](/cloud/azure-service-fabric/create.md)
{% endcontent-ref %}

* ลองเขียนเว็บ Stateful ตัวแรกของเรากัน
* ลองสร้าง Reliable Microservices หน่อยซิ
* มารู้จักกับการใช้งาน State ของมันหน่อย
* มารู้จักกับ Actor กันดูบ้าง
* คิดไรออกเดี๋ยวเอามาใส่ในช่องนนี้ละกันนะ


---

# 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/cloud/azure-service-fabric.md?ask=<question>
```

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.