#แนวคิด Microservices

Microservices คือแนวทางการออกแบบสถาปัตยกรรมซอฟต์แวร์ที่แบ่งระบบขนาดใหญ่ออกเป็น บริการขนาดเล็กหลายบริการ (services) โดยแต่ละบริการรับผิดชอบงานหรือความสามารถทางธุรกิจที่ชัดเจน เช่น User Service, Product Service, Order Service และ Payment Service

แนวคิดสำคัญคือ แต่ละ Service สามารถ พัฒนา ทดสอบ Deploy และขยายระบบได้อย่างอิสระ โดยสื่อสารกันผ่าน API หรือ Message Broker

#1. Microservices คืออะไร

สมมติว่าเรามีระบบ E-Commerce ซึ่งประกอบด้วยความสามารถหลายด้าน เช่น

  • จัดการผู้ใช้งาน
  • จัดการสินค้า
  • จัดการคำสั่งซื้อ
  • ชำระเงิน
  • จัดส่งสินค้า
  • แจ้งเตือนผู้ใช้

หากสร้างทุกอย่างไว้ใน Application เดียว จะเรียกว่า Monolithic Architecture

แต่ถ้าแยกความสามารถเหล่านี้ออกเป็น Service เช่น

User Service
Product Service
Order Service
Payment Service
Shipping Service
Notification Service

แต่ละ Service จะสามารถทำงานแยกจากกัน และมี API สำหรับติดต่อกัน

นี่คือแนวคิดของ Microservices Architecture

#2. เปรียบเทียบ Monolith กับ Microservices

#Monolithic Architecture

ระบบทั้งหมดอยู่ใน Application เดียว

+----------------------------------+
|          Web Application         |
|                                  |
|  User                            |
|  Product                         |
|  Order                           |
|  Payment                         |
|  Shipping                        |
|                                  |
+----------------------------------+
                |
             Database

ข้อดี

  • เริ่มต้นง่าย
  • พัฒนาได้รวดเร็วในโครงการขนาดเล็ก
  • Debug และ Deploy ง่ายในช่วงแรก
  • Infrastructure ไม่ซับซ้อน

ข้อจำกัดเมื่อระบบโตขึ้น

  • Codebase ใหญ่
  • Deploy ต้อง Deploy ทั้งระบบ
  • Module หนึ่งมีปัญหาอาจกระทบทั้ง Application
  • Scale บางส่วนของระบบได้ยาก
  • หลายทีมทำงานพร้อมกันได้ยากขึ้น

#Microservices Architecture

ระบบถูกแบ่งออกเป็นหลาย Service

Client
   |
API Gateway
   |
   +----------------------+
   |          |           |
User      Product       Order
Service    Service      Service
   |          |           |
 User DB   Product DB   Order DB
                         |
                     Payment
                     Service
                         |
                     Payment DB

แต่ละ Service สามารถมี Database ของตัวเอง

#3. แนวคิดหลักของ Microservices

Microservices ไม่ใช่เพียงการแบ่ง API ออกเป็นหลายโปรเจกต์ แต่เป็นการออกแบบระบบโดยเน้น Service Autonomy

หลักสำคัญประกอบด้วย

  1. Single Business Capability
  2. Independent Deployment
  3. Database per Service
  4. Loose Coupling
  5. API Communication
  6. Automation
  7. Observability
  8. Fault Isolation

#4. Service ควรแบ่งอย่างไร

ควรแบ่ง Service ตาม Business Capability มากกว่าการแบ่งตาม Layer ของระบบ

ไม่ควรแบ่งแบบ

Controller Service
Repository Service
Database Service

แต่ควรแบ่งตาม Domain

User Service
Order Service
Payment Service
Inventory Service
Shipping Service

แนวคิดนี้สัมพันธ์กับ Domain-Driven Design (DDD) และ Bounded Context

ตัวอย่าง

E-Commerce
│
├── Customer Context
│   └── User Service
│
├── Catalog Context
│   └── Product Service
│
├── Order Context
│   └── Order Service
│
├── Payment Context
│   └── Payment Service
│
└── Delivery Context
    └── Shipping Service

#5. Service Autonomy

หัวใจของ Microservices คือแต่ละ Service ควรพึ่งพา Service อื่นให้น้อยที่สุด

ตัวอย่าง

Order Service

ควรสามารถ

  • Build ได้เอง
  • Test ได้เอง
  • Deploy ได้เอง
  • Scale ได้เอง
  • Rollback ได้เอง

โดยไม่จำเป็นต้อง Deploy Service อื่นไปพร้อมกันทุกครั้ง

#6. Database per Service

Microservices มักใช้หลัก

One Service, One Database

