Microservices Architecture คืออะไร?

บริบท

คุณกำลังจะสร้างหรือกำลังดูแลแอปพลิเคชันฝั่ง server ที่ซับซ้อนพอสมควรอยู่แล้ว มีการเปิด API ให้ web และ mobile client เรียกใช้ รัน business logic และเก็บข้อมูลลง database พอผลิตภัณฑ์โตขึ้น นักพัฒนาเข้ามามากขึ้น feature ออกถี่ขึ้น codebase ก็พองตามไปด้วย แล้ววันหนึ่งจะมีคนพูดคำว่า microservices ขึ้นมาในที่ประชุมวางแผน คุณจึงต้องรู้ให้ชัดก่อนว่าคำนี้หมายถึงอะไรกันแน่ ก่อนจะตัดสินใจได้ว่าต้องการหรือไม่

งานแรกของคอร์สนี้จึงตรงไปตรงมา คือตกลงกันให้ได้ก่อนว่า microservices architecture คืออะไร แล้วค่อยเถียงกันว่าเมื่อไรถึงคุ้มที่จะลงทุน

ปัญหา

คำนี้ถูกใช้อย่างหลวมมาก บางคนใช้ในความหมายว่า “service ขนาดเล็ก” บางคนหมายถึง “service ที่คุยกันผ่าน HTTP” บางคนก็แค่หมายถึง “ระบบใหม่ที่เรากำลังสร้าง” ไม่มีนิยามไหนแม่นพอจะใช้ตัดสินใจได้เลย ถ้า microservice แปลว่า service เล็ก ๆ แล้วต้องเล็กแค่ไหน ถ้าแปลว่า service ที่คุยกันผ่าน HTTP แล้ว monolith ที่เรียก API ของ third party นับเป็น microservice ด้วยหรือเปล่า

สิ่งที่ต้องการคือนิยามที่ชี้คุณสมบัติที่สำคัญจริง ๆ คือคุณสมบัติที่เปลี่ยนวิธีจัดทีม วิธี deploy และวิธีเก็บข้อมูล ไม่ใช่นิยามที่วัดกันด้วยจำนวนบรรทัด code หรือ transport protocol

วิธีแก้

microservices architecture จัดโครงสร้างแอปพลิเคชันให้เป็นชุดของ service ที่:

จัดระเบียบรอบ business capability แต่ละ service เป็นเจ้าของส่วนหนึ่งของ domain — orders, payments, inventory — แทนที่จะเป็น layer เชิงเทคนิคอย่าง “ชั้นฐานข้อมูล” หรือ “ชั้น UI”
deploy ได้อย่างอิสระ แต่ละ service สามารถ build, test และ release ตามตารางของตัวเอง โดยไม่ต้องประสานงาน deploy ทั้งระบบพร้อมกันแบบ lock-step
coupling แบบหลวม (loosely coupled) service มีปฏิสัมพันธ์กันผ่าน API และ message ที่นิยามไว้ชัดเจนเท่านั้น ไม่เคยล้วงเข้าไปยังภายในของกันและกัน
เป็นเจ้าของข้อมูลของตัวเอง แต่ละ service เก็บข้อมูลของตัวเองไว้เป็นส่วนตัว แล้วเปิดออกผ่าน API หรือ event ที่ตัวเองเผยแพร่เท่านั้น ไม่มี database กลางที่ทุกคนเข้าไปอ่านเขียนร่วมกัน

โดยปกติ client ไม่ได้เรียก service โดยตรง จะมี gateway วางอยู่ด้านหน้า คอยส่งต่อแต่ละ request ไปยัง service ที่เป็นเจ้าของ capability นั้น ๆ เบื้องหลัง gateway แต่ละ service รันเป็น process ของตัวเองพร้อมกับ datastore ของตัวเอง และ service ทั้งหลายทำงานร่วมกันด้วยการเรียก API ของกันและกันหรือแลกเปลี่ยน event

