3.16 API-шлюзы и сервисная сетка

Обзор и мотивация

В момент, когда вы разбиваете одну программу на много сервисов, возникает новый вопрос: кто отвечает за трафик между ними и за трафик, приходящий снаружи? Вы можете ответить на него плохо, вручную разбрасывая одни и те же заботы (аутентификацию, повторы, тайм-ауты, ограничения частоты, журналирование) по каждому сервису, или ответить хорошо, перенеся эти заботы в общий слой, который каждый сервис наследует даром. Эта глава о двух таких слоях. API-шлюз стоит у парадной двери и управляет трафиком, приходящим от клиентов. Сервисная сетка стоит между вашими сервисами и управляет трафиком, текущим между ними. Они решают родственные проблемы в разных местах, и путаница между ними частая и дорогая ошибка.

Отрасль называет два направления трафика метафорой компаса. Трафик «север-юг» пересекает границу вашей системы: мобильное приложение, браузер или партнёр, звонящий снаружи. Трафик «восток-запад» остаётся внутри вашей системы: сервис A вызывает сервис B, который вызывает сервис C, чтобы удовлетворить один запрос. API-шлюз специалист по «север-юг». Сервисная сетка специалист по «восток-запад». Чёткое удержание этого различия единственная самая полезная идея главы, потому что она говорит, какой инструмент владеет какой политикой, и не даёт вам делать одну и ту же работу дважды.

Для больших команд эти слои способ принудить политику один раз, а не сто. Когда аутентификация, шифрование при передаче и ограничение частоты живут в общем слое, исправление безопасности доходит до каждого сервиса в день развёртывания слоя, а не ждёт в сотне бэклогов. В корпоративной и государственной среде эта централизация нередко и есть суть: аудиторы хотят единственное доказуемое место, где проверяется доступ и шифруется трафик, а общий шлюз или сетка дают им именно такую точку принуждения политики. Эта глава опирается на архитектурные стили главы 3.2, реалии распределённых систем главы 3.3 и основы сетей главы 3.13 и превращает их в конкретное руководство о том, кто обрабатывает ваш трафик.

Ключевые принципы

Разделяйте «север-юг» (шлюз) и «восток-запад» (сетка); пусть каждый владеет своим направлением.
Переносите сквозные заботы в общий слой, чтобы писать их один раз, а не на сервис.
Принимайте сервисную сетку, только когда число сервисов делает проводку на сервис большей ценой.
Определяйте одну точку принуждения политики на заботу; никогда не позволяйте шлюзу и сетке обоим выполнять одну и ту же работу.
Держите сервисы тонкими: платформа обрабатывает транспорт, сервис обрабатывает бизнес-логику.
Предпочитайте сети на основе идентичности с нулевым доверием доверию по расположению в сети.
Покупайте эксплуатационную сложность сетки с открытыми глазами и измеряйте, окупается ли она.

Рекомендации

Понимайте, что делает API-шлюз

API-шлюз это единая точка входа, стоящая перед вашими сервисами и посредничающая в каждом запросе из внешнего мира. В простейшем виде это умный обратный прокси (сервер, принимающий клиентские запросы и пересылающий их нужному бэкенду), но шлюз зарабатывает своё имя, делая гораздо больше, чем пересылка. Он маршрутизирует каждый запрос к нужному сервису по пути, хосту или заголовкам. Он аутентифицирует вызывающего (проверяя, кто он) и авторизует запрос (проверяя, что ему можно), так что сервис за ним может доверять, что запрос уже прошёл парадную дверь. Он принуждает к ограничению частоты (потолок запросов на клиента за время) и квотам (потолок общего использования за более длинное окно), чтобы один шумный или злоупотребляющий клиент не обездолил остальных.

Шлюз также преобразует трафик. Преобразование запросов переписывает заголовки, переводит между протоколами или приспосабливает формат старого клиента к ожиданиям нового сервиса. Композиция API позволяет шлюзу разветвить один входящий запрос на несколько сервисов и сшить их ответы в один, так что клиент делает один вызов вместо шести. Поддержка версионирования позволяет запускать v1 и v2 API бок о бок и направлять каждого клиента к ожидаемой версии, что покупает пространство для эволюции без поломки кого-либо. Сосредоточение этих забот на краю держит ваши сервисы сфокусированными на бизнес-логике и даёт одно место для наблюдения, защиты и ограничения всего входящего. Проектирование API, которые шлюз прикрывает, предмет главы 2.3, а проверки идентичности, которые он выполняет, опираются на главу 4.7.

