Welche Architektur-Patterns ermöglichen es, die Atomarität zwischen Microservices zu beseitigen? Haben Sie mit dem Saga-Pattern gearbeitet? Welche zwei Arten von Saga gibt es und worin besteht der Unterschied?

Архитектурные паттерны, позволяющие избавиться от необходимости атомарных транзакций между микросервисами, обычно основаны на асинхронной обработке и компенсационных механизмах. Один из таких паттернов — 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 позволяет обойтись без распределённых транзакций с атомарностью, используя локальные транзакции и компенсации.