โหมดมืด
บทที่ 00 — Quickstart (เริ่มไว — 30 นาทีเห็นภาพรวม) — Microservices ใน 15 นาที (ก่อนเข้าเล่มจริง)
บทนี้ทำเพื่อใคร: คุณกำลังจะเปิดอ่านเล่ม microservices แล้ว สารบัญ (README.md) ทำให้ตกใจ — เห็นคำย่อแปลก ๆ เช่น DDD, Kafka, Saga และตัวอักษรอังกฤษเรียงกันแบบ KRaft / mTLS / ISR / CQRS (ไม่ต้องรู้จักตอนนี้ — เดี๋ยวข้อ 3 แปลคำหลัก ๆ ให้หมด) แล้วไม่รู้จะเริ่มยังไง
💡 ไม่ต้องรีบจำ — ตารางใน ข้อ 3 ของบทนี้จะแปลคำหลัก ๆ ที่คุณจะเจอเป็นภาษามนุษย์ก่อน (คำเฉพาะทางลึก ๆ อย่าง KRaft/ISR จะมีคำอธิบายอีกทีในบทที่เกี่ยวข้อง) แล้วแต่ละบทจะเจาะลึกของตัวเองอีกที
เป้าหมาย: ภายใน 15 นาที คุณจะ
- รู้ว่า microservices "คืออะไรในภาษามนุษย์" (ไม่ใช่คำนิยามทางการ)
- เห็นภาพ 1 request วิ่งผ่านอะไรบ้างใน microservices
- รู้ว่าศัพท์ใน TOC ส่วนใหญ่ "หมายถึงอะไรคร่าว ๆ"
- รู้ว่าควรอ่านบทไหนตามตัวเอง
⚠️ บทนี้ "ผิวเผินตั้งใจ" — ทุกคำที่เห็นจะมีบทเจาะลึกของตัวเอง. ตอนนี้แค่ให้ "เห็นทั้งภาพ" ก่อน ไม่ต้องเข้าใจหมด
1. เปรียบเทียบ: ร้านอาหาร vs ฟู้ดคอร์ท
ลืม code ก่อน คิดเป็นร้านอาหาร:
Monolith = ร้านอาหารตามสั่ง 1 ร้าน
- ทุกคนทำงานในร้านเดียว
- ครัวเดียว ตู้เย็นเดียว
- ถ้าครัวพัง → ทั้งร้านปิด
- เปลี่ยนเมนู = ปิดร้านปรับใหม่
- เจ้าของคนเดียวสั่งทุกอย่างได้
- → ง่าย เร็ว เหมาะร้านเล็ก
Microservices = ฟู้ดคอร์ทใหญ่
(ลูกค้า → Gateway → Services — Gateway รับออเดอร์แล้วส่งต่อไปร้านที่ถูกต้อง)
- แต่ละร้านเป็นเจ้าของของตัวเอง
- ตู้เย็น (database) ของใครของมัน
- ร้านสเต๊กปิด → ร้านก๋วยเตี๋ยวยังเปิดได้
- เปลี่ยนเมนูร้านเดียว = อีกร้านไม่กระทบ
- ต้องมี "เคาน์เตอร์รวม" รับออเดอร์ (API Gateway)
- → ซับซ้อนกว่า แต่ขยายได้, แยกทีมได้
ความ "ซับซ้อน" ของฟู้ดคอร์ทที่ไม่มีในร้านเดียว:
- ถ้าลูกค้าอยากสั่งทั้งก๋วยเตี๋ยว + ส้มตำ + ของหวาน — ใครเป็นคนเดินไปสั่ง? (→ API Gateway / Saga)
- ทุกร้านต้องใช้เครื่องคิดเงินมาตรฐานเดียว (→ contract / API versioning)
- ถ้าไฟดับชั้น 6 ทั้งหมด — ทุกร้านล่ม (→ infrastructure resilience)
- รปภ. ต้องดูทุกร้าน (→ centralized monitoring / security)
นี่คือเหตุผลที่หนังสือเล่มนี้ยาว — ความซับซ้อนที่ไม่ใช่เรื่องของธุรกิจ แต่มาจากการที่ระบบกระจายตัว
2. ภาพ "1 request วิ่งผ่านอะไร" (ที่มือใหม่ต้องเห็น)
ลองดูตัวอย่าง: ผู้ใช้กดปุ่ม "สั่งซื้อ" บน e-commerce app
ใน Monolith
1 stack trace อธิบายทุกอย่างได้
ใน Microservices
ที่เพิ่มมาจาก monolith:
- Network ทุกที่ — ทุกลูกศรอาจ timeout/พัง (→ บท 13 Resilience)
- ไม่มี stack trace เดียว — ต้อง trace request ข้าม service (→ บท 15 Tracing)
- Inventory ลด stock ไม่สำเร็จจะทำยังไง? — ต้อง compensate (→ บท 12 Saga)
- Order Service ต้องรู้ที่อยู่ของ Payment Service (→ บท 05 Service Discovery)
- Email Service อาจล่ม — message หายไหม? (→ บท 06 Broker fundamentals)
💡 ทุกบทในเล่มนี้คือ "วิธีแก้ปัญหาที่ลูกศรเส้นใดเส้นหนึ่งสร้างขึ้น"
3. ศัพท์ใน TOC แปลเป็นภาษามนุษย์
ตารางนี้ให้คุณ "พอจะเดาได้" ว่าแต่ละบทพูดถึงอะไร ก่อนเปิดอ่าน:
| ศัพท์ที่เจอ | ภาษามนุษย์ | เจอในบท |
|---|---|---|
| Service | App ตัวเล็ก ๆ ที่มี API + DB ของตัวเอง — deploy ได้แยก | ทุกบท |
| Monolith | App ก้อนเดียว — ทุก feature อยู่ใน process เดียวกัน | 00 |
| Modular Monolith | Monolith ที่ภายในแบ่งโมดูลชัดเจน — "default ที่ดีกว่า" สำหรับทีมเล็ก | 00 |
| Domain / Bounded Context | "หน่วยธุรกิจ" ที่มีคำศัพท์ของตัวเอง — เป็นเครื่องมือหาว่าควรตัด service ตรงไหน | 01 (Decomposition) |
| DDD (Domain-Driven Design) | วิธีคิดในการออกแบบ system ให้สะท้อนภาษาของ business | 01 (Decomposition) |
| Sync / Async | คุยแล้วรอตอบ (sync) vs ส่งแล้วไม่รอ (async) | 02 (Communication Overview) |
| REST / gRPC | 2 วิธียอดนิยมที่ service A "โทรหา" service B แบบ sync | 02 (Communication), 03 (REST + gRPC) |
| API Gateway | "เคาน์เตอร์รวม" หน้าระบบ — รับ request จาก client แล้วส่งต่อ | 04 (API Gateway + BFF) |
| BFF (Backend For Frontend) | API Gateway เฉพาะของ client แต่ละชนิด (mobile, web) | 04 (API Gateway + BFF) |
| Service Discovery | กลไก "หาเบอร์โทร" ของ service อื่น เพราะ IP เปลี่ยนตลอด | 05 (Discovery + Config) |
| Message Broker | "ที่ทำการไปรษณีย์" — service ส่ง message ทิ้งไว้ ให้คนอื่นมารับเอง | 06 (Broker Fundamentals) |
| Queue | คิวที่ message ถูกอ่านโดยคนเดียวแล้วหายไป | 06 (Broker Fundamentals) |
| Topic / Pub-Sub | กระดานข่าว — หลายคน subscribe อ่านได้พร้อมกัน | 06 (Broker Fundamentals) |
| Stream / Log | สมุดบันทึกแบบ append-only (เขียนต่อท้ายอย่างเดียว ลบ/แก้ไม่ได้) — ย้อนกลับไปอ่านได้ (Kafka) | 06 (Broker Fundamentals), 08 (Kafka Deep) |
| RabbitMQ | Message broker แบบ queue + routing ที่ยืดหยุ่น | 07 (RabbitMQ Deep) |
| Kafka | Message broker แบบ log ที่เก่ง throughput สูง + replay | 08 (Kafka Deep) |
| Partition (Kafka) | "ช่อง" ใน topic ที่ใช้ทำงานคู่ขนาน | 08 (Kafka Deep) |
| Consumer Group | กลุ่ม consumer ที่หาร message กันทำ | 06 (Broker Fundamentals), 08 (Kafka Deep) |
| At-least-once / At-most-once / Exactly-once | ระดับการรับประกันว่า message จะถึงกี่ครั้ง | 06 (Broker Fundamentals) |
| Idempotent | ทำซ้ำได้โดยผลไม่เปลี่ยน — "กดปุ่มหลายครั้งก็ได้ผลเดียว" | 06 (Broker Fundamentals) |
| DLQ (Dead Letter Queue) | "ตะกร้าทิ้ง" สำหรับ message ที่ประมวลไม่สำเร็จ | 06 (Broker Fundamentals) |
| Outbox Pattern | trick ในการส่ง event ให้ตรงกับการ save DB | 06 (Broker Fundamentals), 12 (Event-Driven Patterns) |
| Saga | วิธีทำ transaction ข้าม service — แทน DB transaction ที่ใช้ไม่ได้แล้ว | 12 (Event-Driven Patterns) |
| CDC (Change Data Capture) | อ่านการเปลี่ยนแปลงของ DB แล้วเปลี่ยนเป็น event | 12 (Event-Driven Patterns) |
| CQRS | แยก "อ่าน" กับ "เขียน" เป็นคนละ model | 14 (Data Management) |
| Event Sourcing | แทนที่จะเก็บ "state ปัจจุบัน" — เก็บ "เหตุการณ์ที่เกิด" ทั้งหมด | 14 (Data Management) |
| Circuit Breaker | ฟิวส์ตัดวงจร — เมื่อ downstream ล่ม หยุดเรียกชั่วคราว | 13 (Resilience) |
| Retry / Timeout / Bulkhead | เทคนิคทำให้ระบบไม่ล้มเป็นโดมิโน | 13 (Resilience) |
| Distributed Tracing | ตามรอย 1 request ที่ข้ามหลาย service | 15 (Tracing + Correlation) |
| Correlation ID | ID ที่ตามไปทุก service สำหรับเชื่อม log | 15 (Tracing + Correlation) |
| mTLS | การคุยกันระหว่าง service แบบเข้ารหัส + ทั้ง 2 ฝั่งตรวจตัวตนของกันและกัน (เหมือนทั้งคู่โชว์บัตรประชาชน) | 16 (Security) |
| Zero Trust | "อย่าเชื่อใครแม้แต่ใน network เดียวกัน" | 16 (Security) |
| Service Mesh | infra layer ที่จัดการ network ระหว่าง service ให้อัตโนมัติ (Istio, Linkerd) | 17 (Service Mesh) |
| Sidecar | container เล็ก ๆ ที่รันคู่กับ service หลัก — จัดการ network/security ให้ | 17 (Service Mesh) |
| Canary / Blue-Green | วิธี deploy ที่ปล่อย version ใหม่ทีละนิด | 18 (Deployment) |
| GitOps | "git repo คือ source of truth ของ production" | 18 (Deployment) |
| Polyglot | ใช้หลายภาษา/หลาย DB ในระบบเดียว | 19 (Polyglot Example) |
💡 ถ้าบทไหนคุณยังไม่เปิด แต่อยากรู้ว่าพูดเรื่องอะไร — กลับมาดูตารางนี้
4. หนังสือเล่มนี้แก้ปัญหาอะไรบ้าง (mapping ปัญหา → บท)
ตารางนี้ช่วยให้คุณ "skip ตามปัญหา" ได้:
| ถ้าคุณมีปัญหา / คำถาม | ไปอ่านบท |
|---|---|
| ไม่แน่ใจว่าควรใช้ microservices ไหม | 00 Mindset |
| มี monolith อยู่ — จะตัด service ตรงไหน | 01 Service Decomposition |
| ควรใช้ REST หรือ gRPC ดี | 02, 03 |
| client หลายชนิด (mobile/web) ต้องคุย backend ยังไง | 04 API Gateway + BFF |
| service หา service อื่นเจอยังไง | 05 Discovery + Config |
| ใช้ Kafka หรือ RabbitMQ ดี | 10 Broker Comparison — แต่ต้องอ่าน 06 ก่อน |
| message หาย, ซ้ำ, ลำดับผิด | 06 Broker Fundamentals |
| Kafka offset / partition / consumer group งง | 08 Kafka Deep |
| ทำ transaction ข้าม service ยังไง | 12 Event-Driven Patterns (Saga) |
| service downstream ล่ม — กันยังไงไม่ให้ระบบล้มหมด | 13 Resilience |
| trace 1 request ข้าม 5 service | 15 Tracing + Correlation |
| security ระหว่าง service | 16 Security |
| deploy โดยไม่ทำ user เห็น downtime | 18 Deployment |
| อยากเห็นตัวอย่างจริง | 19 Polyglot Example |
5. คุณควรเริ่มที่ไหน
ถ้าคุณยังไม่เคยทำ backend
หยุดที่นี่. ไปอ่าน java/ หรือ go/ + spring-boot/ ก่อน อย่างน้อย:
- สร้าง REST API ได้ (REST API = ช่องทางให้โปรแกรมคุยกันผ่าน HTTP)
- ต่อ database ทำ CRUD ได้ (CRUD = สร้าง/อ่าน/แก้/ลบข้อมูล — Create/Read/Update/Delete)
- รู้จัก Docker (ซอฟต์แวร์รัน container — แต่ละ service ใน microservices จะรันใน Docker container ของตัวเอง ติดตั้งได้ที่ docker.com/get-started)
แล้วค่อยกลับมา — จะเข้าใจมากกว่าฝืนอ่าน
ถ้าคุณเคยทำ monolith (Spring Boot / Express / Django) แต่ยังไม่เคยทำ microservices
อ่านเรียง: บทนี้ → 00 Mindset → 01 Decomposition → 02 Communication → 06 Broker Fundamentals → 19 Polyglot Example (ดูตัวอย่างก่อน) แล้วค่อยอ่านที่เหลือตามลำดับ
ใช้เวลาประมาณ 8-12 สัปดาห์
🟠 ถ้าทำ microservices อยู่แต่ยังงงบางส่วน
ใช้ตารางในข้อ 4 — skip ไปบทที่ตรงกับปัญหา
ถ้าเตรียมสัมภาษณ์ senior backend / SRE
อ่าน: 00, 01, 02, 06, 08 (Kafka), 12 (Saga), 13 (Resilience), 14 (CQRS/ES), 15 (Tracing) + ฝึก draw diagram
6. กฎ "อย่าหลงกับดัก" ก่อนเริ่ม
3 ข้อที่ผมอยากให้จำก่อนเข้าเล่ม:
⚠️ กฎ 1: Microservices ไม่ใช่เป้าหมาย เป็น "ผลของปัญหา"
"Microservices is not a goal. It's a consequence." — Sam Newman
ถ้า monolith ของคุณยังไม่มีปัญหาจริง — อย่าตัด. คนเก่ง ๆ ในวงการบอกตรงกัน: "เริ่ม monolith ก่อน แตกตามความจำเป็น"
⚠️ กฎ 2: คุณจะอ่านแล้วงง — มันปกติ
หนังสือเล่มนี้มี 20 บท + ศัพท์ใหม่หลายร้อยคำ. ไม่มีใครอ่านรอบเดียวเข้าใจหมด. กลับมาอ่านซ้ำ + ลงมือทำ checkpoint = วิธีเดียวที่จะซึม
⚠️ กฎ 3: ทุก concept "แก้ปัญหาที่ network สร้างขึ้น"
ถ้างงว่า "ทำไมต้องมี X" — ลองนึกว่า "ถ้า network ล่ม / ช้า / ส่งผิดลำดับ — X แก้อะไร?" จะเข้าใจง่ายขึ้นเสมอ
7. ก่อนไปบทต่อไป — checklist เร็ว ๆ
ลองตอบในใจ ไม่ต้องเขียน:
- [ ] อธิบายความต่าง monolith vs microservices ได้ในประโยคเดียว
- [ ] บอกชื่อ "ลูกศรที่เพิ่มขึ้น" ใน microservices มา 2 อย่าง (จากภาพข้อ 2)
- [ ] เดาได้ว่า "Saga" กับ "Circuit Breaker" แก้ปัญหาอะไร
- [ ] รู้ว่าตัวเองอยู่ track ไหน (เขียว/เหลือง/ส้ม/แดง ในข้อ 5)
ตอบไม่ได้ก็ไม่เป็นไร — เปิด 00 Mindset ต่อได้เลย
💡 เฉลย/แนวคำตอบ — กดดูถ้าอยากเช็ค
Monolith vs Microservices ในประโยคเดียว: "Monolith = ทุก feature อยู่ใน app เดียว deploy พร้อมกัน; microservices = แต่ละ feature เป็น service แยก deploy ได้อิสระ มี DB ของตัวเอง"
"ลูกศรที่เพิ่มขึ้น" ใน microservices (เทียบกับ monolith ในภาพข้อ 2):
- Network call ระหว่าง service ทุกตัว → อาจ timeout/พัง
- Message broker → event อาจหายหรือซ้ำ
- API Gateway ที่เป็นจุดเข้ารวม
- DB หลายตัว (ตัวละ service) → ไม่มี global transaction
- บอก 2 ใน 4 ก็ผ่าน
Saga vs Circuit Breaker แก้ปัญหาอะไร:
- Saga = ทำ transaction ข้าม service เมื่อ DB transaction เดียวใช้ไม่ได้ (compensation แทน rollback) — ดูบท 12
- Circuit Breaker = ฟิวส์ตัดวงจรเมื่อ downstream ล่ม กัน cascading failure — ดูบท 13
track ของตัวเอง (จากข้อ 5):
- 🟢 ยังไม่เคยทำ backend → ไป prerequisite (java/spring-boot) ก่อน
- 🟡 เคยทำ monolith แล้ว ยังไม่เคยทำ microservices → อ่านเรียง 00→19
- 🟠 ทำ microservices อยู่แต่ยังงงบางส่วน → skip ตามปัญหา (ตารางข้อ 4)
- 🔴 เตรียม interview senior → focus 00/01/02/06/08/12/13/14/15
ถ้าตอบไม่ตรงเฉลย — ไม่ต้องกังวล เป้าหมายของ checklist คือ "self-check ว่าจำได้ไหม" ไม่ใช่ test pass/fail
← สารบัญ | ➡️ บทที่ 00: Mindset (อ่านเข้มขึ้น)
🔤 Glossary · 📋 Style guide · 📅 last_verified: 2026-06-03