Control plane и data plane в API-шлюзе
Краткое практическое руководство по разделению управления конфигурацией и обработки живых API-запросов.
Содержание
pi 的agent 架构
API-шлюз проще развивать и эксплуатировать, если управление конфигурацией отделено от обработки живых запросов. Такое разделение не требует двух разных продуктов: речь идёт о чёткой границе ответственности внутри системы.
Два контура — две задачи
| Контур | Основная задача | Типичные данные |
|---|---|---|
| Control plane | Управлять желаемым состоянием | маршруты, провайдеры, цены, политики |
| Data plane | Обрабатывать живые запросы | аутентификация, маршрутизация, учёт, ответы |
Control plane проверяет целостность новой конфигурации и публикует её как версию. Data plane читает только утверждённую версию и продолжает обслуживать трафик. Поэтому медленная операция в панели управления не должна попадать в критический путь каждого API-вызова.
Безопасная последовательность обновления
- Проверить кандидата целиком, включая ссылки на маршруты и провайдеров.
- Сохранить его как неизменяемую версию.
- Атомарно переключить указатель активной версии.
- Сбросить только кэши, затронутые изменением.
- Выполнить контрольный запрос и сохранить предыдущую версию для отката.
Эта последовательность даёт конкретную границу отката: оператор возвращает предыдущий указатель, а не пытается вручную восстановить набор отдельных полей.
Что измерять отдельно
Версия конфигурации, ошибки маршрутизации, задержка провайдеров, события биллинга и состояние отката должны наблюдаться как разные сигналы. Тогда можно отличить ошибочную политику от сбоя внешнего провайдера.
Практическое решение
Редактирование, проверку и публикацию размещайте в control plane. Аутентификацию, выбор канала, проверку квоты, потоковую передачу и фиксацию потребления оставляйте в data plane. Это снижает связанность развёртываний и позволяет обновлять правила без остановки обработки запросов.
