分布式文件上传服务假死?

引言

记得以前刚开始学习web项目的时候,经常涉及到需要上传图片啥的,那时候都是把图片上传到当前项目文件夹下面,每次项目一重启图片就丢了。虽然可以通过修改/tomcat/conf/server.xml配置文件,配置一个上传图片的本地文件夹,即配置一个工程配置虚拟路径,这样可以避免项目重启图片丢失。自从参加工作以来基本就没有遇到使用这种方式来存储图片了。一般要么自己搭建文件服务器,要么使用付费的文件服务。比如七牛云、阿里云、腾讯云等。今天我们就一起来聊聊如何使用阿里云OSS文件上传。

oss 文件上传

使用OSS文件上传,阿里云提供了如下几种方式,大家可以选择适合自己的方式。

Web端上传

Web端常见的上传方法是用户在浏览器或App端上传文件到应用服务器,应用服务器再把文件上传到OSS。具体流程如下图所示。


在这里插入图片描述

这种方式肯定不可取它有如下去缺点:

  • 上传慢:用户数据需先上传到应用服务器,之后再上传到OSS,网络传输时间比直传到OSS多一倍。如果用户数据不通过应用服务器中转,而是直传到OSS,速度将大大提升。而且OSS采用BGP带宽,能保证各地各运营商之间的传输速度。
  • 扩展性差:如果后续用户数量逐渐增加,则应用服务器会成为瓶颈。本来就已经采用了OSS上传了,然后还要在占用自己服务器。
  • 费用高:需要准备多台应用服务器。由于OSS上行流量是免费的,如果数据直传到OSS,将节省多台应用服务器的费用。
JavaScript客户端签名直传

这种方式采用纯前端直接上传,不经过应用服务器,不过这种方式阿里云给到的一些关于OSS上传的一些核心参数(AccesssKey ID和AccessKey Secret相当于我们在阿里云那边申请的账号和密码)也需要写在前端代码里面,这样就容易导致我们核心参数被泄漏。存在安全隐患。这种方式也不推荐。

服务端签名后直传

前面直接在前端签名上传会有安全隐患,存在参数泄漏。我们可以把参数放在服务端,然服务端和阿里云去交互,这样就不存在核心参数的泄漏。


在这里插入图片描述

如何接入

引入依赖
  • 因为本人是从事java开发的,所以直接引入官方提供最新的maven依赖。
<!-- https://mvnrepository.com/artifact/com.aliyun.oss/aliyun-sdk-oss -->
<dependency>
    <groupId>com.aliyun.oss</groupId>
    <artifactId>aliyun-sdk-oss</artifactId>
    <version>3.14.0</version>
</dependency>

为什么要引入最新的依赖。因为如果遇到什么问题需要找阿里云的人帮忙解决的时候,别人大多数都会问你什么版本的sdk,然后如果遇到那种一时半会比较难解决的问题,人家会推荐你升级最新版本试试。因为可能在最新版本修复了你所遇到的bug。有人可能会说,引入最新版本不就是帮别人踩坑吗?万一解决一个bug又引入两个bug列?这种情况也不是没有可能的。

服务端构建签名

在这里插入图片描述

上图是官网提供的入门例子,代码是一大坨,我们可以看看稍微优化后的代码:
创建一个单例的ossClient,可以复用线程,不需要每次都去new ossClient().

        String host = String.format("https://%s.%s", ossPropertoooies.getBucketName(), ossPropertoooies.getEndpoint());
        long expiredTime = System.currentTimeMillis() + fileOssProperties.getUploadSignatureTtl();
        Date expiration = new Date(expiredTime);

        // 根据文件名和文件类型设置存储路径,可以按照文件类型+日期格式+UUID文件名 进行分割
        String filepath = getFilePath(request.getCategory(), request.getFilename());

        PolicyConditions policyConditions = new PolicyConditions();
        policyConditions.addConditionItem(PolicyConditions.COND_CONTENT_LENGTH_RANGE, 0, fileOssProperties.getUploadSizeLimit());
        policyConditions.addConditionItem(MatchMode.StartWith, PolicyConditions.COND_KEY, filepath);

        String postPolicy = ossClient.generatePostPolicy(expiration, policyConditions);
        byte[] binaryData = postPolicy.getBytes(StandardCharsets.UTF_8);
        String encodedPolicy = BinaryUtil.toBase64String(binaryData);
        String postSignature = ossClient.calculatePostSignature(postPolicy);

        SignatureDTO signature = new SignatureDTO();
        signature.setAccessId(ossPropertoooies.getAccessKeyId());
        signature.setPolicy(encodedPolicy);
        signature.setSignature(postSignature);
        signature.setFilepath(filepath);
        signature.setHost(host);
        signature.setExpire(fileOssProperties.getUploadSignatureTtl() / 1000);
        signature.setReqFilename(request.getFilename());

接入起来还是非常简单的,一个后端签名,前端上传前后分离的文件上传就已经完成了。这里我们使用postman模拟下前端上传,当然这里可以改为前端使用ajax,或者其他方式都可以。上传的url是由我们自己申请的bucketnameendpoint组成的
[图片上传失败...(image-10af6a-1646306126061)]
但是其实这里面也是有许多坑的我们还是需要稍微注意下。

带宽限制

上传和下载都会有带宽的限制,如果我们是采用外网直传到阿里云oss的话,需要注意下我们的外网带宽是否够用,以及应对大文件的上传是不是会把带宽打满。如果带宽被打满我们上传就gg了。同样的下载也有带宽限制的,需要避免大文件的下载,如果遇到这种大文件下载我们可以采用其他的方式,比如使用oss的客户端。所以我们需要合理的考虑我们服务器的带宽。如果我们的应用直接是部署在阿里云上面的话,我们可以采用内网的上传和下载。这样的话就不会有带宽的限制。

API使用需要注意点

当我们使用OSSclient提供的一些api使用的时候需要仔细去看看里面是怎么实现的,或者看看它的文档有没有特殊交代的。
比如使用OSSclient提供的processObject方法我们最后需要关闭输入流,如果流不关闭,链接不被释放。应用链接马上就会被占满,然后服务就会成为一个假死的状态,这个问题我们在生产环境就遇到一次。如下图所示线程一直没有被释放。

在这里插入图片描述

像这种为什么需要我们手动去关闭流,为什么不直接api帮我们关闭,阿里云的回复是因为这里返回的流可能业务方自己需要复制、或者读什么的。所以需要调用方主动关闭下,在这个很隐秘的文档中我们也有找到这个答案。
在这里插入图片描述

结束

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 217,406评论 6 503
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,732评论 3 393
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 163,711评论 0 353
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,380评论 1 293
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,432评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,301评论 1 301
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,145评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,008评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,443评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,649评论 3 334
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,795评论 1 347
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,501评论 5 345
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,119评论 3 328
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,731评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,865评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,899评论 2 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,724评论 2 354

推荐阅读更多精彩内容