Решение слишком большой проблемы с трафиком
В моей компании есть веб-сервис API, который начинает широко использоваться. Недавно у нас были некоторые проблемы с нехваткой памяти. Мы оптимизировали неэффективный код и решили проблему.
Мы знаем, что собираемся расширяться еще дальше, мы хотим иметь хороший способ справиться с интенсивным движением.
Одна идея, которая пришла, состоит в том, чтобы иметь разные URL для некоторых из наших более активных клиентов. Это просто выскакивает как неправильная вещь для меня. URL в некоторых случаях будут указывать на изолированные серверы, но некоторые также будут просто указывать на большее количество виртуальных каталогов.
Это хорошее решение проблемы в любом случае? Я предвижу ужасные проблемы с ремонтопригодностью и создаю больше проблем, чем решает. Пожалуйста, дайте мне некоторые плюсы и минусы для обеих сторон.
Это уже на ферме серверов с балансировкой нагрузки.
6 ответов
Если она уже находится на ферме с балансировкой нагрузки, и вы получаете слишком большую нагрузку, и вы уже оптимизировали столько, сколько сможете, следующим естественным шагом будет расширение фермы для удовлетворения спроса.
Если вы достигли максимальной мощности балансировщика нагрузки и у вас есть незанятые серверы, вы можете попытаться сбалансировать баланс более равномерно, используя обратную связь с балансировщиками, такими как mod_cluster. Если вы все еще нарушаете ограничения, вы можете попробовать Round Robin DNS в качестве альтернативы раздаче нескольких URL. Таким образом, вы можете переложить балансировку нагрузки на клиента. Вы можете добавить отзыв к этому решению с помощью lbnamed. Еще одним подходом является больший балансировщик нагрузки, который, конечно, требует больше $.
Может ли ваш API использовать преимущества кэширования?
Если определенные части API часто вызывают и возвращают одни и те же результаты, что-то вроде http://memcached.org/ может вам существенно помочь.
Я не вижу преимущества в том, чтобы иметь конкретные URL для разных клиентов. Мне кажется, что вам нужно больше серверов и / или балансировка нагрузки работает неправильно.
Я бы посмотрел на тех клиентов с более интенсивным использованием прямо сейчас. Можете ли вы зарядить их больше? Их использование больше, чем должно быть? Можете ли вы помочь им оптимизировать свои системы, чтобы им не приходилось так интенсивно использовать? Можете ли вы добавить ограничение скорости для ваших API? Достаточно ли их использования, чтобы иметь возможность предоставить им собственный сервер и взимать с них соответствующую плату?
Следующий шаг - посмотреть на вашу архитектуру. У вас есть кэширующие прокси перед вашими веб-серверами? У вас есть отдельные серверы баз данных? Все ваши серверы оптимизированы так же, как и ваш код? Вы кешируете абсолютно все, что можете? У вас есть хорошее оборудование?
Как только вы убедитесь, что ваша архитектура максимально оптимизирована, вам просто нужно добавлять дополнительные поля в настройку балансировки нагрузки всякий раз, когда вы начинаете превышать ограничения (будь то дополнительные кэши, дополнительные веб-серверы или дополнительные серверные серверы, будет зависеть от того, какие ограничения вы Ударили)
Балансировщик нагрузки уровня 7 позволит вам разделить тех клиентов, которые считаются "дорогостоящими", на кластер / компьютер, настроенный для обработки их конкретных запросов. Я предполагаю, что это "занятый" клиент, который выполняет львиную долю запросов, и разделение их на их собственный сервер - вот почему вы решили дать им отдельный URL. С помощью балансировщика нагрузки уровня 7, linuxvirtualserver.org, вы можете фильтровать определенные URL-адреса и иметь довольно простую в обслуживании систему.
Хотя в конечном итоге вы хотите решить проблему правильно, использование чего-то подобного может выиграть у вас достаточно времени.
Вы пытались запустить http://developer.yahoo.com/yslow/ и http://code.google.com/speed/page-speed/ которые являются плагинами для Firebug, пытаясь проанализировать количество запросов, сгенерированных, когда страница загружен?