Ilman jaettua tietokantaa et voi käyttää palveluiden välisiä JOIN-kyselyitä tai yksittäisiä ACID-transaktioita. Kokoat tietoja ja pidät ne yhtenäisinä käyttämällä API-komposition, replikoinnin/CQRS-lukumalleja ja tapahtumia.
avulla koordinaattori kutsuu jokaista palvelua ja yhdistää tulokset:
// 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
Raskaille kyselyille ylläpidä lukumallia (CQRS): palvelu tilaa tapahtumia ja rakentaa denormalisoidun paikallisen kopion, jota voit kyselyt suoraan.
Orders ─event→ ┐
Users ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
Käytä Saga-mallia — paikallisten transaktioiden sarja kompensointitoimintojen kanssa — hajautetun transaktion sijaan.
| Lähestymistapa | Etu | Haitta |
|---|---|---|
| API-komposition | Aina tuore | Viive, fan-out, hauras |
| Replioitu lukumalli | Nopeat luvut | Lopulta yhdenmukainen |
| Saga | Ei 2PC:tä | Monimutkainen, vaatii kompensointia |
Älä "vain" jaa taulukkoa liitoksen tekemiseksi helpoksi — se kytkee palvelut uudelleen yhteen. Hyväksy lopulta johdonmukainen tila, kun liiketoiminta sen sallii.
Tietojen hallinta on se kohta, jossa mikropalvelut muuttuvat todella vaikeiksi, koska helpot työkalut (liitokset, transaktiot) ovat poistuneet suunnittelun mukaan.
Komposition, lukumallien ja sagajen ymmärtäminen on se, mikä mahdollistaa palveluiden riippumattomuuden pitämisen menettämättä oikeellisuutta.