ไมโครเซอร์วิสจะสื่อสารกันได้อย่างไร?

Question

Accepted Answer

บริการสื่อสารกันแบบ **synchronous** (คำขอ/การตอบกลับผ่าน REST หรือ gRPC) หรือแบบ **asynchronous** (ข้อความ/เหตุการณ์ผ่านบ่อเก็บข้อมูลเช่น Kafka หรือ RabbitMQ)

## Synchronous (คำขอ/การตอบกลับ)

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

```http
GET /orders/42 HTTP/1.1
Host: orders-service
Accept: application/json
```

## Asynchronous (ข้อความ/เหตุการณ์)

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

```text
Order Service ──publish "OrderPlaced"──▶ [ Broker ] ──▶ Email Service
                                              │
                                              └──▶ Inventory Service
```

## เมื่อใดที่จะใช้อะไร

| ความต้องการ | เลือก |
|---|---|
| คำตอบทันทีสำหรับผู้ใช้ | Synchronous |
| การถอดเชื่อมโยง บัฟเฟอร์ระบายออก | Asynchronous |
| การเชื่อมโยงเวลาที่แข็งแรงตกลง | Synchronous |
| ความยืดหยุ่นต่อการหยุดทำงานของเซิร์ฟเวอร์ | Asynchronous |

## หลุมพรางอันตราย

**Synchronous chains** ยาว (A → B → C → D) คูณเวลาเดินทางและความน่าจะเป็นของความล้มเหลว เลือก asynchronous หรือการรวมตัวเมื่อเป็นไปได้

## ทำไมถึงสำคัญ

รูปแบบการสื่อสารสร้างรูปลักษณ์ของความยืดหยุ่นของระบบ: การเรียก synchronous เป็นเรื่องง่ายที่จะคิด แต่สร้างการเชื่อมโยงที่แน่นขึ้นด้วยการรันไทม์ ส่วน asynchronous messaging ซื้อการถอดเชื่อมโยงด้วยค่าใช้จ่ายของความเป็นจริงในที่สุด

ระบบจริงส่วนใหญ่ผสมทั้งสองอย่าง — synchronous สำหรับการอ่านแบบเผชิญหน้าผู้ใช้ asynchronous สำหรับขั้นตอนการทำงานเบื้องหลัง

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