Мы оценивали Spring-Stomp-Broker-websockets для приложения обмена сообщениями полного дуплексного типа, которое будет работать на AWS. Мы надеялись использовать Amazon MQ. Мы рассылаем сообщения отдельным пользователям, а также вещаем. Так что функционально стек выглядел хорошо. У нас около 40 000 - 80 000 пользователей. В ходе нагрузочного тестирования мы быстро обнаружили, что ни один из стеков Spring или Amazon MQ не очень хорошо масштабируется: проблемы:
- Экземпляр Spring Cloud Gateway не может обработать более 3000 веб-сокетов перед смертью.
- Экземпляр сервера Spring Websocket также может обрабатывать только около 4000 веб-сокетов на T3.Medium. Когда мы обойдем ворота.
- AWS ограничивает количество активных подключений MQ до 100 для небольшого сервера и только 1000 для массивного сервера. Никаких промежуточных, это просто странно.
Да, мы увеличили количество файловых дескрипторов и c на машинах, поэтому TCP-соединения не являются пределом. В этом случае Spring никогда не сможет приблизиться к пределу. Мы отправляем сообщение с нагрузкой 18 К, максимум, который мы ожидаем. В наших результатах размер сообщения не оказывает существенного влияния, это всего лишь соединение через Spring Stack.
StompBrokerRelayMessageHandler открывает соединение с брокером для каждого STOMP Connect. Нет способа объединить соединения. Так что это делает функцию Spring абсолютно бесполезной для любых «настоящих» веб-приложений. Чтобы поддержать наших пользователей, стоимость AWS массивных серверов для MQ означает, что это решение смехотворно дорого и требует 40 самых крупных серверов. При нагрузочном тестировании машина Amazon MQ ничего не делает, с 1000 пользователей она не загружается. На самом деле пара средних компьютеров - это все, что нам нужно для всех наших брокеров.
Кто-нибудь когда-либо создавал реальное решение, как описано выше, с использованием Spring Stack. Похоже, никто не сделал этого, и никто не увеличил масштаб. Кто-нибудь написал пул StompBrokerRelayMessageHandle. Я предполагаю, что должна быть причина, по которой это не может работать, поскольку это должен быть подход по умолчанию? В чем здесь проблема?
Кажется, что эти проблемы делают весь подход Spring Websocket + STOMP + Broker довольно бесполезным, и теперь мы вынуждены использовать другой подход для обеспечения надежности сообщений и для обмена сообщениями между серверами, где пользователи не подключился (основная причина, по которой мы используем брокер), а также вернулся с помощью простого брокера и написал реестр для управления расположением клиент-сервера. Итак, мы исключили брокера и приведенные выше цифры с этой моделью. Мы можем добавить в AWS SQS для надежности сообщений.
Что осталось. Мы собирались использовать Spring Cloud Gateway для балансировки нагрузки между несколькими маленькими серверами WebSocket, но, похоже, этот подход не сработает, поскольку нагрузка WebSocket, которую может обработать сервер, слишком мала. Шлюз просто не может справиться с этим. Сейчас мы удаляем Spring Cloud Gateway и вместо этого используем балансировщик нагрузки AWS. Так что теперь мы можем получить значительно больше сбалансированной нагрузки на соединения. Почему Spring Cloud Gateway не балансирует нагрузку?
Что осталось. Экземплярами сервера websocket являются t3.mediums, у них нет бизнес-логики c, и они просто передают сообщение между двумя клиентами, поэтому для него действительно не нужен сервер большего размера. Мы ожидали бы значительно лучше, чем 4000 соединений. Однако это близко к пригодности для использования.
Сейчас мы углубляемся в проблемы, чтобы получить более подробную информацию о узких местах производительности, но отсутствие каких-либо руководств по настройке или информации о масштабировании не говорит о хороших вещах о Spring. Сравните это с решениями Node, которые хорошо масштабируются и обрабатывают большее количество соединений на небольших машинах.
Следующий подход - посмотреть на WebFlux + WebSocket, но тогда мы потеряем STOMP. Может быть, мы проверим сырые веб-сокеты?
Это всего лишь ранняя попытка выяснить, действительно ли кто-то использовал Spring Websockets в гневе и может поделиться с ним реальной работающей производственной архитектурой, поскольку доступны только примеры игрушек. Так что любая помощь по вышеуказанным вопросам будет принята.