携程如何借助Higress构建高效AI网关？大规模AI服务接入的实战经验与深度解析。

在大模型浪潮席卷而来的当下，如何高效、安全地管理企业内部成百上千个AI服务调用，已成为众多技术团队面临的现实挑战。携程旅游研发总监董艺荃，在2025中国可信云大会上详细分享了一套基于Higress的AI网关落地实践，从选型到架构设计，再到具体实施中的坑点与应对策略，信息量极为丰富。以下是对分享核心内容的系统梳理，分为四个部分展开阐述。

01 大规模应用AI技术过程中遇到了哪些问题

为了持续提升服务品质与用户体验，携程早在早期阶段便在大模型领域投入大量精力。然而，随着接入大模型的应用数量不断增长，几个尖锐的问题逐渐浮出水面。

首先，接入的模型种类繁多——既有外部商业大模型，也有内部自研模型。不同模型对网络访问能力的要求各不相同，认证机制也千差万别，管理起来相当棘手。

其次，各业务线采用点对点方式直接接入大模型，费用管理各自为政，缺乏统一的用量统计与成本核算，形成了一笔难以追溯的“糊涂账”。

第三，在流量高峰或大模型服务出现故障时，缺少统一的限流、熔断、流量切换机制，完全依赖各业务团队自行应对，风险隐患较大。

面对这一局面，采用网关统一管理各类服务接入，并在各个层面增加流量治理功能，成为最自然的选择。

02 网关选型上有哪些考虑

在对比多个开源项目后，团队最终选择了Higress作为AI网关的基础底座。选型理由非常直接。

第一，Higress在阿里巴巴内部经过长期实践，技术底蕴深厚。它在传统API网关基础上迭代出AI网关能力，对各类大模型接入场景提供了丰富支持，稳定性也得到充分验证。

第二，它采用云原生服务网格领域广泛使用的Istio与Envoy作为内核，并支持用C++、Go、Rust等语言编写Wasm插件，扩展性极强。这意味着团队可以根据自身需求灵活添加功能。

第三，社区活跃度很高，需求响应速度快，通常两到三周就会发布一个新版本。

在内部落地Higress之后，整个AI服务接入架构变得清晰有序。网关的所有组件均部署在内部Kubernetes集群中，统一管理服务器资源与配置信息。

网关本身由三个核心组件构成：Gateway负责数据面，直接承接用户流量并转发至后端大模型服务；Controller为控制面，从Kubernetes读取配置并推送给Gateway；Management API则对接内部的大模型运营平台（携程机器学习平台），管理员可在该平台上配置可访问的各类服务，包括近期接入的MCP服务以及接入方的相关信息。API将这些配置写入Kubernetes持久化存储，供Controller读取。

在配置数据方面，Higress原生使用K8s资源类型与一些自定义资源。团队在对接机器学习平台时，根据实际业务需求，为大模型接入和MCP Server接入两种场景分别设计了独立的领域模型，并对Management API进行二次开发，增加了模型转换功能，同时支持增量与全量两种同步方式。

在大模型服务接入方面，为实现风险隔离，团队为不同的接入方（称为消费者）设置了不同的接入点路径。每个接入点路径可关联多个模型路由，通过模型名称进行匹配。每个模型路由又可关联多个后端大模型服务，实现负载均衡。

在转发请求时，网关还支持对模型名称进行映射。也就是说，用户可以使用统一的模型别名发起调用，网关在转发到不同后端服务时，会根据实际情况自动替换为具体的模型名称。

近期，团队又在网关上新增了MCP服务接入能力。这部分更类似于传统API网关——将服务暴露出来供外部访问。但除了支持现有的MCP服务，网关还能将存量HTTP API转化为MCP服务。用户可以通过SSE或Streamable HTTP方式访问这类服务。

所有经过AI网关处理的请求，都需要提供访问凭证进行认证与鉴权。目前对访问方主要采用Bearer Token机制。每个Token关联一个消费者，一个消费者能访问哪些服务需要经过申请与审批流程。后端服务侧的访问凭证则统一存储在网关内，消费者无需关心。MCP服务方面情况稍显复杂，有的不需要认证，有的需要。网关支持服务提供方根据实际情况选择——认证凭证既可以统一存放在网关内，也可以由调用方提供，网关会调整凭证传递方式以满足端到端认证需求。

当然，以上是正常情况下的流程。接下来是异常流量处理机制。

首先是限流。每个消费者在申请大模型访问时，都需要填写限流阈值，包括Token per Minute (TPM)、Query per Minute (QPM)和并发请求数。这不仅能保护网关和后端服务免受突发流量干扰，也方便运维团队进行容量规划，同时帮助用户管控成本。这些限流机制利用Higress提供的Wasm插件扩展点，内部使用Redis作为中央计数器实现全局限流，并通过LUA脚本保证计数器更新的原子性。

