โดยไม่มี ฐานข้อมูลที่ใช้ร่วมกัน คุณไม่สามารถใช้ JOINข้ามบริการหรือธุรกรรม ACID ครั้งเดียว คุณจัดเรียงข้อมูลและรักษาความสอดคล้องโดยใช้ API composition, replicated/CQRS read models และ events
API composition — ตัวประสานงานเรียกแต่ละบริการและรวมผลลัพธ์:
// build an order view from three services
const order = await ordersApi.get(orderId);
const customer = await usersApi.get(order.customerId); // separate service
const shipment = await shippingApi.get(orderId);
return { ...order, customer, shipment }; // composed in memory
สำหรับการค้นหาที่หนัก ให้รักษา read model (CQRS): บริการสมัครสมาชิกอีเวนต์และสร้างสำเนาท้องถิ่นที่ไม่ปกติซึ่งคุณสามารถค้นหาได้โดยตรง
Orders ─event→ ┐
Users ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
ใช้รูปแบบ Saga — ลำดับของธุรกรรมท้องถิ่นพร้อมการดำเนินการชดเชย — แทนธุรกรรมแบบกระจาย
| วิธีการ | ข้อดี | ข้อเสีย |
|---|---|---|
| API composition | สดใหม่เสมอ | Latency, fan-out, เปราะบาง |
| Replicated read model | การอ่านที่รวดเร็ว | สุดท้ายมีความสม่ำเสมอ |
| Saga | ไม่ต้องใช้ 2PC | ซับซ้อน ต้องชดเชย |
อย่า "แค่" แชร์ตารางเพื่อให้ JOIN ง่าย — นั่นจะทำให้บริการเชื่อมต่ออีกครั้ง ยอมรับความสม่ำเสมอในที่สุดซึ่งธุรกิจอนุญาต
การจัดการข้อมูลคือสิ่งที่ทำให้ microservices กลายเป็นเรื่องยากจริง ๆ เพราะเครื่องมือที่ง่ายที่สุด (joins, transactions) หายไปตามการออกแบบ
การทำความเข้าใจ composition, read models และ sagas คือสิ่งที่ช่วยให้คุณเก็บบริการไว้อย่างอิสระโดยไม่สูญเสียความถูกต้อง