Связь в реальном времени между двумя пользователями-клиентами через REST API с PHP backend, WebSocket и Node JS

Question

Прошу совета по архитектуре, как спроектировать систему с publi c API для взаимодействия пользователей с клиентами.

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

1. Клиент № 1 подключается к серверу и создает ресурс
2. Клиент № 2 подключается к серверу и обращается к ресурс
3. Изменения Клиента №1 Ресурсы
4. Изменения Клиента №2 Ресурсы
5. Повторить шаги 3 и 4 до завершения.

Клиент не может действовать, пока противный клиент не действует - порядок запроса должен быть сохранен.

Клиенты должны иметь доступ к ресурсу через REST API (GET, POST, PUT, DELETE). Каждый клиент должен ждать, пока противный клиент выполнит действие. Время ответа клиента и выполнения действия составляет 1-2 секунды (может незначительно отличаться).

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

Глобальная цель приложения - предоставить API, с помощью которого клиенты, запрограммированные на нескольких разных языках, могут обмениваться данными в реальном времени без какой-либо реализации опроса у пользователя. сторона клиента. Пользовательские клиенты должны быть как можно более простыми.

Пример псевдопользователя-клиента

response = init();
while (response->pending) {
    response = get();
}

while (response->action_required) {
    response = act();

    if (response->error || response->timeout) {
        response = get();
    }
}

function init() {
    // POST resource.example.com
}

function act() {
    // PUT resource.example.com
}

function get() {
    // GET resource.example.com
}

Постановка проблемы

Поскольку каждый клиент должен ждать, пока противный клиент начнет действовать, необходимо ввести в код функцию sleep(), которая будет отложить ответ до тех пор, пока ресурс не будет затронут / изменен противоположным клиентом.

Опрос запроса должен быть исключен из пользовательского клиента и реализован на стороне сервера.

Текущие мысли и предложения

Первоначальная мысль заключалась в том, чтобы реализовать только серверную часть PHP и выполнить задержку ответа внутри функции API, однако эта реализация кажется, вызывает серьезные проблемы с производительностью, поэтому я думаю о более сложном решении. Или, может быть, я ошибаюсь, и задержку ответа можно успешно реализовать с помощью sleep() внутри PHP бэкэнда?

Предлагаемая архитектура системы

• Node WebSocket server (socket.io для получения / возврата событий)
• PHP бэкэнд с REST API (доступ / изменение ресурс , запуск событий в WebSocket)
• Node JS приложение с publi c API для клиента конечного пользователя (функция задержки ответа до получения события)

Обратите внимание, что PHP бэкэнд не может быть заменен в этой архитектуре, однако, WebSocket и приложение Node JS являются гибкими модулями для реализации.

Будет ли такая архитектура реализована без серьезных проблем с производительностью сервера? Есть ли лучший и более реальный способ разработать такую ​​систему? Может ли приложение Node JS обрабатывать несколько одновременных запросов с задержкой ответа или любое другое веб-приложение (Python / Ruby / ...) будет лучше? Обязателен ли сокет для этой системы, чтобы добиться некоторого поведения в реальном времени?

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

Заранее спасибо!

Answer 1

Некоторые примечания:

1. Избегайте сна любой ценой.
2. Ваш вариант использования имеет тенденцию подстраиваться под шаблон микро-сервисов pub / sub.
3. Поскольку вам нужно сохранить порядок обработки сообщений, вам нужна общая очередь. Каждый из ваших узлов REST API действует как издатель / подписка в распределенной системе очередей сообщений (технология RabbitMQ, Kafka и др. c.). Итак, для высокой пропускной способности теперь у вас есть ферма машин, передающих очередь. Они немедленно возвращаются с сообщением 201 Accepted, но нужен способ пометить сообщение каким-либо идентификатором клиента, чтобы вы могли направлять сообщения обновления обратно через веб-сокет (если вы не собираетесь опрашивать обновления статуса по идентификатору ресурса).
4. Для фактической обработки вам нужны подписчики этой очереди. То же самое, пусть они будут отдельными приложениями, и теперь вы можете масштабировать удаление из очереди и обработку. Однако технология, которую вы выбираете для шины pub / sub, должна иметь возможность аннулировать последующие сообщения для этого ресурса, и для каждого из недействительных сообщений предоставлять обратную связь вашему приложению, чтобы оно могло отправлять требуемое сообщение через веб-сокет.

Надеюсь, это поможет.