Используйте шаблон «бэкенд для фронтенда» для расходящихся клиентов

Один универсальный API нередко обслуживает веб-приложение, мобильное приложение и партнёрские интеграции сразу и обслуживает всех слегка плохо. Мобильному клиенту нужны малые полезные нагрузки и мало круговых обходов, потому что пропускная способность и батарея дефицитны; веб-клиент справляется с более болтливыми, богатыми ответами; партнёру нужен стабильный контракт, никогда не удивляющий. Шаблон «бэкенд для фронтенда» (BFF) разрешает это напряжение, давая каждому классу клиентов свой тонкий шлюз, подогнанный под его потребности и стоящий перед общими сервисами за ним.

BFF это шлюз с более узкой аудиторией. Мобильный BFF составляет и обрезает ответы, чтобы приложение делало один эффективный вызов; веб-BFF открывает более полную форму; партнёрский BFF держит медленно меняющийся, тщательно версионируемый контракт. Каждая команда может развивать свой BFF, не дожидаясь остальных, что часто и есть настоящая выгода, потому что она отвязывает клиентские команды друг от друга. Цена больше подвижных частей и некоторая дублированная логика между BFF, поэтому оставляйте шаблон для случаев, где потребности клиентов действительно расходятся. Когда все клиенты хотят одного и того же, один шлюз проще и лучше.

Понимайте, что делает сервисная сетка

Сервисная сетка управляет трафиком «восток-запад» между вашими сервисами и делает это, не требуя от этих сервисов менять код. Классическая сетка работает, развёртывая прокси-«коляску» (sidecar), небольшой процесс прокси, работающий рядом с каждым экземпляром сервиса и перехватывающий весь его сетевой трафик. Ваш сервис думает, что говорит прямо с другим сервисом; на деле он говорит со своей локальной «коляской», которая выполняет настоящий сетевой вызов. Поскольку каждый запрос теперь течёт через прокси, контролируемый платформой, сетка может принуждать к поведению единообразно по каждому сервису, на каждом языке, без общей библиотеки, которую нужно держать синхронной.

Что она принуждает? Во-первых, взаимный TLS (mTLS), когда обе стороны каждого соединения предъявляют сертификаты и шифруют трафик, так что вызовы между сервисами по умолчанию аутентифицированы и приватны. Во-вторых, управление трафиком: сетка может перенаправить малый процент трафика на новую версию для канареечного выпуска, разделить трафик по заголовку для тестирования или зеркалировать трафик на теневой сервис. В-третьих, устойчивость: повторы, тайм-ауты и предохранители (шаблоны главы 2.20), применяемые на платформенном уровне и настраиваемые политикой, а не закодированные в каждый сервис. В-четвёртых, наблюдаемость: поскольку каждый запрос проходит через прокси, сетка испускает согласованные метрики, журналы и распределённые трассировки для всего трафика между сервисами, питая практики наблюдаемости главы 9.2. Автор сервиса не пишет ничего из этого и получает всё.

Знайте шаблон sidecar и альтернативы без sidecar

Модель sidecar элегантна, но не бесплатна. Каждый экземпляр сервиса теперь запускает дополнительный контейнер прокси, потребляющий память и процессор, а каждый вызов делает два лишних сетевых перехода (в локальную «коляску» и из удалённой), добавляя немного задержки. На горстке сервисов эти накладные расходы невидимы; на тысячах подов они становятся реальной строкой в вашем счёте за вычисления и бюджете задержки. Эта цена породила волну подходов без sidecar, или без прокси.

Важны два направления. Одно переносит функции сетки из sidecar на каждый под в прокси на каждый узел, так что многие сервисы на одной машине делят один прокси, а не запускают каждый свой; это меняет часть изоляции на большое снижение накладных расходов. Другой, беспрокси-подход встраивает логику сетки прямо в сервис через тонкую библиотеку или среду выполнения, полностью убирая лишние переходы ценой зависимости по языкам. Более новая разработка переносит некоторые функции сетки в ядро операционной системы с помощью eBPF (технологии запуска изолированных программ внутри ядра Linux), которая может принуждать к политике и собирать телеметрию с меньшими накладными расходами, чем прокси в пользовательском пространстве. Вам не нужно ставить на одного победителя сегодня. Вам нужно знать, что налог sidecar реален, что альтернативы существуют и что ваш платформенный выбор не должен закрывать вам возможность принять их позже. Эти шаблоны стоят на фундаменте оркестрации контейнеров из главы 8.3.

Решайте, когда сетка оправдывает свою сложность

