Можно ли направлять трафик на все серверы приложения через один балансировщик нагрузки?

А, ну ты про это! Слушай, а давай я тебе сейчас такую хуйню расскажу, что ты офигеешь. Вопрос-то вроде простой: «Можно ли всё засунуть в один прокси-сервер?». Ну, типа, и API, и статику, и админку, и микросервисы эти твои, и всё прочее — одним махом, в один nginx-конфиг, и чтоб летало?

Технически-то, ёпта, можно. Конфиг написать — не боги горшки обжигают. Но это, блядь, будет такой анти-паттерн, что мама не горюй! Это как пытаться одной сковородкой накормить всю армию — вроде и помещается, но пиздец как неудобно, и всё пригорит, и половина голодная останется.

Почему это пиздец как плохо (или риски, как говорят умные)

1. Единая точка отказа, или СПОФ (Single Point of Failure). Представь: твой единственный, ненаглядный балансировщик — и вдруг он накрылся медным тазом. Хуй с винтом, отказ по питанию, мартышлюшка-админ что-то не то накосячил. И всё, пиздец! Всё твое приложение, от API до админки, легло пластом. Весь трафик упёрся в мёртвый сервер. Удивление пиздец, да? Вот это и есть SPOF в чистом виде.

2. Бутылочное горлышко производительности. Весь твой трафик, сука, как в воронку, льётся через одну железку. А она, блядь, не резиновая! CPU упрётся в потолок, память кончится, сетевая карта захлебнётся. И получится, что у тебя кластер из сотни мощных серверов стоит, а пользователи ждут, потому что один-единственный балансировщик не справляется. Э, сабака сука, э бошка думай!

3. Конфигурация превращается в ад. Ты представляешь, какой пиздопроебибнный конфиг получится? Тысячи строк правил для десятков сервисов. Захотел поменять что-то в API — перечитал весь файл, блядь, на десять килобайт, ищешь глазами нужный location. Ошибся запятой — и упало всё разом. Поддержка и отладка такого монстра — это волнение ебать, терпения ноль ебать.

4. Огромный радиус поражения (Blast Radius). Сделал ты ошибку в настройке для какого-нибудь левого микросервиса «отчёты-за-пятницу». Перезагрузил nginx, а он, сука, не взлетел из-за синтаксической ошибки. И что? А ничего! Всё приложение, включая главный сайт и API, стало недоступно. Вот это я понимаю — доверия ебать ноль к такой архитектуре.

Так как же правильно, спросишь ты?

А правильно — не быть жадным и не лепить всё в одну кучу. Разделяй и властвуй, блядь!

• По смыслу: Пусть один балансировщик крутит только API (api.example.com), другой — только статику и фронтенд (www.example.com), третий — для внутренней движухи между микросервисами.
• По важности: Критичный платежный шлюз — на отдельной, мощной и хорошо защищённой железяке. А всякая админка для контент-менеджеров — пусть себе живёт на чём попроще.
• Чтобы не было SPOF: Даже для одного логического сервиса (того же API) ставь не один балансировщик, а HA-пару (High Availability). Они между собой договариваются, кто главный, с помощью, например, Keepalived/VRRP. Упал один — второй тут же подхватывает его IP-адрес и трафик. Красота!

Ну и примерчик для наглядности, куда ж без него

Вот смотри, как примерно выглядит нормальная, не распиздяйская конфигурация для группы серверов:

# Группа серверов (апстрим), на которую будет распределяться нагрузка
upstream backend_api {
    # Алгоритм балансировки (по умолчанию round_robin)
    # least_conn; # передать запрос серверу с наименьшим числом активных соединений
    # ip_hash;    # направить клиента на тот же сервер, что и в прошлый раз

    server 10.0.0.1:8080; # Сервер 1
    server 10.0.0.2:8080; # Сервер 2
}

server {
    listen 80;
    server_name api.example.com;

    location / {
        proxy_pass http://backend_api;
        # Обязательно настраивать health checks для автоматического
        # исключения "упавших" серверов из ротации.
    }
}

Видишь? Чётко, ясно, изолированно. Упали бэкенды — это проблемы API. А статика-то твоя продолжает работать! Вот так и надо, а не собирать все яйца в одну корзину, которая, как назло, всегда падает в самую глубокую лужу.