HAProxy спонсировал этот пост.
Протокол контекста модели (MCP) развивается. Благодаря недавнему внедрению Streamable HTTP в начале 2025 года протокол готов к массовому успеху, выйдя за рамки командных строк разработчиков и в мир «MCP-серверов как услуги».
Этот рост ставит новую интересную задачу: масштабирование. Поскольку ваш сервис MCP становится все более популярным, вам придется запускать его на нескольких серверах. Это означает, что вам понадобится балансировщик нагрузки.
Это руководство покажет вам, как использовать HAProxy, балансировщик нагрузки с открытым исходным кодом, для создания масштабируемого, отказоустойчивого и совместимого уровня балансировки нагрузки для ваших серверов Streamable MCP.
Ключевые выводы:
- Сохранение сеанса имеет решающее значение: MCP использует заголовок mcp-session-id для поддержания непрерывного разговора. Мы будем использовать таблицы HAProxy, чтобы запросы из одного и того же сеанса всегда попадали на один и тот же внутренний сервер.
- Краевая проверка — это умно: У MCP есть определенные правила, согласно которым клиенты Accept заголовков должны отправлять. Мы можем проверить эти правила на уровне HAProxy, защищая ваши внутренние серверы от недействительного трафика.
Почему потоковый HTTP меняет все
До сих пор большинство взаимодействий MCP происходило локально. Первоначальную конечную точку событий, отправленных сервером (SSE), оказалось сложно реализовать, поэтому разработчики полагались на локальные инструменты командной строки. Это было хорошо для тестирования и разработки, но стало серьезным препятствием для более широкого внедрения.
Хотя первоначальный метод HTTP+SSE выполнил свою задачу, он представил значительные ограничения по мере расширения внедрения на предприятиях. Этот двухканальный подход, требующий отдельного HTTP POST для сообщений клиент-сервер и выделенной конечной точки событий, отправленных сервером (SSE) для потоковой передачи между сервером и клиентом, создавал сложности, которые препятствовали масштабному развертыванию MCP.
Потоковый HTTP меняет правила игры. Он предоставляет стандартизированный, простой в использовании транспортный уровень, который работает так же, как и любой другой современный веб-API. Это открывает перед поставщиками облачных услуг и SaaS-компаниями возможность предлагать управляемые услуги MCP, делая технологию доступной для гораздо более широкой аудитории.
Как и в случае с любым успешным сервисом, путь быстро начинается с вопроса «Сможем ли мы заставить это работать?» на «Как нам обеспечить бесперебойную работу тысяч пользователей?» Ответ: балансировка нагрузки.
Задача балансировки нагрузки
Спецификация MCP дает нам два ключевых требования, которые мы должны выполнить в балансировщике нагрузки.
1. Прилипчивость сеанса
В спецификации говорится: «Сервер МОЖЕТ назначить идентификатор сеанса, и клиент ДОЛЖЕН использовать его в последующих запросах в качестве заголовка, называемого mcp-session-id».
Это наиболее важное правило для балансировки нагрузки серверов MCP. Сеанс пользователя — это непрерывный разговор. Если один запрос отправляется на сервер A, а следующий — на сервер B, контекст теряется и сеанс прерывается. Мы должны гарантировать, что как только клиент будет назначен серверу, все последующие запросы в этом сеансе «прикрепятся» к этому же серверу.
2. Проверка протокола
Спецификация также определяет строгие правила для заголовка Accept на основе метода HTTP:
- Для запросов HTTP GET клиент должен включать заголовок Accept, содержащий текст/поток событий.
- Для запросов HTTP POST клиент должен включать заголовок Accept, содержащий как application/json, так и text/event-stream.
Обработка этого в балансировщике нагрузки является мощной оптимизацией. Отклоняя недействительные запросы на границе, мы предотвращаем попадание искаженного трафика на наши серверы MCP, уменьшая их рабочую нагрузку и делая всю систему более надежной.
Решение: конфигурация HAProxy
Однопроцессная, управляемая событиями архитектура HAProxy делает его идеальным для обработки десятков тысяч одновременных соединений с отслеживанием состояния с минимальными затратами ресурсов, что имеет решающее значение для управления постоянными диалогами ИИ в масштабе.
Мы можем использовать этот популярный инструмент с открытым исходным кодом для выполнения двух вышеуказанных требований. Давайте построим конфигурацию.
1. Достижение закрепленности сеанса с помощью Stick Tables
Таблицы HAProxy представляют собой мощное хранилище значений ключей в памяти. Конфигурация создает новое хранилище значений ключей в памяти для сеансов. Когда подключается новый клиент, он назначается определенному бэкэнду. HAProxy будет отправлять их на один и тот же сервер каждый раз до конца сеанса. Это называется липкостью сеанса.
Поскольку таблицы Stick являются неотъемлемой частью ядра HAProxy в памяти, они работают с чрезвычайно низкой задержкой. Это позволяет избежать снижения производительности и сложности запросов к внешнему хранилищу сеансов, гарантируя, что поиск сеансов никогда не станет узким местом, даже при большой нагрузке.
Мы настроим HAProxy именно на это, используя заголовок mcp-session-id. Наша серверная конфигурация будет выглядеть так:
backend mcp_servers # Определите таблицу флешек для отслеживания сеансов. тип Stick-table string len 64 size 1m expire 1h # Для последующих запросов придерживаться сервера, # если клиент # отправляет уже известный нам заголовок mcp-session-id. придерживаться hdr(mcp-session-id) # Для первого ответа выучите и сохраните идентификатор сеанса #, который сервер отправляет обратно. Stick store-response res.hdr(mcp-session-id) # Определите наши внутренние серверы MCP. server mcp_server_1 10.0.1.10:8000 check server mcp_server_2 10.0.1.11:8000 check 12345678910111213 backend mcp_servers # Определите таблицу Stick для отслеживания сеансов. тип Stick-table string len 64 size 1m expire 1h # Для последующих запросов придерживаться сервера, # если клиент # отправляет уже известный нам заголовок mcp-session-id. придерживаться hdr(mcp-session-id) # Для первого ответа выучите и сохраните идентификатор сеанса #, который сервер отправляет обратно. Stick store-response res.hdr(mcp-session-id) # Определите наши внутренние серверы MCP. сервер mcp_server_1 10.0.1.10:8000 проверка сервер mcp_server_2 10.0.1.11:8000 проверка
Давайте разберем ключевые директивы:
- Stick-table: это создает наш список сеансов. Мы определяем его размер и как долго хранить записи неактивных сессий.
- придерживаться hdr(mcp-session-id): это указывает HAProxy проверять входящий запрос. Если он находит заголовок mcp-session-idheader, он ищет этот идентификатор в нашей таблице и перенаправляет запрос на соответствующий сервер.
- Stick store-response res.hdr(mcp-session-id): Именно так мы в первую очередь узнаем идентификатор сеанса. Когда сервер MCP отвечает новому клиенту, он включает новый идентификатор сеанса. Эта директива извлекает это значение из ответа и сохраняет его в нашей таблице, связывая его с сервером, который его сгенерировал.
Благодаря этим трем строкам мы имеем идеальную устойчивость сеанса.
2. Добавление проверки запроса на периферии
Далее давайте разгрузим проверку протокола с наших серверов MCP. Мы можем использовать списки управления доступом (ACL) для проверки необходимых заголовков Accept.
Обработка этой проверки на балансировщике нагрузки упрощает архитектуру. Обеспечивая соблюдение правил протокола на границе, HAProxy предотвращает потребление серверных ресурсов недействительным трафиком — задача, которая в противном случае могла бы потребовать отдельного выделенного уровня шлюза API. Это уменьшает задержку, стоимость и сложность.
Мы добавим эти правила в наш раздел внешнего интерфейса:
Нет frontend mcp_frontend привязка :80 # ACL для проверки, содержит ли заголовок Accept «text/event-stream» acl Accept_events req.hdr(accept) -m str text/event-stream # ACL для проверки, содержит ли заголовок Accept «application/json» acl Accept_json req.hdr(accept) -m str application/json # Блокировать недопустимые запросы GET HTTP-запрос отклонить, если METH_GET !accept_events # Блокировать недействительные POST-запросы, отказ в http-запросе, если METH_POST !accept_events или METH_POST !accept_json default_backend mcp_servers 123456789101112131415 Нет frontend mcp_frontend связывает :80 # ACL для проверки, содержит ли заголовок Accept ‘text/event-stream’ acl Accept_events req.hdr(accept) -m str text/event-stream # ACL для проверки, содержит ли заголовок Accept ‘application/json’ acl Accept_json req.hdr(accept) -m str application/json # Блокировать недействительные запросы GET, отказ в http-запросе, если METH_GET !accept_events # Блокировать недопустимые запросы POST, отказ в http-запросе, если METH_POST !accept_events или METH_POST !accept_json default_backend mcp_servers
Эта логика ясна и эффективна:
Затем наша логика таблицы Stick берет на себя управление и перенаправляет любой запрос, который проходит эти проверки, на наш бэкэнд.
Полная конфигурация
Вот полный, готовый к копированию файл haproxy.cfg, который объединяет все в надежное решение по балансировке нагрузки для Streamable MCP. Обратите внимание, что это руководство посвящено нашему проекту с открытым исходным кодом, а не нашему коммерческому корпоративному балансировщику нагрузки; однако эта конфигурация будет работать для обоих.
Внедрение Streamable HTTP является важной вехой для протокола контекста модели, открывая путь для масштабируемых приложений корпоративного уровня. С помощью HAProxy вы можете создать уровень балансировки нагрузки, который разумно распределяет трафик и обеспечивает соблюдение правил протокола на границе, улучшая вашу стратегию шлюза AI. Внедрив сохранение сеансов и проверку запросов, вы можете гарантировать, что ваша служба MCP будет быстрой, масштабируемой и достаточно отказоустойчивой для массового использования.
HAProxy Technologies — это компания, создавшая HAProxy One, самую быструю в мире платформу доставки приложений и безопасности, а также HAProxy, наиболее широко используемый программный балансировщик нагрузки. Узнайте больше на HAProxy.com. Узнайте больше Последние новости HAProxy ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одного эпизода. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Якуб Сухи — директор по разработке решений в HAProxy Technologies, где он разрабатывает и прототипирует решения для доставки приложений и инфраструктуры балансировки нагрузки. Имея опыт работы с инфраструктурой Linux и приложениями с открытым исходным кодом, он специализируется на разработке инновационных подходов… Подробнее от Якуба Сухи