Сервисная сетка мощна и по-настоящему сложна в эксплуатации. Она добавляет плоскость управления для эксплуатации, прокси для обновления, сертификаты для ротации и новый слой для отладки, когда запрос пропадает. Эту сложность стоит покупать, когда сервисов достаточно, чтобы ручная проводка этих забот, на сервис и на язык, стоила больше эксплуатации сетки. Грубый сигнал масштаб и полиглотное разнообразие: десятки или сотни сервисов, написанных на нескольких языках, где общую библиотеку для mTLS и повторов было бы кошмаром поддерживать согласованной. В таком масштабе сетка окупается единообразием и доказуемой безопасностью.

Сетка не оправдывает сложность, когда у вас горстка сервисов, один язык или малая команда. Для скромной системы хорошая библиотека или фреймворк могут дать mTLS, повторы и метрики с гораздо меньшим эксплуатационным бременем, чем полная сетка, а простой шлюз с разумными клиентскими библиотеками нередко покрывает всё нужное. Принятие сетки потому, что это модно, до того как этого требует ваш масштаб, частый способ потратить год на эксплуатацию инфраструктуры, решающей проблему, которой у вас нет. Начните со шлюза, добавляйте шаблоны устойчивости в коде или библиотеках и тянитесь к сетке, когда число сервисов и языков делает подход на сервис более дорогим. Это та же дисциплина «оправдывает ли это свою сложность», к которой облачная глава и глава о распределённых системах (3.11 и 3.3) возвращаются снова и снова.

Избегайте двойной обработки там, где шлюз и сетка перекрываются

Шлюзы и сетки перекрываются, и в этом перекрытии команды вредят себе. Оба могут делать повторы, оба могут принуждать к тайм-аутам, оба могут проверять идентичность, оба могут собирать телеметрию. Если шлюз повторяет запрос три раза, а сетка также повторяет его три раза на каждом внутреннем переходе, один повтор клиента может взорваться в десятки вызовов бэкенда и превратить небольшой сбой в шторм повторов. Если оба слоя принуждают к тайм-ауту, а внутренний длиннее внешнего, внешний сдаётся, пока внутренний продолжает работать, впустую тратя усилия на ответ, который никто не прочтёт.

Исправление это ясное разделение труда, записанное и согласованное. Назначайте каждую заботу ровно одному слою. Шлюз владеет заботами «север-юг»: аутентификация конечного пользователя, внешние ограничения частоты и квоты, преобразование запросов и композиция API для клиентов. Сетка владеет заботами «восток-запад»: mTLS между сервисами, внутренние повторы и предохранители и перенаправление трафика между версиями сервисов. Где забота могла бы жить в любом, выберите одного владельца и сделайте так, чтобы другой слой пропускал. Настраивайте бюджеты повторов и иерархии тайм-аутов так, чтобы внешний тайм-аут всегда был длиннее внутренней работы, которой он ждёт. Цель в том, чтобы у каждого запроса было ровно одно место, обрабатывающее каждую заботу, и ни один запрос не повторялся, не аутентифицировался и не журналировался дважды случайно.

Воспринимайте шлюз и сетку как точки принуждения политики для нулевого доверия

Глубочайшая причина запускать эти слои архитектура безопасности. Нулевое доверие это принцип, что ни один запрос не пользуется доверием из-за того, откуда он пришёл; каждый запрос должен доказать свою идентичность и авторизацию, даже внутри вашей собственной сети. Старая модель доверяла всему, что уже внутри периметра, а значит один взломанный сервис мог свободно бродить. Нулевое доверие заменяет доверие по расположению в сети доверием на основе идентичности на каждом переходе, а шлюзы и сетки естественные точки принуждения, где эта идентичность проверяется.

Шлюз это точка принуждения политики для внешней идентичности: он проверяет конечного пользователя или партнёра до того, как что-либо достигнет ваших сервисов. Сетка это точка принуждения политики для идентичности рабочей нагрузки: каждый сервис получает криптографическую идентичность, mTLS доказывает её при каждом вызове, а политика решает, какие сервисы могут общаться с какими. Вместе они дают защиту в глубину, когда запрос проверяется на краю и снова между сервисами, так что компрометация одного сервиса не даёт свободы движения остальным. В развёртываниях по нескольким кластерам и регионам сетка может распространить эту ткань идентичности через границы кластеров, так что сервис в одном кластере аутентифицируется перед сервисом в другом с теми же гарантиями mTLS, что и локально, давая согласованные сети с нулевым доверием, даже когда след растёт. Основы идентичности здесь прямо связаны с главой 4.7.

