не херь а крайности

именно херь

речь идет о банальной backward/forward compatibility

так и я про то

так и я про то

нет, ты про версии. У меня нет версий. У меня есть совместимость старого и нового кода

ты всегда между деплоями сохраняешь обратную совместимость (это значит, что все контракты и схема у тебя поддерживается)

нет, ты про версии. У меня нет версий. У меня есть совместимость старого и нового кода

ты говоришь что ты ты ее "гарантируешь любой ценой"

а если у тебя задачи в очереди месяцами могут висеть - ну твои проблемы.

а я говорю что можно придумать задачу когда это дорого

можно, вот когда ты придумаешь такую задачу - тогда поговорим)

только не про абстрактный коней а конкретные условия

сильвер булетов нету.

ну скажем подготовка данных для мобильного приложения

а у мобильных рахные версии

Все у кого есть затяжной проект на PHP! Ищу одиночек таких же как я, или мини тимы Хочу работать командой, что бы закрыть все затяжные проекты у каждого. Те у кого все хорошо, но есть желание поработать в новой команде и потренировать лидерство, присоединяйтесь. Будете учавствовать в качестве ведущих разрабов! Как вам такая акция?

причем возможно у 1 юзера разные версии на разных устройствах

ну придется обратную совместимость для мобильников суппортитть столько сколько нужно

сколько нужно -> сколько посчитает бизнес. У меня например это пол года

ну придется обратную совместимость для мобильников суппортитть столько сколько нужно

и происходит пересечение кода и версий.

и происходит пересечение кода и версий.

не происходит

и приходится физически менять старый код под новые миграции

тадааам

у тебя ж мобильники - ты НЕ можешь там ничего менять сам

нет контроля

именно

и в сухом остатке у тебя очереди старых и новых версий с новой базой

что именно? посто через пол года гарантии исчещают. Мы на совсем стремные случаи еще форс апдейт делаем который через 4 месяца например придупреждает юзера что "чел, обновись"

причем накатывающиеся все новым и новым слоем

и в сухом остатке у тебя очереди старых и новых версий с новой базой

у тебя как-то все смешалось. Причем тут база? у тебя мобильники в базу лазиют?

что именно? посто через пол года гарантии исчещают. Мы на совсем стремные случаи еще форс апдейт делаем который через 4 месяца например придупреждает юзера что "чел, обновись"

так я согласен

сам же попросил :)

у тебя как-то все смешалось. Причем тут база? у тебя мобильники в базу лазиют?

воркеры же

у тебя как-то все смешалось. Причем тут база? у тебя мобильники в базу лазиют?

вообще твоИ ПРЕДСТАВЛЕНИЯ О КОЛЛЕГАХ НЕМНОГО ПУГАЮТ :)

воркеры же

воркеры как к этому относятся? ты ж их контролируешь. А стало быть и проблемы нет

еще раз - ситуации когда ты НЕ контролируешь код - это классика. Помимо мобильных приложений есть еще SDK, десктопный софт.

ну смотри - версии мобильных на вход - неважнокакойответ + воркеры которые должны что-то вернуть - воркеры работают всегда с новой базой - возврат в разных версиях черезщ пуш

обычно там больше проблема не структуры данных (можно отдельный гейтвей для совместимости запилить) а с совместимостью бизнес логики

я вообще нить потерял) короче вопросы выписал, постараюсь раскрыть. вопрос с утечками самый сложный, тут хз как проговорить даже.

из этого не слежует что нельзя поддерживать принцип совместимость в обе стороны

обычно там больше проблема не структуры данных (можно отдельный гейтвей для совместимости запилить) а с совместимостью бизнес логики

и бизнес и базы

ну смотри - версии мобильных на вход - неважнокакойответ + воркеры которые должны что-то вернуть - воркеры работают всегда с новой базой - возврат в разных версиях черезщ пуш

мобильники вообще никак не зависят от базы данных

...

ок

инкапсуляция и все такое, если я колонку в базе переименовал - то скорее всего я поправлю код в одном месте а весь остальной код останется не изменным

это никак не повлияет на структуры данных которые ходят между сервисами или там между клиентом и сервером

