У Temporal есть такой механизм, как Continue-As-New. По сути, это запуск новой копии тяжёлого workflow с того места, где закончила работать предыдущая копия.
Именно канареечных релизов пока не делали, так что точно не скажу. Но вроде ка технических ограничений я не вижу. У нас каждый сервис и фасад состоит из 2 контейнеров: temporal и http. На первом работают workflow и activity, на втором крутится код, который обрабатывает http-запросы. Оба контейнера объединены в одну реплику. И если во время деплоя обновлять не сразу все реплики, а по очереди, то в итоге и получим канареечный релиз
В плане производительности пока никаких проблем не наблюдается. В конце лета ожидается очень серьёзное увеличение траффика, сейчас как раз к нему готовимся. И в следующей статье наверняка затрону и эту тему нагрузки.
Из самых очевидных проблем, с которыми столкнулись - это довольно высокие требования к скилам разработчиков, и не самый оперативный онбординг. То есть, у нас нет возможности за пару недель нанять армию джунов, чтобы срочно закрыть какие-то задачи.
Ну, а что в процессе интеграции шло не так, я уже описал. Это, пожалуй, все из известных на данный момент сложностей.
Прошу прощения за долгий ответ. Но всё-таки позволю себе не согласиться с некоторым из написанного.
Насчёт хранилища данных самого Temporal - есть возможность использовать разные базы, в том числе и Postgres. У нас же используется Cassandra для хранения состояний и Elasticsearch для visibility. Я намеренно не углублялся в технические тонкости работы Temporal, т. к. статья не совсем о том.
Насчёт нагрузки и горизонтального масштабирования - во-первых, действительно можно поднять несколько оркестраторов. Но вероятней всего этого не придётся делать, т. к. по заявлениям разработчиков даже один под Temporal легко справляется с сотнями тысяч запросов в секунду. На таких масштабах начинаются уже совсем другие проблемы, вроде нехватки потоков для работы activity.
В целом, я сейчас дописываю следующую статью по результатам внедрения описанной тут архитектуры. Там будет и про нагрузку, и про онбординг новых сотрудников, и про разбиение на команды. В общем, если будет интересно, то добро пожаловать :)
Да, в идеале именно так. В сервисе только хранение/редактирование сущностей, валидация входных параметров запроса и ограничение прав доступа на сущности.
У Temporal есть такой механизм, как Continue-As-New. По сути, это запуск новой копии тяжёлого workflow с того места, где закончила работать предыдущая копия.
Именно канареечных релизов пока не делали, так что точно не скажу. Но вроде ка технических ограничений я не вижу. У нас каждый сервис и фасад состоит из 2 контейнеров: temporal и http. На первом работают workflow и activity, на втором крутится код, который обрабатывает http-запросы. Оба контейнера объединены в одну реплику. И если во время деплоя обновлять не сразу все реплики, а по очереди, то в итоге и получим канареечный релиз
Обязательно. В конце лета ожидаем большой рост нагрузки. И как раз сейчас готовимся к нему.
В плане производительности пока никаких проблем не наблюдается. В конце лета ожидается очень серьёзное увеличение траффика, сейчас как раз к нему готовимся. И в следующей статье наверняка затрону и эту тему нагрузки.
Из самых очевидных проблем, с которыми столкнулись - это довольно высокие требования к скилам разработчиков, и не самый оперативный онбординг. То есть, у нас нет возможности за пару недель нанять армию джунов, чтобы срочно закрыть какие-то задачи.
Ну, а что в процессе интеграции шло не так, я уже описал. Это, пожалуй, все из известных на данный момент сложностей.
Прошу прощения за долгий ответ. Но всё-таки позволю себе не согласиться с некоторым из написанного.
Насчёт хранилища данных самого Temporal - есть возможность использовать разные базы, в том числе и Postgres. У нас же используется Cassandra для хранения состояний и Elasticsearch для visibility. Я намеренно не углублялся в технические тонкости работы Temporal, т. к. статья не совсем о том.
Насчёт нагрузки и горизонтального масштабирования - во-первых, действительно можно поднять несколько оркестраторов. Но вероятней всего этого не придётся делать, т. к. по заявлениям разработчиков даже один под Temporal легко справляется с сотнями тысяч запросов в секунду. На таких масштабах начинаются уже совсем другие проблемы, вроде нехватки потоков для работы activity.
В целом, я сейчас дописываю следующую статью по результатам внедрения описанной тут архитектуры. Там будет и про нагрузку, и про онбординг новых сотрудников, и про разбиение на команды. В общем, если будет интересно, то добро пожаловать :)
Да, в идеале именно так. В сервисе только хранение/редактирование сущностей, валидация входных параметров запроса и ограничение прав доступа на сущности.
Спасибо за оценку!
Если честно, у меня с названием Даркстор ассоциируется только даркнет. То есть, что-то не совсем легальное :)