Архитектура сервера в зависимости от емкости

Question

Я новичок на стороне сервера, , но у меня есть шанс разработать и внедрить сервер, который будет охватывать около 2000 ~ 3000 клиентов.

И я думаю, что буду использовать Python и Websocket, хотя я не знаю, что этот выбор уместен.

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

В противном случае, могу ли я использовать сервер Websocket, предлагаемый пакетом python, например Tornado или Django?

Надеюсь, что я получу любую информацию об этом.

Любые советы?

Answer 1

У меня были хорошие впечатления, используя haproxy перед sockjs-tornado. В зависимости от того, насколько сложны ваши требования к логике, маршрутизации и персистентности на стороне сервера, вы можете написать все конечные точки сервера с помощью торнадо и использовать SQLAlchemy для обработки записей в реляционной базе данных или использования хранилища данных без SQL, например Redis.

Если ваше основное требование - интерактивность в режиме реального времени, возможно, стоит также изучить meteor.

Answer 2

Одним из решений может быть Pyramid, sockjs, gunicorn и gevent. Nginx, вероятно, лучше подходит для интерфейса, чем Apache, но, конечно, если у вас нет длительной обработки на бэкэнд, любой достойный асинхронный сервер Python с поддержкой websocket и sockjs (не уверен, что сокет.io в качестве альтернативы) будет работать вы из коробки.

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

Просто проверьте, совместимы ли все используемые адаптеры хранилища данных/базы данных с вашим серверным решением асинхронно или многопоточно.