Веб-сервисы RESTful и Socket Programming для приложений, интенсивно использующих данные

Question

Я создаю веб-приложение с Ruby on Rails, которое должно быть легко масштабируемым.В этом приложении данные создаются мобильным клиентом (приблизительно 20 байтов) каждую секунду.Все эти данные должны быть переданы на сервер в определенный момент, желательно как можно скорее.

Чтобы выполнить эту задачу, я хочу, чтобы сервер работал как служба RESTful.Клиент может буферизовать местоположения (скажем, каждые 5–30 секунд), а затем отбрасывать их как HTTP-запрос пут, где сервер может их затем сохранить.Я полагаю, что эта модель проще в реализации и лучше обрабатывает большой объем трафика, поскольку клиенты могут продолжать буферизовать данные, пока не услышат ответ от сервера.

С другой стороны, мой начальник хочет реализоватьсервер с использованием сокет программирования.Он считает, что программирование сокетов приведет к уменьшению объема передаваемых данных, что повысит общую эффективность системы.Я не могу не согласиться по этому вопросу, но я думаю, что с учетом современной пропускной способности дополнительные издержки с HTTP оправдывают себя.Кроме того, я думаю, что попытка поддерживать тысячи (или миллионы) одновременных соединений с пользователями вызовет свои собственные проблемы и значительно увеличит сложность сервера.

Честно говоря, я не знаю правильного подхода к этой проблемеТак что я решил опубликовать это здесь и узнать мнение более умных людей, чем я.Буду признателен, если в любые ответы будут включены плюсы и минусы предложенного решения.

Спасибо.

Обновление

Теперь у нас есть несколькодополнительные требования выброшены.Во-первых, мобильный клиент не может загружать более 5 ГБ данных в месяц.В этом случае мы говорим одно сообщение в секунду по восемь часов в день в месяц.Во-вторых, мы хотим объединить сообщения как можно меньше.Это делается для того, чтобы в случае, если что-то случилось с мобильным клиентом (например, автокатастрофа), мы потеряли как можно меньше данных.

Answer 1

Кажется, ваш босс преждевременно оптимизирует, что не очень хорошая идея.

Вместо того, чтобы пытаться бороться с воображаемым чудовищем производительности еще до того, как вы начнете писать код, вы должны изучить требования вашего приложения.и дизайн им.Не позволяйте воспринимаемым проблемам влиять на ваш дизайн.

Если дело доходит до этого, попросите вашего босса точно описать, как он собирал данные через соединение с сокетом, а затем сделайте несколько быстрых вычислений, чтобы увидеть, можете ли вы соответствовать илибить их с HTTP.Будет ли он использовать что-то вроде протокольных буферов Google или написать свой собственный протокол маршалинга?Если так, это будет самоописанием?Как насчет "глаголов" приложения, как то, что вы получите бесплатно в HTTP?Будут ли его связи постоянными?«Сокеты» - это гораздо больше, чем просто открытие соединения и израсходование байтов по нему.

Вы также правильно заметили, что ваш начальник, похоже, предпочитает грубую скорость сокетов по сравнению со всем остальным: масштабируемость, ремонтопригодность,доступность средств разработки и тестирования, снифферов протоколов, полезной семантики глаголов HTTPS и так далее.HTTP хорошо понимают балансировщики нагрузки и брандмауэры и тому подобное.Вашему проприетарному протоколу сокетов не повезет.

Я бы посоветовал вам изучить все возможные варианты и оценить их с точки зрения производительности с помощью тестирования, создания прототипов и тестирования производительности.Затем сравните эти цифры со сложностью создания и поддержки приложения с использованием этой технологии.

Answer 2

Придерживайтесь HTTP.

Гораздо проще создать парк HTTP-серверов и поместить их за балансировщиком нагрузки, чем пытаться сделать то же самое с вашим собственным протоколом. Зачем? Все уже существует для HTTP.

Обновление

Что нужно, чтобы переопределить себя:

