సంझా డేటాబేస్ లేకుండా, మీరు సేవల మధ్య 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 | ఎప్పుడూ తాజా | జాప, పాలిక, నిస్సారం |
| ప్రతిరూపాభిప్రాయ మోడల్ | వేగవంతమైన చదవడం | చివరకు సంగతమైన |
| Saga | 2PC అవసరం లేదు | సంక్లిష్టమైన, పరిహారం అవసరం |
JOINను సులభం చేయడానికి "కేవలం" ఒక టేబుల్ను షేర్ చేయవద్దు — ఇది సేవలను పునः కపలించుకుంటుంది. వ్యాపారం అనుమతించిన చోట ఆఖిర సంగతిని అంగీకరించండి.
డేటా నిర్వహణ అనేది microservices నిజంగా కఠినంగా ఉండే చోటు, ఎందుకంటే సులభ సాధనాలు (joins, transactions) డిజైన్ ద్వారా పోయిపోయాయి.
Composition, read models, మరియు sagas ను అర్థం చేసుకోవడం సేవలను స్వతంత్రమంగా ఉంచుకోవడానికి మరియు ఖచ్చితత్వం కోల్పోకుండా ఉంచుకోవడానికి మిమ్మల్ని అనుమతిస్తుంది.