பகிரப்பட்ட தரவுத்தளம் இல்லாத போது, நீங்கள் சேவைகளுக்கு இடையிலான JOINகளையோ அல்லது ஒற்றை ACID பரிவர்த்தனைகளையோ பயன்படுத்த முடியாது. நீங்கள் API composition, replicated/CQRS read models, மற்றும் events ஆகியவற்றைப் பயன்படுத்தி தரவை இணைத்து சீராக வைத்திருக்கின்றீர்கள்.
— ஒரு ஒருங்கிணைப்பாளர் ஒவ்வொரு சேவையையும் அழைத்து முடிவை தைக்கிறது:
// 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 ஐ புரிந்துகொள்வது சேவைகளை சுயாதீனமாக வைத்திருப்பதற்கும் சரியான தன்மை இழக்காமலிருப்பதற்கும் உங்களை வழங்குகிறது.