Kokie architektūros modeliai leidžia atsikratyti atomariškumo tarp mikroservisų? Ar dirbote su Saga modeliu? Kokie du Saga tipai egzistuoja ir kuo jie skiriasi?

Архитектурные паттерны, позволяющие избавиться от необходимости атомарных транзакций между микросервисами, обычно основаны на асинхронной обработке и компенсационных механизмах. Один из таких паттернов — Saga.

Saga — это паттерн управления распределёнными транзакциями, который разбивает большую транзакцию на серию локальных транзакций, каждая из которых выполняется в отдельном микросервисе. Если одна из транзакций неудачна, выполняются компенсационные транзакции для отката предыдущих изменений.

Существует два основных вида Saga:

1. Choreography (Хореография)

   • Каждый сервис публикует события и подписывается на события других сервисов.
   • Нет центрального оркестратора, сервисы самостоятельно реагируют на события и запускают свои локальные транзакции.
   • Пример: сервис A завершил операцию и опубликовал событие, сервис B, подписанный на это событие, запускает свою транзакцию.

2. Orchestration (Оркестрация)

   • Центральный оркестратор управляет последовательностью вызовов микросервисов.
   • Оркестратор вызывает сервисы по очереди и обрабатывает ошибки, инициируя компенсации при необходимости.

Разница:

• В хореографии нет единой точки управления, что повышает децентрализацию, но усложняет отслеживание состояния.
• В оркестрации есть централизованный контроллер, что упрощает управление, но создаёт потенциальную точку отказа.

Пример упрощённой оркестрации на Go (псевдокод):

func SagaOrchestrator() error {
    if err := ServiceA(); err != nil {
        return err
    }
    if err := ServiceB(); err != nil {
        compensateServiceA()
        return err
    }
    return nil
}

Таким образом, паттерн Saga позволяет обойтись без распределённых транзакций с атомарностью, используя локальные транзакции и компенсации.