Я рассматриваю возможность настройки службы pub/sub с веб-сокетами. Насколько я могу судить, узкие места масштабируемости будут в основном связаны с памятью, которая влияет на то, сколько сокетов может быть открыто одновременно, поэтому я бы счел разумным отделить это от других серверов, на которых запущены такие службы, как API. Это правильно? Я предполагаю, что память дороже вычислительной мощности, когда дело касается хостинга, так есть ли какие-либо передовые практики, когда дело касается оптимизации этого типа сервера для масштабируемости и стоимости?
Цель состоит в том, чтобы предоставить пользователю этого веб-приложения обновления в реальном времени, поскольку системы в полевых условиях регистрируют новые данные, без необходимости периодически опрашивать бэкенд. Но мы не хотим удваивать наши серверные расходы, иначе это может того не стоить. Мы используем AWS EC2 с балансировкой нагрузки и автоматическим масштабированием для наших текущих серверов API.
решение1
Фактическое использование памяти одним сокетом не так уж и велико.
Память потребляет состояние, связанное с тем, какой клиент заинтересован в тех или иных обновлениях, и какой клиент уже получил конкретное обновление.
В примитивной реализации (т. е. с использованием сетевого стека ОС) последнее состояние сохраняется в виде исходящих буферов — так, если обновление отправляется 10 000 клиентов, данные копируются 10 000 раз, каждая из копий добавляется в исходящую очередь, где она дополняется необходимыми заголовками (содержащими состояние для каждого соединения), а затем для оборудования создается дескриптор, который дает ему команду отправить пакет, представляющий собой конкатенацию заголовков и полезной нагрузки.
Копия полезной нагрузки для каждого клиента хранится в памяти до тех пор, пока клиент ее не подтвердит, и отсюда возникают требования к памяти. Эта память не может быть выгружена, поэтому она создает нагрузку на память и кэш для других приложений.
Существуют реализации, которые реализуют части сетевого стека внутри самой серверной программы, и они могут избегать копирования с помощью подсчета ссылок или повторного создания полезных данных по требованию, что позволяет вам обойтись гораздо меньшим использованием памяти, но требует большого количества сложного кодирования для обеспечения настоящей масштабируемости, особенно многосокетные серверы, которые создают некоторые интересные проблемы, с которыми сетевой стек ОС уже умеет справляться.
Варианты, которые у вас есть
- запустить службу pub/sub на том же сервере, что и приложение
- запустить службу pub/sub на выделенном сервере с сетевым подключением ОС
- запустить службу pub/sub на выделенном сервере с настраиваемой сетью
- запустить службу pub/sub на нескольких выделенных серверах
ваша стратегия эскалации по мере роста сервиса. Переход от общего к выделенному не требует особого планирования и может быть выполнен по мере необходимости; как только это произошло, наступает время подготовить дальнейшие этапы.
Масштабирование до нескольких серверов привнесет недетерминированность в вашу систему, поскольку клиенты могут получать обновления в разном порядке. Поэтому для успешного масштабирования ваши клиенты должны знать об этом и иметь возможность предоставлять единообразное представление. Насколько это просто или сложно, зависит от вашего конкретного приложения.
вкратце:нет необходимости оптимизировать преждевременно. Разделите службу так, чтобы первым шагом масштабирования было простое изменение конфигурации, и начните оптимизацию сразу после того, как это произойдет.