Χωρίς κοινή βάση δεδομένων, δεν μπορείτε να χρησιμοποιήσετε cross-service JOINs ή μεμονωμένες ACID συναλλαγές. Συνθέτετε δεδομένα και διατηρείτε τη συνέπεια χρησιμοποιώντας API composition, replication/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): μια υπηρεσία συνδρομητεύει σε events και κατασκευάζει ένα denormalized τοπικό αντίγραφο που μπορεί να ερωτήσει απευθείας.
Orders ─event→ ┐
Users ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
Χρησιμοποιήστε το Saga pattern — μια ακολουθία τοπικών συναλλαγών με compensating actions — αντί μιας κατανεμημένης συναλλαγής.
| Προσέγγιση | Pro | Con |
|---|---|---|
| API composition | Πάντα φρέσκα | Latency, fan-out, fragile |
| Replicated read model | Γρήγορες αναγνώσεις | Eventually consistent |
| Saga | Χωρίς 2PC | Complex, χρειάζεται compensation |
Μην "απλώς" κοινοποιήσετε έναν πίνακα για να κάνετε ένα join εύκολο — αυτό ξαναζευγώνει υπηρεσίες. Δεχτείτε eventual consistency όπου το business το επιτρέπει.
Η διαχείριση δεδομένων είναι ο τόπος όπου τα microservices γίνονται πραγματικά δύσκολα, γιατί τα εύκολα εργαλεία (joins, transactions) είναι κατά σχεδιασμό απόντα.
Η κατανόηση composition, read models, και sagas είναι αυτό που σας επιτρέπει να διατηρήσετε τις υπηρεσίες ανεξάρτητες χωρίς να χάσετε ορθότητα.