Исправление dimgel, (текущая версия) :
фильтрацией атак
Вот тут соглашусь, для анти-ДДоСа разносить приложение и фронт-сервер имеет смысл. Это первый осмысленный аргумент из серии «какую проблему решает», а не «мне больше нравится». Откровенно говоря, я ждал аргумент про надёжность (приложение упало – сервер нет), будучи готов поднять его на смех.
Мой подход решает проблемы:
Максимально возможная эффективность. Никаких прокси-слоёв и прочих фасадов, тем более взаимодействующих через сеть; максимальная интеграция с API веб-сервера. (C++ vs Java здесь в целом ортогонально, но меня всё-таки зудит заявить, что цена вопроса – 20-кратная экономия на серверах, если боттлнек - вычислительная мощность.)
Простота развёртывания: прописать в nginx.conf пару строк load_module /lib/myapp_ngxmod.so; на верхнем уровне + myapp /etc/myapp.conf; внутри server{} и скопировать в систему два вышеупомянутых файла проще, чем прописать две строчки для reverse proxy и потом поднять-настроить ещё и бакенд (молитесь чтобы там был просто JRE общедоступной версии, а не JBoss или питон какой-нибудь).
Понятно, что anti-DDoS это блокер, в отличие от. Но тут у кого какие задачи. Кроме того, если anti-DDoS предоставляется хостером (а он обычно предоставляется), то для разработчиков и админов он в целом прозрачен.
Исправление dimgel, :
фильтрацией атак
Вот тут соглашусь, для анти-ДДоСа разносить приложение и фронт-сервер имеет смысл. Это первый осмысленный аргумент из серии «какую проблему решает», а не «мне больше нравится». Откровенно говоря, я ждал аргумент про надёжность (приложение упало – сервер нет), будучи готов поднять его на смех.
Мой подход решает проблемы:
Максимально возможная эффективность. Никаких прокси-слоёв и прочих фасадов, тем более взаимодействующих через сеть; максимальная интеграция с API веб-сервера. (C++ vs Java здесь в целом ортогонально, но меня всё-таки зудит заявить, что цена вопроса – 20-кратная экономия на серверах.)
Простота развёртывания: прописать в nginx.conf пару строк load_module /lib/myapp_ngxmod.so; на верхнем уровне + myapp /etc/myapp.conf; внутри server{} и скопировать в систему два вышеупомянутых файла проще, чем прописать две строчки для reverse proxy и потом поднять-настроить ещё и бакенд (молитесь чтобы там был просто JRE общедоступной версии, а не JBoss или питон какой-нибудь).
Понятно, что anti-DDoS это блокер, в отличие от. Но тут у кого какие задачи. Кроме того, если anti-DDoS предоставляется хостером (а он обычно предоставляется), то для разработчиков и админов он в целом прозрачен.
Исправление dimgel, :
фильтрацией атак
Вот тут соглашусь, для анти-ДДоСа разносить приложение и фронт-сервер имеет смысл. Это первый осмысленный аргумент из серии «какую проблему решает», а не «мне больше нравится». Откровенно говоря, я ждал аргумент про надёжность (приложение упало – сервер нет), будучи готов поднять его на смех.
Мой подход решает проблемы:
Максимально возможная эффективность. Никаких прокси-слоёв и прочих фасадов, тем более взаимодействующих через сеть; максимальная интеграция с API веб-сервера.
Простота развёртывания: прописать в nginx.conf пару строк load_module /lib/myapp_ngxmod.so; на верхнем уровне + myapp /etc/myapp.conf; внутри server{} и скопировать в систему два вышеупомянутых файла проще, чем прописать две строчки для reverse proxy и потом поднять-настроить ещё и бакенд (молитесь чтобы там был просто JRE общедоступной версии, а не JBoss или питон какой-нибудь).
Понятно, что anti-DDoS это блокер, в отличие от. Но тут у кого какие задачи. Кроме того, если anti-DDoS предоставляется хостером (а он обычно предоставляется), то для разработчиков и админов он в целом прозрачен.
Исправление dimgel, :
фильтрацией атак
Вот тут соглашусь, для анти-ДДоСа разносить приложение и фронт-сервер имеет смысл. Это первый осмысленный аргумент из серии «какую проблему решает», а не «мне больше нравится». Откровенно говоря, я ждал аргумент про надёжность (приложение упало – сервер нет), будучи готов поднять его на смех.
Мой подход решает проблемы:
Максимально возможная эффективность. Никаких прокси-слоёв и прочих фасадов, тем более взаимодействующих через сеть; максимальная интеграция с API веб-сервера.
Простота развёртывания: прописать в nginx.conf пару строк load_module /lib/myapp_ngxmod.so; на верхнем уровне + myapp /etc/myapp.conf; внутри server{} и скопировать в систему два вышеупомянутых файла проще, чем прописать две строчки для reverse proxy и потом поднять-настроить ещё и бакенд (молитесь если там просто JRE общедоступной версии, а не JBoss или питон какой-нибудь).
Понятно, что anti-DDoS это блокер, в отличие от. Но тут у кого какие задачи. Кроме того, если anti-DDoS предоставляется хостером (а он обычно предоставляется), то для разработчиков и админов он в целом прозрачен.
Исправление dimgel, :
фильтрацией атак
Вот тут соглашусь, для анти-ДДоСа разносить приложение и фронт-сервер имеет смысл. Это первый осмысленный аргумент из серии «какую проблему решает», а не «мне больше нравится». Откровенно говоря, я ждал аргумент про надёжность (приложение упало – сервер нет), будучи готов поднять его на смех.
Мой подход решает проблемы:
Максимально возможная эффективность. Никаких прокси-слоёв и прочих фасадов, тем более взаимодействующих через сеть; максимальная интеграция с API веб-сервера.
Простота развёртывания: прописать в nginx.conf пару строк load_module /lib/ngxmod_myapp.so; на верхнем уровне + myapp /etc/myapp.conf; внутри server{} и скопировать в систему два вышеупомянутых файла проще, чем прописать две строчки для reverse proxy и потом поднять-настроить ещё и бакенд (молитесь если там просто JRE общедоступной версии, а не JBoss или питон какой-нибудь).
Понятно, что anti-DDoS это блокер, в отличие от. Но тут у кого какие задачи. Кроме того, если anti-DDoS предоставляется хостером (а он обычно предоставляется), то для разработчиков и админов он в целом прозрачен.
Исходная версия dimgel, :
фильтрацией атак
Вот тут соглашусь, для анти-ДДоСа разносить приложение и фронт-сервер имеет смысл. Это первый осмысленный аргумент из серии «какую проблему решает», а не «мне больше нравится». Откровенно говоря, я ждал аргумент про надёжность (приложение упало – сервер нет), будучи готов был поднять его на смех.
Мой подход решает проблемы:
Максимально возможная эффективность. Никаких прокси-слоёв и прочих фасадов, тем более взаимодействующих через сеть; максимальная интеграция с API веб-сервера.
Простота развёртывания: прописать в nginx.conf пару строк load_module /lib/ngxmod_myapp.so; на верхнем уровне + myapp /etc/myapp.conf; внутри server{} и скопировать в систему два вышеупомянутых файла проще, чем прописать две строчки для reverse proxy и потом поднять-настроить ещё и бакенд (молитесь если там просто JRE общедоступной версии, а не JBoss или питон какой-нибудь).
Понятно, что anti-DDoS это блокер, в отличие от. Но тут у кого какие задачи. Кроме того, если anti-DDoS предоставляется хостером (а он обычно предоставляется), то для разработчиков и админов он в целом прозрачен.