Очень может быть. Тем более что чем разнообразней паттерны работы с данными в рамках одной БД, тем сложнее ее готовить. Хотя может это только у меня так.
Все так, и мы его потом реплицировали, и кеши сделали распределенными. Повысили и производительность и отказоустойчивость. Но все это было потом, после того как я получил бесценный опыт.
Ну лично мне больше всего запомнился сгоревший БП у сервера на котором монолит хостился, не зря тут картинка с лодкой.. SSH на телефоне и редактирование конфигов в vim'е с помощью экранной клавиатуры с чуть живым мобильным интернетом - это развлечение очень на любителя.
Монолит, особенно нормально поделенный на домены, это вполне себе нормальное решение если команда разработки не особо большая и не нужно много думать о масштабируемости. Но когда команд много или они большие, выдерживать границы в пределах монолита становится сложно. Ну и единственная база все же весьма часто становится узким горлышком, так что приходится идти на компромиссы и выбирать с чем смиряться.
Ссылку на статистику, плз. Распределённые обычно используются, если памяти на одном сервере не хватает. Для всего остального они мало полезны.
При использовании локальных кешей в конфигурации с больше чем одним инстансом, мы получаем увлекательное приключении по обеспечению их непротиворечивости. Плюс их надо греть после каждого рестарта сервиса. Уже эти два момента добавляют полезности распределенным кешам. Но, конечно, это не серебряная пуля. В минусах - дополнительные ресурсы и еще одна тока отказа. Хотя второе обычно нивелируется возможностью запустить тот же редис в режиме кластера.
На клиентской стороне сделать балансировщик - религия не позволяет?
Балансировку на клиентской стороне конечно можно добавить, но она оправдывает себя не во всех сценариях. Например балансир на входе в кластер может осуществлять терминацию tls, а внутренние микросервисы вообще не доступны извне.
ээээ .... а готовность приверить до регистрации инстанса ваша инфраструктура не позволяет? В кубернетисе это как бы из коробки
Я тут немного про другое, про пробы я как раз отдельно писал, они нужны в любом случае. Но чем они помогут, если мы уже не справляемся с трафиком, а новым инстасам требуется несколько минут чтобы стать готовыми к принятию трафика?
Ну наконец-то! Хоть что-то вы делаете разумное.
Спасибо :)
Ничего не снижается. Есть такая штука, теория надёжности называется. Чем больше компонентов - тем менее надёжна система. Вы переносите с больной головы на здоровую подменяете одну точку отказа 2-мя точками отказа.
Согласен, EDD в целом тема довольно холиварная, а системы на его основе сложнее и в разработке и в отладке. Я, конечно, хожу тут по тонкому льду, но при наличии надежной шины, мы перекладываем на нее часть ответственности. Например, если нужно доставить сообщение от A к B, то при недоступности B, при синхронном обмене нужно будет реализовывать повторные отправки и персистенс в A. При наличии шины, A отправит сообщение и забудет про него, а B прочитает его когда вновь станет доступен. Опять же, рецепт не универсальный и со своими подводными камнями, но связность тут явно меньше, как мне кажется.
С чего это вдруг? Вообще-то они используют тот же самый TCP.
Конечно используют, но в той же кафке из коробки есть и репликация и гарантии доставки. Может я тут не очень ясно свою мысль донес, тут не про протокол, а про весь механизм обмена.
Так значит, SQL базы не обеспечивают горизонтального масштабирование, а NoSQL - надёжности? Ну надо же! Век живи - век учись!
Каюсь, слишком упростил, тем более в такой теме... Но CAP теорему в любом случае нужно держать в голове, все же SQL и NoSQL относятся к разным классам и обеспечиваю несколько разные характеристики.
Да, есть еще хаос инжиниринг, как например в Netflix, где Chaos Monkey ломает всякое нужное в неожиданный момент. Мне всегда такое было интересно, но, к сожалению, попробовать не довелось.
Про планы полностью согласен, в Альфе такое есть, как и деление систем по классам критичности, чем он выше, тем больше требований к самим системам так и к disaster recovery.
Анализ инцидентов - само собой, с изменениями в тестах и т.д. А еще я люблю результаты разбора в личную базу знаний и извлеченных уроков вносить, мало ли где еще с таким столкнешься.
Не совсем, устав это не технического задание, это краткое описание целей и рисков проекта, критериев его успешности + грубые прикидки сроков, бюджетов и основных вех + выбор руководителя проекта (ответственное лицо).
Техническое задание и технические требования это уже содержание проекта (по PMI). Оно куда более подробное и для его составления привлекаются члены проектной команды (устав пишется целиком спонсором или, что куда чаще, будущим руководителем проекта).
А статья про важность системного подхода в проектной деятельности, иначе «без внятного ТЗ результат ХЗ», а виновата будет разработка…
Очень может быть. Тем более что чем разнообразней паттерны работы с данными в рамках одной БД, тем сложнее ее готовить. Хотя может это только у меня так.
Все так, и мы его потом реплицировали, и кеши сделали распределенными. Повысили и производительность и отказоустойчивость. Но все это было потом, после того как я получил бесценный опыт.
Ну лично мне больше всего запомнился сгоревший БП у сервера на котором монолит хостился, не зря тут картинка с лодкой.. SSH на телефоне и редактирование конфигов в vim'е с помощью экранной клавиатуры с чуть живым мобильным интернетом - это развлечение очень на любителя.
Монолит, особенно нормально поделенный на домены, это вполне себе нормальное решение если команда разработки не особо большая и не нужно много думать о масштабируемости. Но когда команд много или они большие, выдерживать границы в пределах монолита становится сложно. Ну и единственная база все же весьма часто становится узким горлышком, так что приходится идти на компромиссы и выбирать с чем смиряться.
При использовании локальных кешей в конфигурации с больше чем одним инстансом, мы получаем увлекательное приключении по обеспечению их непротиворечивости. Плюс их надо греть после каждого рестарта сервиса. Уже эти два момента добавляют полезности распределенным кешам. Но, конечно, это не серебряная пуля. В минусах - дополнительные ресурсы и еще одна тока отказа. Хотя второе обычно нивелируется возможностью запустить тот же редис в режиме кластера.
Балансировку на клиентской стороне конечно можно добавить, но она оправдывает себя не во всех сценариях. Например балансир на входе в кластер может осуществлять терминацию tls, а внутренние микросервисы вообще не доступны извне.
Я тут немного про другое, про пробы я как раз отдельно писал, они нужны в любом случае. Но чем они помогут, если мы уже не справляемся с трафиком, а новым инстасам требуется несколько минут чтобы стать готовыми к принятию трафика?
Спасибо :)
Согласен, EDD в целом тема довольно холиварная, а системы на его основе сложнее и в разработке и в отладке. Я, конечно, хожу тут по тонкому льду, но при наличии надежной шины, мы перекладываем на нее часть ответственности. Например, если нужно доставить сообщение от A к B, то при недоступности B, при синхронном обмене нужно будет реализовывать повторные отправки и персистенс в A. При наличии шины, A отправит сообщение и забудет про него, а B прочитает его когда вновь станет доступен. Опять же, рецепт не универсальный и со своими подводными камнями, но связность тут явно меньше, как мне кажется.
Конечно используют, но в той же кафке из коробки есть и репликация и гарантии доставки. Может я тут не очень ясно свою мысль донес, тут не про протокол, а про весь механизм обмена.
Каюсь, слишком упростил, тем более в такой теме... Но CAP теорему в любом случае нужно держать в голове, все же SQL и NoSQL относятся к разным классам и обеспечиваю несколько разные характеристики.
Да, есть еще хаос инжиниринг, как например в Netflix, где Chaos Monkey ломает всякое нужное в неожиданный момент. Мне всегда такое было интересно, но, к сожалению, попробовать не довелось.
Про планы полностью согласен, в Альфе такое есть, как и деление систем по классам критичности, чем он выше, тем больше требований к самим системам так и к disaster recovery.
Анализ инцидентов - само собой, с изменениями в тестах и т.д. А еще я люблю результаты разбора в личную базу знаний и извлеченных уроков вносить, мало ли где еще с таким столкнешься.
Техническое задание и технические требования это уже содержание проекта (по PMI). Оно куда более подробное и для его составления привлекаются члены проектной команды (устав пишется целиком спонсором или, что куда чаще, будущим руководителем проекта).
А статья про важность системного подхода в проектной деятельности, иначе «без внятного ТЗ результат ХЗ», а виновата будет разработка…
launchpad.net/~nrbrtx/+archive/ubuntu/xorg-hotkeys