HZERO PaaS平台-Docker版demo笔记（二）Docker版测试 问题1-4
#启动AI平台的所有容器：
$ bash start-all-dockers-h0base.sh*
$ bash start-ai-part-dockers.sh*
AI平台包括了中间件容器8个，H0基础开发平台服务15个，流程平台服务1个，AI平台服务4个. 其中需要在注册中心出现的java服务是17个（注册中心自己除外）。
全部容器启动完成时间大约10分钟
问题一、启动后去有三个服务成功在注册中心出现：
http://localhost:8000注册中心看服务启动情况，发下三个服务没出现：
1、hzero-schedule
看 hzero-gateway的容器日志
有条错误信息是：Caused by: java.net.UnknownHostException: db.hzero.com.cn: Name or service not known
按理不应该再有访问 db.hzero.com.cn 这个地址的，应该是mysql-hzero才对。
估计是容器中的jar包是老的，没有更新过的。
解决方案：
重新构建jar包，重新构建docker镜像。
#源环境（ubuntu-22.04-hzero）构建jar包：
$ cd /d02/hzero/project/ps-scheduler/
$ bash build.sh
#拷贝Jar包到目标环境
#在windows powershell 中执行
$ cp \\wsl.localhost\Ubuntu-22.04-hzero\d02\hzero\project\ps-scheduler\target\ps-scheduler.jar \\wsl.localhost\Ubuntu-22.04\d01\hzero-dockers\hzero-scheduler-docker\
#目标环境(ubuntu-22.04)构建docker镜像
$ cd /d01/hzero-dockers/hzero-scheduler-docker
$ docker compose down
$ docker build -t hzero-scheduler-jk-demo:1.12 .
$ docker compose up -d
结果：问题解决，再注册中心可见hzero-scheduler.
2、hzero-massage
看hzero-massage的容器日志：
有条错误信息：Caused by: java.net.UnknownHostException: db.hzero.com.cn: Name or service not known
按理不应该再有访问 redis.hzero.com.cn 这个地址的，应该是redis-hzero才对。
估计是容器中的jar包是老的，没有更新过的。
解决方案：
重新构建jar包，重新构建docker镜像。
#源环境：
$ cd /d02/hzero/project/ps-message/
$ bash build.sh
#Windows PowShell:
cp \\wsl.localhost\Ubuntu-22.04-hzero\d02\hzero\project\ps-message\target\ps-message.jar \\wsl.localhost\Ubuntu-22.04\d01\hzero-dockers\hzero-message-docker\
#目标环境：
$ cd /d01/hzero-dockers/hzero-message-docker
$ docker compose down
$ docker build -t hzero-message-jk-demo:1.12 .
$ docker compose up -d
结果：问题解决，再注册中心可见hzero-massage.
3、hzero-gateway
看 hzero-gateway的容器日志
有条错误信息是：Caused by: io.lettuce.core.RedisConnectionException: Unable to connect to redis.hzero.com.cn/<unresolved>:6379
分析：
按理不应该再有访问 redis.hzero.com.cn 这个地址的，应该是redis-hzero才对。
估计是容器中的jar包是老的，没有更新过的。
解决方案：
重新构建jar包，重新构建docker镜像。
结果：问题解决，再注册中心可见hzero-gateway.
解决完上述问题后，在注册中心出现的服务是17个；
好，接下来，我们进入系统，测试，首先要进入系统把AIGC平台中neo4j图数据库地址,、默认向量库elasticsearch的地址、文件管理minio的地址换掉。
这里默认图数据库neo4j的地址换成容器服务名
这里默认向量库elasticsearch的地址换成容器服务名
注意minio配置这个地方：
Endpoint：应用与 MinIO 在同一 Docker 网络时，用容器服务名；否则用宿主机 IP + 端口。
代理地址：必须用外部可访问的地址（宿主机 IP / 域名 / 代理地址），不能用容器服务名。
问题二、登录问题：
首次进入dev.hzero.com.cn 会重定向到登录页面，登录页面地址错误：
分析：
这是我们在之前为容器中运行的oauth服务的application.yml中配置的地址, 看起来这个配置应该用外面的网关域名，不能用容器网络内的容器服务名，因为这个其实相当于定义一个变量返回，而不是真的要oauth服务去调用这个网关。
动作：
hzero-oauth服务的application.yml中
# oauth 服务基础地址
base-url: ${HZERO_OAUTH_BASE_URL:http://hzero-gateway:8080/oauth}
更改为：
base-url: ${HZERO_OAUTH_BASE_URL:http://gateway.hzero.com.cn:8080/oauth}
重新构建, 重起服务。
结果：可以正常进入登录页面了。问题解决。
问题三、文档预览问题
背景：文件服务minio和 文件预览服务kkfielview原来直接安装在linux Host机上，后来都迁移到docker compose容器内运行了。
迁移后测试：PDF文件可以正常预览：
word和PPT文件预览会报错：
分析：前端检查：
前端会直接去用file服务的application.yml中配置的文件预览URL , 由于都改到容器内运行，所以之前把这个预览地址的URL也改成kkfileview的容器服务名开头了，但这个服务名在容器网络外是无法解析的。
解决方案：在文件服务的application.yml配置中把kk-file-view-url的域名从容器服务名改成容器外能访问的域名：kkv.hzero.com.cn
修改前：kk-file-view-url: http://kkfileview-hzero:8012/onlinePreview # kkFileView的文件预览地址
修改后：kk-file-view-url: http://dev.hzero.com.cn:8012/onlinePreview # kkFileView的文件预览地址。
然后重新构建jar,Docke镜像，重启容器。再测，这次kkfileview的URL没问题了，但内容显示404，看浏览器检查网络没有错误信息：
看kkfileview容器日志：
文件下载失败，url：
这个文件URL是文档表中存储的文件地址，oss.hzero.com.cn是之前minio服务直接装在host机上时配置的访问域名。所以之前存储的文档地址都是这个域名开开头的，但现在minio改成容器内服务了，以后所有的文档都会以minio的容器服务名开头了，但历史数据还是之前的域名，现在因为kkfileview文件预览服务也在容器内运行，所以无法解析oss.hzero.com.cn这个域名；
解决方案：
更改数据库表中文档url的域名地址为minio的容器服务名：
UPDATE hzero_aip.hdoc_document_version
SET document_url = REPLACE(document_url, ‘oss.hzero.com.cn’, ‘minio-hzero’)
WHERE document_id = 4;
再次测试，可以正常预览了：
kkfileview容器日志也显示正常访问：
2025-11-28 06:06:36.449 INFO 1 — [tp1224347463-48] c.k.w.c.OnlinePreviewController : 预览文件url：
不过这带来另一个问题就是PDF文件因为不经过kkfileview,直接显示，而且是直接用数据库中存储的URL显示，也没有把文件服务的容器服务名替换成代理地址的域名，所以就反而显示不出来了，解决方案感觉应该前端处理时，如果不调用预览服务进行显示，那么是否也应该把从后端获得的文件URL地址中的域名部分替换成文件服务的代理地址再进行显示？ 这样就不会错了。
我在nginx配置反向代理：
# oss.hzero.com.cn minio服务的反向代理
server {
listen 80;
server_name oss.hzero.com.cn;
location / {
# 改为后端服务实际IP:端口
proxy_pass http://minio-hzero:9000; # 示例：minio-hzero的9000端口
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection “upgrade”;
proxy_set_header Host $host; # 保留一个Host配置
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_buffering off; # 按需开启/关闭（实时交互场景建议关闭）
}
重启nginx容器服务
Windows Hosts中配置oss.hzero.com.cn的DNS解析；
我们来看，如果前端执行了代理地址替换：
替换后的地址访问就是OK的：
备注：这个反向代理仅用于临时测试，测试完成后删除掉。
这个问题，产研说会在下个PI中解决掉，就是走代理，只是这个代理是在文件服务中写的，也是解决浏览器不能访问服务器内网Endpoint地址的情况。以前是要求Endpoint内外网能能访问到，解决这个问题之后可以允许Endpoint只能内网访问。
临时解决方案：
1、修数据：文档地址
UPDATE hzero_aip.hdoc_document_version
SET document_url = REPLACE(document_url, ‘oss.hzero.com.cn:9000’, ‘minio-hzero:9000’)
;
UPDATE hzero_aip.hdoc_document_version
SET source_key = REPLACE(source_key, ‘oss.hzero.com.cn:9000’, ‘minio-hzero:9000’)
;
- windows的hosts中添加解析
172.18.14.48 minio-hzero
个人Demo使用问题暂时解决。
不过这并不稳定，第二天重启服务之后，发现docx 文档预览就不行了：
经过测试从文件服务API ：signedURL 返回的负载，响应，预览内容都是正确的，把这返回直接在浏览器访问是可以下载文件的。
但是到了调用kkfileview 去预览的时候出错了：
把这个kkfileView的响应中的URL是：
直接访问这个URL返回：
<Error>
<Code>InvalidRequest</Code>
<Message>The authorization mechanism you have provided is not supported. Please use AWS4-HMAC-SHA256.</Message>
<Resource>/hz-haip/haip01/0/MINIO/ca310b2e73b94fd1a47a29c6e13bcb5a@上海益吉-低代码平台应用成功案例.docx</Resource>
<RequestId>187D19B0939102B8</RequestId>
<HostId>dd9025bab4ad464b049177c95eb6ebf374d3b3fd1af9251148b658df7ac2e3e8</HostId>
</Error>
这就很奇怪，kkfileview 提交给minio的请求为啥要加 .docx?后面那段内容呢？这段内容不加一点问题都没有，加了反而有问题。
解决方案（按优先级排序，从简单到复杂）
核心思路：让 kkfileview 使用的 URL「参数与签名时完全一致」，避免新增参数导致签名失效。
方案 1：禁止 kkfileview 修改原始 URL（最快生效）
kkfileview 新增参数是可配置的，通过关闭「URL 重写」或「参数追加」功能，让它直接转发文件服务返回的 signedURL，不做任何修改。
操作步骤（kkfileview 配置）：
找到 kkfileview 的配置文件（通常是 application.properties 或 application.yml）；
添加 / 修改以下配置，禁用参数追加和 URL 重写：
properties
# 禁用自动添加 response-content-disposition 参数（关键）
keking.file.preview.add.response.content.disposition=false
# 禁用 URL 重写（避免修改原始 URL）
keking.file.preview.url.rewrite.enabled=false
# 禁用缓存控制参数追加
keking.file.preview.add.response.cache.control=false
执行：把容器kkfileview-hzero
的配置文件：/opt/kkFileView-4.1.0/config/application.properties 挂载出来
$ cd /d01/hzero-dockers/volumes
$ mkdir kkfileview
拷贝命令：
$ docker cp kkfileview-hzero:/opt/kkFileView-4.1.0/config/application.properties /d01/hzero-dockers/volumes/kkfileview/
更改文件权限：
sudo chown -R root:root /d01/hzero-dockers/volumes/kkfileview
sudo chmod -R 755 /d01/hzero-dockers/volumes/kkfileview
Docker-compose.yml中添加：
volumes:
– ${DOCKER_VOLUME_DIRECTORY:-../volumes}/kkfileview/application.properties:/opt/kkFileView-4.1.0/config/application.properties
添加配置后，重启容器，
重启 kkfileview 服务，测试预览是否正常：
结果还是一样，文件名后加签的内容依然存在，看起来不是kkfileview加签的，应该是aip-app服务的开发者加签的，找下产品组…
产品组反馈，是他们加签的，就是应对文件是要授权（登录）才能访问的情况，这个地址是文件加签后的地址，可以直接通过加签后的地址去访问文件。
但是加签的内容在这个场景中被minio认为格式有问题，存在无效的分割符。奇怪的是如果不是在容器环境，是不会报错的，文件名也是经过加签的。
测试：
#第一步：配置 mc 别名（关联 MinIO 实例，关键！）
sh-5.1$ mc alias set my-minio http://minio-hzero:9000 hzero.admin hzero.hand.2020.
Added `my-minio` successfully.
#第二步：验证文件是否存在（避免路径 / 文件名错误）
sh-5.1$ mc ls ‘my-minio/hz-haip/haip01/0/MINIO/ca310b2e73b94fd1a47a29c6e13bcb5a@上海益吉-低代码平台应用成功案例.docx’
[2025-11-30 07:52:51 UTC] 1.3MiB STANDARD ca310b2e73b94fd1a47a29c6e13bcb5a@上海益吉-低代码平台应用成功案例.docx
#第三步：生成加签下载 URL（有效期 1 小时）
sh-5.1$ mc share download ‘my-minio/hz-haip/haip01/0/MINIO/ca310b2e73b94fd1a47a29c6e13bcb5a@上海益吉-低代码平台应用成功案例.docx’ –expire 1h
URL: http://minio-hzero:9000/hz-haip/haip01/0/MINIO/ca310b2e73b94fd1a47a29c6e13bcb5a@上海益吉-低代码平台应用成功案例.docx
Expire: 1 hours 0 minutes 0 seconds
Share: http://minio-hzero:9000/hz-haip/haip01/0/MINIO/ca310b2e73b94fd1a47a29c6e13bcb5a%40%E4%B8%8A%E6%B5%B7%E7%9B%8A%E5%90%89-%E4%BD%8E%E4%BB%A3%E7%A0%81%E5%B9%B3%E5%8F%B0%E5%BA%94%E7%94%A8%E6%88%90%E5%8A%9F%E6%A1%88%E4%BE%8B.docx?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=hzero.admin%2F20251202%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20251202T054304Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Signature=f2ef45fef57367c86003e28c5185c80fc122d35bbf0d57b3763c91e9c347e08f
#第四步：测试加签 URL 是否有效（kkfileview容器内 curl 测试）
# curl -v -o /tmp/test-mc-sign.docx “http://minio-hzero:9000/hz-haip/haip01/0/MINIO/ca310b2e73b94fd1a47a29c6e13bcb5a%40%E4%B8%8A%E6%B5%B7%E7%9B%8A%E5%90%89-%E4%BD%8E%E4%BB%A3%E7%A0%81%E5%B9%B3%E5%8F%B0%E5%BA%94%E7%94%A8%E6%88%90%E5%8A%9F%E6%A1%88%E4%BE%8B.docx?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=hzero.admin%2F20251202%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20251202T054304Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Signature=f2ef45fef57367c86003e28c5185c80fc122d35bbf0d57b3763c91e9c347e08f”
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 –:–:– –:–:– –:–:– 0* Trying 172.18.0.7:9000…
* TCP_NODELAY set
* Connected to minio-hzero (172.18.0.7) port 9000 (#0)
> GET /hz-haip/haip01/0/MINIO/ca310b2e73b94fd1a47a29c6e13bcb5a%40%E4%B8%8A%E6%B5%B7%E7%9B%8A%E5%90%89-%E4%BD%8E%E4%BB%A3%E7%A0%81%E5%B9%B3%E5%8F%B0%E5%BA%94%E7%94%A8%E6%88%90%E5%8A%9F%E6%A1%88%E4%BE%8B.docx?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=hzero.admin%2F20251202%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20251202T054304Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Signature=f2ef45fef57367c86003e28c5185c80fc122d35bbf0d57b3763c91e9c347e08f HTTP/1.1
> Host: minio-hzero:9000
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Content-Length: 1409842
< Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
< ETag: “612676ff41515da42d52f09b2bcfcbeb”
< Last-Modified: Sun, 30 Nov 2025 07:52:51 GMT
< Server: MinIO
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< Vary: Origin
< Vary: Accept-Encoding
< X-Amz-Id-2: dd9025bab4ad464b049177c95eb6ebf374d3b3fd1af9251148b658df7ac2e3e8
< X-Amz-Request-Id: 187D4FBB94215DED
< X-Content-Type-Options: nosniff
< X-Ratelimit-Limit: 8421
< X-Ratelimit-Remaining: 8421
< X-Xss-Protection: 1; mode=block
< Date: Tue, 02 Dec 2025 05:44:56 GMT
<
{ [3468 bytes data]
100 1376k 100 1376k 0 0 168M 0 –:–:– –:–:– –:–:– 168M
* Connection #0 to host minio-hzero left intact
#
豆包分析：
https://www.doubao.com/thread/w75a47efaadfddcb0
豆包结论：所有环境（MinIO 容器、kkfileview 容器、网络、权限）都正常！问题 100% 出在 AIP-App 生成的加签 URL 上！
但实际上我直接在非容器环境运行是没有问题的，所以按理说也不应该是生成的加签URL的问题。是不是我哪里配置还是有问题？
跟产品组沟通，让在kkfileview容器中直接wget 平台生成的加签的URL:
# wget “http://minio-hzero:9000/hz-haip/haip01/0/MINIO/ca310b2e73b94fd1a47a29c6e13bcb5a%40%E4%B8%8A%E6%B5%B7%E7%9B%8A%E5%90%89-%E4%BD%8E%E4%BB%A3%E7%A0%81%E5%B9%B3%E5%8F%B0%E5%BA%94%E7%94%A8%E6%88%90%E5%8A%9F%E6%A1%88%E4%BE%8B.docx?response-content-disposition=attachment;filename*=UTF-8”%E4%B8%8A%E6%B5%B7%E7%9B%8A%E5%90%89-%E4%BD%8E%E4%BB%A3%E7%A0%81%E5%B9%B3%E5%8F%B0%E5%BA%94%E7%94%A8%E6%88%90%E5%8A%9F%E6%A1%88%E4%BE%8B.docx&response-cache-control=must-revalidate,%20post-check=0,%20pre-check=0&response-expires=1764657679219&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=hzero.admin/20251202/us-east-1/s3/aws4_request&X-Amz-Date=20251202T064118Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host&X-Amz-Signature=c8c2c8dd43a7971e46a4743b138717e9fbc03421b5ad0e49c48dfdb998b5692c”
The name is too long, 549 chars total.
Trying to shorten…
New name is ca310b2e73b94fd1a47a29c6e13bcb5a@上海益吉-低代码平台应用成功案例.docx?response-content-disposition=attachment;filename*=UTF-8”上海益吉-低代码平台应用成功案例.docx&response-cache-control=must-revalidate, po.
–2025-12-02 15:05:37– http://minio-hzero:9000/hz-haip/haip01/0/MINIO/ca310b2e73b94fd1a47a29c6e13bcb5a%40%E4%B8%8A%E6%B5%B7%E7%9B%8A%E5%90%89-%E4%BD%8E%E4%BB%A3%E7%A0%81%E5%B9%B3%E5%8F%B0%E5%BA%94%E7%94%A8%E6%88%90%E5%8A%9F%E6%A1%88%E4%BE%8B.docx?response-content-disposition=attachment;filename*=UTF-8”%E4%B8%8A%E6%B5%B7%E7%9B%8A%E5%90%89-%E4%BD%8E%E4%BB%A3%E7%A0%81%E5%B9%B3%E5%8F%B0%E5%BA%94%E7%94%A8%E6%88%90%E5%8A%9F%E6%A1%88%E4%BE%8B.docx&response-cache-control=must-revalidate,%20post-check=0,%20pre-check=0&response-expires=1764657679219&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=hzero.admin/20251202/us-east-1/s3/aws4_request&X-Amz-Date=20251202T064118Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host&X-Amz-Signature=c8c2c8dd43a7971e46a4743b138717e9fbc03421b5ad0e49c48dfdb998b5692c
正在解析主机 minio-hzero (minio-hzero)… 172.18.0.7
正在连接 minio-hzero (minio-hzero)|172.18.0.7|:9000… 已连接。
已发出 HTTP 请求，正在等待回应… 400 Bad Request
2025-12-02 15:05:37 错误 400：Bad Request。
一样的，也是返回400 错误。
然后让试试kkfileview本地上传这个docx文件试试，看看是否能正常预览，本地上传后预览报错：
查日志：
解决方案：
把 /etc/hosts 文件挂载出去
添加dev.hzero.com.cn 的本地解析：
拷贝命令：
$ docker cp kkfileview-hzero:/etc/hosts /d01/hzero-dockers/volumes/kkfileview/
更改文件权限：
sudo chown -R root:root /d01/hzero-dockers/volumes/kkfileview
sudo chmod -R 755 /d01/hzero-dockers/volumes/kkfileview
Docker-compose.yml中添加：
volumes:
– ${DOCKER_VOLUME_DIRECTORY:-../volumes}/kkfileview/hosts:/etc/hosts
添加配置后，重启容器，再测试，本地上传文件预览就OK了:
上面这个办法太复杂，有更简单的，不用这么麻烦，不用挂载host文件，直接在容器服务的docker-compose.yml中 添加extra_hosts解析即可。
extra_hosts:
– “dev.hzero.com.cn:127.0.0.1” # 自定义域名 → 局域网服务IP
所以文件格式没问题，是可以被预览的，问题还是回到encode的地方，我们把平台生成的URL的后半部分在encode 一次，可以正常访问。
所以最终结论就是：程序处理里面需要把后半部分再encode一次。
那为啥之前非容器环境预览没问题呢？我特意查了非容器环境kkfileview的日志：发现其URL的下半部分是被encode过的。
所以看起来也不是环境在容器外还是容器内的问题，就是URL的下半部分需要encode的问题。ps-file\kkv\kkFileView-4.4.0 我容器外的版本高，4.4的，容器是4.1的，难道高版本的kkv 会自己去encode 一下吗?
问了豆包，豆包说：
你的猜想完全正确！核心差异就是 kkfileview 版本不同导致的「URL 自动编码行为」差异：
为什么 4.4 版本会加这个优化？
kkfileview 官方在后续版本（比如 4.2+）中，应该是收到了大量 “URL 含特殊字符导致下载失败” 的反馈，所以在 4.4 版本中新增了「URL 自动编码兜底」逻辑 —— 本质是帮用户处理 “上游应用（如 AIP-App）编码不完整” 的问题，提升兼容性。
而 4.1 版本是较旧的版本，还没有这个兜底逻辑，完全 “依赖上游应用传递标准 URL”，上游漏编码就必然报错。
那我们拉取4.4的镜像试试：
# 官方下载 kkFileView-4.4.0-docker_x64.tar
$ docker load -i kkFileView-4.4.0-docker_x64.tar
更改docker-compose.yml之后重启kkfileview
services:
kkfileview-hzero:
image: keking/kkfileview_x64:4.4.0
container_name: kkfileview-hzero
重启kkV之后再试：好了，问题解决。
所以，这个问题跟kkfileview的版本有关，需要使用4.2以上的版本，跟/opt/kkFileView-4.1.0/config/application.properties 中的配置也没有关系，可以把这个文件的挂载去掉了。
问题四、多模态向量测试找不到文件的问题
背景：进行多模态向量模型测试，上传图片文件测试，报错下载失败。
分析：
看起来是文件地址中包含了oss.hzero.com.cn不能解析，看文件服务日志：
Caused by: io.minio.errors.ErrorResponseException: Object name contains unsupported characters.
这个报错不正确，因为我在老环境里面测试过这个文件是没问题的，所以文件名没问题，看表里面的数据，文件名存储是拼接的是我在minio配置的代理地址。你如果用代理地址的话，在docker网络外访问是可以的，但在docker网络内部访问就不行了。文件服务在Docker容器内运行，所以文件服务就会报错。
看了下存到数据库的地址，发现其实在文件服务配置代理地址的情况下，拼接文件URL地址存入数据库的时候，会用代理地址开头，感觉新的PI中应该把逻辑修改为：不管文件服务是否配置代理地址，存入数据库的文件地址都要用endpoint开头。目前的逻辑，代理地址留空的话，会取endpoint地址开头，否则会去代理地址开头。所以，不要去配置代理地址，会导致问题。代理地址留空就好。
执行：修数据 hzero_file.hfle_file表：
先执行：
update hzero_file.hfle_file set file_url=REPLACE(file_url, ‘oss.hzero.com.cn:9000’, ‘minio-hzero:9000’)
再执行：
update hzero_file.hfle_file set file_url=REPLACE(file_url, ‘oss.hzero.com.cn’, ‘minio-hzero:9000’)
Updated Rows 40814
再次测试：还是有错误，file服务的后台日志显示错误信息是：：Caused by: io.minio.errors.ErrorResponseException: Object name contains unsupported characters.
查后台数据库表：
把file_url取出来直接在浏览器访问，是可以成功访问的：
所以这个错误就莫名其妙，是否全部用容器服务名解析就有问题呢？也不是，我在模型配置导入文件就成功的，区别在于这里导入文件，可能没有调用文件服务的URI=/v1/0/files/download/inner
但是这个地方导出下载也成功的，所以也不是下载有问题啊！
当天工作结束，停服务，关机。
第二天开机，启动服务，再测，错误一样，界面上显示的错误消息是：
url[http://gateway.hzero.com.cn:8080/hfle/v1/0/files/redirect-url?bucketName=haip&access_token=afa27805-11b0-40fd-9b13-c5d2107e48ed&url=http%3A%2F%2Fminio-hzero%3A9000%2Fhz-haip%2Fhaip01%2F0%2FMINIO%2Faf9388a45f1d4194bc1ecba6576aba17%40%E6%9F%90%E5%AE%A2%E6%88%B7%E5%90%84%E4%B8%9A%E5%8A%A1%E9%83%A8%E9%97%A8AI%E9%9C%80%E6%B1%82%E4%B8%80%E8%A7%88.png]下载失败
这个 URL后面内容转成可读的就是：
http://minio-hzero:9000/hz-haip/haip01/0/MINIO/af9388a45f1d4194bc1ecba6576aba17@某客户各业务部门 AI 需求一览.png
直接访问这个地址会提示key错误：
看文件服务日志：
io.choerodon.core.exception.CommonException: hfle.error.download.file
Caused by: io.minio.errors.ErrorResponseException: Object name contains unsupported characters.
At org.hzero.starter.file.service.MinioFileServiceImpl.download(MinioFileServiceImpl.java:323)
到数据库中查这个文件记录：
SELECT file_url FROM hzero_file.hfle_file WHERE file_url LIKE ‘%某客户各业务部门%’ AND creation_date >= CURDATE();
返回：
http://minio-hzero:9000/hz-haip/haip01/0/MINIO/af9388a45f1d4194bc1ecba6576aba17@某客户各业务部门AI需求一览.png ， AI两边多了两个空格。
另外我们用一个纯英文文件名测试，现象也是一样的：用响应中的地址可以直接访问，就是说文件URL没有问题，可文件服务就报错：
Hzero-aip-app中的错误日志是：
Caused by: io.choerodon.core.exception.CommonException: haip.error.model.download.url
hzero-file 容器测试访问minio-hzero:
# echo ‘public class Test { public static void main(String[] args) { try (java.net.Socket s = new java.net.Socket()) { s.connect(new java.net.InetSocketAddress(“minio-hzero”, 9000), 3000); System.out.println(“✅ 连通成功！”); } catch (Exception e) { System.out.println(“❌ 连通失败: ” + e.getMessage()); } } }’ > Test.java && javac Test.java && java Test && rm -f Test.java Test.class
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8 -Duser.language=zh -Duser.region=zh_CN -Duser.country=zh_CN
✅ 连通成功！
联想到今天做文件预览的时候，minio日志报错：
API: SYSTEM.authN
Time: 10:11:23 UTC 11/30/2025
DeploymentID: 45cf993b-5631-4c8d-860e-5bb2f89dec36
Error: invalid semicolon separator in query (*errors.errorString)
5: internal/logger/logger.go:271:logger.LogIf()
4: cmd/logging.go:50:cmd.authNLogIf()
3: cmd/auth-handler.go:129:cmd.getRequestAuthType()
2: cmd/auth-handler.go:621:cmd.setAuthMiddleware.func1()
1: net/http/server.go:2294:http.HandlerFunc.ServeHTTP()
猜想是不是我现在用的minio镜像是mimio:latest 最新版的，查豆包说最新版的minio对请求字符串有严格的检查，可能是不太兼容了，那么要回到老版本，尝试了一个24年的镜像，但启动不起来，原因是minio的元数据在使用最新版本之后，已经升级了，旧版本的minio无法读取新版的元数据。
我原系统功能是好的，看了下原系统上的minio, 版本是RELEASE.2025-06-13T11-33-47Z
这是25年的，也许能兼容latest的元数据格式，尝试：
$ docker pull minio/minio:RELEASE.2025-06-13T11-33-47Z
Status: Downloaded newer image for minio/minio:RELEASE.2025-06-13T11-33-47Z
docker.io/minio/minio:RELEASE.2025-06-13T11-33-47Z
修改minio的docker-compose.yml文件，用这个版本试试。
试验结果还是有问题，看起来跟minio版本没关系。
还是回到文件服务关键错误日志：
Caused by: io.minio.errors.ErrorResponseException: Object name contains unsupported characters.
这个错误看起来跟文件预览的错误类似，是否也是有部分URL少encode了一次？
另一个文件测试，后台文件服务中的错误日志是：
#io.choerodon.core.exception.CommonException: hfle.error.download.file
#Caused by: io.minio.errors.ErrorResponseException: The specified key does not exist.
网页上请求头地址是：http://aigc.hzero.com.cn/v1/open/image-emb/common
请求的负载是：
{“accountCode”:”HAIP.IMAGE_EMB_DOUBAO_COPY”,”inputs”:[{“type”:”image_url”,”imageUrl”:{“url”:”http://gateway.hzero.com.cn:8080/hfle/v1/0/files/redirect-url?bucketName=haip&access_token=00cad27f-13ea-40cc-85f7-ce046da09eb9&url=http%3A%2F%2Fminio-hzero%3A9000%2Fhz-haip%2Fhaip01%2F0%2FMINIO%2F6a5d7178989441899a4bb11525e8a2f1%40PaaS%20%E5%B9%B3%E5%8F%B0%E9%85%8D%E5%9B%BE%20(19).png”}}]}
这个imageUrl在浏览器里面是可以直接访问的。而且这个URL地址明显是已经 encode过的，所以这问题跟文件预览不一样，不是encode的问题。
实际运行的时候是不是在hzero-aip-app那个容器中运行？ 如果是，那么确实有问题，容器中没有gateway.hzero.com.cn的域名解析。
解决方案：在hzero-gateway 容器的docker-compose.yml中添加别名：gateway.hzero.com.cn，这样让hzero-aip-app服务在容器网络内的服务也能通过gateway.hzero.com.cn访问到hzero-gateway
## 要求Docker/Docker CE >= 19.x
services:
hzero-gateway:
image: hzero-gateway-jk-demo:1.12
container_name: hzero-gateway
networks:
hzero-demo:
aliases: # 在此为网关服务设置网络别名
– gateway.hzero.com.cn # 添加这一行
更改后重启gateway, 再测试，OK了：
关于作者:
| 昵称:Jack.shang 档案信息:jack.shang 程序员->项目经理->技术总监->项目总监->部门总监->事业部总经理->子公司总经理->集团产品运营支持 联系方式:你可以通过syfvb@hotmail.com联系作者 点击查看Jack.shang发表过的所有文章... 本文永久链接： http://blog.retailsolution.cn/archives/4815 |
对本文的评价:
