Paylaşılan veritabanı olmadan, hizmetler arasında JOINları veya tek ACID işlemlerini kullanamazsınız. API composition, replicated/CQRS read models ve events kullanarak verileri oluşturur ve tutarlılığını korursunuz.
— bir koordinatör her hizmeti çağırır ve sonuçları birleştirir:
// 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
Yoğun sorgular için read model (CQRS) işletmeye alın: bir hizmet olaylara abone olur ve doğrudan sorgulayabileceğiniz denormalize edilmiş yerel bir kopya oluşturur.
Orders ─event→ ┐
Users ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
Saga deseni kullanın — telafi edici eylemlerle yerel işlemlerin bir dizisi — dağıtılmış işlem yerine.
| Yaklaşım | Artı | Eksi |
|---|---|---|
| API composition | Daima taze | Latans, fan-out, kırılgan |
| Çoğaltılmış read model | Hızlı okumalar | Sonunda tutarlı |
| Saga | 2PC gerekli değil | Karmaşık, telafi gerekir |
JOINı kolay hale getirmek için "sadece" bir tabloyu paylaşmayın — bu hizmetleri yeniden bağlar. İşletmenin izin verdiği yerde nihai tutarlılığı kabul edin.
Veri yönetimi, microservices'in gerçekten zor hale geldiği yerdir, çünkü kolay araçlar (joins, transactions) tasarım gereği ortadan kalkmıştır.
Composition, read models ve sagas'ı anlamak, hizmetleri bağımsız tutmanızı sağlarken doğruluğu kaybetmemenizi sağlayan şeydir.