Reference
Sagas process
- Saga init by system command
- Coordination logic select and tell the first Saga participant to execute local transaction
- After finish, Saga's sequencing coordination select and invoke next Saga participant
- Continue until all steps executed
- If any local transaction fail, Saga must execute the compensating transaction in reverse order.
Ways to construct Saga's Coordination logic
- Choreography - Distribute decision making and sequence among the Saga participants. Primary communicate by exchanging events.
- Orchestration - Centralize coordination logic in a Saga Orchestration class. Saga orchestrator send command to Saga participants to tell them which operation to perform.
Choreography-based sagas
- saga participants subscribe to each other’s events and respond accordingly
IMPLEMENTING THE CREATE ORDER SAGA USING CHOREOGRAPHY
Each participant updates its database and publishes an event that triggers the next participant
RELIABLE EVENT-BASED COMMUNICATION
Need consider following items when implementing choreography-based sagas:
- Ensure saga participant update database and publish event as part of database transaction => Atomically.To communicate reliably, the saga participant must use transactional messaging.
- Saga participant must be able to map each event that it receives to its own data.=> When Order Service receives a event, it must be able to look up the corresponding Order.=> Solution: Publish event containing a correlation id, used to enable other participants to perform mapping.=> Ex. Order Id
BENEFITS AND DRAWBACKS OF CHOREOGRAPHY-BASED SAGAS
- Benefit
- Simplicity: Service publish its own events
- Loose Coupling: Each service communicate through events, don't have direct knowledge of each other
- Drawback
- Difficult to understand: Unlike orchestration, no single place to define Saga. Difficult for a developer to understand how Sagas work.
- Cyclic dependencies between Services
- Risk of tight coupling
- Because of these drawbacks, more complex Sagas use orchestration.
Orchestration-based sagas
- orchestrator class whose sole responsibility is to tell the saga participants what to do
- orchestrator communicates with the participants using command/ async reply-style interaction
- it sends a command message to a participant telling it what operation to perform.
- After the saga participant has performed the operation, it sends a reply message to the orchestrator
- orchestrator then processes the message and determines which saga step to perform next
MODELING SAGA ORCHESTRATORS AS STATE MACHINES
- A good way to model a saga orchestrator is as a state machine
BENEFITS AND DRAWBACKS OF ORCHESTRATION-BASED SAGAS
- Simpler dependencies
- Less coupling
- Improves separation of concerns and simplifies the business logic
DRAWBACK
the risk of centralizing too much business logic in the orchestrator
沒有留言:
張貼留言