Ожидание ответа на серверах API

Question

У меня есть HTTP-сервер Netty, который я использую в качестве сервера API. Пользователь отправляет события на сервер API и обрабатывает событие на других потоках на том же сервере, используя службы-исполнители или инфраструктуру параллелизма, такую ​​как Akka. У меня есть два варианта ответа; когда я отправляю событие в другой поток, я могу подождать ответа и записать его в сокет или просто записать сообщение подтверждения обратно в сокет.

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

public void channelRead(ChannelHandlerContext ctx, Object msg) { 
    if (msg instanceof HttpRequest) { 
     executor.submit(new Event(msg)); 
     // do not wait for the response 
     ctx.write(new DefaultFullHttpResponse(HTTP_1_1, OK)); 
    } 
} 

public void channelRead(ChannelHandlerContext ctx, Object msg) { 
    if (msg instanceof HttpRequest) { 
     Future<Object> future = executor.submit(new Event(msg)); 
     future.after(x -> ctx.write(new DefaultFullHttpResponse(HTTP_1_1, OK))); 
    } 
} 

Поскольку это сервер API, я не должен ждать ответа для того, чтобы информировать пользователя о том, что обрабатывается событие, потому что это просто запрос на запись, которая не возвращает ответ. Итак, какой способ является наиболее удобным для серверов HTTP, и считаете ли вы, что второй вариант стоит для его производительности?

Answer 1

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

задать себе следующие вопросы:

1. Могут ли клиенты использовать статус возврата, чтобы сделать что-то значимое? Что могут сделать ваши клиенты без этого статуса?
2. Можете ли вы предвидеть, что клиент нуждается в изменении в будущем, чтобы потребовать обработки ответов после ответа? (т. е. статус возврата, тело возврата, коды ошибок и т. д.)
3. Ваш сервер должен отслеживать, что происходит на всем пути, от получения запроса клиента, чтобы превратить это в действие на сервере?
4. Какова ваша видимость и возможность отладки проблем?
5. Какова дополнительная сложность и накладные расходы, необходимые для добавления функциональности? Это приемлемо?

Это лишь некоторые из многих вопросов, которые вы должны задать себе в этой ситуации. Основываясь на информации, которую вы предоставили, я не уверен, что вы можете предоставить вам ответ «вы должны сделать X» или «вы должны сделать Y». Я думаю, вам лучше всего воспользоваться повторной оценкой ваших требований и задать себе несколько вопросов, как перечисленные выше.