Сообщение Re: Развертывание (деплоймент) микросервисов от 18.12.2022 13:31
Изменено 18.12.2022 13:38 ботаныч
Re: Развертывание (деплоймент) микросервисов
Здравствуйте, andsm, Вы писали:
A>Имеется довольно крупная eCom компания. И, как у многих, у нее архитектура – монолит.
A>Сейчас занялись переходом на микросервисную архитектуру. В микросервисной архитектуре имеется ряд стратегий развертывания.
A>Рассматриваем переход на полноценное канареечное развертывание. Что хочется от системы развертывания:
A>• Бесшовное обновление, без простоя системы и без воздействия на пользователей
A>• Быстрота доставки изменений на рынок (time to market)
A>• Быстрая обратная связь от пользователей при новых релизах
A>• Возможность управлять процентом пользователей, которые будут обслуживаться разными версиями микросервиса, для каждого микросервиса
A>• Простота отката изменений, если что-то пойдет не так
A>• Возможность быстрого масштабирования нагрузки
A>Думаю, многие такое уже пытались делать, интересно, что получилось.
A>Имеется ли у кого успешный опыт перехода на канареечное развертывание? Все ли получилось, что хотелось? Насколько это задевает А/Б тесты? Насколько это трудоемко в разработке, и насколько сложно в поддержке?
A>Сейчас у нас все сервисы в своем датацентре, не в облаке. Подумываю о развертывании своего кластера кубера, чтобы упростить развертывание и поддержку работы системы. Может кто-то делал такое без кубера? Насколько кубер обязателен?
можно пробовать (поговорить) по разному. 1. надо договориться про термины, т.к. был у меня собес, где спросили, а какой один из ключевых компонентов в микросеврсиной архитектуре, .. я долго перечислял, и совсем ослаб внутренне от того, что мне сказали, что логи.
В общем и целом уточним вопросы ? как перевести архитектуру на микросервис? как получалось деплоить?
вот не могу без предыстории. если говорить про микросервисную архитектуру аля амазон (в конторе по задачам которой я попытаюсь отобразить свое мнение) (почему аля амазон? — китайцы, которые оказались инвесторами скупили одного из архитекторов амазона). C++. Кстати, там в этих архитектурах, где правильные клауды с виртуалками на концах графа архитектуры, так правильно микросервисными и называются (далее в этом текте). Ну и на завтравку, была задача про миграцию операционной систе.. виртуалки без перезагрузки и остановки работы в одного хоста на другой. Бага больше заключалась в хардварных особенностях проца с юлять знаком который я сейчас уже даже не упомню. мне знаетели как комп. лингвисту не оч оказалось интересно.
Так вот, можете что конкретно вас интересует, с тех пунктов ничего не понял. не указано время ренджа процесса разработки — деплоя
1. time ? — какой тайм, обновление чего и на базе чего?
к примеру есть уровень деплоя на QA уровень? они схожи, но в нашей архитектуре разница была. в целом считаю, что на том проекте раздута архитектура в области тестинга, да и пусть даже ..если они умудрялись в области фронт-енда что-то реализовать в этой области. зачем парсеры на руби, где элементарный json играл бы лучше. Ну то такое
Что касается миграции виртуальной машины, повторю —
1. машина не прекращала работу
2. относительно прозрачна для пользователя ..
ну это область настоящих клауд, на базе микросервисов. что вас интересует — перечислить библиотеки ) либвирт. малтисрединг — intel:) concurent lib, boost::asio etc..
собственно там много еще чего, но все остальное — такое.
клиент серверы, демоны и драйвера в юниксподобных ... а виндоподные были только сервисами и драйверами под виртуалками.
так вот перевод на малти(микро)сервисы оч зависит от того какую архитектуру переводят. В целом реализованного рефлекшина и немного мозга у решающих задачи — делается относительно недолго. это практически эквивалентно экспоузингу допустим из c\c++ -> (c#|python|objective c|etc...)/ т.е. просто привести архитектуру к масштабируемому виду. где возможно- использовать только мета об архитектуре (пока будете реализовывать масштабируемость должна появиться и мета) ... ну и в добрый и интересный путь.
A>Имеется довольно крупная eCom компания. И, как у многих, у нее архитектура – монолит.
A>Сейчас занялись переходом на микросервисную архитектуру. В микросервисной архитектуре имеется ряд стратегий развертывания.
A>Рассматриваем переход на полноценное канареечное развертывание. Что хочется от системы развертывания:
A>• Бесшовное обновление, без простоя системы и без воздействия на пользователей
A>• Быстрота доставки изменений на рынок (time to market)
A>• Быстрая обратная связь от пользователей при новых релизах
A>• Возможность управлять процентом пользователей, которые будут обслуживаться разными версиями микросервиса, для каждого микросервиса
A>• Простота отката изменений, если что-то пойдет не так
A>• Возможность быстрого масштабирования нагрузки
A>Думаю, многие такое уже пытались делать, интересно, что получилось.
A>Имеется ли у кого успешный опыт перехода на канареечное развертывание? Все ли получилось, что хотелось? Насколько это задевает А/Б тесты? Насколько это трудоемко в разработке, и насколько сложно в поддержке?
A>Сейчас у нас все сервисы в своем датацентре, не в облаке. Подумываю о развертывании своего кластера кубера, чтобы упростить развертывание и поддержку работы системы. Может кто-то делал такое без кубера? Насколько кубер обязателен?
можно пробовать (поговорить) по разному. 1. надо договориться про термины, т.к. был у меня собес, где спросили, а какой один из ключевых компонентов в микросеврсиной архитектуре, .. я долго перечислял, и совсем ослаб внутренне от того, что мне сказали, что логи.
В общем и целом уточним вопросы ? как перевести архитектуру на микросервис? как получалось деплоить?
вот не могу без предыстории. если говорить про микросервисную архитектуру аля амазон (в конторе по задачам которой я попытаюсь отобразить свое мнение) (почему аля амазон? — китайцы, которые оказались инвесторами скупили одного из архитекторов амазона). C++. Кстати, там в этих архитектурах, где правильные клауды с виртуалками на концах графа архитектуры, так правильно микросервисными и называются (далее в этом текте). Ну и на завтравку, была задача про миграцию операционной систе.. виртуалки без перезагрузки и остановки работы в одного хоста на другой. Бага больше заключалась в хардварных особенностях проца с юлять знаком который я сейчас уже даже не упомню. мне знаетели как комп. лингвисту не оч оказалось интересно.
Так вот, можете что конкретно вас интересует, с тех пунктов ничего не понял. не указано время ренджа процесса разработки — деплоя
1. time ? — какой тайм, обновление чего и на базе чего?
к примеру есть уровень деплоя на QA уровень? они схожи, но в нашей архитектуре разница была. в целом считаю, что на том проекте раздута архитектура в области тестинга, да и пусть даже ..если они умудрялись в области фронт-енда что-то реализовать в этой области. зачем парсеры на руби, где элементарный json играл бы лучше. Ну то такое
Что касается миграции виртуальной машины, повторю —
1. машина не прекращала работу
2. относительно прозрачна для пользователя ..
ну это область настоящих клауд, на базе микросервисов. что вас интересует — перечислить библиотеки ) либвирт. малтисрединг — intel:) concurent lib, boost::asio etc..
собственно там много еще чего, но все остальное — такое.
клиент серверы, демоны и драйвера в юниксподобных ... а виндоподные были только сервисами и драйверами под виртуалками.
так вот перевод на малти(микро)сервисы оч зависит от того какую архитектуру переводят. В целом реализованного рефлекшина и немного мозга у решающих задачи — делается относительно недолго. это практически эквивалентно экспоузингу допустим из c\c++ -> (c#|python|objective c|etc...)/ т.е. просто привести архитектуру к масштабируемому виду. где возможно- использовать только мета об архитектуре (пока будете реализовывать масштабируемость должна появиться и мета) ... ну и в добрый и интересный путь.
Re: Развертывание (деплоймент) микросервисов
Здравствуйте, andsm, Вы писали:
A>Имеется довольно крупная eCom компания. И, как у многих, у нее архитектура – монолит.
A>Сейчас занялись переходом на микросервисную архитектуру. В микросервисной архитектуре имеется ряд стратегий развертывания.
A>Рассматриваем переход на полноценное канареечное развертывание. Что хочется от системы развертывания:
A>• Бесшовное обновление, без простоя системы и без воздействия на пользователей
A>• Быстрота доставки изменений на рынок (time to market)
A>• Быстрая обратная связь от пользователей при новых релизах
A>• Возможность управлять процентом пользователей, которые будут обслуживаться разными версиями микросервиса, для каждого микросервиса
A>• Простота отката изменений, если что-то пойдет не так
A>• Возможность быстрого масштабирования нагрузки
A>Думаю, многие такое уже пытались делать, интересно, что получилось.
A>Имеется ли у кого успешный опыт перехода на канареечное развертывание? Все ли получилось, что хотелось? Насколько это задевает А/Б тесты? Насколько это трудоемко в разработке, и насколько сложно в поддержке?
A>Сейчас у нас все сервисы в своем датацентре, не в облаке. Подумываю о развертывании своего кластера кубера, чтобы упростить развертывание и поддержку работы системы. Может кто-то делал такое без кубера? Насколько кубер обязателен?
можно пробовать (поговорить) по разному. 1. надо договориться про термины, т.к. был у меня собес, где спросили, а какой один из ключевых компонентов в микросеврсиной архитектуре, .. я долго перечислял, и совсем ослаб внутренне от того, что мне сказали, что логи.
В общем и целом уточним вопросы ? как перевести архитектуру на микросервис? как получалось деплоить?
вот не могу без предыстории. если говорить про микросервисную архитектуру аля амазон (в конторе по задачам которой я попытаюсь отобразить свое мнение) (почему аля амазон? — китайцы, которые оказались инвесторами скупили одного из архитекторов амазона). C++. Кстати, там в этих архитектурах, где правильные клауды с виртуалками на концах графа архитектуры, так правильно микросервисными и называются (далее в этом текте). Ну и на завтравку, была задача про миграцию операционной систе.. виртуалки без перезагрузки и остановки работы в одного хоста на другой. Бага больше заключалась в хардварных особенностях проца с юлять знаком который я сейчас уже даже не упомню. мне знаетели как комп. лингвисту не оч оказалось интересно.
Так вот, можете что конкретно вас интересует, с тех пунктов ничего не понял. не указано время ренджа процесса разработки — деплоя
1. time ? — какой тайм, обновление чего и на базе чего?
к примеру есть уровень деплоя на QA уровень? они схожи, но в нашей архитектуре разница была. в целом считаю, что на том проекте раздута архитектура в области тестинга, да и пусть даже ..если они умудрялись в области фронт-енда что-то реализовать в этой области. зачем парсеры на руби, где элементарный json играл бы лучше. Ну то такое
Что касается миграции виртуальной машины, повторю —
1. машина не прекращала работу
2. относительно прозрачна для пользователя ..
ну это область настоящих клауд, на базе микросервисов. что вас интересует — перечислить библиотеки ) либвирт. малтисрединг — intel:) concurent lib, boost::asio etc..
собственно там много еще чего, но все остальное — такое.
клиент серверы, демоны и драйвера в юниксподобных ... а виндоподные были только сервисами и драйверами под виртуалками.
ах да, если вопрос касается безперезагрузочной работы то, максимум чего вы сможете достичь так это обеспечить работу своей систему — если она способна иметь некий слепок себя и с негоже стартануть на другом хосте, с соблюдением всех правил консистентности. иначе эта задача вероятно решается не так как и вижу. ) (а как?). ну в общем виртуалки имеют такую возможность, и это один из способов — запускайте свою архитектуру на честном клауде, и работайте гарантированно без .. стопов.
так вот перевод на малти(микро)сервисы оч зависит от того какую архитектуру переводят. В целом реализованного рефлекшина и немного мозга у решающих задачи — делается относительно недолго. это практически эквивалентно экспоузингу допустим из c\c++ -> (c#|python|objective c|etc...)/ т.е. просто привести архитектуру к масштабируемому виду. где возможно- использовать только мета об архитектуре (пока будете реализовывать масштабируемость должна появиться и мета) ... ну и в добрый и интересный путь.
A>Имеется довольно крупная eCom компания. И, как у многих, у нее архитектура – монолит.
A>Сейчас занялись переходом на микросервисную архитектуру. В микросервисной архитектуре имеется ряд стратегий развертывания.
A>Рассматриваем переход на полноценное канареечное развертывание. Что хочется от системы развертывания:
A>• Бесшовное обновление, без простоя системы и без воздействия на пользователей
A>• Быстрота доставки изменений на рынок (time to market)
A>• Быстрая обратная связь от пользователей при новых релизах
A>• Возможность управлять процентом пользователей, которые будут обслуживаться разными версиями микросервиса, для каждого микросервиса
A>• Простота отката изменений, если что-то пойдет не так
A>• Возможность быстрого масштабирования нагрузки
A>Думаю, многие такое уже пытались делать, интересно, что получилось.
A>Имеется ли у кого успешный опыт перехода на канареечное развертывание? Все ли получилось, что хотелось? Насколько это задевает А/Б тесты? Насколько это трудоемко в разработке, и насколько сложно в поддержке?
A>Сейчас у нас все сервисы в своем датацентре, не в облаке. Подумываю о развертывании своего кластера кубера, чтобы упростить развертывание и поддержку работы системы. Может кто-то делал такое без кубера? Насколько кубер обязателен?
можно пробовать (поговорить) по разному. 1. надо договориться про термины, т.к. был у меня собес, где спросили, а какой один из ключевых компонентов в микросеврсиной архитектуре, .. я долго перечислял, и совсем ослаб внутренне от того, что мне сказали, что логи.
В общем и целом уточним вопросы ? как перевести архитектуру на микросервис? как получалось деплоить?
вот не могу без предыстории. если говорить про микросервисную архитектуру аля амазон (в конторе по задачам которой я попытаюсь отобразить свое мнение) (почему аля амазон? — китайцы, которые оказались инвесторами скупили одного из архитекторов амазона). C++. Кстати, там в этих архитектурах, где правильные клауды с виртуалками на концах графа архитектуры, так правильно микросервисными и называются (далее в этом текте). Ну и на завтравку, была задача про миграцию операционной систе.. виртуалки без перезагрузки и остановки работы в одного хоста на другой. Бага больше заключалась в хардварных особенностях проца с юлять знаком который я сейчас уже даже не упомню. мне знаетели как комп. лингвисту не оч оказалось интересно.
Так вот, можете что конкретно вас интересует, с тех пунктов ничего не понял. не указано время ренджа процесса разработки — деплоя
1. time ? — какой тайм, обновление чего и на базе чего?
к примеру есть уровень деплоя на QA уровень? они схожи, но в нашей архитектуре разница была. в целом считаю, что на том проекте раздута архитектура в области тестинга, да и пусть даже ..если они умудрялись в области фронт-енда что-то реализовать в этой области. зачем парсеры на руби, где элементарный json играл бы лучше. Ну то такое
Что касается миграции виртуальной машины, повторю —
1. машина не прекращала работу
2. относительно прозрачна для пользователя ..
ну это область настоящих клауд, на базе микросервисов. что вас интересует — перечислить библиотеки ) либвирт. малтисрединг — intel:) concurent lib, boost::asio etc..
собственно там много еще чего, но все остальное — такое.
клиент серверы, демоны и драйвера в юниксподобных ... а виндоподные были только сервисами и драйверами под виртуалками.
ах да, если вопрос касается безперезагрузочной работы то, максимум чего вы сможете достичь так это обеспечить работу своей систему — если она способна иметь некий слепок себя и с негоже стартануть на другом хосте, с соблюдением всех правил консистентности. иначе эта задача вероятно решается не так как и вижу. ) (а как?). ну в общем виртуалки имеют такую возможность, и это один из способов — запускайте свою архитектуру на честном клауде, и работайте гарантированно без .. стопов.
так вот перевод на малти(микро)сервисы оч зависит от того какую архитектуру переводят. В целом реализованного рефлекшина и немного мозга у решающих задачи — делается относительно недолго. это практически эквивалентно экспоузингу допустим из c\c++ -> (c#|python|objective c|etc...)/ т.е. просто привести архитектуру к масштабируемому виду. где возможно- использовать только мета об архитектуре (пока будете реализовывать масштабируемость должна появиться и мета) ... ну и в добрый и интересный путь.