Компромиссы: плюсы и минусы

Подход	Плюсы	Минусы
API-шлюз	Одно место для аутентификации, ограничений частоты, композиции, версионирования	Единая точка сужения для масштабирования и поддержания высокой доступности
Бэкенд для фронтенда	Каждый клиент получает подогнанный независимо развивающийся API	Больше шлюзов для эксплуатации; логика дублируется между BFF
Сервисная сетка (sidecar)	Единообразные mTLS, повторы, наблюдаемость без изменения кода	Накладные расходы прокси, задержка и плоскость управления для эксплуатации
Сетка без sidecar / без прокси	Меньше накладных расходов и задержки, чем у sidecar на под	Менее зрела; более слабая изоляция или зависимость по языкам
Устойчивость на библиотеках	Просто эксплуатировать; нет дополнительной инфраструктуры	Дублирование по языкам; трудно держать согласованным в масштабе
Сетка между кластерами	Согласованная идентичность с нулевым доверием повсюду	Значительная эксплуатационная и сетевая сложность

Центральное напряжение это единообразие против эксплуатационной цены. Общий слой покупает согласованность, доказуемую безопасность и политику, которую вы пишете один раз, но это реальная система, которую вы должны эксплуатировать, масштабировать, защищать и отлаживать, и она вставляется в путь каждого запроса. Разрешайте напряжение масштабом и потребностью. Шлюз почти всегда окупается в момент появления внешних клиентов, потому что централизуемые им заботы неизбежны. Сетка окупается позже, когда число сервисов и языков делает проводку на сервис более дорогим путём. Ниже этого порога библиотеки и простой шлюз дают большую часть выгоды за долю цены. Выше него единообразие сетки стоит своего веса. Ошибка в обе стороны принятие по моде, а не по нужде: сетка слишком рано это год бессмысленной возни, а сетка, пропущенная слишком поздно, сотня несогласованных самодельных реализаций mTLS.

Вопросы для обсуждения с командой

