ИЕ
Приветствую!
Я тоже думал о том как в картридже+vshard организовать обновление конфигурации без простоев - для нас это важно.
Пока у меня мысль движется в стороне подхода аналогичного zelando для PG.
Там ребята ввели слой хранимок и доступ к данным выполняли только через них ( в vshard - это так же).
А для наката релиза создавалась новая схема с именем api_2020_45 ( потом 46 и т.д.) - и в нее загружалась полностью новая версия апи для работы с данными.
После этого обновлялся приклад.
После этого старая версия схема удалялась (когда никто уже ей не пользовался).
При этом изменения между релизами должны быть обратно совместимы на 1-2 релиза назад.
Насколько я понимаю подход - в целом это можно реализовать в vshard'е:
1. Выкатываем обновления на слой хранилищь - создается новый спейс с новыми версиями функций, права доступа и т.д.
2. Выкатываем обновления на роутеры - создаем новый спейс с новыми версиями функций, которые используют новый спейс в хранилищах
3. обновляем (возможно постепенно) приклады - они начинают работать с новой версией API (может нужна доработка на стороне приклада, а может просто имя спецса для вызова функций поменять).
Хотел узнать мнение более близко работающих с этим коллег.
Вопрос в том как такое создание нового спейса удобнее всего запускать в кластере.
Я тоже думал о том как в картридже+vshard организовать обновление конфигурации без простоев - для нас это важно.
Пока у меня мысль движется в стороне подхода аналогичного zelando для PG.
Там ребята ввели слой хранимок и доступ к данным выполняли только через них ( в vshard - это так же).
А для наката релиза создавалась новая схема с именем api_2020_45 ( потом 46 и т.д.) - и в нее загружалась полностью новая версия апи для работы с данными.
После этого обновлялся приклад.
После этого старая версия схема удалялась (когда никто уже ей не пользовался).
При этом изменения между релизами должны быть обратно совместимы на 1-2 релиза назад.
Насколько я понимаю подход - в целом это можно реализовать в vshard'е:
1. Выкатываем обновления на слой хранилищь - создается новый спейс с новыми версиями функций, права доступа и т.д.
2. Выкатываем обновления на роутеры - создаем новый спейс с новыми версиями функций, которые используют новый спейс в хранилищах
3. обновляем (возможно постепенно) приклады - они начинают работать с новой версией API (может нужна доработка на стороне приклада, а может просто имя спецса для вызова функций поменять).
Хотел узнать мнение более близко работающих с этим коллег.
Вопрос в том как такое создание нового спейса удобнее всего запускать в кластере.
В продолжение обсуждения:
В картридже есть ограничение на количество ролей?
В дополнение к описанному выше подходу (или как механизм его обеспечения) - можно было бы:
1. новый релиз объявлять новой ролью.
2. при инициализации роли на хранилищах и роутерах (по порядку) проводить всю необходимую инициализацию.
3. после переключение основного приложение на работу с новыми спейсами ( новой ролью) - выполнять выключение старой роли аналогично.
Пока в этой картинке у меня не получается сами исходники новых ролей раскидать по инстансам, но это я так понимаю можно сделать через глобальный конфиг... хотя и не самая хорошая наверное идея...
Может где-то есть нараотки в этом направлении - был бы очень благодарен.
В картридже есть ограничение на количество ролей?
В дополнение к описанному выше подходу (или как механизм его обеспечения) - можно было бы:
1. новый релиз объявлять новой ролью.
2. при инициализации роли на хранилищах и роутерах (по порядку) проводить всю необходимую инициализацию.
3. после переключение основного приложение на работу с новыми спейсами ( новой ролью) - выполнять выключение старой роли аналогично.
Пока в этой картинке у меня не получается сами исходники новых ролей раскидать по инстансам, но это я так понимаю можно сделать через глобальный конфиг... хотя и не самая хорошая наверное идея...
Может где-то есть нараотки в этом направлении - был бы очень благодарен.
