对接AI大模型之nginx代理配置SSE接口

一、背景

在对接AI大模型的时候,采用流式输出,可以较好地缓解用户等待的焦虑,但是,接口极其容易超时。

前端这时候会一直报错:

bash 复制代码
Expected content-type to be text/event-stream, Actual: text/html

而后端的错误显示是客户端断开了连接。

这里摘录其中的一段错误信息,如果你也遇到该错误,希望本文可以帮助到你。

bash 复制代码
Caused by: java.io.IOException: Broken pipe
	at java.base/sun.nio.ch.SocketDispatcher.writev0(Native Method) ~[na:na]
	at java.base/sun.nio.ch.SocketDispatcher.writev(SocketDispatcher.java:66) ~[na:na]
	at java.base/sun.nio.ch.IOUtil.write(IOUtil.java:227) ~[na:na]
	at java.base/sun.nio.ch.IOUtil.write(IOUtil.java:158) ~[na:na]
	at java.base/sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:574) ~[na:na]
	at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:162) ~[xnio-nio-3.8.16.Final.jar!/:3.8.16.Final]
	at io.undertow.conduits.IdleTimeoutConduit.write(IdleTimeoutConduit.java:130) ~[undertow-core-2.3.18.Final.jar!/:2.3.18.Final]

二、架构图

不通过内网域名访问后端服务:

三、排查过程

1、机房B的nginx配置

第一个被怀疑的对象是机房B的nginx超时时长,因为sse接口总是60秒即超时。

机房A的nginx,我看全局的配置nginx.conf已把连接超时调整为600秒。

vi /etc/nginx/nginx.conf

而接口每到了60秒的时候就断开了。

这一点,从机房B的nginx可以看到。

所以我们尝试改大机房B的nginx的超时,ingress的配置见下:

bash 复制代码
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/proxy-connect-timeout: '600'
    nginx.ingress.kubernetes.io/proxy-read-timeout: '600'
    nginx.ingress.kubernetes.io/proxy-send-timeout: '600'

它无需重启,热加载配置生效。

2、机房A的nginx

既然机房B的nginx超时不能解决问题,试着从源头来排查。

首先,在机房A通过IP地址访问,不通过内网域名访问机房B的后端服务。

尝试后,无果。

在机房A,无论通过内网域名还是IP地址,测试后端服务的接口,都不会出现60秒即超时的异常。

bash 复制代码
curl -w "\n=== 耗时统计 ===\nDNS解析: %{time_namelookup}s\nTCP连接: %{time_connect}s\nSSL握手: %{time_appconnect}s\n首字节: %{time_starttransfer}s\n总耗时: %{time_total}s\nHTTP状态: %{http_code}\n" \
  -X POST \
  -H "Accept:text/event-stream" \
  -H "Content-Type:application/json" \
  -d '...略' \
  "http://内网域名/api/v1/pub/.../chat/messages" \
  -o /dev/null \
  -s

你可以通过curl进行测试,这一点很关键,可以排查,非机房B的问题。

既然是机房A的问题,那就转换下思路。

因为机房B的后端服务,原本是kong代理对外提供服务正常的,不同的是机房A现在是使用nginx代理。

3、nginx配置

试着单独配置sse接口的反向代理,见下:

bash 复制代码
location ~ ^/ai(/api/v1/pub/.../chat/messages)$ {
    proxy_pass http://10.xxx.xxx.196:7209$1;

    proxy_http_version 1.1;
    proxy_set_header Connection "";
    # sse 关闭缓存
    proxy_buffering off;
    proxy_cache off;
    chunked_transfer_encoding on;

    proxy_connect_timeout 600s;
    proxy_send_timeout 600s;
    proxy_read_timeout 600s;
    send_timeout 30s;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

其他接口则走默认:

bash 复制代码
	location /ai/ {
	    # 注意host末尾要加斜杆,否则访问后端接口的地址会被追加/ai
       proxy_pass  http://10.xxx.xxx.196:7209/;
    }

当然,proxy_pass 也可以配置内网域名。

经测试,前端访问sse接口,终于不会60秒即断开了。

三、测试验证

同样,通过curl工具,对外网接口进行测试。

bash 复制代码
curl -w "\n=== 耗时统计 ===\nDNS解析: %{time_namelookup}s\nTCP连接: %{time_connect}s\nSSL握手: %{time_appconnect}s\n首字节: %{time_starttransfer}s\n总耗时: %{time_total}s\nHTTP状态: %{http_code}\n" \
  -X POST \
  -H "Accept:text/event-stream" \
  -H "Content-Type:application/json" \
  -d '...略' \
  "http://外网域名/api/v1/pub/.../chat/messages" \
  -o /dev/null \
  -s

=== 耗时统计 ===

DNS解析: 0.012s

TCP连接: 0.024s

SSL握手: 0.185s

首字节: 17.739s

总耗时: 72.965s

HTTP状态: 200

相关推荐
日常筹谋记18 分钟前
自动化仓储安全防护工况评估:明治传感器AS-33C技术适配性分析
大数据·运维·创业创新·业界资讯
updayday85426 分钟前
离职域账号状态变更与Ping64操作记录核对
大数据·网络·数据库·安全·智能路由器
Shadow(⊙o⊙)44 分钟前
Linux进阶知识1.0
linux·运维·服务器
szephyr1 小时前
HTTPS 证书申请与自动续期:acme.sh + Let‘s Encrypt 完整记录
nginx·https·acme.sh·证书续期
安易算力1 小时前
PUE优化工程实践:从1.5到1.2的制冷架构与气流组织改造路径
网络·python·容器·架构·kubernetes
闲云自留地1 小时前
告别命令恐惧症,openEuler 基础操作 + 文本 + 网络管理实战
linux·运维·云计算
等待_迷失的Linux2 小时前
嘉信国际的8位账号
ai
Ivanqhz2 小时前
数据搬运是性能关键
java·服务器·网络·人工智能·深度学习
其实防守也摸鱼2 小时前
常见安全架构中 Shiro 的认证确认机制解析
运维·服务器·数据库·windows·github
MayBaymax3 小时前
Spring AI Alibaba Graph 实战:客服工单智能处理
java·ai·ai编程