Какой единственный слой владеет каждой сквозной заботой (аутентификация, повторы, тайм-ауты, ограничение частоты, шифрование, телеметрия) и все ли могут назвать владельца, не гадая? Этот вопрос предотвращает двойную обработку, и большинство команд ни разу не отвечали на него явно, а значит ответ различается по сервису и автору. Принесите конкретный список забот по левой стороне и ваши слои (клиентская библиотека, шлюз, сетка, отдельный сервис) сверху и заполните сетку вместе. Места, где для одной заботы отмечены две клетки, это ваши штормы повторов и инверсии тайм-аутов, ждущие своего часа. Пустые строки это заботы, которыми не занимается никто. Результат единая согласованная таблица, опубликованная там, где её видит каждая команда, говорящая, что ровно один слой владеет каждой заботой, а остальные пропускают. Эта таблица стоит больше любого количества конфигурации шлюза или сетки, потому что именно она не даёт двум слоям сражаться друг с другом.
Достаточно ли у нас на самом деле сервисов и языкового разнообразия, чтобы оправдать сервисную сетку, или мы собираемся купить плоскость управления для решения проблемы, которой у нас нет? Сетка серьёзное эксплуатационное обязательство, и честный ответ для многих команд в том, что хорошая библиотека плюс шлюз послужили бы им сегодня лучше. Принесите реальное число ваших сервисов, число языков, на которых они написаны, и честную оценку того, насколько дублированная сетевая логика реально вредит вам сейчас. Затем принесите другую сторону: кто будет эксплуатировать сетку, обновлять её прокси, ротировать сертификаты и получать вызов, когда она неверно маршрутизирует запрос. Если боль проводки на сервис меньше цены эксплуатации сетки, у вас есть ответ, и он ждать. Если вы тонете в несогласованном коде mTLS и повторов по десяткам полиглотных сервисов, сетка отрабатывает своё. Суть в том, чтобы решать по свидетельствам, а не по тому, как сетка выглядела в докладе на конференции.
Где сегодня проходит наша граница нулевого доверия и что произойдёт, если будет скомпрометирован один внутренний сервис? Многие системы по-прежнему доверяют всему, что уже внутри сети, а значит один взломанный сервис может двигаться вбок и достигать всего остального, и команды часто обнаруживают это только во время инцидента. Честно пройдите по радиусу поражения: если атакующий владеет одним из ваших сервисов, что он может вызвать, что прочитать и что его останавливает? Принесите ваш текущий ответ о том, как вызовы между сервисами аутентифицируются и шифруются, и будьте конкретны, какие вызовы защищены mTLS, а какие это открытое доверие по нахождению в одной сети. Следующее действие намеренный план доступа на основе идентичности на каждом переходе, где шлюз проверяет внешнюю идентичность, а сетка или эквивалент проверяет идентичность рабочей нагрузки, так что компрометация локализуется, а не катастрофична. Даже если вы не готовы запускать полную сетку, назвать, где граница доверия действительно проходит, первый честный шаг.
Если бы наш уровень API-шлюзов отказал прямо сейчас, какая часть системы погасла бы и тестировали ли мы этот отказ, а не списывали его со счетов? Шлюз централизует так много, что его отказ выводит из строя всё за ним, и большие команды склонны недоинвестировать в его избыточность именно потому, что он работает тихо, пока не перестаёт. Взвесьте конкурирующие тяготения: единый простой шлюз легко осмыслить и дёшево эксплуатировать, тогда как горизонтально масштабируемый многозонный уровень стоит больше и добавляет собственную конфигурацию переключения при отказе и сложность. Принесите на обсуждение реальные числа, включая то, сколько экземпляров работает сегодня, в скольких зонах доступности, каково время переключения и когда вы в последний раз проводили учения, намеренно убивавшие шлюз. Для корпоративных и государственных платформ с обязательствами по времени безотказной работы или установленными законом уровнями обслуживания добавьте договорный или регуляторный штраф за простой, потому что парадная дверь без избыточности это риск доступности, который вы тихо приняли от имени каждого сервиса и каждого гражданина за ней.
Измерили ли мы налог sidecar, который наша сетка на самом деле взимает, и есть ли у нас план по альтернативам без sidecar и на eBPF или мы платим вслепую? В масштабе накладные расходы прокси на под в вычислениях и задержке перестают быть невидимыми и становятся реальной строкой бюджета, однако многие команды запускают тысячи sidecar, ни разу не измерив цену. Напряжение между зрелостью и изоляцией модели sidecar с одной стороны и меньшими накладными расходами прокси на узел, беспрокси библиотек или подходов eBPF на уровне ядра с другой, которые новее и меняют часть изоляции или добавляют зависимость по языкам. Принесите измеренные числа: память и процессор, потребляемые прокси по парку, добавленную хвостовую задержку на переход и какую долю вашего счёта за вычисления представляет сетка. Для большой корпорации, запускающей сетку на тысячах подов, или государственной платформы под бюджетным контролем это решение о расходах, о котором надзор в итоге спросит, поэтому знание налога и сохраняет ли ваш платформенный выбор открытыми более дешёвые альтернативы базовая должная осмотрительность.
Действительно ли каждому классу клиентов нужен собственный бэкенд для фронтенда или мы собираемся дублировать логику между шлюзами для клиентов, которые на самом деле хотят одного и того же? Шаблон BFF отвязывает клиентские команды и позволяет каждой развивать подогнанный контракт, но каждый новый BFF ещё один шлюз для эксплуатации, защиты и синхронизации, а дублированная между ними логика тихо становится налогом на сопровождение. Конкурирующие соображения автономия команд и клиентская эффективность против эксплуатационной цены и дрейфа многих почти одинаковых шлюзов. Принесите свидетельства того, насколько потребности клиентов действительно расходятся: размеры полезной нагрузки, число круговых обходов, ритм версионирования и как часто изменение одного клиента заблокировало бы другого при едином общем шлюзе. В большой организации со многими клиентскими командами или государственной платформе, обслуживающей публичное веб-приложение, мобильное приложение и партнёрские интеграции сразу, честный вопрос в том, оправдывает ли расхождение размножение, потому что BFF на клиента, который хочет ту же форму, это расползание, за сопровождение которого вы будете платить годами.

Взгляд по секторам

Стартап. Поставляйте API-шлюз и пропустите сетку. С горсткой сервисов и крошечной командой единый шлюз обрабатывает аутентификацию, ограничения частоты и композицию, а общая клиентская библиотека даёт mTLS и повторы за долю цены плоскости управления. Ваш самый дефицитный ресурс инженерное внимание, поэтому сетка, которую вы не можете эксплуатировать, обязательство, а не ров. Держите шлюз достаточно избыточным, чтобы пережить смерть одного узла, и возвращайтесь к вопросу о сетке только когда число сервисов и языковое разнообразие действительно вынудят.