ตัวอย่าง

User Service
   |
User Database

Product Service
   |
Product Database

Order Service
   |
Order Database

ไม่ควรให้หลาย Service เข้าถึง Database เดียวกันโดยตรง

ตัวอย่างที่ควรหลีกเลี่ยง

User Service -----+
                  |
Order Service ----+---- Shared Database
                  |
Payment Service --+

เพราะทำให้เกิด Tight Coupling

แนวทางที่เหมาะสมคือ Service อื่นต้องเรียกผ่าน API หรือ Event

#7. การสื่อสารระหว่าง Service

Microservices มีรูปแบบการสื่อสารหลัก 2 แบบ

#7.1 Synchronous Communication

เช่น

  • REST API
  • gRPC

ตัวอย่าง

Order Service
     |
     | REST API
     v
Payment Service

ตัวอย่าง REST API

POST /payments
Content-Type: application/json

{
  "orderId": 1001,
  "amount": 2500
}

เหมาะกับงานที่ต้องการผลลัพธ์ทันที

#7.2 Asynchronous Communication

ใช้ Message Broker เช่น

  • Apache Kafka
  • RabbitMQ
  • Amazon SQS
  • NATS

ตัวอย่าง

Order Service
     |
     | OrderCreated Event
     v
Kafka
  |
  +----------+-----------+
  |          |           |
Payment   Shipping   Notification
Service   Service      Service

ข้อดี

  • ลด Coupling
  • รองรับโหลดสูง
  • Service ไม่จำเป็นต้องออนไลน์พร้อมกัน
  • เหมาะกับ Event-Driven Architecture

#8. API Gateway

หาก Client ต้องเรียก Service จำนวนมากโดยตรง ระบบจะซับซ้อน

เช่น

Frontend
 ├── User Service
 ├── Product Service
 ├── Order Service
 └── Payment Service

จึงนิยมใช้ API Gateway

Frontend
   |
API Gateway
   |
   +----------+----------+----------+
   |          |          |          |
 User      Product     Order      Payment
Service    Service    Service     Service

หน้าที่ของ API Gateway เช่น

  • Routing
  • Authentication
  • Rate Limiting
  • Request Logging
  • Load Balancing
  • API Aggregation

เครื่องมือที่นิยม เช่น

  • Kong
  • NGINX
  • Traefik
  • Spring Cloud Gateway
  • AWS API Gateway

#9. Service Discovery

ในระบบ Kubernetes หรือ Cloud Service อาจเปลี่ยน IP Address ได้ตลอดเวลา

ดังนั้นจึงต้องมี Service Discovery

ตัวอย่าง

Order Service
     |
     | lookup
     v
Service Registry
     |
     v
Payment Service

เครื่องมือที่เกี่ยวข้อง เช่น

  • Kubernetes Service
  • Consul
  • Eureka

ใน Kubernetes มี Service Discovery ผ่าน DNS อยู่แล้ว เช่น

payment-service.default.svc.cluster.local

#10. Container กับ Microservices

Microservices มักทำงานร่วมกับ Container เช่น Docker

ตัวอย่าง

User Service
   |
Docker Container

Order Service
   |
Docker Container

Payment Service
   |
Docker Container

ข้อดี

  • Environment เหมือนกัน
  • Deploy ง่าย
  • Scale ง่าย
  • รองรับ CI/CD

#11. Kubernetes กับ Microservices

เมื่อมี Microservices จำนวนมาก การจัดการ Container จะซับซ้อน

Kubernetes ช่วยจัดการ

  • Deployment
  • Scaling
  • Load Balancing
  • Service Discovery
  • Rolling Update
  • Self Healing

ตัวอย่าง

Kubernetes Cluster
│
├── user-service
│   ├── pod
│   └── pod
│
├── order-service
│   ├── pod
│   └── pod
│
└── payment-service
    ├── pod
    └── pod

#12. CI/CD สำหรับ Microservices

แต่ละ Service ควรมี Pipeline ของตัวเอง

ตัวอย่าง

Developer
   |
Git Push
   |
GitHub Actions
   |
Unit Test
   |
Build Docker Image
   |
Push Registry
   |
Deploy Kubernetes

ตัวอย่างโครงสร้าง Repository

services/
├── user-service/
│   ├── Dockerfile
│   └── .github/workflows/deploy.yml
│
├── order-service/
│   ├── Dockerfile
│   └── .github/workflows/deploy.yml
│
└── payment-service/
    ├── Dockerfile
    └── .github/workflows/deploy.yml

#13. Observability

ระบบ Microservices มี Service จำนวนมาก ดังนั้น Monitoring จึงสำคัญ

Observability มักประกอบด้วย 3 ส่วน

