乐趣区

关于java:分布式文件上传导致服务假死了

jiezi

引言

记得以前刚开始学习 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 是由咱们本人申请的bucketname 和endpoint组成的

    然而其实这外面也是有许多坑的咱们还是须要略微留神下。

    带宽限度

    上传和下载都会有带宽的限度，如果咱们是采纳外网直传到阿里云 oss 的话，须要留神下咱们的外网带宽是否够用，以及应答大文件的上传是不是会把带宽打满。如果带宽被打满咱们上传就 gg 了。同样的下载也有带宽限度的，须要防止大文件的下载，如果遇到这种大文件下载咱们能够采纳其余的形式，比方应用 oss 的客户端。所以咱们须要正当的思考咱们服务器的带宽。如果咱们的利用间接是部署在阿里云下面的话，咱们能够采纳内网的上传和下载。这样的话就不会有带宽的限度。

    API 应用须要留神点

    当咱们应用 OSSclient 提供的一些 api 应用的时候须要认真去看看外面是怎么实现的，或者看看它的文档有没有非凡交代的。
    比方应用 OSSclient 提供的 processObject 办法咱们最初须要敞开输出流，如果流不敞开，链接不被开释。利用链接马上就会被占满，而后服务就会成为一个假死的状态，这个问题咱们在生产环境就遇到一次。如下图所示线程始终没有被开释。

    像这种为什么须要咱们手动去敞开流，为什么不间接 api 帮咱们敞开，阿里云的回复是因为这里返回的流可能业务方本人须要复制、或者读什么的。所以须要调用方被动敞开下，在这个很隐秘的文档中咱们也有找到这个答案。

    完结

  • 因为本人满腹经纶，难免会有纰漏，如果你发现了谬误的中央，还望留言给我指出来, 我会对其加以修改。
  • 如果你感觉文章还不错，你的转发、分享、赞叹、点赞、留言就是对我最大的激励。
  • 感谢您的浏览, 非常欢送并感谢您的关注。
    站在伟人的肩膀上摘苹果:
    https://help.aliyun.com/docum…
    https://gosspublic.alicdn.com…
退出移动版