Bez wspólnej bazy danych nie możesz używać cross-service JOINów ani pojedynczych transakcji ACID. Składasz dane i zachowujesz spójność za pomocą API composition, replication/CQRS read models i events.
— koordynator wywołuje każdą usługę i łączy wynik:
// 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
Dla ciężkich zapytań utrzymuj read model (CQRS): usługa subskrybuje zdarzenia i buduje denormalizowaną lokalną kopię, którą może bezpośrednio pytać.
Orders ─event→ ┐
Users ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
Użyj wzorca Saga — sekwencji lokalnych transakcji z akcjami kompensacyjnymi — zamiast transakcji rozproszonej.
| Podejście | Zaleta | Wada |
|---|---|---|
| API composition | Zawsze świeże | Opóźnienie, fan-out, kruche |
| Replicated read model | Szybkie odczyty | Ostatecznie spójne |
| Saga | Nie trzeba 2PC | Złożone, wymaga kompensacji |
Nie dziel po prostu tabeli, aby ułatwić join — to ponownie łączy usługi. Zaakceptuj spójność ostateczną tam, gdzie biznes na to pozwala.
Zarządzanie danymi to miejsce, gdzie microservices naprawdę stają się trudne, ponieważ łatwe narzędzia (joins, transactions) zniknęły z projektu.
Zrozumienie composition, read models i sagas to to, co pozwala Ci utrzymywać usługi niezależne bez utraty poprawności.
Biblioteka pytań rekrutacyjnych IT ze szczegółowymi odpowiedziami — od Juniora do Seniora.
Wesprzyj