Это бесплатная версия, и она уже обладает широким функционалом. А в Enterprise-решении возможности просто взлетают. Сохраняя все преимущества бесплатной версии — простоту конфигурации и надежность и добавляет огромное количество новых функций. Именно поэтому на github у nginx столько звезд, что впереди планеты всей
Для проведения качественного нагрузочного тестирования, которое не ограничивается однотипными запросами, а реалистично моделирует нагрузку, необходимо привлекать QA-инженеров. Тема эта достаточно обширна и заслуживает отдельной статьи. Стоит сделать две оговорки: во-первых, я не являюсь экспертом в этом вопросе и основываюсь на своём практическом опыте работы с реальными проектами, где используются эти lb. Во-вторых, упор делался не столько на синтетические бенчмарки, сколько на теорию и последующую эксплуатацию систем
Я имел в виду, что HTTP/3 не был добавлен именно в версии 3.2.3 — его реализовали намного раньше. Но поскольку сборка пока не включена в официальный Docker-образ и выполняется вручную, эту функциональность можно считать бета-версией.
Пока писал, забыл про эту тему — да, с переменными не всё так просто в haproxy. Дописывать уже наверное не буду, кому интересно - думаю, найдут где почитать про это.
Сами разрабы xray пишут, чтобы настраивали direct до ресурсов страны в которой проживаете. Я настроил по geoip и regexp и вроде пока сервер в бан не отлетал, upload нормальный.
Под legacy в данном контексте можно понимать все, что не интегрируется с общим API и не управляется через scheduler. Это, например, системы, построенные на docker, docker-compose или systemd unit, где отсутствует возможность полноценной реализации service discovery, аналогичной Kubernetes или если есть планы строить именно динамическую конфигурацию и управлять ей через единый gateway при этом не переводя все сервисы на кубы
Здесь я хотел больше сосредоточиться на использовании Envoy как Service mesh или Ambient Mesh в legacy инфраструктуре, а не превращать его в огромный gateway с кучей логики на борту. Конечно, часть функционала нужно будет вынести в приложение, но акцент я делал именно на TCP-стек и его взаимодействие. Я бы не стал добавлять JWT-аутентификацию в Envoy, а перенес её в приложение, если это действительно необходимо. В этом вопросе есть нюанс: где-то это может быть полезно, а где-то — нет. Каждый решает для себя, нужно ли это вообще. Поэтому я и не приводил конкретных примеров, их может быть слишком много, и каждый проект требует индивидуального подхода
Большинство сетевых проблем, а также типичные ответы HTTP (особенно ошибки 5xx), поддаются стандартным подходам к обработке. Пытаться добавлять сложную логику на стороне приложения для таких ситуаций – это не только увеличивает вероятность багов, но и нарушает принципы разделения ответственности.
Лучше избегать превращения микросервисов в раздутые сущности или монолиты, нагруженные лишней логикой. Для обработки сетевых сбоев и ошибок 5xx на транспортном уровне существуют проверенные решения.
Разработчику же, на мой взгляд, нет смысла углубляться в тонкости работы TCP-стека – это задача инфраструктуры и сетевых решений. Его фокус должен оставаться на бизнес-логике, а не на решении транспортных проблем.
Это бесплатная версия, и она уже обладает широким функционалом. А в Enterprise-решении возможности просто взлетают. Сохраняя все преимущества бесплатной версии — простоту конфигурации и надежность и добавляет огромное количество новых функций. Именно поэтому на github у nginx столько звезд, что впереди планеты всей
Для проведения качественного нагрузочного тестирования, которое не ограничивается однотипными запросами, а реалистично моделирует нагрузку, необходимо привлекать QA-инженеров. Тема эта достаточно обширна и заслуживает отдельной статьи. Стоит сделать две оговорки: во-первых, я не являюсь экспертом в этом вопросе и основываюсь на своём практическом опыте работы с реальными проектами, где используются эти lb. Во-вторых, упор делался не столько на синтетические бенчмарки, сколько на теорию и последующую эксплуатацию систем
UPD. Был все таки добавлен абзац про использование переменных в haproxy
Я имел в виду, что HTTP/3 не был добавлен именно в версии 3.2.3 — его реализовали намного раньше. Но поскольку сборка пока не включена в официальный Docker-образ и выполняется вручную, эту функциональность можно считать бета-версией.
Пока писал, забыл про эту тему — да, с переменными не всё так просто в haproxy. Дописывать уже наверное не буду, кому интересно - думаю, найдут где почитать про это.
Сами разрабы xray пишут, чтобы настраивали direct до ресурсов страны в которой проживаете. Я настроил по geoip и regexp и вроде пока сервер в бан не отлетал, upload нормальный.
Кому интересно посмотреть конфиги можно сюда еще зайти - https://github.com/XTLS/Xray-examples
Под legacy в данном контексте можно понимать все, что не интегрируется с общим API и не управляется через scheduler. Это, например, системы, построенные на docker, docker-compose или systemd unit, где отсутствует возможность полноценной реализации service discovery, аналогичной Kubernetes или если есть планы строить именно динамическую конфигурацию и управлять ей через единый gateway при этом не переводя все сервисы на кубы
Сравнить гипервизор и систему управления контейнерами эт конечно жестко
Здесь я хотел больше сосредоточиться на использовании Envoy как Service mesh или Ambient Mesh в legacy инфраструктуре, а не превращать его в огромный gateway с кучей логики на борту. Конечно, часть функционала нужно будет вынести в приложение, но акцент я делал именно на TCP-стек и его взаимодействие. Я бы не стал добавлять JWT-аутентификацию в Envoy, а перенес её в приложение, если это действительно необходимо. В этом вопросе есть нюанс: где-то это может быть полезно, а где-то — нет. Каждый решает для себя, нужно ли это вообще. Поэтому я и не приводил конкретных примеров, их может быть слишком много, и каждый проект требует индивидуального подхода
Большинство сетевых проблем, а также типичные ответы HTTP (особенно ошибки 5xx), поддаются стандартным подходам к обработке. Пытаться добавлять сложную логику на стороне приложения для таких ситуаций – это не только увеличивает вероятность багов, но и нарушает принципы разделения ответственности.
Лучше избегать превращения микросервисов в раздутые сущности или монолиты, нагруженные лишней логикой. Для обработки сетевых сбоев и ошибок 5xx на транспортном уровне существуют проверенные решения.
Разработчику же, на мой взгляд, нет смысла углубляться в тонкости работы TCP-стека – это задача инфраструктуры и сетевых решений. Его фокус должен оставаться на бизнес-логике, а не на решении транспортных проблем.