Синтез с выбором ответа по всему юниту трафика: L4 против L7 и алгоритмы балансировки, обратный прокси против шлюза и концентрируемый им SPOF, разделение mesh, а также hit ratio, TTL и что не кэшировать на CDN.
SDSenior◷ 13 min
Уровень
ОсновыJuniorMiddleSenior
Шесть вопросов через весь юнит. Каждый — решение, которое принимаешь, размещая балансировщик, выбирая алгоритм, решая, окупается ли шлюз, или задавая политику кэша CDN — не определение для зубрёжки, а компромиссы L4/L7, алгоритмов, SPOF, mesh и экономики hit ratio под реальной нагрузкой.
Подтверди, что умеешь выбрать верный уровень и алгоритм для балансировщика, увидеть, почему единственный шлюз — SPOF и когда вместо него подходит mesh, провести арифметику hit ratio и отвергнуть кэширование ответа на пользователя на разделяемом edge.
Викторина
Completed
Нужно маршрутизировать запросы по URL-пути и читать cookie маршрутизации, а ещё хочешь ретраи на уровне запроса. Какой уровень балансировщика требуется и какова цена?
Heads-up L4 маршрутизирует только по IP/порту и никогда не парсит HTTP-байты, поэтому не видит путь или cookie и не ретраит запрос. Маршрутизация по содержимому требует L7.
Heads-up Путь и cookie лежат внутри HTTP-сообщения; L4-балансировщик пересылает соединение, не читая его. Чтобы маршрутизировать по содержимому, надо быть на L7.
Heads-up Способность реальна, но не бесплатна: L7 терминирует TLS/TCP, парсит каждый запрос и проксирует два соединения, стоя CPU и задержки. Этот компромисс и есть причина существования L4.
Викторина
Completed
В round-robin пуле из десяти один узел деградирует до 5 с/запрос (остальные ~50 мс), но продолжает принимать соединения. Что с p99 сервиса и какой алгоритм чинит?
Heads-up Round-robin считает запросы, а не времена ответа; он продолжает слать медленному узлу равную долю. Нужен алгоритм с учётом нагрузки или пассивный health-check с учётом задержки.
Heads-up Он доминирует в хвосте: десятая часть запросов получает ответ 5 с, поэтому p99 сервиса идёт за медленным узлом. Хвост следует за худшим сервером, на который ты продолжаешь слать.
Heads-up Медленный — не падающий: базовый health-check видит, что он принимает соединения и отвечает (поздно), и оставляет в ротации. Реагирует только алгоритм с учётом нагрузки или проба с учётом задержки.
Викторина
Completed
Единственный API-шлюз перед 15 сервисами падает на плохом пуше конфига; каждый сервис здоров, но все 15 недостижимы. Какое свойство и какой фикс?
Heads-up Сервисы были здоровы — шлюз не мог в них маршрутизировать. Сконцентрированный отказ — это SPOF шлюза; перезапуск здоровых сервисов его не лечит.
Heads-up Централизация (аутентификация/rate-limit/маршрутизация один раз) ценна. Фикс — устранить SPOF одного инстанса избыточным пулом и поэтапными раскатами, а не удалить.
Heads-up Это воссоздаёт дублирование, которое шлюз решил, и оставляет SPOF маршрутизации. Сделай уровень шлюза избыточным и раскатывай конфиг безопасно.
Викторина
Completed
У сорока сервисов интенсивный трафик сервис-к-сервису с отсутствующими ретраями, несогласованным mTLS и без трассировки. Публичному API тоже нужна одна дверь аутентификации/rate-limit. Какая форма верна?
Heads-up Гнать east-west трафик через шлюз создаёт бог-шлюз и центральное узкое место/SPOF. East-west заботы — в sidecar'ах mesh на инстанс, не в центральном уровне.
Heads-up Mesh ведёт east-west (сервис-к-сервису) заботы; это не публичная дверь. Тебе всё равно нужен шлюз для north-south аутентификации, публичных rate-limit и публичной поверхности API.
Heads-up Это снова проблема дублирования (расходящиеся копии, исходные инциденты). Mesh стандартизирует east-west ретраи/mTLS/трассировку централизованно-конфигурируемо, но локально-исполняемо; шлюз владеет публичным API.
Викторина
Completed
CDN при hit ratio 90% шлёт 20 000 RPS промахов на origin. Чистка ключей поднимает его до 95%. Что примерно с нагрузкой origin?
Heads-up Это линейно по доле ПРОМАХОВ (10% → 5%, то есть вдвое), а не по доле попаданий. Нагрузка origin примерно вдвое. Эта нелинейность и есть причина, почему малые приросты окупаются.
Heads-up Hit ratio — это ровно разгрузка origin: попадание — запрос, который origin не видит. 90% → 95% делит долю промахов вдвое и примерно вдвое срезает RPS origin.
Heads-up Наоборот — больше кэшируется значит меньше промахов доходит до origin. 90% → 95% делит долю промахов вдвое, поэтому нагрузка origin примерно вдвое падает.
Викторина
Completed
Инженер хочет закэшировать аутентифицированную страницу аккаунта (показывает заказы залогиненного пользователя) на разделяемом CDN ради скорости. Каков вердикт и почему?
Heads-up Разделяемый кэш ключуется по URL, а не по пользователю; без private/no-store он может отдать страницу одного пользователя другому. Персонализированные ответы никогда не живут в разделяемом кэше.
Heads-up Короткий TTL всё равно отдаёт закэшированную копию любому, кто запросит этот URL в окне — включая другого пользователя. Дело не в свежести, а в том, что данные на пользователя нельзя делить.
Heads-up Вердикт верный, причина нет: их можно кэшировать в собственном браузере пользователя (Cache-Control: private). Правило — нет РАЗДЕЛЯЕМОГО кэширования контента на пользователя, а не нет кэширования вообще.
Вспомните перед уходом
01
Почему алгоритм с учётом нагрузки бережёт хвост задержки там, где round-robin нет?
02
Как отвергнуть кэширование ответа на пользователя на разделяемом CDN одним предложением?
Итог
Сквозная линия — трафик и периметр это компромиссы, которые улаживаешь до прихода нагрузки. Балансировщику нужен верный уровень (L4 быстр и слеп к протоколу, L7 учитывает содержимое ценой CPU) и верный алгоритм (учитывающие нагрузку least-connections/EWMA берегут хвост; консистентное хеширование хранит локальность кэша). Шлюз централизует аутентификацию/rate-limit/маршрутизацию — выигрыш консистентности, становящийся единой точкой отказа, поэтому он избыточен и тонок, тогда как service mesh ведёт east-west заботы в sidecar’ах на инстанс. CDN живёт или умирает на своём hit ratio, чья экономика нелинейна (90% → 95% делит трафик origin вдвое), и дисциплина — кэшировать одинаковое для всех и безопасное при устаревании и никогда не кэшировать данные на пользователя или обязанные быть верными на разделяемом edge.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.