Metrics
Logs
Traces

เครื่องมือที่นิยม

#Metrics

Prometheus
Grafana

#Logging

ELK Stack
Loki

#Distributed Tracing

Jaeger
Zipkin
OpenTelemetry

#14. Distributed Tracing

ตัวอย่าง Request

Client
  |
API Gateway
  |
Order Service
  |
Payment Service
  |
Bank API

หากเกิด Error เราต้องทราบว่า Error เกิดที่ Service ใด

Distributed Tracing จะช่วยสร้าง Trace

Trace ID: abc123

API Gateway       20 ms
Order Service     50 ms
Payment Service   80 ms
Bank API         500 ms

ทำให้สามารถวิเคราะห์ Performance ได้ง่ายขึ้น

#15. Fault Tolerance

ระบบ Microservices ต้องออกแบบให้รองรับ Failure

ตัวอย่าง

Order Service
     |
Payment Service

หาก Payment Service ไม่ตอบสนอง

Order Service ไม่ควรค้างไปตลอด

จึงนิยมใช้ Pattern เช่น

  • Timeout
  • Retry
  • Circuit Breaker
  • Bulkhead
  • Fallback

#16. Circuit Breaker

Circuit Breaker ช่วยป้องกัน Service เรียก Service ที่กำลังมีปัญหาซ้ำ ๆ

ตัวอย่าง

Order Service
      |
Circuit Breaker
      |
Payment Service

สถานะทั่วไป

CLOSED
   |
Failure
   |
OPEN
   |
Timeout
   |
HALF-OPEN

Library ที่ใช้ได้ เช่น

Resilience4j
Polly

#17. Event-Driven Microservices

ระบบ Microservices มักใช้ Event

ตัวอย่าง

Customer Order
     |
Order Service
     |
OrderCreated
     |
Kafka
 ├── Payment Service
 ├── Inventory Service
 └── Notification Service

Event ตัวอย่าง

{
  "event": "OrderCreated",
  "orderId": 1001,
  "customerId": 45,
  "total": 2500
}

#18. Saga Pattern

Microservices ไม่สามารถใช้ Transaction แบบ Database เดียวได้ง่าย

เช่นกระบวนการสั่งซื้อ

Create Order
     |
Reserve Product
     |
Payment
     |
Shipping

หาก Payment ล้มเหลว ต้อง Rollback

จึงใช้ Saga Pattern

ตัวอย่าง

Order Created
     |
Inventory Reserved
     |
Payment Failed
     |
Cancel Inventory
     |
Cancel Order

#19. CQRS

CQRS ย่อมาจาก

Command Query Responsibility Segregation

แยกการทำงานออกเป็น

Command
Create / Update / Delete

และ

Query
Read

ตัวอย่าง

Command API
    |
Write Database

Query API
    |
Read Database

เหมาะกับระบบที่มี Read และ Write Pattern แตกต่างกันมาก

#20. Microservices Architecture ตัวอย่าง

ตัวอย่างระบบ E-Commerce

flowchart LR

Client --> Gateway[API Gateway]

Gateway --> User[User Service]
Gateway --> Product[Product Service]
Gateway --> Order[Order Service]

Order --> Payment[Payment Service]
Order --> Kafka[Kafka]

Kafka --> Shipping[Shipping Service]
Kafka --> Notify[Notification Service]

User --> UserDB[(User DB)]
Product --> ProductDB[(Product DB)]
Order --> OrderDB[(Order DB)]
Payment --> PaymentDB[(Payment DB)]

#21. Technology Stack ตัวอย่าง

Frontend

React
Next.js
Vue
Angular

Backend

Spring Boot
Node.js
Go
.NET
Laravel
FastAPI

API

REST
GraphQL
gRPC

Message Broker

Kafka
RabbitMQ
NATS

Database

PostgreSQL
MySQL
MongoDB
Redis

Container

Docker

Orchestration

Kubernetes

CI/CD

GitHub Actions
GitLab CI
Jenkins
Argo CD

Monitoring

Prometheus
Grafana
OpenTelemetry

#22. ข้อดีของ Microservices

#Independent Deployment

สามารถ Deploy Service แยกกันได้

Update Payment Service

ไม่จำเป็นต้อง Deploy

User Service
Product Service
Order Service

#Independent Scaling

สามารถ Scale เฉพาะ Service ที่โหลดสูง

Product Service

2 Pods
   ↓
20 Pods

โดย Service อื่นไม่ต้อง Scale ตาม

#Technology Flexibility

แต่ละ Service สามารถเลือก Technology ต่างกันได้

User Service
Spring Boot

Payment Service
Go

Recommendation Service
Python

Notification Service
Node.js