其次是降级。如果后端大模型服务出现故障，可以预先配置模型降级规则。当路由指向的原服务返回4xx、5xx等异常响应码时，网关不会直接将错误响应返回给调用方，而是将请求转发至降级服务，并返回降级服务的响应数据。该降级操作仅执行一次，并且可以为降级服务配置独立的模型名称映射规则。

在下方的图中，绿色线对应的服务出现故障时，请求自动切换到了黄色线对应的服务上。之所以能生成这张图，是因为网关本身提供了强大的可观测能力。

第三是日志与监控。网关请求日志落盘在本地磁盘，通过logrotate进行滚动以避免占用过多存储。日志内容可自定义，通过Wasm插件配合自定义日志模板，能够记录大模型请求的详细信息——如模型名称、消耗的Token数、输入输出消息内容等。这些数据有助于分析用户使用情况，帮助用户优化使用方式。日志采集复用公司现有监控链路：FileBeat将日志送至Kafka，通过类似LogStash的组件消费Kafka获取日志信息，解析重组后写入ClickHouse，最后在Kibana上提供查询。

监控方面则更加直接——网关本身暴露了供Prometheus抓取的接口，抓取到的监控信息可以在内部Grafana上查看。

总体来说，网关的整体情况就是如此。接下来是一些关键难点的分享。当然，在Higress的帮助下，原本的难点也并没有那么棘手。

03 落地AI网关的难点和应对方案

第一个难点是适配各种大模型供应商的接口契约。目前请求大模型最通用的是OpenAI接口协议，网关对外提供的服务也基于这套协议。但有些大模型服务并不完全兼容，比如接口路径不同，或者认证方式有差异。这就要求网关在转发数据时，对请求和响应数据进行修改，以对齐对端所支持的协议。好在Higress已经适配了市面上许多种大模型服务类型，基本无需改动即可对接。但在推广MCP服务接入方面，情况就没这么简单了。

携程内部有大量HTTP服务，覆盖了业务场景的方方面面。如果能把它们转化为MCP服务提供给AI使用，对业务方接入AI体系将大有裨益。但问题在于，要将一个接口作为工具放到MCP Server上，需要提供工具描述信息，包括接口名称、参数列表等。而REST API通常最多只有Swagger生成的OpenAPI接口契约，核心工作就是把左侧的接口契约转化为右侧的工具描述。

除了请求参数部分，还需要对后端接口的响应数据进行格式化，作为MCP Server的响应数据，便于大模型理解。这显然是重复性很强的工作——而只要是重复性的工作，就可以让AI来完成。团队利用提示词，将接口契约提供给大模型，大模型就能生成基本可用的描述信息，人工校对并做少量调整后即可使用。

完成协议转换后，下一个问题接踵而至。虽然SSE这种传输方式已被MCP官方废弃，但仍有不少调用方希望网关支持它。SSE采用请求与响应分离的设计，这就要求网关层提供会话管理功能。

大致流程如下：MCP Client请求服务的/SSE接口，启动一个新会话。网关生成一个新的SessionID，并在Redis里监听一个与该SessionID关联的Channel，然后把MCP Server对应的Endpoint信息返回给客户端。这样客户端就可以向这个Endpoint发起后续请求（如初始化监听、获取工具列表、调用工具等）。这些请求的响应数据并不会被直接返回给客户端，而是发布到前面监听的Redis Channel中，通过这个Channel把信息传递给/SSE请求的上下文，再推送给客户端。

04 应用成效和未来规划

目前，AI网关在携程内部已经接入了多款大模型，具备稳定支撑大规模模型调用的能力，为公司的AI技术探索奠定了扎实基础。同时也在不断接入各类MCP Server，丰富整个产品的生态体系。

可以看到，整个AI网关的许多功能是开源Higress原生提供的，团队更多的工作是将它适配到携程的研发体系中，并对接周边的治理平台。通过验证，也发现了一些社区尚未支持的场景，这些都已经通过Pull Request的方式提交给社区，并合并进了代码库。随着越来越多的人使用开源产品、贡献开源代码，社区也会越来越好。

正如那句话所说：每一次代码回馈，都是开源生命力的延续。

接下来，团队会继续对网关能力进行迭代，在模型路由规则、模型输出后处理、调用方优先级识别和内容安全防护等方面进行优化，并将AI能力融入到网关内部，而不仅仅停留在由网关承载的业务这一层面，进一步强化网关的安全性与合规性，让网关在整个AI流量链路上发挥更大作用。

（免责说明：本文是携程旅游使用Higress的客观描述，不代表携程对Higress的功能和可用性进行背书。）