Сообщение Re[3]: Развертывание (деплоймент) микросервисов от 28.02.2023 23:56
Изменено 28.02.2023 23:57 vsb
Re[3]: Развертывание (деплоймент) микросервисов
Здравствуйте, Дельгядо Филипп, Вы писали:
vsb>>С архитектурной точки зрения надо думать про БД. Чтобы миграция между версиями всегда была условно мгновенная и всегда можно было откатить сервис на предыдущую версию без отката БД. В целом это не проблема, но сложные миграции придётся разделять на несколько версий, какие-то изменения, которые бы лочили БД надолго (обновление кучи строк) нужно реализовывать через батч-задачи, которые там по 100 строк будут обрабатывать не мешая остальным и тд.
ДФ>Нее, миграции в БД надо делать несколько иначе.
Как?
A>>>• Возможность управлять процентом пользователей, которые будут обслуживаться разными версиями микросервиса, для каждого микросервиса
vsb>>Кубер умеет.
ДФ>А где это кубер это умеет? Это умеет делать какой-нибудь istio, но в кубере нет поддержки балансировки пользователя в зависимости от выложенной версии.
https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#canary
Ну да, формально это дополнительный компонент.
A>>>• Возможность быстрого масштабирования нагрузки
vsb>>Кубер умеет. В хорошем облаке масштабировать можно от условного нуля до условной бесконечности. Понятно, что для кубера масштабирование это просто запуск очередного инстанса с сервисом, когда метрики переходят какие-то границы. А будет ли это масштабироваться на практике или всё упрётся в БД — это уже вопрос архитектуры, тут надо своей головой думать.
ДФ>Обычно автоматическое масштабирование скорее опасно, чем полезно.
Почему?
vsb>>С архитектурной точки зрения надо думать про БД. Чтобы миграция между версиями всегда была условно мгновенная и всегда можно было откатить сервис на предыдущую версию без отката БД. В целом это не проблема, но сложные миграции придётся разделять на несколько версий, какие-то изменения, которые бы лочили БД надолго (обновление кучи строк) нужно реализовывать через батч-задачи, которые там по 100 строк будут обрабатывать не мешая остальным и тд.
ДФ>Нее, миграции в БД надо делать несколько иначе.
Как?
A>>>• Возможность управлять процентом пользователей, которые будут обслуживаться разными версиями микросервиса, для каждого микросервиса
vsb>>Кубер умеет.
ДФ>А где это кубер это умеет? Это умеет делать какой-нибудь istio, но в кубере нет поддержки балансировки пользователя в зависимости от выложенной версии.
https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#canary
Ну да, формально это дополнительный компонент.
A>>>• Возможность быстрого масштабирования нагрузки
vsb>>Кубер умеет. В хорошем облаке масштабировать можно от условного нуля до условной бесконечности. Понятно, что для кубера масштабирование это просто запуск очередного инстанса с сервисом, когда метрики переходят какие-то границы. А будет ли это масштабироваться на практике или всё упрётся в БД — это уже вопрос архитектуры, тут надо своей головой думать.
ДФ>Обычно автоматическое масштабирование скорее опасно, чем полезно.
Почему?
Re[3]: Развертывание (деплоймент) микросервисов
Здравствуйте, Дельгядо Филипп, Вы писали:
vsb>>С архитектурной точки зрения надо думать про БД. Чтобы миграция между версиями всегда была условно мгновенная и всегда можно было откатить сервис на предыдущую версию без отката БД. В целом это не проблема, но сложные миграции придётся разделять на несколько версий, какие-то изменения, которые бы лочили БД надолго (обновление кучи строк) нужно реализовывать через батч-задачи, которые там по 100 строк будут обрабатывать не мешая остальным и тд.
ДФ>Нее, миграции в БД надо делать несколько иначе.
Как?
A>>>• Возможность управлять процентом пользователей, которые будут обслуживаться разными версиями микросервиса, для каждого микросервиса
vsb>>Кубер умеет.
ДФ>А где это кубер это умеет? Это умеет делать какой-нибудь istio, но в кубере нет поддержки балансировки пользователя в зависимости от выложенной версии.
https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#canary
Ну да, формально это дополнительный компонент. И там всего одна дополнительная версия возможна.
A>>>• Возможность быстрого масштабирования нагрузки
vsb>>Кубер умеет. В хорошем облаке масштабировать можно от условного нуля до условной бесконечности. Понятно, что для кубера масштабирование это просто запуск очередного инстанса с сервисом, когда метрики переходят какие-то границы. А будет ли это масштабироваться на практике или всё упрётся в БД — это уже вопрос архитектуры, тут надо своей головой думать.
ДФ>Обычно автоматическое масштабирование скорее опасно, чем полезно.
Почему?
vsb>>С архитектурной точки зрения надо думать про БД. Чтобы миграция между версиями всегда была условно мгновенная и всегда можно было откатить сервис на предыдущую версию без отката БД. В целом это не проблема, но сложные миграции придётся разделять на несколько версий, какие-то изменения, которые бы лочили БД надолго (обновление кучи строк) нужно реализовывать через батч-задачи, которые там по 100 строк будут обрабатывать не мешая остальным и тд.
ДФ>Нее, миграции в БД надо делать несколько иначе.
Как?
A>>>• Возможность управлять процентом пользователей, которые будут обслуживаться разными версиями микросервиса, для каждого микросервиса
vsb>>Кубер умеет.
ДФ>А где это кубер это умеет? Это умеет делать какой-нибудь istio, но в кубере нет поддержки балансировки пользователя в зависимости от выложенной версии.
https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#canary
Ну да, формально это дополнительный компонент. И там всего одна дополнительная версия возможна.
A>>>• Возможность быстрого масштабирования нагрузки
vsb>>Кубер умеет. В хорошем облаке масштабировать можно от условного нуля до условной бесконечности. Понятно, что для кубера масштабирование это просто запуск очередного инстанса с сервисом, когда метрики переходят какие-то границы. А будет ли это масштабироваться на практике или всё упрётся в БД — это уже вопрос архитектуры, тут надо своей головой думать.
ДФ>Обычно автоматическое масштабирование скорее опасно, чем полезно.
Почему?