Comments 6
Было бы интересно еще узнать - а что пошло не так или стало хуже с новой архитектурой.
В плане производительности пока никаких проблем не наблюдается. В конце лета ожидается очень серьёзное увеличение траффика, сейчас как раз к нему готовимся. И в следующей статье наверняка затрону и эту тему нагрузки.
Из самых очевидных проблем, с которыми столкнулись - это довольно высокие требования к скилам разработчиков, и не самый оперативный онбординг. То есть, у нас нет возможности за пару недель нанять армию джунов, чтобы срочно закрыть какие-то задачи.
Ну, а что в процессе интеграции шло не так, я уже описал. Это, пожалуй, все из известных на данный момент сложностей.
Думаю стоит ждать следующую статью про то, как система повела себя и какие изменения пережила после больших нагрузок
1) Как обходите лимиты на размер истории воркфлоу при работе с «тяжёлыми» payload ?
2) Как у вас организовано канареечное выкатывание новых версий воркфлоу?
У Temporal есть такой механизм, как Continue-As-New. По сути, это запуск новой копии тяжёлого workflow с того места, где закончила работать предыдущая копия.
Именно канареечных релизов пока не делали, так что точно не скажу. Но вроде ка технических ограничений я не вижу. У нас каждый сервис и фасад состоит из 2 контейнеров: temporal и http. На первом работают workflow и activity, на втором крутится код, который обрабатывает http-запросы. Оба контейнера объединены в одну реплику. И если во время деплоя обновлять не сразу все реплики, а по очереди, то в итоге и получим канареечный релиз
Как мы год прожили с распределённой архитектурой и не сошли с ума