Dengan tiada pangkalan data bersama, anda tidak boleh menggunakan JOIN merentas perkhidmatan atau transaksi ACID tunggal. Anda menyusun data dan mengekalkan konsistensi menggunakan komposisi API, model baca yang direplikasi/CQRS, dan peristiwa.
— koordinator memanggil setiap perkhidmatan dan menyambung hasilnya:
// 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
Untuk pertanyaan yang berat, mengekalkan model baca (CQRS): perkhidmatan melanggan peristiwa dan membina salinan tempatan yang tidak dinormalisasi yang boleh ditanya secara langsung.
Orders ─event→ ┐
Users ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
Gunakan pola Saga — urutan transaksi tempatan dengan tindakan pampasan — bukannya transaksi teragih.
| Pendekatan | Pro | Kontra |
|---|---|---|
| Komposisi API | Sentiasa segar | Latency, fan-out, rapuh |
| Model baca yang direplikasi | Pembacaan pantas | Akhirnya konsisten |
| Saga | Tidak perlu 2PC | Rumit, memerlukan pampasan |
Jangan "hanya" berkongsi jadual untuk membuat sambungan mudah — ini mengkupel semula perkhidmatan. Terima konsistensi akhirnya di mana perniagaan membenarkan.
Pengurusan data adalah tempat di mana perkhidmatan mikro benar-benar sukar, kerana alat mudah (JOIN, transaksi) dialih keluar oleh reka bentuk.
Memahami komposisi, model baca, dan saga adalah apa yang membenarkan anda mengekalkan perkhidmatan bebas tanpa kehilangan ketepatan.