Сообщение Re[3]: Развертывание (деплоймент) микросервисов от 19.12.2022 22:03
Изменено 19.12.2022 23:34 ботаныч
Re[3]: Развертывание (деплоймент) микросервисов
Здравствуйте, andsm, Вы писали:
A>Здравствуйте, ботаныч, Вы писали:
A>Это немного не про то, непрерывная работа виртуалок и тому подобное мне не интересно.
непрерывность работы виртуалки в (эталонной) микросервисной архитектуре есть лишь критерий того, что очевидно вы называете "не оказывающим влияния на пользователя.", еще часто говорят прозрачно для пользователя. или что вы называете этой фразой ) без-остановочную работу? даже при условиях ошибки? так таки да, так и работают надежные системы. однако, про слепок. а как вы устроите безостановочную работу в условиях деплоя?
A>В хорошей микросервисной архитектуре падение экземпляра какого-то микросервиса должно быть не аварией, а штатным событием, не оказывающим влияния на пользователя.
ага выше.
A>Мне интересен реальный опыт проектирования высоконагруженных систем с канареечным развертыванием, были ли какие неожиданные проблемы в части реализации развертывания.
вот не вижу зависимости от высоконагруженных систем и канареечным развертыванием. по описанию этого термина я понял, что это своего рода слоеный беттатестинг с распределением пользователей на группы , готовых взять на грудь ..новую версию, и не готовых. в моей практике слой QA зачастую играл достаточно сложную партию. и что вы называете высоконагруженными задачами? много людей? или много вычислений?
однако по описанию немного осознал наличие решений в упомянутой мной архитектуре. в нашей системе была compitabilaty модулей работающих в соях архитекуры, в обе стороны — чаще, когда старый модуль должен был понимать? что ему говорит новый. (там соединение может быть как на вебсервисах *(что просо надcтройка для http)) либо же tcp\ip (это к тому, что вы про канареечный деплой больше про вебсервисы).
A>Я такую систему проектировал, но полностью канареечное развертывание там так и не сделали. В этой системе, думаю, это все же будет реализовано.
я повторю вопрос, что актуальнее
— перевод на микросервисы какого нить легаси
— или развертывание ? второе кажется существенно проще ..
A>Здравствуйте, ботаныч, Вы писали:
A>Это немного не про то, непрерывная работа виртуалок и тому подобное мне не интересно.
непрерывность работы виртуалки в (эталонной) микросервисной архитектуре есть лишь критерий того, что очевидно вы называете "не оказывающим влияния на пользователя.", еще часто говорят прозрачно для пользователя. или что вы называете этой фразой ) без-остановочную работу? даже при условиях ошибки? так таки да, так и работают надежные системы. однако, про слепок. а как вы устроите безостановочную работу в условиях деплоя?
A>В хорошей микросервисной архитектуре падение экземпляра какого-то микросервиса должно быть не аварией, а штатным событием, не оказывающим влияния на пользователя.
ага выше.
A>Мне интересен реальный опыт проектирования высоконагруженных систем с канареечным развертыванием, были ли какие неожиданные проблемы в части реализации развертывания.
вот не вижу зависимости от высоконагруженных систем и канареечным развертыванием. по описанию этого термина я понял, что это своего рода слоеный беттатестинг с распределением пользователей на группы , готовых взять на грудь ..новую версию, и не готовых. в моей практике слой QA зачастую играл достаточно сложную партию. и что вы называете высоконагруженными задачами? много людей? или много вычислений?
однако по описанию немного осознал наличие решений в упомянутой мной архитектуре. в нашей системе была compitabilaty модулей работающих в соях архитекуры, в обе стороны — чаще, когда старый модуль должен был понимать? что ему говорит новый. (там соединение может быть как на вебсервисах *(что просо надcтройка для http)) либо же tcp\ip (это к тому, что вы про канареечный деплой больше про вебсервисы).
A>Я такую систему проектировал, но полностью канареечное развертывание там так и не сделали. В этой системе, думаю, это все же будет реализовано.
я повторю вопрос, что актуальнее
— перевод на микросервисы какого нить легаси
— или развертывание ? второе кажется существенно проще ..
Re[3]: Развертывание (деплоймент) микросервисов
Здравствуйте, andsm, Вы писали:
A>Здравствуйте, ботаныч, Вы писали:
A>Это немного не про то, непрерывная работа виртуалок и тому подобное мне не интересно.
непрерывность работы виртуалки в (эталонной) микросервисной архитектуре есть лишь критерий того, что очевидно вы называете "не оказывающим влияния на пользователя.", еще часто говорят прозрачно для пользователя. или что вы называете этой фразой ) без-остановочную работу? даже при условиях ошибки? так таки да, так и работают надежные системы. однако, про слепок. а как вы устроите безостановочную работу в условиях деплоя?
A>В хорошей микросервисной архитектуре падение экземпляра какого-то микросервиса должно быть не аварией, а штатным событием, не оказывающим влияния на пользователя.
ага выше.
A>Мне интересен реальный опыт проектирования высоконагруженных систем с канареечным развертыванием, были ли какие неожиданные проблемы в части реализации развертывания.
вот не вижу зависимости от высоконагруженных систем и канареечным развертыванием. по описанию этого термина я понял, что это своего рода слоеный беттатестинг с распределением пользователей на группы , готовых взять на грудь ..новую версию, и не готовых. в моей практике слой QA зачастую играл достаточно сложную партию. и что вы называете высоконагруженными задачами? много людей? или много вычислений?
однако по описанию немного осознал наличие решений в упомянутой мной архитектуре. в нашей системе была compitabilaty модулей работающих в соях архитекуры, в обе стороны — чаще, когда старый модуль должен был понимать? что ему говорит новый. (там соединение может быть как на вебсервисах *(что просо надcтройка для http)) либо же tcp\ip (это к тому, что вы про канареечный деплой больше про вебсервисы).
A>Я такую систему проектировал, но полностью канареечное развертывание там так и не сделали. В этой системе, думаю, это все же будет реализовано.
я повторю вопрос, что актуальнее
— перевод на микросервисы какого нить легаси
— или развертывание ? второе кажется существенно проще ...
A>Здравствуйте, ботаныч, Вы писали:
A>Это немного не про то, непрерывная работа виртуалок и тому подобное мне не интересно.
непрерывность работы виртуалки в (эталонной) микросервисной архитектуре есть лишь критерий того, что очевидно вы называете "не оказывающим влияния на пользователя.", еще часто говорят прозрачно для пользователя. или что вы называете этой фразой ) без-остановочную работу? даже при условиях ошибки? так таки да, так и работают надежные системы. однако, про слепок. а как вы устроите безостановочную работу в условиях деплоя?
A>В хорошей микросервисной архитектуре падение экземпляра какого-то микросервиса должно быть не аварией, а штатным событием, не оказывающим влияния на пользователя.
ага выше.
A>Мне интересен реальный опыт проектирования высоконагруженных систем с канареечным развертыванием, были ли какие неожиданные проблемы в части реализации развертывания.
вот не вижу зависимости от высоконагруженных систем и канареечным развертыванием. по описанию этого термина я понял, что это своего рода слоеный беттатестинг с распределением пользователей на группы , готовых взять на грудь ..новую версию, и не готовых. в моей практике слой QA зачастую играл достаточно сложную партию. и что вы называете высоконагруженными задачами? много людей? или много вычислений?
однако по описанию немного осознал наличие решений в упомянутой мной архитектуре. в нашей системе была compitabilaty модулей работающих в соях архитекуры, в обе стороны — чаще, когда старый модуль должен был понимать? что ему говорит новый. (там соединение может быть как на вебсервисах *(что просо надcтройка для http)) либо же tcp\ip (это к тому, что вы про канареечный деплой больше про вебсервисы).
A>Я такую систему проектировал, но полностью канареечное развертывание там так и не сделали. В этой системе, думаю, это все же будет реализовано.
я повторю вопрос, что актуальнее
— перевод на микросервисы какого нить легаси
— или развертывание ? второе кажется существенно проще ...