flowchart TB
  Client[Web / Mobile Client] --> GW[API Gateway]
  GW --> OAPI
  GW --> PAPI
  GW --> IAPI
  subgraph Orders[Order Service]
    OAPI[API]
    ODB[(Orders DB)]
    OAPI --> ODB
  end
  subgraph Payments[Payment Service]
    PAPI[API]
    PDB[(Payments DB)]
    PAPI --> PDB
  end
  subgraph Inventory[Inventory Service]
    IAPI[API]
    IDB[(Inventory DB)]
    IAPI --> IDB
  end
  OAPI -. events .-> PAPI
  OAPI -. events .-> IAPI

service ไม่กี่ตัว แต่ละตัวมีฐานข้อมูลส่วนตัว อยู่หลัง API gateway เพียงตัวเดียว

สังเกตสิ่งที่ไดอะแกรม ไม่ได้ แสดง คือไม่มี database กลางที่ทั้งสาม service ใช้ร่วมกัน และไม่มี service ไหนล้วงเข้าไปในตารางของอีก service ลูกศรเส้นประคือ event แบบ asynchronous ไม่ใช่การเรียกตรงเข้าไปหาข้อมูลส่วนตัว การแยกออกจากกันนี่แหละคือหัวใจทั้งหมด เพราะเป็นสิ่งที่ทำให้แต่ละกล่อง deploy, scale และล้มเหลวได้แยกจากกัน

คอร์สนี้ครอบคลุมอะไรบ้าง

คอร์สนี้พาเดินผ่าน pattern language ของ microservices ในแปดโมดูล:

Intro and Principles — โมดูลที่คุณกำลังอ่านอยู่นี้: microservices คืออะไร เปรียบเทียบกับ monolith อย่างไร trade-off เป็นอย่างไร เมื่อไรควรใช้ และ pattern ต่าง ๆ ประกอบกันอย่างไร
Decomposition — วิธีหั่นระบบออกเป็น service รอบ business capability และ bounded context
Data Management — การรักษาความสอดคล้องของข้อมูลและความสามารถในการ query เมื่อแต่ละ service เป็นเจ้าของ store ของตัวเอง
Transactional Messaging — การเผยแพร่ event อย่างเชื่อถือได้ในฐานะส่วนหนึ่งของ local transaction
Communication — รูปแบบการสื่อสารทั้งแบบ synchronous และ asynchronous, API และ gateway
Reliability — การอยู่รอดจาก partial failure ที่ระบบแบบกระจาย (distributed) ทำให้เป็นเรื่องปกติ
Observability — การมองเห็นว่ากองทัพ service กำลังทำอะไรอยู่จริง ๆ
Deployment and Cross-cutting — การส่งมอบ รัน และรักษาความปลอดภัยของ service บน production

สรุปภาษาแห่ง pattern ในบรรทัดเดียว

ไม่มี pattern ใดที่ยืนอยู่ได้ลำพัง แต่ละ pattern แก้ปัญหาที่เกิดจากการเลือกในขั้นก่อนหน้า ดังนั้น pattern ทั้งหลายจึงก่อตัวเป็น ภาษา ที่เชื่อมโยงกัน มากกว่าจะเป็นเช็กลิสต์ เราจะ map ภาษานี้ออกมาให้ชัดเจนในบทเรียนสุดท้ายของโมดูลนี้

pattern ที่เกี่ยวข้อง

Monolith vs Microservices — สิ่งที่คุณกำลังจะก้าวออกมา และทำไมจึงไม่ใช่ศัตรู
The Pattern Language — ทุก pattern ในคอร์สนี้เชื่อมโยงกันอย่างไร
Data Management — โมดูลที่ “แต่ละ service เป็นเจ้าของข้อมูลของตัวเอง” กลายเป็นเรื่องยาก

🧩 เป็นคุณสมบัติ ไม่ใช่ขนาด

อย่าหลงนิยาม microservice ด้วยขนาดที่เล็ก คุณสมบัติที่สำคัญจริง ๆ คือความเป็นอิสระและความเป็นเจ้าของ นั่นคือ service ที่ deploy ได้ด้วยตัวเอง เป็นเจ้าของข้อมูลของตัวเอง และ map ตรงกับ business capability หนึ่งอย่าง service จะยาวไม่กี่ร้อยบรรทัดหรือหลายพันบรรทัดก็ได้ทั้งนั้น สิ่งที่ทำให้เป็น microservice คือเส้นแบ่งที่ล้อมรอบอยู่ ไม่ใช่จำนวนบรรทัดข้างใน