Комментарии 6
Хорошая статья, спасибо!
я верно понимаю, что сервис будет представлять из себя уже, по большей части, просто БД и в нем не будет почти никакой (читай никакой) логики?
Я бы не торопился с темпорал. В статье не указано на чём, то есть где темпорал хранит все сценарии и статусы у себя внутри. Допустим это постгрес или мускуль, а значит о простом горизонтальном масштабировании с ростом нагрузки можно забыть. Это ещё не упомянуто о том, что как и в любом оркестраторе, с ростом количества систем растет количество не только сценариев, но и шагов даже в старых сценариях, а при хайлоаде скажем даже в 50000 сценариев в секунду там всё лежать будет. А с учётом, что там основные бизнес процессы, то считай и вся компания.
Моё мнение, что единая оркестрация не подходит под действительно серьёзные нагрузки. Да, можно несколько оркестраторов использовать, но там другие вопросы возникнут...
С другой стороны, указанные в начале статьи проблемы можно было бы решить разбиением всех систем на продукты со своими командами системных архитекторов и разработки со связующим звеном в виде солюшен/ентерпрайз аналитиков и архитекторов. И тогда верхний уровень бизнес процессов описывается кубиками достаточно просто и внутренняя хореография командами продуктов тоже ведется с прекрасным пониманием что где как точно работает, и погружение новичков не проблема. Зато масштабирование систем продуктов с ростом бизнеса вообще не будет вызывать вопросов при хореографии и никогда весь бизнес не встанет из-за одного узкого места.
Прошу прощения за долгий ответ. Но всё-таки позволю себе не согласиться с некоторым из написанного.
Насчёт хранилища данных самого Temporal - есть возможность использовать разные базы, в том числе и Postgres. У нас же используется Cassandra для хранения состояний и Elasticsearch для visibility. Я намеренно не углублялся в технические тонкости работы Temporal, т. к. статья не совсем о том.
Насчёт нагрузки и горизонтального масштабирования - во-первых, действительно можно поднять несколько оркестраторов. Но вероятней всего этого не придётся делать, т. к. по заявлениям разработчиков даже один под Temporal легко справляется с сотнями тысяч запросов в секунду. На таких масштабах начинаются уже совсем другие проблемы, вроде нехватки потоков для работы activity.
В целом, я сейчас дописываю следующую статью по результатам внедрения описанной тут архитектуры. Там будет и про нагрузку, и про онбординг новых сотрудников, и про разбиение на команды. В общем, если будет интересно, то добро пожаловать :)
Как управлять распределённой системой, не привлекая внимания санитаров