Comments 2
Неплохой обзор, но чуть добавлю.
Непонятно, почему у оркестратора «средняя масштабируемость». Можно же запустить любое количество экземпляров оркестратора.
Непонятно, почему в недостатках хореографии не указано наличие компенсирующих транзакций. Они там нужны так же, как и при оркестрации.
Непонятно, где в 2PC сложная конфигурация. Сами же пишете, что существует множество готовых реализаций.
Непонятно, почему у 2PC плохая масштабируемость. Если, конечно, вы хотите все транзакции пускать через единственный координатор, то да. Но ведь у каждой транзакции может быть собственный координатор! Например, так работает Apache Ignite.
Падение координатора – не единственная проблема 2PC. Стандарт вообще не предусматривает потерю узла: предполагается, что у узла есть надёжное хранилище, и если узел упал, то через некоторое время он будет восстановлен, причём содержимое его диска сохранится. Восстановление после безвозвратной потери узла – каждый раз произведение искусства.
Для полноты картины здесь можно было бы упомянуть детерминированные транзакции – это третий способ выполнения распределённых транзакций, пусть и не связанный с микросервисной архитектурой.
Статья хорошая как обзор.
Согласен с первым комментарием. Добавил-бы сагу с семантическими блокировками и соответствующей компенсацией. ИМХО, строгая консистентность в SOA, скорее, миф. Достигать ее занятие чисто академическое.
Распределённые транзакции