Я знаю в HTTP 1.1, keep-alive является поведением по умолчанию, если только клиент явно не просит сервер закрыть соединение, включив заголовок Connection: close в свой запрос, или сервер не решит включить заголовок Connection: closeв своем ответе.Мне интересно, не является ли это препятствием для масштабируемости при горизонтальном росте серверов.
Мой сценарий: мы разрабатываем все новые сервисы, следуя шаблонам микросервисов на Java или Phyton.Понятно, что мы можем спроектировать и реализовать так, как мы можем увеличивать по горизонтали.Для удобства я могу использовать докер, чтобы легко масштабировать или использовать Spring Boot Cloud Config.Какой бы ни была реализация физического хоста, основная идея заключается в предпочтении масштабируемости.
Мое понимание: я должен сохранять сервер и клиент как можно более независимыми, и когда я настраиваю HTTP Keep Alive, я понимаю, что при использованиито же http-соединение (и сохранить некоторый процессорный процесс), но я предполагаю, что заставляю клиента (например, другую службу) продолжать использовать одно и то же соединение, что может снизить преимущество нескольких экземпляров Docker одной и той же службы, так как я рекомендую клиенту продолжать потреблятьто же самое начальное соединение.
Предполагая, что мое понимание правильное, я полагаю, что это не очень хорошая идея, поскольку мы разрабатываем ответные услуги, которые могут быть повторно использованы различными потребителями с различными подходами: некоторые потребители могут потреблять асинхронно или следовать парадигмам реактивного проектирования, которые делаютмне интересно, если сохранить в живых ту же связь.Скажем на практике: используемое соединение должно быть как можно скорее свободным, чтобы реально сбалансировать спрос по всем провайдерам.
*** отредактировано после первого комментария
Давайте предположим, что Iиметь несколько различных потребительских служб (CS1, CS2 ... CSn), подключающихся к одному экземпляру балансировки нагрузки (LB), который будет пересылать запрос нескольким докерам с одним и тем же сервисом поставщика (D1, D2 ... Dn).Так как keep alive - стандартное поведение в http 1+, мы должны сохранять «alive = true» во всех соединениях (между Cx и LB или LB и Dx).Насколько я знаю, единственное преимущество в том, чтобы сохранять работоспособность - это процесс сохранения процессора при открытии / закрытии соединения.Если я отправляю Соединение: закрывать после каждого запроса, нет никаких преимуществ использовать keep alive.Если у меня есть какая-то логика для отправки «connection: close», это означает, что я рекомендую LB поддерживать соединение с определенным Dx, используя точно такое же соединение какое-то время, верно?(Я выбираю здесь слово «промоушен», потому что, я думаю, сила не может быть подходящей, так как есть время на поддержание в живых, а затем LB в любом случае может проложить маршрут к другому Dx).Таким образом, у меня в какой-то момент C1 -> LB -> D1 живое сохраняется какое-то время, верно?Возвращаясь к моему первоначальному вопросу, разве это не противоречит идее асинхронной / паралелальной / реактивной парадигмы?Например, у меня есть сценарий, когда один потребительский сервис будет вызывать другой сервис несколько раз, прежде чем вернуть один ответ на страницу.Сегодня мы делаем это последовательно, но если мы решим позвонить в paralalel и, в зависимости от первого ответа, уже будет ответ на страницу, или мы решим составить ответ на страницу, но мне плевать на порядок.Служба вызывающего абонента будет ждать каждого ответа, прежде чем вернуться к контроллеру, и порядок не имеет значения.Разве не странно, что я остаюсь в живых = правда?