Недавно, когда я использовал браузер для доступа к этому сайту, я пытался обновить его ещё несколько раз, и получала ошибку 503, как показано на рисунке ниже:
Маршрут 503 временно недоступен Тем временем заголовок ответа выглядит следующим образом:
content-length: 608
content-type: text/html
date: Sat, 07 Jan 2023 13:50:32 GMT
via: HTTP/2.0 SLB.205 Ошибка временного недоступного сервиса 503
503 — это HTTP-код, обусловленный временнымОбслуживание серверов илиперегрузка, сервер в настоящее время не может обработать запрос. Это заболевание временное и будет восстановлено со временем.
В целом, ошибка 503 в основном связана сВысокий трафик на сайте, что приводит к ошибке, вызванной чрезмерным трафиком или большим количеством одновременных ресурсов.
через заголовок ответа
Мы видим это в ответе 503via: HTTP/2.0 SLB.205Информация о заголовке ответа, касающаяся заголовка via ответа, объясняется следующим образом:
Через
Показывает, какой прокси-сервер отправляет ответ клиента в OCS или наоборот, а также с каким протоколом (и версией) они отправили запрос.
Когда следующий прокси-сервер получает запрос от первого прокси-сервера, он копирует заголовок Via запроса предыдущего прокси-сервера в свой собственный запрос и добавляет соответствующую информацию в заднюю сторону, и так далее, когда OCS получает запрос от последнего прокси-сервера, он проверяет заголовок Via, чтобы узнать маршрут, по которому проходит запрос. Например: Via:1.0 236-81.D07071953.sina.com.cn:80 (кальмар/2.6.STABLE13) Исходя из описания, можно примерно предположить, что этоСервис SLB (балансировка нагрузки) напрямую возвращал ошибку 503То есть запрос не доходил до реального сервера на нашем бэкенде, и на него напрямую отвечал Alibaba Cloud SLB (Load Balancing) пользователю.
В это время я вдруг подумал, что сервис SLB (балансировка нагрузки) от Alibaba Cloud имеет разные характеристики, а также разные ограничения по совместности, например, простой тип I (slb.s1.small).Максимальное количество соединений, поддерживаемых этой спецификацией, составляет 5000, новых соединений (CPS): 3000, а запросы в секунду (QPS): 1000。 Как показано ниже:
Решение:Обновляю конфигурации SLB!! Обновляю конфигурации SLB!! Обновляю конфигурации SLB!!
Что касается мониторинга SLB (балансировки нагрузки), видно, что он превысил установленный лимит.
SSL конфигурации SLB по умолчанию будет включать http/2.0, так как http2.0 повторно использует TCP-соединения, и после установления TCP-соединения он будет загружаться только на один узел SLB
Конфигурация slb.s1.small с гарантированной производительностью следующая: количество соединений: 5000, CPS: 3000, QPS: 1000
QPS в этой спецификации — 1000, но QPS одного узла SLB — 1000/(8-1), седьмой слой — 8 узлов, а QPS одного узла — около 142. http/2.0 размещается на бэкенде для настройки
Вы можете обратиться к немуhttps://help.aliyun.com/knowledge_detail/55193.htmlобъяснение, почему каждое соединение не достигает пиков пропускной способности; Причина одна и та же Ресурсы:
Вход по гиперссылке виден.
Вход по гиперссылке виден.
|