Bu Saga yöntemin bir tane Orchestrator (Saga Manager) kullanılır. Açıklaması şöyle.
In this approach, there is a Saga orchestrator that manages all the transactions and directs the participant services to execute local transactions based on events. This orchestrator can also be thought of as a Saga Manager.
Saga Orchestrator veya Saga Manager haberleşme için Message Broker kullanabilir. Her şey REST olmak zorunda değil.
Örnek
Otel, taksi ve uçak rezervasyonu bir seferde yapan bir akış şöyle
1. Traveler sends a “Book Trip” request from the browser, which will hit the Trip microservice.2. The Trip microservice is responsible for starting Saga. It calls on what is called as a Saga coordinator endpoint, starting a Saga. The coordinator announces a Saga identifier in response. The Trip microservice enlists itself with the created Saga by calling the Saga coordinator providing the Saga identifier and handing over addresses of REST endpoints for compensation (optionally confirmation) callbacks. Those are endpoint the coordinator can call back in response to the outcome of the execute action on any participating microservices.3. The Trip microservice takes the Saga ID and adds it as an HTTP header to the REST call to the 3 other fulfilling microservices, Cab Microservice, Hotel Microservice and Flight Microservice.4. The called microservices distinguishes the Saga and they can enlist themselves (by announcing REST endpoints for compensation/confirmation callbacks) to Saga coordinator.5. The participant microservices, viz. Cab Microservice, Hotel Microservice and Flight Microservice executes the business process6. Any of the participant microservices could fail the Saga by calling “Execution Failure” on the Saga coordinator.7. Saga coordinator sends commands either to confirm or to compensate, to all participants8. On way back, the initiator microservice is responsible for finishing the Saga by calling complete (with a success or failure flag) on the Saga coordinator with the saga identifier.
Compensation Operations
Örnek
Elimizde şöyle bir saga olsun
Compensation Operation için şu şartlar gerekli
1. Event Log
Açıklaması şöyle. Orchestrator bir event log tutmalı
One way of handling this issue would be to keep a log of operations done by the admin service. This could be similar to the following:TX1: CHECK INVENTORYTX1: CREATE ORDERTX1: UPDATE INVENTORYTX1: PROCESS PAYMENT - FAILEDTX1: MARK ORDER AS CANCELLEDTX1: UPDATE INVENTORY - INCREMENT STOCK COUNTS
2. Servisler Idempotent Olmalı
Açıklaması şöyle. Idempotency Nedir yazısına bakabilirsiniz.
So the admin service can track the operations that have already been executed, and what hasn’t. But again, we have to be thoughtful of possible edge cases that can happen even when processing an event log like this. The admin service and its log is separate from the other remote service operations, thus those interactions themselves do not work transactionally. There are changes like the following:- Admin service executes inventory service to revert inventory counts (by incrementing)- Admin service updates its log with “TX1: UPDATE INVENTORY - INCREMENT STOCK COUNTS”What if the first operation above executes, then the service crashes before the second operation? When the admin service continues its operations again, it will think that it didn’t do the inventory revert operation and will execute the first operation again. This will leave the inventory data with invalid values because it has done stock number increments twice, which isn’t good! This is a situation of having at-least-once delivery as we would often see in a distributed system. A common approach to handle this would be to model our operations to be idempotent. That is, even if the same operation is done multiple times, it will not cause any harm, and the target system’s state would be the same.
Orchestrator Compensation İşlemi Esnasında Çökerse
Bu yöntemin zayıflığının açıklaması şöyle. Eğer bir transaction ortasında Orchestrator çökerse, diğer katılımcılar tutarsız (inconsistent) bir durumda kalabilirler
An Orchestration based Saga is based on a central coordinator who is responsible for instructing individual services to continue or rollback. ... this central coordinator service is responsible for centralising the Saga’s decision making and sequencing the constituent transactions. ...The inherent weakness of an Orchestration based Saga is its central coordinator, which is it’s single point of failure. The Saga manager can be a separate service or a part of one of the coordinating microservices. If the Saga Manager goes down in the middle of a Saga, the entire participating microservices might remain inconsistent till the Saga Manager comes back to operational state.
EDA sadece Orchestration-Based Saga Örüntüsü için kullanılmaz. Genel bir kavramdır ancak bu bağlama çok iyi uyuyor. EDA için açıklama şöyle
Using this pattern, we can make sure if we emit a message successfully to a message broker that is meant to target some service, it will at some point be successfully sent to the intended recipient. This guarantee makes our other processes much easier to model. Also, the message broker’s asynchronous communication model, where it allows simultaneous reading and writing, provides much better performance due to lower overheads and wait times for roundtrip calls. Error handling is also simpler because even if the target service is down, the message broker will hold the messages and deliver them when the target endpoint is available. Additionally, it can do other operations such as failure retries and load balancing requests with multiple service instances. This pattern also encourages loose coupling between services. The communication happens via queue/topics, and producers and consumers do not need to know about each other explicitly.
Açıklaması şöyle
The communication between the coordinator services and other services will be done via request and response queues.
Şeklen şöyle
The asynchronous communication between the coordinator service and the other services allows it to model the transactional process as a state machine, wherein each of the steps completed with the services can update the state machine. The state machine should be persisted in a database to recover from any failures of the coordination service.
Örnek - State Machine Kullanan Orchestration-Based Saga
Açıklaması şöyle
Modeling a saga orchestrator as a state machine is an effective way to not only manage distributed transactions but also support long-running business transactions. A state machine consists of a set of states and a set of transitions between states that are triggered by events. Each transition can have an action, which for a saga is the invocation of a saga participant.The transitions between states are triggered by the completion of a local transaction performed by a saga participant. The current state and the specific outcome of the local transaction determine the state transition and what action, if any, to perform. As a result, using a state machine model makes designing, implementing, and testing sagas easier.
Şeklen şöyle
State'lerin açıklaması şöyle
Order Open : The initial state. Saga set this state at the start of the workflow.Blocking Seat : When in this state, the saga is waiting for the SeatBlockingService to block the seat for booking.Authorizing Payment : The saga is waiting for a reply to the payment authorization command from PaymentService.Allocating Seat : Waiting for SeatAllocationService to allocate the seat after payment success.Reverse Payment : If Seat allocation fails, the saga would send a request for a payment refund.Unblock Seat : If payment authorization fails, the saga would send a fail event to unblock the seat.Order Completed : A final state indicating that the saga was completed successfully.Order Rejected : A final state indicating that the Order was rejected by one of the participants.
Aynı anda birden fazla Saga çalışıyor olabilir. Şeklen şöyle
Hiç yorum yok:
Yorum Gönder