საერთო ბაზის გარეშე, თქვენ ვერ გამოიყენებთ სერვისებს შორის JOIN-ებს ან ერთ ACID ტრანზაქციას. თქვენ აკომპოზებთ მონაცემებს და ზღუპრობთ მათი თანმიმდევრობას API კომპოზიციის, რეპლიკაციის/CQRS წაკითხვის მოდელების და ღონისძიებების გამოყენებით.
— კოორდინატორი ითხოვს თითოეულ სერვისს და აკრიფავს შედეგს:
// 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
მძიმე მოთხოვნების შემთხვევაში, შენარჩუნება წაკითხვის მოდელი (CQRS): სერვისი გამოწერილია ღონისძიებებზე და აშენებს დე-ნორმალიზებული ლოკალური ასლი, რომელიც შეიძლება პირდაპირ იკითხება.
Orders ─event→ ┐
Users ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
იყენებთ Saga შაბლონი — ლოკალური ტრანზაქციების თანმიმდევრობა კომპენსაციის ქმედებებით — განაწილებული ტრანზაქციის ნაცვლად.
| მიდგომა | სარგებელი | ხარვეზი |
|---|---|---|
| API კომპოზიცია | ყოველთვის ახალი | შეფერხება, ფანი-აუტი, სუსტი |
| რეპლიკაციული წაკითხვის მოდელი | სწრაფი წაკითხვა | საბოლოო ჯამში თანმიმდევრული |
| Saga | 2PC არ არის საჭირო | რთული, საჭიროებს კომპენსაციას |
ნе "უბრალოდ" გააზიარეთ ცხრილი JOIN-ის მარტივად გასაკეთებლად — ეს სერვისებს ხელახლა აკავშირებს. მიიღეთ საბოლოო ჯამში თანმიმდევრობა, სადაც ბიზნესი ამის დაშვებას სთავაზობს.
მონაცემების მართვა არის ის, სადაც მიკროსერვისები ხდება ნამდვილი რთული, რადგან მარტივი ინსტრუმენტები (JOIN-ები, ტრანზაქციები) დიზაინით ამოღებულია.
კომპოზიციის, წაკითხვის მოდელებისა და saga-ს გაგება არის ის, რაც საშუალებას გაძლევთ შენარჩუნდეთ სერვისები დამოუკიდებელი სიზუსტის კარგვის გარეშე.