Малый бизнес. У вас нет платформенной команды для эксплуатации сетки, поэтому опирайтесь на то, что ваша платформа хостинга или продукт-шлюз даёт из коробки: управляемый TLS, встроенное ограничение частоты и размещённый шлюз, а не тот, что вы патчите сами. Формулируйте выбор как «купить или построить» и покупайте, потому что управляемый API-шлюз стоит меньше инженерных часов на эксплуатацию собственного. Воспринимайте внутреннее шифрование между сервисами как функцию, которую даёт ваша платформа, а не проект, которым вы укомплектовываете.

Крупная организация. С сотнями сервисов по многим командам и языкам сетка оправдывает свою сложность, и настоящая работа в управлении: одно записанное разделение труда, чтобы шлюз и сетка никогда не обрабатывали заботу дважды, единообразные mTLS и телеметрия и платформенная команда, владеющая обновлениями прокси и ротацией сертификатов. Аудиторам нужна единственная доказуемая точка принуждения для доступа и шифрования, поэтому стандартизируйте интерфейс и делайте политику тем, что команды наследуют, а не реализуют заново. Управляйте налогом sidecar как реальной строкой бюджета и держите варианты без sidecar открытыми, чтобы позже вам не закрыли доступ к более дешёвым подходам.

Государственный сектор. Правила закупок, прозрачность и публичная подотчётность определяют архитектуру. Воспринимайте шлюз и сетку как хребет нулевого доверия, которого ожидают регуляторы: каждый гражданин и партнёр аутентифицирован у парадной двери, каждый внутренний вызов аутентифицирован и зашифрован по идентичности рабочей нагрузки, а след аудита в каждой точке принуждения доказывает, где проверялся доступ и где шифровался трафик. Отдавайте предпочтение открытым стандартам и переносимой конфигурации, а не проприетарной привязке, которую могут запретить правила закупок, и публикуйте, где уместно, как платформа защищает данные граждан при пересечении каждой границы.

Примеры

Стартап. Стартап из двенадцати человек запускает восемь сервисов за единым API-шлюзом. Шлюз выполняет всю работу «север-юг»: аутентифицирует пользователей проверкой токена, принуждает к ограничениям частоты по тарифам, чтобы пользователи бесплатного уровня не могли завалить систему, и составляет пару болтливых конечных точек в одиночные удобные для мобильных вызовы. Для трафика «восток-запад» они намеренно пропускают сервисную сетку, потому что восемь сервисов на двух языках не оправдывают плоскость управления. Вместо этого они получают mTLS и повторы из общей клиентской библиотеки и встроенного управления сертификатами платформы и собирают трассировки лёгким агентом. Когда позже они добавляют отдельный мобильный клиент с более жёсткими потребностями в полезной нагрузке, они вводят мобильный «бэкенд для фронтенда» рядом с существующим веб-шлюзом. Они пересматривают вопрос о сетке каждый год и продолжают решать, верно, что порога, на котором она окупилась бы, пока не пересекли.

Крупная организация. Международный банк ведёт несколько сотен сервисов по многим командам и языкам, и здесь сервисная сетка оправдывает свою сложность. Каждый сервис по умолчанию получает идентичность рабочей нагрузки и mTLS, так что весь внутренний трафик аутентифицирован и зашифрован без того, чтобы какая-либо команда писала криптографический код, что удовлетворяет и службу безопасности, и аудиторов, желающих единственную доказуемую точку принуждения. Сетка применяет единообразные повторы, тайм-ауты и предохранители политикой и постепенно перенаправляет трафик для канареечных выпусков, так что плохое развёртывание затрагивает один процент пользователей, прежде чем коснётся всех. Уровень API-шлюзов прикрывает внешний и партнёрский трафик, владея аутентификацией, квотами и версионированием, с твёрдым записанным правилом, что внутренние повторы живут только в сетке, а внешние ограничения частоты только в шлюзах, так что два слоя никогда не обрабатывают запрос дважды. Согласованная телеметрия от каждого прокси питает центральную платформу наблюдаемости, позволяющую одному дежурному инженеру проследить запрос через десятки переходов между сервисами.