แต่ควรควบคุมไม่ให้เกิด Technology Sprawl มากเกินไป

#23. ข้อจำกัดของ Microservices

Microservices เพิ่มความซับซ้อนในหลายด้าน

เช่น

Network
Deployment
Monitoring
Security
Testing
Distributed Transaction
Service Discovery

ปัญหาที่พบบ่อย

  • Network Failure
  • Distributed Transaction
  • Debug ยาก
  • Infrastructure ซับซ้อน
  • Logging กระจายหลาย Service
  • DevOps มีภาระมากขึ้น

ดังนั้น Microservices ไม่ใช่คำตอบที่เหมาะกับทุกระบบ

#24. Modular Monolith ก่อน Microservices

สำหรับโครงการใหม่ หลายกรณีควรเริ่มจาก

Modular Monolith

ก่อน

Microservices

ตัวอย่าง

Application
│
├── User Module
├── Product Module
├── Order Module
└── Payment Module

เมื่อระบบเติบโตจึงค่อยแยก Module บางส่วนออกเป็น Service

ตัวอย่าง

Application
│
├── User Module
├── Product Module
└── Order Module

Payment Module
      ↓
Payment Microservice

แนวทางนี้ช่วยลดความซับซ้อนในช่วงเริ่มต้น

#25. Microservices Maturity

การพัฒนา Microservices มักเติบโตตามลำดับ

Monolith
   |
Modular Monolith
   |
Microservices
   |
Container
   |
Kubernetes
   |
CI/CD
   |
Observability
   |
Service Mesh

#26. Service Mesh

เมื่อ Microservices มีจำนวนมาก อาจใช้ Service Mesh

เช่น

Istio
Linkerd

ช่วยจัดการ

  • Service-to-Service Communication
  • mTLS
  • Traffic Management
  • Retry
  • Circuit Breaking
  • Observability

ตัวอย่าง

Service A
   |
Sidecar Proxy
   |
Service Mesh
   |
Sidecar Proxy
   |
Service B

#27. Microservices Best Practices

แนวทางที่ควรใช้

Design Around Business Domain

Database per Service

API First

Automated Testing

CI/CD

Observability

Containerization

Infrastructure as Code

Fault Tolerance

Zero Trust Security

#28. สถาปัตยกรรมที่พบในระบบ Cloud Native

ระบบสมัยใหม่มักมีโครงสร้าง

Users
  |
CDN
  |
Load Balancer
  |
API Gateway
  |
Microservices
  |
Kafka
  |
Databases
  |
Kubernetes
  |
Cloud Infrastructure

โดยมี

CI/CD
Monitoring
Logging
Tracing
Security

ทำงานร่วมกัน

#29. Roadmap การเรียน Microservices

ลำดับการเรียนที่แนะนำ

1. REST API
       ↓
2. Docker
       ↓
3. Microservices Design
       ↓
4. API Gateway
       ↓
5. Service Discovery
       ↓
6. Message Broker
       ↓
7. Kubernetes
       ↓
8. CI/CD
       ↓
9. Observability
       ↓
10. Event-Driven Architecture

#สรุป

Microservices คือแนวทางการออกแบบระบบโดยแยก Application ออกเป็น Service ขนาดเล็กหลาย Service แต่ละ Service รับผิดชอบ Business Capability ของตัวเอง

หัวใจสำคัญคือ

Independent Service
Independent Deployment
Independent Database
Loose Coupling
API Communication
Automation
Observability
Fault Tolerance

Microservices เหมาะกับระบบที่

  • มีขนาดใหญ่
  • มีหลายทีมพัฒนา
  • ต้อง Scale สูง
  • ต้อง Deploy บ่อย
  • ต้องการแยกความรับผิดชอบของแต่ละ Domain

แต่ Microservices มีต้นทุนด้าน Infrastructure และ Distributed System สูง

ดังนั้นสำหรับระบบขนาดเล็ก ควรพิจารณาเริ่มจาก

Modular Monolith

แล้วค่อยพัฒนาไปสู่

Microservices

เมื่อระบบและทีมมีความซับซ้อนมากขึ้น

#Architecture Journey

Monolith
   ↓
Modular Monolith
   ↓
Microservices
   ↓
Docker
   ↓
Kubernetes
   ↓
CI/CD
   ↓
Observability
   ↓
Cloud Native

แนวคิดสำคัญที่สุดของ Microservices ไม่ใช่การทำให้ระบบมี Service จำนวนมาก แต่คือ

การออกแบบแต่ละ Service ให้มีขอบเขตชัดเจน พึ่งพากันให้น้อย และสามารถเปลี่ยนแปลงหรือ Deploy ได้อย่างอิสระ