Имеется довольно крупная eCom компания. И, как у многих, у нее архитектура – монолит.
Сейчас занялись переходом на микросервисную архитектуру. В микросервисной архитектуре имеется ряд стратегий развертывания.
Рассматриваем переход на полноценное канареечное развертывание. Что хочется от системы развертывания:
• Бесшовное обновление, без простоя системы и без воздействия на пользователей
• Быстрота доставки изменений на рынок (time to market)
• Быстрая обратная связь от пользователей при новых релизах
• Возможность управлять процентом пользователей, которые будут обслуживаться разными версиями микросервиса, для каждого микросервиса
• Простота отката изменений, если что-то пойдет не так
• Возможность быстрого масштабирования нагрузки
Думаю, многие такое уже пытались делать, интересно, что получилось.
Имеется ли у кого успешный опыт перехода на канареечное развертывание? Все ли получилось, что хотелось? Насколько это задевает А/Б тесты? Насколько это трудоемко в разработке, и насколько сложно в поддержке?
Сейчас у нас все сервисы в своем датацентре, не в облаке. Подумываю о развертывании своего кластера кубера, чтобы упростить развертывание и поддержку работы системы. Может кто-то делал такое без кубера? Насколько кубер обязателен?
Здравствуйте, andsm, Вы писали:
A>• Бесшовное обновление, без простоя системы и без воздействия на пользователей
В простом случае запускается новый экземпляр, когда на лив и реди чеки отвечать начал — трафик переходит на него, старый тушится. Кубер умеет из коробки. От сервиса нужен только работающий лив и/или реди чек.
С архитектурной точки зрения надо думать про БД. Чтобы миграция между версиями всегда была условно мгновенная и всегда можно было откатить сервис на предыдущую версию без отката БД. В целом это не проблема, но сложные миграции придётся разделять на несколько версий, какие-то изменения, которые бы лочили БД надолго (обновление кучи строк) нужно реализовывать через батч-задачи, которые там по 100 строк будут обрабатывать не мешая остальным и тд.
A>• Быстрота доставки изменений на рынок (time to market)
Тут просто CI/CD. Пришёл пулл-реквест, получил код ревью, смерджился, собрался образ, приехал на стейджинг, прогнались тесты, поехал на прод.
Ну и, конечно, культура разработки. Это самое главное. Чтобы писали код нормально, чтобы код ревью делали нормально, чтобы тесты были и на них можно было бы полагаться. Не должно быть ситуации, когда человек берёт задачу и уходит её делать на два дня. Нужно коммитить условно каждые полчаса и постоянно проводить код-ревью и мердж в основную ветку. Новые фичи должны быть закрыты переключалками и тд.
A>• Быстрая обратная связь от пользователей при новых релизах
Не очень понял, о чём речь. Метрики, a/b тестирование, фич-флаги, это всё известные технологии.
A>• Возможность управлять процентом пользователей, которые будут обслуживаться разными версиями микросервиса, для каждого микросервиса
Кубер умеет.
A>• Простота отката изменений, если что-то пойдет не так
Кубер умеет. Понятно, что откаченная версия должна работать на мигрировавшей базе, про это уже надо думать программистам.
A>• Возможность быстрого масштабирования нагрузки
Кубер умеет. В хорошем облаке масштабировать можно от условного нуля до условной бесконечности. Понятно, что для кубера масштабирование это просто запуск очередного инстанса с сервисом, когда метрики переходят какие-то границы. А будет ли это масштабироваться на практике или всё упрётся в БД — это уже вопрос архитектуры, тут надо своей головой думать.
A>Имеется ли у кого успешный опыт перехода на канареечное развертывание? Все ли получилось, что хотелось? Насколько это задевает А/Б тесты? Насколько это трудоемко в разработке, и насколько сложно в поддержке?
Это всё требует квалифицированной команды девопсов, квалифицированных программистов, больших начальных вложений. Если бюджеты неограничены — так все крупнейшие софтовые компании делают. Если бюджеты ограничены, лучше работать в рамках привычных спринтов и редких релизов, тщательно протестированных (или не тщательно, это уже вам видней).
A>Сейчас у нас все сервисы в своем датацентре, не в облаке. Подумываю о развертывании своего кластера кубера, чтобы упростить развертывание и поддержку работы системы. Может кто-то делал такое без кубера? Насколько кубер обязателен?
Есть альтернативы. Docker Swarm производителем признан устаревшим, но технически он работает. Nomad считается простой альтернативой кубера. У меня опыт только с кубером. По-мне он классный и я бы не советовал его избегать. Это стандарт де-факто, это переносимая технология, она позволяет не привязываться к конкретному облаку. Но требует достаточно глубокого и квалифицированного погружения. Я сам не использовал управляемые кластеры, но скорей всего посоветую именно их, если у вас нет жёсткого требования к хостингу на своих серверах. Если есть — вам потребуется хотя бы небольшая команда хороших специалистов. Альтернативно можете эту работу зааутсорсить, в русском интернете очень часто светится компания Флант, я с ними никогда не взаимодействовал, но они производят впечатление знающих ребят.
Ну и скорей всего на переход потребуется ощутимое время а также трансформация скиллов всех технарей. Рассчитывайте на год-два для миграции и на то, что всем нужно будет изучить хотя бы основы.
Если команда девопсов будет не очень опытная, лучше воздерживаться от того, чтобы тащить в кластер все самые крутые технологии, про которые рассказывают на конференциях, а делать всё максимально дубово и просто, хотя бы пока команда не станет опытная. Кубер штука не такая простая, а навороты там ещё сложней. Всякие istio и прочее. Хотя конечно круто когда можно вплоть до конкретных запросов между сервисами смотреть без какой-либо доработки. Но если оно перестаёт работать, тут будет сложно.
A>Имеется довольно крупная eCom компания. И, как у многих, у нее архитектура – монолит. A>Сейчас занялись переходом на микросервисную архитектуру. В микросервисной архитектуре имеется ряд стратегий развертывания.
Прежде чем думать про стратегию развертывания, сначала надо подумать про самое главное: shared state.
Ключевое различие монолита от микросервисов — хранение и работа с данными. В первую очередь вопросы consistency. Каждый микросервис имеет свою базу данных, и все эти JOIN, FOREIGN KEY и прочие штуки нужно реализовывать врукопашную, с кучей спецэффектов. Равно как и транзакции, и все прочее, что базы данных предлагают из коробки.
Если же вы не планируете разделять состояние, и сервисы все будут по факту работать с одной БД, то это не микросервисы, а все тот же монолит (в БД), просто с разными view на одну и ту же БД.
Здравствуйте, SkyDance, Вы писали:
SD>Прежде чем думать про стратегию развертывания, сначала надо подумать про самое главное: shared state. SD>Ключевое различие монолита от микросервисов — хранение и работа с данными.
Эти вопросы понятно, они и так уже детально проработаны у нас.
Здравствуйте, vsb, Вы писали:
vsb>В простом случае запускается новый экземпляр, когда на лив и реди чеки отвечать начал — трафик переходит на него, старый тушится. Кубер умеет из коробки. От сервиса нужен только работающий лив и/или реди чек.
Это rolling update описан. Канареечное развертывание чуть более сложно. Как технически сделать, вопросов нет, интересен именно опыт внедрения и реального использования.
A>>Имеется ли у кого успешный опыт перехода на канареечное развертывание? vsb>Это всё требует квалифицированной команды девопсов, квалифицированных программистов, больших начальных вложений.
Это понятно. Мы думаем про выделение 1-2 команд devops-ов и программистов на это, выглядит ли достаточным?
vsb> Я сам не использовал управляемые кластеры, но скорей всего посоветую именно их, если у вас нет жёсткого требования к хостингу на своих серверах.
Предыдущую систему, проектировал ее "с нуля", тоже eCom и микросервисы, сначала сделали под частное облако, потом переместили в яндекс-облако. Переход с частного облако в публичное позволил значительно снизить стоимость инфраструктуры.
Но системы имеют ряд существенных отличий, напрямую, без осмысления, опыт переносить нельзя.
Почитал про то, какая часть частных облаков успешна. Как-то не вдохновляет, чуть ли не у 95% те или иные проблемы.
Почитал еще про то, что большинство компаний в наилучшей производительностью труда разработчиков используют облака, причем еще и публичные. Интересно, у нас есть в публичном облаке хоть один из топ20 интернет магазинов?
Здравствуйте, vsb, Вы писали:
vsb>какие-то изменения, которые бы лочили БД надолго (обновление кучи строк) нужно реализовывать через батч-задачи, которые там по 100 строк будут обрабатывать не мешая остальным
А как такое оформляется в техническом плане? В каком виде эти миграции будут лежать в репозитории? "На чём" эти батч-задачи запускать?
Здравствуйте, rosencrantz, Вы писали:
vsb>>какие-то изменения, которые бы лочили БД надолго (обновление кучи строк) нужно реализовывать через батч-задачи, которые там по 100 строк будут обрабатывать не мешая остальным
R>А как такое оформляется в техническом плане? В каком виде эти миграции будут лежать в репозитории? "На чём" эти батч-задачи запускать?
Тут скорей не технический план, а организационный. В техническом плане всё как обычно — ну к примеру миграции в виде SQL-скриптов flyway, батч-задача в виде scheduled или cronjob какой-нибудь или просто на старте приложения пустить отдельный поток и в нём в цикле делать.
Организационный — имеется в виду, что некоторые DDL-скрипты выполняются мгновенно, а некоторые могут лочить базу, в том числе надолго. К примеру добавить nullable столбец в постгресе это мгновенная операция. А создать уникальный индекс это уже лочит таблицу, постгресу же нужно проверить, что данные действительно уникальные. Если таблица крошечная, то никто не заметит, а если не крошечная, то система встанет колом, пока это происходит. У постгреса есть опция CONCURRENTLY которая этот индекс создаёт не блокируя систему, хотя там тоже есть некоторые нюансы. Как добавить non-null столбец я сходу не скажу, но думаю тоже можно. Быстро погуглил, до 11 версии перезаписывалась вся таблица, так что всё сложно было, после 11 версии он научился онлайн это делать.
А если, к примеру, в DDL скрипте будет написано что-то вроде update table set x = null where a = b, и предполаагется, что этот update будет изменять много строк, то понятно, что это может быть тяжёлая операция, она может залочить много строк и система повиснет на это время. Поэтому такой update нужно делать в каком-то виде, чтобы он работал не за раз, а порциями, не оказывая существенного влияния на работающую систему.
В общем тут нужен человек, который разбирается в БД и предварительно тестировать все такие миграции на копии базы с похожими размерами. Какие-то изменения может быть и вовсе не получится сделать таким макаром, хотя я сходу не скажу — какие.
A>Предыдущую систему, проектировал ее "с нуля", тоже eCom и микросервисы, сначала сделали под частное облако, потом переместили в яндекс-облако. Переход с частного облако в публичное позволил значительно снизить стоимость инфраструктуры.
На каком уровне происходило перемещение? Недавно считали стоимость AWS/GCP в сравнении с IaaS от IBM (SoftLayer), и по всем параметрам выходило что рентовать hardware куда дешевле, чем использовать высокоуровневую инфраструктуру (контейнеры, БД и т.п.). Но те расчеты были со своей спецификой (дешевая инженерная сила, не в США).
A>Почитал еще про то, что большинство компаний в наилучшей производительностью труда разработчиков используют облака, причем еще и публичные. Интересно, у нас есть в публичном облаке хоть один из топ20 интернет магазинов?
Скорее всего да, т.к. это позволяет специализироваться на том, что компания делает лучше всего. Сделать хорошее частное облако довольно дорого. Поэтому, если вы его таки сделали, следующий логичный шаг — открыть возможность другим пользоваться вашим частным облаком. Потому и есть все эти AWS/GCP, выросшие из внутренних проектов инфраструктуры. Это позволяет существенно снизить затраты на разработку (не для вас, а для Amazon/Google).
A>Думаю, многие такое уже пытались делать, интересно, что получилось. A>Насколько это задевает А/Б тесты?
Если речь идет о "выкатываем фичу на 10% пользователей в Нигере" vs "выкатываем апдейт на 10% серверов в этом датацентре", то как правило это две ортогональные фичи. И выкатывание новой версии не должно влиять на А/Б эксперимент. В реальности корреляция может существовать (скажем, в новом апдейте сломали gatekeeper и оно вместо 10% нигерийцев обслуживает 100%). Поэтому можно встретить alarms, генерируемые для каждой комбинации "[service version] x [a/b experiment value]". Мне неведомо, смог ли кто-то автоматизировать данный процесс, но допускаю, что где-то это умеют.
A>Насколько это трудоемко в разработке, и насколько сложно в поддержке?
Разработка зависит от платформы. В первую очередь от размеров и разнообразия кодовой базы сервисов, во вторую, — от используемых технологий. Идеальный случай — моно-стек, моно-язык, моно-протокол, и платформа без наследственных болячек. Но это скорее в сказках, а в реальности long tail будет, и вообще не факт, что удастся все автоматизировать. Говоря конкретно, end state будет не "все в облаке", а что-то здесь, что-то там, а что-то и вовсе висит на Васе/John/Xiaotian/Bhupendra. При очередном инциденте будет находиться еще один непортированный кусок. Надо просто к этому быть готовым, и иметь план + guidelines "как это портировать".
Поддержка всегда будет балансом между вложениями в разработку инфраструктуры и development velocity инженерной команды. Чем лучше инфраструктура, чем выше ее SLA, тем меньше времени разработчики будет проводить, тыкая Retry или читая мегатонны не относящихся к проблеме логов. Соотношение между infra/product инженерами — пожалуй, одна из самых интригующих статистик. Встречал разные мнения на эту тему. Кто-то кивает на технологических гигантов (у которых 50% инженеров — инфра), кто-то, напротив, кивает на интернет-магазины, где разработчики порой сами себе инфра. Как правильно, никто не знает, общественное мнение говорит "посмотрите как у успешных конкурентов и делайте так же".
A>Сейчас у нас все сервисы в своем датацентре, не в облаке. Подумываю о развертывании своего кластера кубера, чтобы упростить развертывание и поддержку работы системы. Может кто-то делал такое без кубера? Насколько кубер обязателен?
К глубочайшему сожалению, делал. Поэтому скажу так: если данный вопрос возникает, то кубер — обязателен.
Создать свою систему можно лишь имея богатый опыт работы с чужими, и с пониманием, какие решения и почему были приняты при разработке тех систем. Иначе придется по всем граблям пройти самостоятельно, а потом еще и тащить запаздывающий за кубером софт, учить инженеров им пользоваться, и слышать "на кой ляд мы пользуемся плохо документироанным in-house софтом, если есть хорошо изученный кубер".
Здравствуйте, andsm, Вы писали:
A>Сейчас у нас все сервисы в своем датацентре, не в облаке. Подумываю о развертывании своего кластера кубера, чтобы упростить развертывание и поддержку работы системы. Может кто-то делал такое без кубера? Насколько кубер обязателен?
ИМХО, без кубера будет очень тяжко. Но выше уже все очень хорошо расписали.
Основная Ж в моем опыте — это правильно организовать переход с монолита на микросервисы.
Одно дело, когда нужно построить систему с нуля, а другое, когда нужно постепенно переводить систему с одной архитектуры на другую.
Не знаю, как у вас, но нам пришлось поддерживать и синхронизировать два процесса развертывания, и два процесса тестирования и по-сути даже два процесса разработки.
Основная засада была в базой, пришлось написать много кода, который был потом выкинут. Мотивация программистов — тоже отельная история. Никто не хочет поддерживать старое и унылое, все хотят писать новое и красивое. Возникают трения в коллективе.
И если честно, то у меня до сих нет хорошего ответа, как правильно организовать переход с монолита на микросервисы.
Здравствуйте, 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...)/ т.е. просто привести архитектуру к масштабируемому виду. где возможно- использовать только мета об архитектуре (пока будете реализовывать масштабируемость должна появиться и мета) ... ну и в добрый и интересный путь.
Описанный подход хорошо работает только пока БД содержит малое количество объектов, что обычно и бывает у БД микросервисов. Если объектов много, да еще и куча хранимок и т.п., то переход с версии на версию, с сохранением обратной совместимости, становится сложной задачей.
Здравствуйте, SkyDance, Вы писали:
SD>На каком уровне происходило перемещение? Недавно считали стоимость AWS/GCP в сравнении с IaaS от IBM (SoftLayer), и по всем параметрам выходило что рентовать hardware куда дешевле, чем использовать высокоуровневую инфраструктуру (контейнеры, БД и т.п.). Но те расчеты были со своей спецификой (дешевая инженерная сила, не в США).
Как именно делали, не знаю, это было уже после моего ухода. Исходное облако имело довольно мало функций, наверное, поэтому получилось просто перевести.
Это немного не про то, непрерывная работа виртуалок и тому подобное мне не интересно. В хорошей микросервисной архитектуре падение экземпляра какого-то микросервиса должно быть не аварией, а штатным событием, не оказывающим влияния на пользователя.
Мне интересен реальный опыт проектирования высоконагруженных систем с канареечным развертыванием, были ли какие неожиданные проблемы в части реализации развертывания.
Я такую систему проектировал, но полностью канареечное развертывание там так и не сделали. В этой системе, думаю, это все же будет реализовано.
Здравствуйте, andsm, Вы писали:
A>Здравствуйте, ботаныч, Вы писали:
A>Это немного не про то, непрерывная работа виртуалок и тому подобное мне не интересно.
непрерывность работы виртуалки в (эталонной) микросервисной архитектуре есть лишь критерий того, что очевидно вы называете "не оказывающим влияния на пользователя.", еще часто говорят прозрачно для пользователя. или что вы называете этой фразой ) без-остановочную работу? даже при условиях ошибки? так таки да, так и работают надежные системы. однако, про слепок. а как вы устроите безостановочную работу в условиях деплоя?
A>В хорошей микросервисной архитектуре падение экземпляра какого-то микросервиса должно быть не аварией, а штатным событием, не оказывающим влияния на пользователя.
ага выше.
A>Мне интересен реальный опыт проектирования высоконагруженных систем с канареечным развертыванием, были ли какие неожиданные проблемы в части реализации развертывания.
вот не вижу зависимости от высоконагруженных систем и канареечным развертыванием. по описанию этого термина я понял, что это своего рода слоеный беттатестинг с распределением пользователей на группы , готовых взять на грудь ..новую версию, и не готовых. в моей практике слой QA зачастую играл достаточно сложную партию. и что вы называете высоконагруженными задачами? много людей? или много вычислений?
однако по описанию немного осознал наличие решений в упомянутой мной архитектуре. в нашей системе была compitabilaty модулей работающих в соях архитекуры, в обе стороны — чаще, когда старый модуль должен был понимать? что ему говорит новый. (там соединение может быть как на вебсервисах *(что просо надcтройка для http)) либо же tcp\ip (это к тому, что вы про канареечный деплой больше про вебсервисы).
A>Я такую систему проектировал, но полностью канареечное развертывание там так и не сделали. В этой системе, думаю, это все же будет реализовано.
я повторю вопрос, что актуальнее
— перевод на микросервисы какого нить легаси
— или развертывание ? второе кажется существенно проще ...
A>В хорошей микросервисной архитектуре падение экземпляра какого-то микросервиса должно быть не аварией, а штатным событием, не оказывающим влияния на пользователя.
Технологически это невозможно, в силу CAP. Пользователь все равно заметит. Либо потому, что потребуется перезапустить какую-то операцию (которая приземлилась на этот экземпляр, и была невосстановимо утеряна), либо операция займет существенно больше обычного (latency), если реализованы всякие там retry loop (тоже спорный вопрос, на каком уровне хорошо иметь retry, но по факту они есть почти везде).
Скорее, вопрос ставится как "не выйти за границы SLA", т.е. "не более чем N failed requests" и "не выше XX секунд среднего времени исполнения запроса". Конкретные пользователи все равно будут задеты, но в общем и целом оно как бы работает.
Беда с этими системами в том, что такой подход зачастую маскирует и реальные проблемы (особенно если SLA очень расслабленые). Но это вопрос цены/качество.
Здравствуйте, SkyDance, Вы писали:
A>>В хорошей микросервисной архитектуре падение экземпляра какого-то микросервиса должно быть не аварией, а штатным событием, не оказывающим влияния на пользователя.
SD>Технологически это невозможно, в силу CAP.
мсье говорит про клауд, и говорит (практически оретъ), что ему не надо виртуалок .. надо понимать, что клауд это — хардварно-софтверное решение, где хардвар складывается как ЛЕГО, хард-диск контроллеры, контроллеры памяти берется с шасси (стойки) в общем, берется покупаемое клиентом железо, и в целях оптимизации на нем стартуех гипервизор, что необходимо, чтобы стартануть виртуалку, то что вы наблюдаете в виде ssh \ terminal service и прочая есть — виртуалка на концах архитектуры.
так вот прозрачная миграция виртуалок — объективная реальность. соостветственно отсюда и могут идти отправные точки для имплементора майкросрвисес, тупо ждать нужны чаннел, и сомтреть когда эта — миграция свершилась (синхронизация етц, дабы было понятно почему это возможно), потому опираясь на эти реперные точки мсье мг бы получить что ему хотелось, но мсье не надо виртуалок .. кошмар
SD>Пользователь все равно заметит. Либо потому, что потребуется перезапустить какую-то операцию (которая приземлилась на этот экземпляр, и была невосстановимо утеряна), либо операция займет существенно больше обычного (latency), если реализованы всякие там retry loop (тоже спорный вопрос, на каком уровне хорошо иметь retry, но по факту они есть почти везде).
сбой — штатная ситуация, кто сказал, что его не должно быть видно? разве, что "сбой" технологический аля неудавшаяся операция вставки в локфри, если не удалось — пусть продолжит THREAD-помогатель, либо запустим второй раз.
SD>Скорее, вопрос ставится как "не выйти за границы SLA", т.е. "не более чем N failed requests" и "не выше XX секунд среднего времени исполнения запроса". Конкретные пользователи все равно будут задеты, но в общем и целом оно как бы работает.
SD>Беда с этими системами в том, что такой подход зачастую маскирует и реальные проблемы (особенно если SLA очень расслабленые). Но это вопрос цены/качество.
а вы можете расшифровывать SLA SLAMrequest вы-же тут не читаете?
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, andsm, Вы писали:
vsb>С архитектурной точки зрения надо думать про БД. Чтобы миграция между версиями всегда была условно мгновенная и всегда можно было откатить сервис на предыдущую версию без отката БД. В целом это не проблема, но сложные миграции придётся разделять на несколько версий, какие-то изменения, которые бы лочили БД надолго (обновление кучи строк) нужно реализовывать через батч-задачи, которые там по 100 строк будут обрабатывать не мешая остальным и тд.
Нее, миграции в БД надо делать несколько иначе.
Ну и приложения должны уметь работать с разными "версиями" БД, иначе не бывает.
A>>• Быстрота доставки изменений на рынок (time to market)
vsb>Тут просто CI/CD. Пришёл пулл-реквест, получил код ревью, смерджился, собрался образ, приехал на стейджинг, прогнались тесты, поехал на прод.
Это не всегда оптимальная стратегия, так как предполагает не TBD, а Gitflow, что больно.
А если такое делать с TBD, то нужно еще фичафлагами управлять.
A>>• Возможность управлять процентом пользователей, которые будут обслуживаться разными версиями микросервиса, для каждого микросервиса
vsb>Кубер умеет.
А где это кубер это умеет? Это умеет делать какой-нибудь istio, но в кубере нет поддержки балансировки пользователя в зависимости от выложенной версии.
A>>• Возможность быстрого масштабирования нагрузки
vsb>Кубер умеет. В хорошем облаке масштабировать можно от условного нуля до условной бесконечности. Понятно, что для кубера масштабирование это просто запуск очередного инстанса с сервисом, когда метрики переходят какие-то границы. А будет ли это масштабироваться на практике или всё упрётся в БД — это уже вопрос архитектуры, тут надо своей головой думать.
Обычно автоматическое масштабирование скорее опасно, чем полезно.
Здравствуйте, andsm, Вы писали:
A>Имеется довольно крупная eCom компания. И, как у многих, у нее архитектура – монолит.
Как всегда, надо бы понять, какие нефункциональные требования, сколько железа используется (1 сервер, 10 серверов, 100 серверов),
как планируется расти.
В среднем, для ecom микросервисы вообще не очень нужны, достаточно реализовать несколько монолитов по доменам.
A>Думаю, многие такое уже пытались делать, интересно, что получилось.
Делал, несколько раз.
A>Имеется ли у кого успешный опыт перехода на канареечное развертывание? Все ли получилось, что хотелось? Насколько это задевает А/Б тесты? Насколько это трудоемко в разработке, и насколько сложно в поддержке?
Канарейка — довольно сложно в создании (нужен один вменяемый архитектор продукта и два-три вменяемых опса, и тех и других практически не бывает в природе), не очень трудоемко в разработке (если понимать, что делать), требует аккуратности от всей разработки (это самое сложное).
Во многих реальных случаях проще сделать на каком-нибудь конге, нежели поднимать системы оркестрации, но зависит от нагрузки (впрочем, в ecom она небольшая).
A>Сейчас у нас все сервисы в своем датацентре, не в облаке. Подумываю о развертывании своего кластера кубера, чтобы упростить развертывание и поддержку работы системы. Может кто-то делал такое без кубера? Насколько кубер обязателен?
Кубер нужен если нужно поддерживать сотню и более серверов, тысячи сервисов и нужна изоляция опсов от разработки.
Если команда не очень большая и нет ненависти между опсами и разработкой, то кубер не очень нужен, так как реально покрывает очень небольшую часть реально важной функциональности. При этом нормальная эксплуатация своего кубера — очень непростая штука.
Впрочем, раз у вас только один ДЦ, то надежность вам не очень важна, так что может и кубер, поставленный без опыта — тоже сойдет. Ну полежите несколько дней в первые полгода...
Кстати, к куберу еще придется придумывать сторадж, а ceph — тоже штука крайне неприятная.
Здравствуйте, Дельгядо Филипп, Вы писали:
vsb>>С архитектурной точки зрения надо думать про БД. Чтобы миграция между версиями всегда была условно мгновенная и всегда можно было откатить сервис на предыдущую версию без отката БД. В целом это не проблема, но сложные миграции придётся разделять на несколько версий, какие-то изменения, которые бы лочили БД надолго (обновление кучи строк) нужно реализовывать через батч-задачи, которые там по 100 строк будут обрабатывать не мешая остальным и тд.
ДФ>Нее, миграции в БД надо делать несколько иначе.
Как?
A>>>• Возможность управлять процентом пользователей, которые будут обслуживаться разными версиями микросервиса, для каждого микросервиса
vsb>>Кубер умеет.
ДФ>А где это кубер это умеет? Это умеет делать какой-нибудь istio, но в кубере нет поддержки балансировки пользователя в зависимости от выложенной версии.
Ну да, формально это дополнительный компонент. И там всего одна дополнительная версия возможна.
A>>>• Возможность быстрого масштабирования нагрузки
vsb>>Кубер умеет. В хорошем облаке масштабировать можно от условного нуля до условной бесконечности. Понятно, что для кубера масштабирование это просто запуск очередного инстанса с сервисом, когда метрики переходят какие-то границы. А будет ли это масштабироваться на практике или всё упрётся в БД — это уже вопрос архитектуры, тут надо своей головой думать.
ДФ>Обычно автоматическое масштабирование скорее опасно, чем полезно.
