Pa një bazë të dhënash të përbashkët, nuk mund të përdorësh JOINs ndërmjet shërbimeve ose transaksione të vetme ACID. Tu komponon të dhënat dhe i mbajnë ato të qëndrueshme duke përdorur API composition, replicated/CQRS read models, dhe events.
— një koordinator thërret secilin shërbim dhe qep rezultatin:
// 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
Për pyetje të rënda, mbraje një read model (CQRS): një shërbim subscribon në events dhe ndërton një kopje lokale të denormalizuar që mund të kërkosh direkt.
Orders ─event→ ┐
Users ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
Përdor modelin Saga — një sekuencë tranzaksionesh lokale me veprime kompenzuese — në vend të një transaksioni të shpërndarë.
| Qasja | Pro | Con |
|---|---|---|
| API composition | Përherë i freskët | Latency, fan-out, i brishtë |
| Replicated read model | Lexim i shpejtë | Eventuelisht konsistent |
| Saga | Asnjë 2PC i nevojshëm | Kompleks, nevojitet kompensim |
Mos "thjesht" share një tabelë për ta bërë një JOIN të lehtë — kjo ri-ndërthur shërbimeve. Pranoje konsistencën eventuale ku biznesi lejon.
Menaxhimi i të dhënave është vendi ku microservices bëhet vërtetë i vështirë, sepse mjetet e lehta (joins, transactions) janë të ndaluara me qëllim.
Kuptimi i composition, read models, dhe sagas është ajo që të lejon të mbash shërbimeve të pavarur pa humbur korreksionin.
Një bibliotekë pyetjesh intervistash IT me përgjigje të detajuara — nga Junior te Senior.
Dhuro