Microservices ตามแนวคิด Martin Fowler: เมื่อไรควรใช้ และแพตเทิร์นที่ต้องรู้

Microservices ไม่ใช่คำตอบของทุกระบบ Martin Fowler เตือนไว้ชัดเจนว่าอย่าเริ่มโปรเจกต์ใหม่ด้วย Microservices ทันที บทความนี้อธิบายว่าสถาปัตยกรรมนี้คืออะไร เหมาะกับใคร พร้อมแพตเทิร์นสำคัญอย่าง API Gateway, Database per Service และ Circuit Breaker

Microservices คืออะไรกันแน่

ตามนิยามในบทความคลาสสิกของ James Lewis และ Martin Fowler สถาปัตยกรรม Microservices คือการออกแบบระบบเป็นชุดของบริการขนาดเล็กหลายตัว แต่ละตัวรันเป็นโปรเซสของตัวเอง สื่อสารกันผ่านกลไกเบา ๆ เช่น HTTP API หรือ Message Queue และแต่ละบริการสามารถ Deploy แยกกันได้อย่างอิสระ

จุดแบ่งที่สำคัญคือบริการควรถูกจัดตามขอบเขตธุรกิจ (Business Capability) เช่น บริการสั่งซื้อ บริการชำระเงิน บริการจัดส่ง ไม่ใช่แบ่งตามชั้นเทคนิคอย่างทีม UI ทีม Backend ทีม Database ซึ่งสอดคล้องกับแนวคิด Domain-Driven Design ที่ใช้ Bounded Context เป็นเส้นแบ่งบริการ

คำเตือนสำคัญ: Monolith First

Fowler เขียนบทความ "Monolith First" เตือนว่าระบบที่ประสบความสำเร็จด้วย Microservices ส่วนใหญ่เริ่มจาก Monolith ที่โตจนถึงจุดที่ต้องแยก ขณะที่ระบบที่เริ่มต้นเป็น Microservices ตั้งแต่วันแรกมักเจอปัญหา เพราะตอนเริ่มโปรเจกต์เรายังไม่รู้ขอบเขตโดเมนดีพอ การตัดเส้นแบ่งบริการผิดตั้งแต่แรกมีต้นทุนแก้ไขสูงมาก

นอกจากนี้ Microservices มาพร้อมภาษีที่ต้องจ่ายเสมอ (Microservice Premium) ได้แก่ ความซับซ้อนของระบบกระจาย, Eventual Consistency, การดีบักข้ามบริการ และภาระ DevOps ที่เพิ่มขึ้น ทีมขนาด 5-10 คนที่ดูแลระบบเดียวมักได้ประโยชน์จาก Monolith ที่จัดโครงสร้างดี (Modular Monolith) มากกว่า

แพตเทิร์นการสื่อสาร: API Gateway และ Async Messaging

เมื่อมีหลายบริการ ไคลเอนต์ไม่ควรต้องรู้จักทุกบริการโดยตรง แพตเทิร์น API Gateway ให้มีประตูทางเข้าเดียวที่ทำหน้าที่ Routing, ยืนยันตัวตน, Rate Limiting และรวมข้อมูลจากหลายบริการให้ไคลเอนต์ในคำขอเดียว ช่วยลดความซับซ้อนฝั่งแอปมือถือและเว็บอย่างมาก

ส่วนการคุยระหว่างบริการ ควรลดการเรียกแบบ Synchronous ต่อกันเป็นลูกโซ่ เพราะบริการหนึ่งช้าจะฉุดทั้งสาย แพตเทิร์นที่ช่วยคือการสื่อสารแบบ Asynchronous ผ่าน Message Broker เช่น Kafka หรือ RabbitMQ โดยบริการประกาศ Event เช่น "OrderCreated" แล้วให้บริการอื่นสมัครรับไปทำงานของตัวเอง ทำให้ระบบหลวมตัวและทนความล้มเหลวได้ดีขึ้น

ข้อมูลใครข้อมูลมัน: Database per Service และ Saga

หลักการสำคัญคือแต่ละบริการเป็นเจ้าของข้อมูลตัวเอง (Decentralized Data Management) ห้ามบริการอื่นเข้าถึงฐานข้อมูลตรง ๆ ต้องผ่าน API เท่านั้น เพราะการแชร์ฐานข้อมูลจะผูกบริการเข้าด้วยกันจน Deploy แยกไม่ได้จริง ซึ่งทำลายประโยชน์หลักของสถาปัตยกรรมนี้

ผลที่ตามมาคือทำ Transaction ข้ามบริการแบบเดิมไม่ได้ จึงเกิดแพตเทิร์น Saga ที่แตกธุรกรรมใหญ่เป็นขั้นตอนย่อยในแต่ละบริการ พร้อมกำหนด Compensating Action สำหรับย้อนกลับเมื่อขั้นตอนใดล้มเหลว เช่น ถ้าตัดบัตรไม่ผ่าน ก็ส่ง Event ให้บริการคลังสินค้าคืนสต๊อกที่จองไว้

ออกแบบรับความล้มเหลว: Circuit Breaker และ Observability

ในระบบกระจาย ความล้มเหลวบางส่วนคือเรื่องปกติ Fowler ย้ำหลัก "Design for Failure" แพตเทิร์น Circuit Breaker จะตัดวงจรเมื่อบริการปลายทางล้มเหลวติดต่อกันเกินเกณฑ์ เช่น Error เกิน 50% ใน 10 วินาที แล้วตอบ Fallback ทันทีแทนการรอ Timeout ซ้ำ ๆ ซึ่งป้องกันความล้มเหลวลุกลามเป็นลูกโซ่ (Cascading Failure)

ควบคู่กันต้องมี Observability ครบสามขา คือ Log แบบรวมศูนย์, Metrics และ Distributed Tracing ที่แปะ Correlation ID ตามคำขอข้ามทุกบริการ เพื่อให้ตอบได้ว่าคำสั่งซื้อหนึ่งรายการวิ่งผ่านบริการไหนบ้างและช้าที่จุดใด เครื่องมือมาตรฐานเปิดอย่าง OpenTelemetry ช่วยให้เริ่มได้โดยไม่ผูกกับผู้ให้บริการรายใด

เงื่อนไขความพร้อมก่อนตัดสินใจใช้

Fowler ระบุ Prerequisites ที่ควรมีก่อนใช้ Microservices ได้แก่ ความสามารถ Provision เครื่องอัตโนมัติอย่างรวดเร็ว, ระบบ Monitoring ที่ตรวจจับปัญหาได้เร็ว, Deployment อัตโนมัติเต็มรูปแบบ และวัฒนธรรม DevOps ที่ทีมรับผิดชอบบริการของตัวเองแบบ You Build It, You Run It ถ้ายังไม่มีสิ่งเหล่านี้ ควรสร้างก่อน

แนวทางที่ปลอดภัยสำหรับองค์กรส่วนใหญ่คือเริ่มจาก Modular Monolith ที่แบ่งโมดูลตามโดเมนชัดเจน เมื่อโมดูลใดมีเหตุผลชัด เช่น ต้อง Scale ต่างจากส่วนอื่นมาก หรือทีมโตจนเหยียบกันเอง จึงค่อยแยกออกมาเป็นบริการด้วยแพตเทิร์น Strangler Fig ทีละส่วนอย่างมีการควบคุม