Jei nėra bendros duomenų bazės, negalite naudoti skirtingų paslaugų JOIN ar vienos ACID operacijos. Jūs sudarote duomenis ir išlaikote jų nuoseklumą naudodami API sudėtį, replikuotus/CQRS skaitymo modelius ir įvykius.
— koordinatorius iškviečia kiekvieną paslaugą ir surenka rezultatą:
// 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
Sunkiems užklausoms palaikykite skaitymo modelį (CQRS): paslauga prenumeruoja įvykius ir sudaro denormalizuotą lokalią kopiją, kurią galima tiesiogiai užklausti.
Orders ─event→ ┐
Users ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
Naudokite Saga šabloną — vietos operacijų seką su kompensuojančiais veiksmais — vietoj paskirstytosios operacijos.
| Metodas | Privalumas | Trūkumas |
|---|---|---|
| API sudėtis | Visada šviežias | Latencija, "fan-out", trapus |
| Replikuotas skaitymo modelis | Greitas skaitymas | Galiausiai nuoseklus |
| Saga | 2PC nereikalingas | Sudėtinga, reikalingas kompensavimas |
Nekopijuokite lentelės, kad JOIN būtų lengvas — tai iš naujo sujungti paslaugas. Priimkite galiausią nuoseklumą, kur verslas leidžia.
Duomenų valdymas yra vieta, kur mikropaslaugos tampa iš tikrųjų sunkios, nes paprasti įrankiai (JOIN, operacijos) pašalinti pagal dizainą.
Supratimas apie sudėtį, skaitymo modelius ir saga yra tai, kas leidžia paslaugoms išlikti nepriklausomoms, neprarandant teisumo.