Комментарии 38
Гм. Микросервисы на php. Звучит как cpu intensive на js.
Спасибо за статью!
Подскажите, а рассматривали еще какие-то варианты параллельных запросов к сервисам,
например, через очереди ?
Привет.
Рассматривали. И даже в ряде сценариев используем.
Но этот способ не очень подходит для интерактивных типов запросов - пока положишь в очередь пока вычитают, поработают, положат обратно, пока прочитаешь ответ.. + нужно вычитать именно свой ответ а не ответ на другой запрос, и оверхед от самой очереди..
Хорошо что у нас не php)
А зачем в закрытом контуре https? Чтобы героически его отключить?)
Привет.
Я легко могу представить больше одного сценария когда это оправдано. К примеру это требование сертификации при работе с персональными данными. Или желание защитить свои данные когда используешь не свое железо( MIM атаку никто не отменял)
Это вполне себе реальные риски. И прежде чем решить - http\https их надо оценить.
Подскажите, сколько по факту получилось сэкономить времени при реализации Reverse-proxy стратегии?
Т.е. например есть endpoint, он отдает инфу за 100мс, из них 80мс это http запрос к другому сервису. Сколько в таком случае получается сэкономить?
Боюсь я сильно конкретных цифр дать не смогу.
Оно все достаточно специфично под объемы нагрузки. Но из того чем могу поделится - уменьшения рейта ошибок до 5-10%, ускорение примерно до 5%.
Позволю влезть в ветку.
Поставили nginx-proxy перед внешним https-сервисом. Если ранее 3600 воркеров могли выполнять до 900 запросов без ошибок, а потом начинали валиться сетевые ошибки (разного рода - от резолва до коннект таймаутов), то с nginx-proxy, держащим до 1500 открытых коннектов до сервиса, без проблем держатся и 2k rps к внешнему сервису.
Задержки установления https-коннекта сошли на нет.
Но PHP не умеет работать в многопоточности (ждем PHP 8.1)
Подскажите, а чего именно мы там ждем? Если речь о Fibers, то они не предоставляют реальной многопоточности - это просто надстройка для упрощенной "ручной" остановки и продолжения некоего участка кода без потери контекста.
Retry не работает для идемпотентных запросов.
Не опечатка? Мне казалось только для идемпотентных и работает.
Graceful degradation увеличивает сложность и так непростой бизнес-логики в PHP-контроллерах.
Это наследие, или у вас реально БЛ в контроллерах?
Спасибо за статью. Есть вопрос: если ретраи реализованы на reverse_proxy и выбрана стратегия фиксированого ретрая (например, 3 попытки с 1-секундным перерывом между ними), то процесс PHP всё это время висит ожидая ответа? И получает ошибку от reverse_proxy по истечении 3 секунд?
Привет, да. все верно описал, но не 3 секунды, а больше.
запрос: {таймаут 1сек}{задержка между попытками 1 сек}-{таймаут 1сек}{задержка между попытками 1 сек}-{таймаут 1сек}{задержка между попытками 1 сек}
Итого: 6 секунд
Но есть еще circuit breaker - который может ответить ошибкой мгновенно, без ожидания 6 секунд, если количество ошбок большое было
Вот уже и вышел PHP 8.1. Скажите, как с ним поменялась ваша оптимизация?
А http2 не решает проблему поддержания keep alive соединений?
Её и http1.1 решает. Проблема-то не в протоколе, а в том чтобы это соединение реально сохранялось и переиспользовалось.
К примеру, короткоживущая программа не способна удержать соединение дольше чем живёт сама. А PHP в стандартном режиме использования "создан чтобы умирать", то есть очень короткоживущий.
Ну да, действительно. Это проблема для традиционных рантаймов, вроде php-fpm.
В swoole, workerman или просто в демонизированных процессах, получается, этой проблемы быть не должно.
Зависит от количества воркеров и того чем они занимаются. Cloudflare, к примеру, писали что "напоролись" на аналогичную проблему аж в nginx.
Но да, при обращении просто к сервисам такая проблема возникать не должна.
к слову - а почему "просто к сервисам" проблемы быть не может?
Потому что эта проблема тем острее, чем к большему количеству сервисов обращается программа и чем реже она обращается к каждому из них.
То есть чтобы проблема проявилась — надо сначала найти такой сервис, который будет обращаться к огромному количеству других сервисов, да ещё и в зависимости от запроса. А, и сам он должен существовать во многих инстансах. В нормальной архитектуре сюда может попасть только API gateway и всё.
Соглашусь - что такой тип проблем более свойственен api-gateway чем сервисам.
Просто есть composition сервисы, к примеру, сервисы не имеющие стейта, занимающиеся формированием ответа конечному пользователю и опрашивая другие сервисы.
Есть вообще graphQL - и там еще больше запросов может случится
Если я верно прочитал - на там напоролись с Nginx - это не только пулы соединений, но и не сбалансированная нагрузка по ядрам в зависимости от тяжести запроса. а в сервисах такое тоже вполне может случится.
Если сможете организовать коннекшн-пул в swoole, c возможностью переиспользования открытых соединений - то конечно-)
Натолкнувшись на этот пост в трекере я наконец-то понял о чём он вообще.
Автор, можно вопрос? Как вам вообще пришло в голову прокси, работающий на стороне приложения, обозвать обратным?
приложение выступает тут тем самым клиентом. для которого скрыты все те абстракции что лежат под reverse proxy, включая балансировку, ретраи и прочее. Что в целом соответствует понятию reverse proxy
если вместо reverse proxy использовать просто proxy - люди будут путаться еще сильнее - проверено на тестовой группе
"Как вам вообще пришло в голову" - грубовато звучит, чет-)
Строим эффективный сетевой обмен в PHP-микросервисах