Государственный сектор. Национальная налоговая служба модернизирует платформу подачи деклараций для граждан и воспринимает шлюз и сетку как хребет архитектуры нулевого доверия, которой требуют регуляторы. API-шлюз контролируемая парадная дверь: каждый гражданин и партнёр аутентифицируется и авторизуется там, внешние ограничения частоты защищают систему во время всплеска в день срока подачи, а старые форматы клиентов преобразуются на краю, чтобы унаследованные интеграции продолжали работать. За ним сервисная сетка даёт каждому внутреннему сервису криптографическую идентичность и принуждает к mTLS при каждом вызове, так что ни один сервис не пользуется доверием просто за нахождение внутри сети, а политика доступа явно перечисляет, какие сервисы могут вызывать какие. Поскольку платформа охватывает несколько центров обработки данных для устойчивости, сетка распространяет те же гарантии идентичности и шифрования через кластеры, давая согласованное сетевое нулевое доверие по всей стране. Каждая точка принуждения испускает след аудита, так что служба может доказать надзорным органам, где именно проверялся доступ и где шифровался трафик.

Бизнес-обоснование: мотивы, ROI и TCO

Отдача от шлюза легко видна и обычно велика. Вместо того чтобы каждый сервис заново реализовывал аутентификацию, ограничение частоты и журналирование запросов, вы строите это один раз на краю, и каждый сервис наследует. Исправление безопасности или новая политика ограничения частоты выходит за одно развёртывание, а не за сто, что сокращает время закрытия уязвимости и снижает стоимость каждого аудита, потому что есть единственное место для проверки. Функции композиции и версионирования сокращают круговые обходы клиентов и позволяют развивать API, не ломая вызывающих, что снижает и затраты на задержку, и налог на координацию между командами. Почти для любой системы с внешними клиентами шлюз быстро окупается.

У сервисной сетки более тонкое бизнес-обоснование, потому что её совокупная стоимость владения реальна и постоянна. Вы платите за вычисления и задержку прокси, за инженеров, эксплуатирующих плоскость управления, и за кривую обучения отладки нового слоя. Эта цена оправдана, когда альтернатива (реализации mTLS, повторов и телеметрии на сервис и на язык) была бы больше и, хуже того, несогласованной способами, создающими дыры в безопасности и отказы. В высоком масштабе сетка превращает сотню хрупких самодельных решений в одно единообразное доказуемое, и отдача проявляется как меньше инцидентов безопасности, более быстрые безопасные развёртывания через перенаправление трафика и резко лучшая наблюдаемость. Ниже этого масштаба честный расчёт нередко в пользу библиотек и шлюза, и дисциплинированный ход ждать. Чтобы обосновать это перед руководством, свяжите шлюз с метриками, которые оно уже отслеживает (время устранения уязвимостей, стоимость аудита, накладные расходы координации API), а сетку с локализацией инцидентов безопасности, безопасностью развёртываний и стоимостью полиглотного дублирования, которое она заменяет.

Антипаттерны и ловушки

Сетка до того, как она нужна: принятие полной сервисной сетки на горстке сервисов, покупка плоскости управления для решения проблемы, которой у вас ещё нет.
Двойные повторы: шлюз и сетка оба повторяют, так что один вызов клиента умножается в шторм повторов бэкенда, усиливающий отказ.
Инверсия тайм-аутов: внутренний тайм-аут длиннее внешнего, так что вызывающий сдаётся, пока вызываемый продолжает работать над ответом, который никто не прочтёт.
Шлюз как монолит: запихивание бизнес-логики в шлюз, пока он не станет общим узким местом, изменение которого должна согласовывать каждая команда.
Единая точка отказа: запуск одного экземпляра шлюза без избыточности, так что отказ парадной двери выводит из строя каждый сервис за ней.
Доверие сети: воспринимание всего внутри периметра как безопасного, так что один скомпрометированный сервис может двигаться вбок и достигать всего.
Перекрывающееся владение: нет записанного разделения труда, поэтому одна забота случайно обрабатывается в обоих слоях и никто не знает, какой авторитетен.
Расползание BFF: создание «бэкенда для фронтенда» на каждого клиента, когда клиенты хотят одного и того же, умножение шлюзов и дублирование логики без выгоды.
Игнорирование налога sidecar: развёртывание тысяч sidecar без измерения накладных расходов на вычисления и задержку с последующим удивлением, куда ушёл бюджет.

Модель зрелости

