Microservice Patterns - Managing transactions with sagas - 4.2 Coordinating sagas


Reference

Sagas process
  1. Saga init by system command
  2. Coordination logic select and tell the first Saga participant to execute local transaction
  3. After finish, Saga's sequencing coordination select and invoke next Saga participant
  4. Continue until all steps executed
  5. 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:
  1. Ensure saga participant update database and publish event as part of database transaction => Atomically.
    To communicate reliably, the saga participant must use transactional messaging.
  2. 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
  1. orchestrator class whose sole responsibility is to tell the saga participants what to do
  2. orchestrator communicates with the participants using command/ async reply-style interaction
  3. it sends a command message to a participant telling it what operation to perform.
  4. After the saga participant has performed the operation, it sends a reply message to the orchestrator
  5. 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



沒有留言:

張貼留言

別名演算法 Alias Method

 題目 每個伺服器支援不同的 TPM (transaction per minute) 當 request 來的時候, 系統需要馬上根據 TPM 的能力隨機找到一個適合的 server. 雖然稱為 "隨機", 但還是需要有 TPM 作為權重. 解法 別名演算法...