Балансировка на диаграмме — без лишнего шума
Когда вы рисуете HTTP-ребро перед несколькими репликами, вы закладываете решение: какая реплика получит следующий запрос и что происходит, если она занята или «больна». В ArchiPanopticon мы не притворяемся конкретным продуктом; мы связываем правила маршрутизации, «здоровье» и метрики ёмкости с измерениями на исходящем ребре.
Почему симулятору важен один хоп
Каждое синтетическое сообщение несёт бюджеты задержки и ошибок от связи, которая его породила. Узел в духе шлюза удобен, потому что к нему можно привязать политику и увидеть p50/p99 на исходящем ребре, а не отговариваться «высокой доступностью».
Что можно исследовать
- Менять агрессивность перераспределения при ошибках downstream и смотреть, как падает error rate отдельно от throughput.
- Сравнивать один upstream и несколько — даже если на канвасе подписи похожи.
- Соединять хоп с observability-узлами, чтобы понимать, давление у балансировщика или глубже.
Материалы (открытые)
- Википедия: Load balancing (computing) — общая таксономия алгоритмов.
- IETF RFC 9110 — семантика HTTP для промежуточных узлов.
Попробуйте
Откройте симулятор и проведите трафик через прокси-подобный компонент к двум репликам; увеличивайте нагрузку и фиксируйте, как меняются хвосты задержки до того, как добавлять кэш или очереди ниже по потоку.