Уровень 1, Начальный: Сервисы общаются напрямую без общего слоя. Аутентификация, повторы и тайм-ауты закодированы вручную на сервис и непоследовательны. Внутренний трафик нередко открытый и пользуется доверием за нахождение в сети, и нет единого места для принуждения политики или наблюдения за трафиком. Решения реактивны и принимаются сервис за сервисом по мере проявления проблем.
Уровень 2, Развитие: API-шлюз прикрывает внешний трафик и централизует аутентификацию, ограничение частоты и маршрутизацию, но заботы «восток-запад» обрабатываются общими библиотеками с неравномерным принятием. У некоторых сервисов есть mTLS; у многих нет. Команды осознают различие «север-юг» и «восток-запад», но владение неформально, а практики различаются от команды к команде.
Уровень 3, Стандартизация: Заботы «север-юг» и «восток-запад» чисто разделены с записанным разделением труда, применяемым по организации. Шлюз владеет внешней идентичностью, квотами и композицией; сетка или согласованный слой библиотек владеет внутренним mTLS, повторами и телеметрией. Перекрытия разрешены, так что ни одна забота не обрабатывается дважды, внутренний трафик по умолчанию зашифрован и проверен по идентичности, а стандарт документирован и принуждается, а не оставлен на усмотрение каждой команды.
Уровень 4, Управление: Слой трафика измеряется и контролируется относительно базовых значений. Вы отслеживаете налог sidecar в вычислениях и хвостовой задержке на переход, доступность шлюза и сетки относительно бюджетов ошибок, инциденты усиления повторов и инверсии тайм-аутов, покрытие mTLS как процент внутренних вызовов и время распространения изменения политики по парку. Метрики управляют решениями: обновление прокси, новый бюджет повторов или правило канарейки оцениваются по данным относительно базового значения, а не по интуиции, а любой дрейф от стандарта запускает исправление.
Уровень 5, Оркестрация: Шлюз и сетка точки принуждения политики зрелой архитектуры с нулевым доверием, где идентичность проверяется на каждом переходе по кластерам и регионам. Перенаправление трафика обеспечивает безопасную прогрессивную поставку, наблюдаемость единообразна и богата, а организация непрерывно оценивает и принимает подходы без sidecar, без прокси и на eBPF там, где они окупаются. Слой трафика интегрирован с безопасностью, поставкой и планированием мощности и адаптируется по мере сдвигов масштаба, языков и картины рисков.

Идеи для обсуждения

Если бы ваш единственный API-шлюз прямо сейчас отказал, сколько сервисов стало бы недоступно и каков ваш план резервирования парадной двери?
Какая забота в вашей системе сейчас обрабатывается и в шлюзе, и в сервисе (или библиотеке) и как вы докажете, что она не обрабатывается дважды?
При каком числе сервисов и языков ваша команда согласилась бы, что сетка наконец оправдала свою сложность, и как далеко вы от этой черты?
Если бы завтра атакующий скомпрометировал один внутренний сервис, до каких других сервисов он мог бы дотянуться и какая проверка идентичности его остановила бы?
Достаточно ли зрелы для вашей платформы уже подходы сетки без sidecar или на eBPF и что вы измерили бы, чтобы решить?
Действительно ли каждому из ваших расходящихся клиентов нужен собственный «бэкенд для фронтенда» или вы собираетесь дублировать логику, которая могла бы остаться общей?

Главные выводы

Разделяйте трафик «север-юг» (его обрабатывает API-шлюз) и «восток-запад» (его обрабатывает сервисная сетка); каждый владеет своим направлением, а путаница между ними вызывает двойную обработку.
Шлюз централизует маршрутизацию, аутентификацию, авторизацию, ограничение частоты, квоты, преобразование запросов, композицию и версионирование, так что сервисы остаются тонкими, а политика живёт в одном месте.
Сервисная сетка даёт mTLS, перенаправление трафика, повторы и предохранители на уровне платформы и единообразную наблюдаемость без изменения кода сервисов, классически через прокси sidecar.
Принимайте сетку, только когда число сервисов и языков делает проводку на сервис более дорогим путём; ниже этого побеждают библиотеки плюс шлюз, а налог sidecar достаточно реален, чтобы за ним следить.
Воспринимайте шлюз и сетку как точки принуждения политики архитектуры с нулевым доверием, назначайте каждую сквозную заботу ровно одному слою и проверяйте идентичность на каждом переходе по кластерам.

Источники и дополнительное чтение

Sam Newman, Building Microservices: Designing Fine-Grained Systems
Chris Richardson, Microservices Patterns: With Examples in Java
Lee Calcote and Zack Butcher, Istio: Up and Running
Ken Owens, Alois Reitbauer, and others; the CNCF Cloud Native Landscape and service mesh documentation
Evan Gilman and Doug Barth, Zero Trust Networks: Building Secure Systems in Untrusted Networks
Scott Rose, Oliver Borchert, Stu Mitchell, and Sean Connelly, Zero Trust Architecture, NIST Special Publication 800-207
Susan Fowler, Production-Ready Microservices