[Анализ и проектирование систем, IT-инфраструктура, Nginx, Mesh-сети, DevOps] Зачем нужен обратный прокси сервер в 5 актах
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
На текущий момент есть большое разнообразие обратных прокси серверов. Я перечислю только парочку из них.
- Nginx
- Envoy
- HAProxy
- Traefik
Также у каждого уважающего себя клауд провайдера есть свой прокси сервер.
- AWS Elastic LoadBalancer
- Google Cloud Load Balancer
- DigitalOcean Load Balancer
- Azure load balancer
Дадим определение слову обратный прокси-сервер.Обратный прокси-сервер (англ. reverse proxy) — тип прокси-сервера, который ретранслирует запросы клиентов из внешней сети на один или несколько серверов, логически расположенных во внутренней сети. При этом для клиента это выглядит так, будто запрашиваемые ресурсы находятся непосредственно на прокси-сервере.И картинку прилепим для наглядности.
Какую проблему решают прокси сервера?Акт первыйУ нас есть веб-сайт, который не поддерживает HTTPS(т.к. общение по TLS/SSL не программировали). Сказать девелоперам запилить это - легко, а вот самим девелоперам может быть напряжно с реализацией. Если у нас приложение монолит - нам нужно внести изменения в этот, чаще всего не поворотливый агрегат, и доставить это на продакшн, если у нас легкие микросервисы, каждый надо посетить, в каждый надо внести небольшие правки + опять таки всё это доставить.Как решаем проблему? Берем ничем не занятого SysOps/DevOps, говорим, что нам нужен https. Какой-тоOps ставит нам прокси сервер настраивает его на приём HTTPS трафика + SSL termination. Задача решена, цена решения: 1 Какой-тоOps.
Акт второйДа осталось у нас то самое приложение, да сделали инженеры его чтобы оно могло масштабироваться горизонтально, да подняли аж две копии приложения. Супер! Как настроить так, чтобы трафик равномерно на оба поступал?И снова на помощь приходит проски сервер, который выполняет роль "балансировщика нагрузки". Плюс ко всему можно еще и проверку жизнеспособности настроить, вдруг одна копия упадет, зачем же нам расстраивать пользователей. Всех на оставшийся сервер временно расположить, и дело в шляпе. После починки сломанного сервера, прокси сервер вернет его в строй автоматом, и можно дольше себе балансировать.В итоге: двух зайцев, так сказать.Акт третийВзломали нас "хакеры", беда. Дать такому повториться - ну никак нельзя.Что нам для этого нужно? Перспективная китайская разработка - файрвол, чтоб и трафик от нежелательных пользователей фильтровать и от DDoS-атак оборонятся.Чтож, и это проблему поможет нам прокси сервер решить, на него "вещаем" все эти настройки и никакие "хакеры" нашу мега-сесурити не обойдут. Главное настроить правильно, чтобы CEO при демках за хакера не посчитало.
Акт четвертыйТак-так, HTTPS - есть, балансировщик - есть, защита от хакеров - есть, казалось бы, сиди и чиль себе перед телеком, но снова что-то не так. Запросы по сети гуляют долго, пару десятков вообще не вернулись, клиенты в панике.Анализируем проблему, ага, к гадалке - у нас огромный "пэйлоад в запросах" и парочка "популярных" конечных точек (пользователи любят часть сервиса и активно ей пользуются).Чтож, лепим на уровне нашего прокси сервер сжатие запроса и кэшируем на нём ответы серверов приложения. Это что получается? Опять двух зайцев? Так точно!Теперь запросы на холодную возвращаются быстрее некуда, а с кэшом, так и подавно.Акт пятыйПростой мы уже сделали для клиентов нашего приложения жизнь, подумать о себе пора.Новых функций в продакшн страдает доставка что если?A/B тестирование можно настроить с прокси сервера помощью, что лучше может быть, чем отказ системы полный при багах в новом релизе? Правильно, у части пользователей только отказ.После внедрения этой фичи, репутация вашего приложения не будет страдать так сильно, как страдала до внедрения A/B тестирования, т.к. негативные комментарии будут писаться только узким кругом "счастливчиков".
Суммируем выше сказанноеФункции которые предоставляют прокси-сервера:
- Поддержка SSL/TLS трафика
- SSL/TLS termination
- Балансировка нагрузки
- Проверка жизнеспособности целевых серверов
- Сжатие содержимого
- Кэширование запросов
- Файрвол/DDoS-защита
- A/B тестирование
Итого, добавляя в ваше приложение прокси сервер, ваша жизнь станет простой и понятной, вы познаете Дзен, начнёте больше общаться с близкими, наладится пищеварение и ...
===========
Источник:
habr.com
===========
Похожие новости:
- [Информационная безопасность, Системное администрирование, DevOps, Kubernetes] Как я сдавал Certified Kubernetes Security
- [Системное администрирование, IT-инфраструктура, DevOps] Изучаем ELK. Часть I — Установка Elasticsearch
- [Системное администрирование, Виртуализация, Серверное администрирование, DevOps] Хранение данных в Docker
- [Системное администрирование, Системное программирование, DevOps] Функции Terraform (перевод)
- [Настройка Linux, DevOps] Что нового добавилось в Terraform v0.13
- [IT-инфраструктура, DevOps] Неужели нельзя обойтись без кафок и рэббитов, когда принимаешь 10 000 ивентов в секунду
- [Git, Управление продуктом, Конференции, DevOps] Acceleration Community Meetup 28/01
- [Информационная безопасность, IT-инфраструктура, Софт, IT-компании] Microsoft рассказала, как хакеры избежали обнаружения при атаке SolarWinds
- [DevOps] Стать инженером DevOps в 2021 году: подробное руководство (перевод)
- [Системное администрирование, Системное программирование, DevOps] Режим высокой доступности HashiCorp Vault (HA) (перевод)
Теги для поиска: #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_itinfrastruktura (IT-инфраструктура), #_nginx, #_meshseti (Mesh-сети), #_devops, #_obratnyj_proksi_server (обратный прокси сервер), #_balansirovschik (балансировщик), #_a/b_testirovanie (a/b тестирование), #_nginx, #_envoy, #_traefik, #_haproxy, #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
), #_itinfrastruktura (
IT-инфраструктура
), #_nginx, #_meshseti (
Mesh-сети
), #_devops
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 16:00
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
На текущий момент есть большое разнообразие обратных прокси серверов. Я перечислю только парочку из них.
 Какую проблему решают прокси сервера?Акт первыйУ нас есть веб-сайт, который не поддерживает HTTPS(т.к. общение по TLS/SSL не программировали). Сказать девелоперам запилить это - легко, а вот самим девелоперам может быть напряжно с реализацией. Если у нас приложение монолит - нам нужно внести изменения в этот, чаще всего не поворотливый агрегат, и доставить это на продакшн, если у нас легкие микросервисы, каждый надо посетить, в каждый надо внести небольшие правки + опять таки всё это доставить.Как решаем проблему? Берем ничем не занятого SysOps/DevOps, говорим, что нам нужен https. Какой-тоOps ставит нам прокси сервер настраивает его на приём HTTPS трафика + SSL termination. Задача решена, цена решения: 1 Какой-тоOps.  Акт второйДа осталось у нас то самое приложение, да сделали инженеры его чтобы оно могло масштабироваться горизонтально, да подняли аж две копии приложения. Супер! Как настроить так, чтобы трафик равномерно на оба поступал?И снова на помощь приходит проски сервер, который выполняет роль "балансировщика нагрузки". Плюс ко всему можно еще и проверку жизнеспособности настроить, вдруг одна копия упадет, зачем же нам расстраивать пользователей. Всех на оставшийся сервер временно расположить, и дело в шляпе. После починки сломанного сервера, прокси сервер вернет его в строй автоматом, и можно дольше себе балансировать.В итоге: двух зайцев, так сказать.Акт третийВзломали нас "хакеры", беда. Дать такому повториться - ну никак нельзя.Что нам для этого нужно? Перспективная китайская разработка - файрвол, чтоб и трафик от нежелательных пользователей фильтровать и от DDoS-атак оборонятся.Чтож, и это проблему поможет нам прокси сервер решить, на него "вещаем" все эти настройки и никакие "хакеры" нашу мега-сесурити не обойдут. Главное настроить правильно, чтобы CEO при демках за хакера не посчитало.  Акт четвертыйТак-так, HTTPS - есть, балансировщик - есть, защита от хакеров - есть, казалось бы, сиди и чиль себе перед телеком, но снова что-то не так. Запросы по сети гуляют долго, пару десятков вообще не вернулись, клиенты в панике.Анализируем проблему, ага, к гадалке - у нас огромный "пэйлоад в запросах" и парочка "популярных" конечных точек (пользователи любят часть сервиса и активно ей пользуются).Чтож, лепим на уровне нашего прокси сервер сжатие запроса и кэшируем на нём ответы серверов приложения. Это что получается? Опять двух зайцев? Так точно!Теперь запросы на холодную возвращаются быстрее некуда, а с кэшом, так и подавно.Акт пятыйПростой мы уже сделали для клиентов нашего приложения жизнь, подумать о себе пора.Новых функций в продакшн страдает доставка что если?A/B тестирование можно настроить с прокси сервера помощью, что лучше может быть, чем отказ системы полный при багах в новом релизе? Правильно, у части пользователей только отказ.После внедрения этой фичи, репутация вашего приложения не будет страдать так сильно, как страдала до внедрения A/B тестирования, т.к. негативные комментарии будут писаться только узким кругом "счастливчиков".  Суммируем выше сказанноеФункции которые предоставляют прокси-сервера:
=========== Источник: habr.com =========== Похожие новости:
Анализ и проектирование систем ), #_itinfrastruktura ( IT-инфраструктура ), #_nginx, #_meshseti ( Mesh-сети ), #_devops |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 16:00
Часовой пояс: UTC + 5