साझा डेटाबेस के बिना, आप क्रॉस-सेवा JOINs या एकल ACID लेनदेन का उपयोग नहीं कर सकते। आप API संरचना, प्रतिकृति/CQRS पढ़ने के मॉडल और इवेंट्स का उपयोग करके डेटा संरचना करते हैं और इसे सुसंगत रखते हैं।
API संरचना — एक समन्वयक प्रत्येक सेवा को कॉल करता है और परिणाम को सीवता है:
// 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
भारी प्रश्नों के लिए, एक पढ़ने का मॉडल (CQRS) बनाए रखें: एक सेवा इवेंट्स की सदस्यता लेती है और एक विकृत स्थानीय प्रति बनाती है जिसे वह सीधे क्वेरी कर सकती है।
Orders ─event→ ┐
Users ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
वितरित लेनदेन के बजाय Saga पैटर्न का उपयोग करें — प्रतिपूरक कार्यों के साथ स्थानीय लेनदेन का अनुक्रम।
| दृष्टिकोण | पेशेवर | विपक्ष |
|---|---|---|
| API संरचना | हमेशा ताजा | विलंबता, प्रशंसक, नाजुक |
| प्रतिकृत पढ़ने का मॉडल | तेज़ पढ़ना | अंततः सुसंगत |
| Saga | 2PC आवश्यक नहीं | जटिल, मुआवजे की आवश्यकता |
जोड़ को आसान बनाने के लिए एक तालिका "साझा" न करें — यह सेवाओं को फिर से जोड़ता है। जहां व्यवसाय की अनुमति हो, अंतिम स्थिरता को स्वीकार करें।
डेटा प्रबंधन वह जगह है जहां माइक्रोसर्विसेस वास्तव में कठिन हो जाती हैं, क्योंकि आसान उपकरण (जोड़, लेनदेन) डिज़ाइन द्वारा चले गए हैं।
संरचना, पढ़ने के मॉडल और sagas को समझना ही है जो आपको सेवाओं को स्वतंत्र रखने देता है बिना सही होने के।