原创 吴就业 135 0 2023-06-09
本文为博主原创文章,未经博主允许不得转载。
本文链接:https://wujiuye.com/article/debd6d78d3c342d3ad1d55419c5227d3
作者:吴就业
链接:https://wujiuye.com/article/debd6d78d3c342d3ad1d55419c5227d3
来源:吴就业的网络日记
本文为博主原创文章,未经博主允许不得转载。
业务反馈有个iOS设备上传出现403问题,打点日记只能看到403,没有详细的错误信息。
开了s3的日记后,也只是看到403 AccessDenied。根据常见的AccessDenied,排除了客户端时间设置问题。
问s3的人是否可以查到具体的错误,答案也是看不到。
服务端是aws的服务,客户端直传s3,靠自己查怎么查呢?
想到两个排查方案:
代理服务上线后,观察到所有403的请求,响应body如下:
<?xml version="1.0" encoding="UTF-8"?>
<Error>
<Code>AccessDenied</Code>
<Message>AWS authentication requires a valid Date or x-amz-date header</Message>
<RequestId>GWTFZNYPVEQFW5XT</RequestId>
<HostId>LlMv1YmDvqLUZxHP2Tj1CoQWxzhOuB/v/w5v8zzXgy8PkJFlZsJ5fQRKeLC1SlWiZZzlf9mcVWg=</HostId>
</Error>
代理服务打印的客户端请求信息:
/xxx/xxx/1266d18a32a32fcf9675705bfb3a05f2/5ac28032aec305dfe4006cebdc8ed6ab.jpeg
authStr="AWS4-HMAC-SHA256 Credential=xxx/20230608/us-east-1/s3/aws4_request, SignedHeaders=content-length;content-type;host;x-amz-content-sha256;x-amz-date;x-amz-security-token, Signature=4f2639adf461283de1a1976d2af721df4b410f33969c98b6936f008895dedbbf"
header={"content-length":"100792","content-type":"image/jpeg","host":"upload.xxx.com","x-amz-content-sha256":"UNSIGNED-PAYLOAD","x-amz-date":"20230608T122913 AMZ","x-amz-security-token":"FwoGZXIvYXdzEDIaDIMQ+d6Q5/8HZWA/4SLXAl2ndBDJPaHkleFSTMuCHMSlCmviOY4pKzor3GedYQ/5YZEp/omWvFIVjfVODqmLk9u+X47/yA+HCqraKk6Hg/1n3pS/j5OHgwhv+c5dRfKP4Rjs6Em0okPAAR/CdZg53K3TxSBWMqvi8c+wkPM6apSKNc8Pj2S9/uPXkJEu5OyeCPD6JomybI5TczCZaTt4YN2Z7h27ROy6ZtCj+N8KIqZoERQUGH9/IM33AVqeaDU8JIrU3+bHKYVIk5qpFzQQnuYiJleybmwMAyaHjzaJpm6dX+XWQ8BQLjaUkfn2tE45o2/xivtcRixW1BvU1fKJMeXqBkOd7dXBzOyILAM1cJRpU/YFslG71ghwWTe067rAQS+nQqfGCP7N2f3vG2vjfU4u0FujWug259jBf5urj+KLqznDB9W1a9UNy7xRMZnl4C7T5GRNCfqNAtFG1vfG+RGK42YCkF8o2cGEpAYyKebyLKPJqXT2nmauo4AfAm/joTnCgmGpu3RSE49Rt69KWrp4rf/qSMrG"}
reqBody size is 100792
其中请求头x-amz-date的值‘20230608T122913 AMZ’格式有问题,正确应该是20230609T002913Z。
其实这个问题通过抓包就能找出问题,但由于设备是用户的,我们无法要求用户帮忙抓包。然后就是AWS的s3服务不打印请求的详细信息,所以无法通过查看s3的日记定位。
声明:公众号、CSDN、掘金的曾用名:“Java艺术”,因此您可能看到一些早期的文章的图片有“Java艺术”的水印。
因为go标准库实现tls握手性能比较差,在一台8核的机器,只能到达2000这个量级,所以当到达某个临界点的时候,握手占用CPU过高,反过头来影响正常的业务请求,导致了业务请求处理变得十分慢。
用go开发的一个文件上传中间件,由于依赖了ceph这个c库,早期通过pprof排查,怀疑内存泄露在c层,而项目依赖ceph,于是就怀疑是ceph的问题。但通过使用jemalloc排查后,并未发现ceph有什么异常。最后使用最笨的方法,定位到github.com/chai2010/webp库存在内存泄露bug。
一个微服务可能引入非常多的SDK,例如消息中间件kafka的组件、RPC框架dubbo、定时任务调度平台xxl-job的组件,以及提供web服务的jetty/tomcat等。这些组件的初始化是不确定的,那么假如启动初始化过程中,其中某个组件初始化失败了,会发生什么?
基于go提供的基准测试能力编写并发测试用例,为排除脚本本身的性能影响,脚本只实现简单的逻辑,并实现预编译。通过调整虚拟机池策略、cpu数、并行度等,输出调用lua脚本的平均耗时、占用的内存。
moosefs没有关于底层自定义二进制通信协议的文档,且各大版本api上差异很大。我们在github上找到一个go语言实现api操作moosefs的开源库,但不幸的是,这个组件实现的api版本很低,在测试阶段,我们发现上传文件到moosefs后,moosefs上存储的文件的md5与本地原文件md5不一致,如果是图片,能很明显的看出少了一块像素。
订阅
订阅新文章发布通知吧,不错过精彩内容!
输入邮箱,提交后我们会给您发送一封邮件,您需点击邮件中的链接完成订阅设置。