Почему двухфазная фиксация не подходит для архитектуры микросервисов?

Основная причина отказа от двухфазной фиксации заключается в том, что координатор транзакций является своего рода диктатором, поскольку он сообщает всем остальным узлам, что делать. Обычно координатор транзакции встроен в сервер приложений. Проблема возникает, когда после 1-й фазы или фазы подготовки координатор транзакций или сервер приложений выходит из строя. Теперь участвующие узлы не знают, что делать. Они не могут выполнить обязательство, потому что они не знают, ответили ли другие координатору с «нет», и они не могут выполнить откат, потому что другие могли сказать «да» координатору. Таким образом, до тех пор, пока координатор не вернется через 15 минут (скажем) и не завершит 2-й этап, участвующие хранилища данных будут оставаться в заблокированном состоянии. Это препятствует масштабируемости и производительности . Хуже всего случается, когда журнал транзакций координатора повреждается после 1-й фазы. В этом случае хранилища данных остаются в заблокированном состоянии навсегда. Даже перезапуск процессов не поможет. Единственное решение состоит в том, чтобы вручную проверить данные для обеспечения согласованности, а затем снять блокировки. Эти вещи обычно происходят в ситуации высокого давления, и, следовательно, это определенно огромные накладные расходы на эксплуатацию . Следовательно, традиционная двухфазная фиксация не является хорошим решением.

Однако следует отметить, что некоторые современные системы, такие как Kafka, также реализовали двухэтапную фиксацию. Но это отличается от традиционного решения тем, что здесь каждый брокер может быть координатором, и, таким образом, алгоритм выбора лидера Kafka и модель репликации облегчают проблемы, упомянутые в традиционной модели.

«Мы не можем» здесь на самом деле означает «Это плохая идея, и я не хочу, и, если я допускаю такую ​​возможность, я не смогу убедить вас не настаивать».

Конечно, вы можете внедрить 2-фазную фиксацию через микросервисы, но:

• 2-фазная фиксация требует значительных усилий по разработке в каждой службе, которая может участвовать в транзакции,
[111 ] Это вызывает много разногласий между клиентами, которые растут с задержкой связи между серверами; и
• Все задействованные службы должны согласовать множество протоколов, конфигурации, развертывания и других деталей, которые определяют, как на самом деле будет работать двухфазная фиксация.

Этими проблемами достаточно сложно управлять среди нескольких тесно связанных служб на совместно расположенных серверах с выделенными сетями. В более разнородных средах с большим количеством серверов и более высокими задержками, которые характеризуют развертывание микросервисов, это становится намного сложнее.

Общая идея микросервисов - это слабосвязанные и независимые сервисы. Поскольку 2pc означает, что у нас есть 2 фазы для фиксации транзакции. управляющий узел будет управлять транзакцией, и все остальные узлы сначала отвечают, что они готовы, и на втором этапе все они фиксируют или откатываются в зависимости от первого этапа.

Что произойдет, если управляющий узел не работает? Что происходит, когда любой из других узлов не работает? из-за этого ограничения вся ваша транзакция не может пройти. В распределенных транзакциях ваши узлы могут находиться в разных дата-центрах или регионах. самый медленный узел для ответа будет держать другие узлы в состоянии ожидания, пока они могут двигаться дальше. так атомарность мешает работе.

Вы не можете масштабировать систему, и в целом сервисы должны быть независимыми и масштабируемыми.

2pc не является неправильным ответом, но в большинстве случаев мы рассматриваем возможную последовательность. если у вас есть система, которая требует строгой согласованности, то 2pc может быть вариантом.

Некоторые вещи, на которые следует обратить внимание, а также дать некоторые предпосылки:

1. В большинстве сценариев микросервисы взаимодействуют через HTTP (протокол без сохранения состояния), и в результате глобальные транзакции / транзакции XA просто не применимы / невозможны. [ 112]
2. Ровно однажды семантика невозможна, и вы должны пойти «хотя бы раз». Это означает, что все услуги должны быть идемпотентными.
3. Один хороший пример того, почему невозможно достичь семантики «ровно один раз» при такой настройке, заключается в том, что HTTP-соединения очень часто теряются на обратном пути к клиенту. Это означает, что через POST состояние сервера изменилось, а клиент получил ошибку тайм-аута.
4. Внутри границ микросервисов вы можете использовать их очень хорошо. Как вы упомянули Kafka, вы можете довольно легко потреблять (из 1 темы) и производить (до 1 или более тем) одну атомарную / все или ничего операцию (ровно семантику).
5. Но если вы хотите, чтобы глобальные и долгосрочные транзакции между микросервисами, которые взаимодействуют через http, единственно возможный вариант (вы можете увидеть глобальные транзакции через http, если вы используете Google, но для производственной системы просто игнорируйте их), - это проектировать для возможной согласованности , Короче говоря, это означает, что нужно повторить навсегда для исправимых ошибок (это целая глава сама по себе) и выставить компенсирующие конечные точки или произвести компенсационные события, которые в конечном итоге исправят неисправимые ошибки. Посмотрите паттерн саг . Нараяна менеджер транзакций имеет хорошую поддержку Sagas и хорошее сравнение продуктов.
6. Распределенные системы очень сложны, и у вас должна быть причина для такого решения. Если вы будете распределены, то операции, которые ваш монолит может безопасно делегировать вашему менеджеру транзакций, должны будут выполняться разработчиком / архитектором: -).