• Управление буфером (важно, если ваша нагрузка высока)
• Убедиться, что вы получили все сообщение (простого Receive / BeginReceive недостаточно)
• Асинхронная обработка сокетов
• Аутентификация
• Балансировщик нагрузки (эта часть сложная, и вам нужно тщательно ее спроектировать)
• Ваш собственный протокол (вам нужен способ определить, когда вы получили сообщение целиком)

Если вы используете ASP.NET MVC + JSON (шаги для merb или rails аналогичны):

1. Создать новый сайт
2. Активировать дайджест-проверку подлинности в IIS
3. Создайте новый контроллер, отметьте его атрибутом [Authorize]
4. Добавить действие

Что дешевле? Сервер или вы потратили месяц на то, что уже сделано?

Answer 3

HTTP был разработан для масштабирования на основе предположения, что подавляющее большинство запросов являются GET. Похоже, что большинство ваших взаимодействий - это клиент, отправляющий данные на сервер. Я думаю, что вполне вероятно, что существует лучший архитектурный стиль, чем REST для достижения того, что вы пытаетесь сделать.

Вопрос в том, можете ли вы позволить себе начать все с нуля или HTTP достаточно хорош для ваших нужд. Не зная больше деталей о вашем приложении, я думаю, что трудно дать хороший совет.

Answer 4

Ваш начальник и вы оба правы, и правильный выбор зависит от требований бизнеса: как скоро вам придется масштабироваться.

Если вы начинаете запускать новую услугу и боитесь, что не сможете управлять миллионами новых пользователей, которые у вас появятся в течение 3 месяцев, тогда @ Brian-Kelly прав - это преждевременная оптимизация. OTOH, если вы Twitter и создаете новый сервис на основе определения местоположения, то масштаб - это основная проблема, с которой вам следует иметь дело. Если вы где-то посередине, тогда это ваше дело - сделайте выбор.

Создание веб-службы RESTful с Rails является быстрым и простым, и вызов его с мобильного клиента также прост (хотя буферизация на стороне мобильного клиента требует большего количества кода). Это главное (и единственное имхо) преимущество этого подхода в вашем случае - и это огромное преимущество.

Однако HTTP добавляет много накладных расходов. Если ваши сообщения имеют длину 20 байт, на самом деле издержки в несколько раз превышают полезную нагрузку на сообщение. Это означает большую пропускную способность сети и больше процессорного времени. Да, вы можете добавить больше серверов, чтобы справиться с этим, но это будет стоить вам - потребуется несколько серверов для выполнения работы, достижимой одним.

Если ваша служба просто получает очень короткие сообщения от мобильных клиентов, и , если все в порядке для потери случайного сообщения, то я бы подумал об использовании UDP. Ваши 20 байтов должны поместиться в одном пакете. Это значительно экономит по сравнению с несколькими обходами TCP для установления соединения, а затем для отправки данных.

Еще одна вещь, о которой следует помнить, когда вы рассматриваете вопрос о том, является ли оптимизация преждевременной в вашем случае, это мобильные клиенты: вносить изменения в ваш сервер несложно, но выдвигать новую версию, которая использует более оптимизированный протокол обмена сообщениями, на миллионы устройств. в поле "не тривиально.

Обновление , после обновления вопроса:

5 ГБ в месяц вполне достаточно. Сообщение каждую секунду в течение месяца означает 86 400 * 30 = ~ 2,6 млн сообщений. Это позволяет вам тратить почти 2 КБ за сообщение. Не проблема, если ваша полезная нагрузка составляет ~ 20 байт ...

Что касается вашего предпочтения не объединять сообщения, чтобы не потерять какую-либо информацию, вы должны спросить себя, сколько сообщений можно потерять. Может быть, целая минута - это слишком много, но 10 секунд - это не проблема? клиент, движущийся со скоростью 60 миль в час, будет двигаться только 0,16 миль за 10 секунд.

В любом случае, если это система реального времени, которая должна спасти жизни, подумайте о проведении некоторого тестирования в реальных условиях (мобильный клиент в дороге). Это единственный способ определить, как ведет себя мобильная сеть (ы) - какие задержки вы можете ожидать, как часто пакеты теряются, поступают вне последовательности и т. Д.