Отключен был дроплет полностью от сети, доступ только из консоли DO, можно сделать все что вы перечислили, но
п. 3. Дроплет и так был под cloud firewall, но ведь порт открыт? весь трафик проходит
п. 5 Cloudflare предоставляет бесплатную защиту от DDOS для HTTP/S трафика, от UDP Flood у них есть платный инструмент, стоимость которого исчисляется в тысячах $.
ничего не мешает злоумышленнику направить трафик на новый IP адрес и также увести его в черную дыру
Одной из рекомендаций DO было добавить всех валидных клиентов на их cloud firewall. Но это невозможно для нашего кейса (онлайн игра) Т.е. я полагаю канал у них достаточный, а отрубило в первый раз на атаке 500Mb/s. Это кхм кхм, очень низкий показатель для DDOS. Я бы сказал лучше если бы не пострадал никто ) И я очень надеялся что таким гигантам как DO подобные вещи не страшны, потому и выбрал их первоначально как хостинг
Отталкиваясь от того что репа со скриптами одна, значит речь идет о монолите, а много разработчиков планируют работать с такой репой? Запуск на каждый коммит без ревью грозит огромным количеством исправлений и косяков, любой скрипт джуна наворотит делов, (несоответствие принятым в компании стандартам, некорректные типы и размероость полей и т п.) , также как решаете проблему, при которой разраб ставит дефолт велью на новую колонку в таблице с 1ккк записей и это все вешает вам весь прод на несколько часов локом таблицы?
Неужели этот чудо зашифрованный вирус имеет хоть какой-то шанс запуститься на компьютере пользователя с дефолтно настроенным виндоус дефендером? Который иногда легальный то софт блокирует. Или это как раз работает как по маслу из-за того что вирус написан на .Net? Грустновато видеть обратную тенденцию в той сфере, где всегда ценилась изобретательность и низкроуровневый кодинг и высокий скилл :)
Если стоит вопрос, экономить ресурсы или нет, я обычно выбираю экономить. В своей практике периодически сталкиваюсь с OOM, и в долгосрочной перспективе выбираю оптимизацию и рефакторинг вместо "завалить железом". Не считаю удачной идеей в 5000 потоков опрашивать микросервисы, когда могу сделать это с помощью 1. Не считаю удачной идеей открывать 5000 коннектов к базе. Считаю что разработчик должен полностью контролировать ресурсы, которые использует его приложение. Создание потока, операция затратная, также существует понятие context switch. Сталкивался с ситуациями когда при большой нагрузке веб-сервер начинает реджектить запросы, упирается в лимиты сессий. Сталкивался с ситуациями когда система теряет стабильность из-за того что один микросервис выходит из под контроля, превышая разумные рамки по созданию файловых дескрипторов. Считаю что если приложение работает используя 5000 потоков, или даже 1000 потоков, то с ним что-то не в порядке, пока в своем опыте не встречал необходимости так тратить ресурсы.
Реактор развивается и обновляется, не вижу с этим каких-либо проблем. Возможно, он не взлетает в Ваших проектах, у нас взлетел.
Вечер добрый, конкретно мы, используем реактор, потому что перед нами стоит задача по разработке системы, которая обрабатывает десятки миллионов транзакций в день, десятки тысяч отчетов, платежных документов и всего сопутствующего. Я не агитирую всех и каждого начать использовать реактор по любому поводу и без. В этой статье я описал ряд проблем и решений, с которыми мы сталкивались и боролись в нашей команде. Надеюсь это сэкономит время и силы другим разработчикам. Реактор позволяет бережно использовать потоки, из коробки дает некоторые интересные возможности, retry / backpressure / cancel обработчики и т.п. Удачно подходит для микросервисной архитектуры. Код кажется write-only, нечитаемым, одноразовым, потому что здесь происходит смена парадигмы программирования. Императивное -> Функциональное -> Реактивное. Для тех кто работает с реактором достаточное количество времени, все выглядит вполне "maintainable".
Вот небольшая цитата, достаточно полно описывающая зачем нужно реактивное программирование.
Compared to traditional imperative and functional programming, reactive programming requires a mindset-shift in order to apply the concepts and techniques effectively. The benefits we gain support us in some key challenges that every engineer is facing with essentially every (micro-) service in today’s backend architectures: handling of blocking IO, backpressure, managing highly varying loads as well as message and error propagation.
Осмелюсь возразить, в настоящий момент успешно разрабатываем и поддерживаем 40 микросервисов в проекте :) Spring Boot + Kotlin + Reactor, новые разработчики проходят стадию отрицания при знакомстве с реактором, но потом всем начинает нравиться, когда понимают как его правильно готовить. Проводим периодические семинары и обучение внутри команды.
Дает текущее значение счетчика, которое будет равно количеству одновременно существующих (параллельных) задач в реакторе на конкретный момент когда был сделан get(), удобно мониторить текущее состояние
Отключен был дроплет полностью от сети, доступ только из консоли DO, можно сделать все что вы перечислили, но
п. 3. Дроплет и так был под cloud firewall, но ведь порт открыт? весь трафик проходит
п. 5 Cloudflare предоставляет бесплатную защиту от DDOS для HTTP/S трафика, от UDP Flood у них есть платный инструмент, стоимость которого исчисляется в тысячах $.
ничего не мешает злоумышленнику направить трафик на новый IP адрес и также увести его в черную дыру
Одной из рекомендаций DO было добавить всех валидных клиентов на их cloud firewall. Но это невозможно для нашего кейса (онлайн игра) Т.е. я полагаю канал у них достаточный, а отрубило в первый раз на атаке 500Mb/s. Это кхм кхм, очень низкий показатель для DDOS. Я бы сказал лучше если бы не пострадал никто ) И я очень надеялся что таким гигантам как DO подобные вещи не страшны, потому и выбрал их первоначально как хостинг
Отталкиваясь от того что репа со скриптами одна, значит речь идет о монолите, а много разработчиков планируют работать с такой репой? Запуск на каждый коммит без ревью грозит огромным количеством исправлений и косяков, любой скрипт джуна наворотит делов, (несоответствие принятым в компании стандартам, некорректные типы и размероость полей и т п.) , также как решаете проблему, при которой разраб ставит дефолт велью на новую колонку в таблице с 1ккк записей и это все вешает вам весь прод на несколько часов локом таблицы?
Неужели этот чудо зашифрованный вирус имеет хоть какой-то шанс запуститься на компьютере пользователя с дефолтно настроенным виндоус дефендером? Который иногда легальный то софт блокирует. Или это как раз работает как по маслу из-за того что вирус написан на .Net? Грустновато видеть обратную тенденцию в той сфере, где всегда ценилась изобретательность и низкроуровневый кодинг и высокий скилл :)
Прелесть статьи в том, что ее можно перечитать :) задайте конкретные вопросы, что не понятно, попробуем разобраться
Если стоит вопрос, экономить ресурсы или нет, я обычно выбираю экономить. В своей практике периодически сталкиваюсь с OOM, и в долгосрочной перспективе выбираю оптимизацию и рефакторинг вместо "завалить железом". Не считаю удачной идеей в 5000 потоков опрашивать микросервисы, когда могу сделать это с помощью 1. Не считаю удачной идеей открывать 5000 коннектов к базе. Считаю что разработчик должен полностью контролировать ресурсы, которые использует его приложение. Создание потока, операция затратная, также существует понятие context switch. Сталкивался с ситуациями когда при большой нагрузке веб-сервер начинает реджектить запросы, упирается в лимиты сессий. Сталкивался с ситуациями когда система теряет стабильность из-за того что один микросервис выходит из под контроля, превышая разумные рамки по созданию файловых дескрипторов. Считаю что если приложение работает используя 5000 потоков, или даже 1000 потоков, то с ним что-то не в порядке, пока в своем опыте не встречал необходимости так тратить ресурсы.
Реактор развивается и обновляется, не вижу с этим каких-либо проблем. Возможно, он не взлетает в Ваших проектах, у нас взлетел.
Вечер добрый, конкретно мы, используем реактор, потому что перед нами стоит задача по разработке системы, которая обрабатывает десятки миллионов транзакций в день, десятки тысяч отчетов, платежных документов и всего сопутствующего. Я не агитирую всех и каждого начать использовать реактор по любому поводу и без. В этой статье я описал ряд проблем и решений, с которыми мы сталкивались и боролись в нашей команде. Надеюсь это сэкономит время и силы другим разработчикам. Реактор позволяет бережно использовать потоки, из коробки дает некоторые интересные возможности, retry / backpressure / cancel обработчики и т.п. Удачно подходит для микросервисной архитектуры. Код кажется write-only, нечитаемым, одноразовым, потому что здесь происходит смена парадигмы программирования. Императивное -> Функциональное -> Реактивное. Для тех кто работает с реактором достаточное количество времени, все выглядит вполне "maintainable".
Вот небольшая цитата, достаточно полно описывающая зачем нужно реактивное программирование.
Осмелюсь возразить, в настоящий момент успешно разрабатываем и поддерживаем 40 микросервисов в проекте :) Spring Boot + Kotlin + Reactor, новые разработчики проходят стадию отрицания при знакомстве с реактором, но потом всем начинает нравиться, когда понимают как его правильно готовить. Проводим периодические семинары и обучение внутри команды.