(обычно я не колонки переименовываю, а таблицы разделяю. Типа колонка была в таблице А а я ее в отдельную таблицу вынес что бы можно было в отдельный сервис потом вынести)

ты куда-то не туда уехал

вопрос кто ставит очереди

какие к черту очереди?)

легаси код или как и база всегда только новый

и ты не можешь сказать - ну окей, очереди ставят новый код

у тебя уже 100500 очередей разных версий возможно даже не двух

у тебя уже 100500 очередей разных версий возможно даже не двух

у меня нет версий

еще раз

не явных

а по структуре

не в ерсия 123

О каких очередях-то речь?

просто старые и новые

я тож хз...

я тож хз...

ты сам попросил придумать ситуацию :)

не явных

ты о формате сообщений? а очереди - это типа брокер сообщений для общения между клиентом и сервером?

ты сам попросил придумать ситуацию :)

ну у тебя пока плохо получается эту ситуацию сформулировать.

ты о формате сообщений? а очереди - это типа брокер сообщений для общения между клиентом и сервером?

речь была про воркеры

задачи в очередях

с каким-то набором вводных данных

речь был о демонах, а не воркерах и очередях

это вопервых

fpm?

во вторых нет абсолютно никакой разницы в том как это хэндлить, очереди у тебя или http

fpm?

демоны, представь что у тебя пых не умирает и у тебя там вообще модель экторов

ловишь sigterm, доделываешь дела и новые задачи перестаешь обрабатывать, закончил и умер. А рядом поднимается новый воркер который уже новые задачки обрабатывает

^

Ну есть в брокере 100500 сообщений, что дальше? Где разница между полученным хттп запросом и сообщением из очереди?

мне по бизнесс логике совсем просто: если там даунтайм будет минут в 5 - всем похеру. Воркерам только придётся потом постараться. в целом, zero downtime для демонов - имхо излишне. Это фоновая обработка всё же, а она как бы ничего не гарантирует

^

^

окей, "новые задачи" замени на "новые запросы"

либо рестарт воркера автоматический по изменению исходников (что бы разрабатывать удобнее). Ну и да - деплой без даунтайма это будет полезно. Как и блу грин деплой. Но думаю что ты не покроешь эти вопросы в своем докладе

^

вобщем, не важно :)

я лишь сказал о том что не все так просто и есть куда оверинженерить

^

короч.... поправь меня если я неправильно понимаю о чем ты: - у нас есть клиент и сервер которые общаются как-то (очереди, http - не важно). - у нас есть код, который обрабатывает задачи - у нас есть код который паблишит задачи И вопрос в том что: - как хэндлить изменения кода который обрабатывает запросы, в ситуациях когда у тебя есть контроль за кодом и клиентов и серверов и рассинхрон по обновлениям всегда небольшой (до недели) - как хэндлить изменения кода который обрабатывает запросы, в ситуациях когда у тебя нет контроля за кодом который паблишит задачи и он может обновиться только через год

так?

в целом - все это про обратную совместимость, а не про миграции и уж тем более не про демоны.

иногда проще зашедулить релиз на определенный день, и тогда на какое-то время чтобы был доступен даунт тайм, чтобы потушить все зависимые сервисы от схемы, сделать миграцию и потом дальше пустить

и так выйдет дешевле чем делать совместимость

в общем по ситуации надо смотреть

так?

есть еще возврат асинхронный клиенту

есть еще возврат асинхронный клиенту

ну это не столь важно

там тоже версии

бля откуда ты версии родил?

то что ты описал по сути щина api call

просто совместимость на уровне структур данных и бизнес процессов

то что ты описал по сути щина api call

ты чето все усложняешь добавляя не нужные детали

разница большая

шина она горячая в 1 очередь

а в брокере очередей могут быть условные рассылки которые неделю работают

но структуры данных же совместимы

какая функция добавит в конец массива элементы другого массива?

в чем проблема?

какая функция добавит в конец массива элементы другого массива?

то есть тебе надо склеить два массива? добро пожаловать в гугл

в чем проблема?

в брокере очередей накапливаются задачи созданные разными версиями и несущие разные данные на одну и ту же задачу, например

в брокере очередей накапливаются задачи созданные разными версиями и несущие разные данные на одну и ту же задачу, например

ну ок, структуры данных совместимы

нет проблемы