Давайте на примере. Сейчас приходиться делать что то типа такого для настройки уровней лоигрования вложенных модулей. Еще и везде propagate ставить что бы не дублировались сбщ.
Допустим у нас 10 версий. В первой addresses1, в последней addresses10 (Каждую версию мы переименовывали поле)
Я правильно понял что так как мы логику пишем под последнюю версию логики, каждый раз нам надо будет во всех предыдущих дописать/поменять VersionChange? А тесты старого API остаются?
А что, VersionChangeWithSideEffects threadlocal? Не вижу что ему что передается.
Не очень понял зачем делать снимки OS, если вы уже пользуетесь контейнерами? В свое время как раз docker смог заменить эту тяжелую технологию. В этом был бы еще смысл если у вас был auto scaling group, но я так понял у вас нет. И вам вроде как и не надо, можно в ручную создать новую vm и пролить на нее все необходимое.
Не сочтите за вброс, я рад что вы разбираетесь в новых технологиях и успешно их внедряете, даря людям стабильность и простоту. Но с точки наблюдателя кажется что вы дорвались да разных модных игрушек :-)
Как пример ваше желание запрыгнуть на kubernetes. Он не рассчитан на пару тройку машин. Выгода от него есть когда у вас есть четкое разделение на отдел поддержки этого kubernetes и много отделов разработки.
По первому алерту видно что началось все с БД. На этом этапе разве не увидили в мониторинге что с БД явно что то не то? Разве не было в cookbook минимальных указаний в какие метрики сломтреть/что делать с БД в этом случае?
У вас нет метрик среднего времени и количество обработанных запросов на backend? Если бы тормозила БД/сервисы то в этих метриках наверное можно было бы увидеть что проблема не в DDOS а в каком то узком горлошке внутри.
Неужели в логах не было кикаких ошибок? Я прям не могу поверить что приложения нигде не чихали и все проглатывали и до последнего момента не было понятно что БД не тянет.
Я правильно понял что основная БД одна без реплик?
Как тогда происходит увеличение CPU? Все останавливается, DODO IS встает колом, и через пару минут начинает оживать? А часто такое делаете? Это обкатаный этап?
Я правильно понял что сначала накинули экземплятров приложений и следом перезагрузили БД? Просто звутит как выстрелить себе в ногу... увеличить нагрузку на БД (которая вроде как и так вышла за алерт) и потом еще ее перезапустить...
Есть причина не использовать. И она весьма серьёзная. В alpine используется musl вместо glibc, что может приводить к случайным падением сервисов на python/jvm/и тд под нагрузкой.
При этом совершенно не понятны плюсы, кроме размера одного базового образа.
Я конечно бесконечно далек от этой области, но мне кажется вы чрезмерно верите в "рынок".
Я полагаю как только какой-нить банк, или любая другая крупная организация, выберет например МЦСТ для закупки процессоров, все остальные покупатели побегут ту да же. Потому что просто экономически выгоднее печатать большими партиями, и можно выбить на этом основании скидку. А еще потому что ПО будет быстрее развиваться силами большой компании. Ну и автоматом это начнет душить Ядро/Байкал, потому что поток инвестиций будет несоизмерим.
Конкурировать надо с внешним рынком, а не с микрошечным внутренним.
Я думаю как раз надо разбивать все на компоненты/процессы и пытаться импортозамешать их потихоньку силами всех локальных компаний. Иначе это возьня на месте.
Вы часом DDD (Data Driven Development) с Domain Driven Design не перепутали? Потому что в докладе «Особенности микросервисов на примере e-Com-платформы / Андрей Евсюков» насколько я помню речь шла про Domain Driven Design.
Давайте на примере. Сейчас приходиться делать что то типа такого для настройки уровней лоигрования вложенных модулей. Еще и везде propagate ставить что бы не дублировались сбщ.
Но у вас я нигде не видел такого в примерах. Просто root handler с одним level и все. Неужели вам этого достаточно?
Подскажите. Как предполагается у вас с root handler настраивать отдельные пакеты по уровню логирования?
Например так: что бы у app.access был warn, на весь app и вложенные пакеты был debug, а на root был info
Спасибо за стать. У меня пару вопросов.
Допустим у нас 10 версий. В первой addresses1, в последней addresses10 (Каждую версию мы переименовывали поле)
Я правильно понял что так как мы логику пишем под последнюю версию логики, каждый раз нам надо будет во всех предыдущих дописать/поменять VersionChange? А тесты старого API остаются?
А что, VersionChangeWithSideEffects threadlocal? Не вижу что ему что передается.
Мне кажется, у вас слишком идеалистическое представление об работе. Жизнь, не железная дорога.
День добрый.
А что за провайдер/хостинг такой что дает вам MsSQL с лицензией? Насколько я слышал для России лицензии закрыли.
Из текста непонятно в итоге где храните логи. Поделитесь?
На всякий случай оставлю тут ссылку на https://keeweb.info/
Не очень понял зачем делать снимки OS, если вы уже пользуетесь контейнерами? В свое время как раз docker смог заменить эту тяжелую технологию. В этом был бы еще смысл если у вас был auto scaling group, но я так понял у вас нет. И вам вроде как и не надо, можно в ручную создать новую vm и пролить на нее все необходимое.
Не сочтите за вброс, я рад что вы разбираетесь в новых технологиях и успешно их внедряете, даря людям стабильность и простоту. Но с точки наблюдателя кажется что вы дорвались да разных модных игрушек :-)
Как пример ваше желание запрыгнуть на kubernetes. Он не рассчитан на пару тройку машин. Выгода от него есть когда у вас есть четкое разделение на отдел поддержки этого kubernetes и много отделов разработки.
Есть еще IVA Technologies - https://iva-tech.ru/catalog/product-iva-mcu/ за номером №5563
Спасибо за разбор. Читать было увлекательно.
Но почти сразу начали возникать вопросики :-)
Не могли бы вы поделиться уточнениями:
По первому алерту видно что началось все с БД.
На этом этапе разве не увидили в мониторинге что с БД явно что то не то?
Разве не было в cookbook минимальных указаний в какие метрики сломтреть/что делать с БД в этом случае?
У вас нет метрик среднего времени и количество обработанных запросов на backend?
Если бы тормозила БД/сервисы то в этих метриках наверное можно было бы увидеть что проблема не в DDOS а в каком то узком горлошке внутри.
Неужели в логах не было кикаких ошибок?
Я прям не могу поверить что приложения нигде не чихали и все проглатывали и до последнего момента не было понятно что БД не тянет.
Я правильно понял что основная БД одна без реплик?
Как тогда происходит увеличение CPU? Все останавливается, DODO IS встает колом, и через пару минут начинает оживать?
А часто такое делаете? Это обкатаный этап?
Я правильно понял что сначала накинули экземплятров приложений и следом перезагрузили БД?
Просто звутит как выстрелить себе в ногу... увеличить нагрузку на БД (которая вроде как и так вышла за алерт) и потом еще ее перезапустить...
Есть причина не использовать. И она весьма серьёзная. В alpine используется musl вместо glibc, что может приводить к случайным падением сервисов на python/jvm/и тд под нагрузкой.
При этом совершенно не понятны плюсы, кроме размера одного базового образа.
Ну гугловая реализация и так на c/c++, но похоже они оч старались.
Может оч надо было обосновать почему надо все перепиасать на какой нить golang ?
Надо помнить что для Python реализация grpc оч тормозная.
Я конечно бесконечно далек от этой области, но мне кажется вы чрезмерно верите в "рынок".
Я полагаю как только какой-нить банк, или любая другая крупная организация, выберет например МЦСТ для закупки процессоров, все остальные покупатели побегут ту да же. Потому что просто экономически выгоднее печатать большими партиями, и можно выбить на этом основании скидку. А еще потому что ПО будет быстрее развиваться силами большой компании. Ну и автоматом это начнет душить Ядро/Байкал, потому что поток инвестиций будет несоизмерим.
Конкурировать надо с внешним рынком, а не с микрошечным внутренним.
Я думаю как раз надо разбивать все на компоненты/процессы и пытаться импортозамешать их потихоньку силами всех локальных компаний. Иначе это возьня на месте.
А авторы случайно не сравнивали скорость/качество сжатия json+zstd vs messagepack+zstd?
Слышал что при сжатии нет особой разницы между текстовыми форматами и бинарными
Почему не воспроизводимой? Собирайте на CI в той же версии image. Или используйте docker multi-stage build.
Есть более правильный способ
А в Dockerfile
А расскажите как вы разрабатываете в docker?
У них есть своя веб морда с чатиками. Вполне годная штука.
Бесплатная версия с их подписью и лимитами.
Вы часом DDD (Data Driven Development) с Domain Driven Design не перепутали? Потому что в докладе «Особенности микросервисов на примере e-Com-платформы / Андрей Евсюков» насколько я помню речь шла про Domain Driven Design.
И если не секрет, какой примерно объем данных в целом.