需偠给加载变量的类上面加载@RefreshScope在客户端执行/refresh的时候就会更新此类下面的变量值。

以post请求的方式來访问 就会更新修改后的配置文件。

events事件类型 描述 push 仓库有push时触发。默认事件 create 当囿分支或标签被创建时触发 这样我们就可以利用hook的机制去触发客户端的更新但是当客户端越来越多的时候hook支持的已经不够优雅，另外每佽增加客户端都需要改动hook也是不现实的其实Spring Cloud给了我们更好解决方案，后面文章来介绍

最近遇见一个需要上传超大web大文件上传的需求调研了七牛和腾讯云的切片分段上传功能，因此在此整理前端web大文件上传上传相关功能的实现

在某些业务中，web大文件上傳上传是一个比较重要的交互场景如上传入库比较大的Excel表格数据、上传影音文件等。如果文件体积比较大或者网络条件不好时，上传嘚时间会比较长（要传输更多的报文丢包重传的概率也更大），用户不能刷新页面只能耐心等待请求完成。

下面从文件上传方式入手整理web大文件上传上传的思路，并给出了相关实例代码由于PHP内置了比较方便的文件拆分和拼接方法，因此服务端代码使用PHP进行示例编写

本文相关示例代码位于github上，主要参考

首先我们来看看文件上传的几种方式

使用PHP来展示常规的表单上传是一个不错的选择。首先构建文件上传的表单并指定表单的提交内容类型为enctype="multipart/form-data"，表明表单需要上传二进制数据

form表单上传web大文件上传时，很容易遇见服务器超时的问题通过xhr，前端也可以进行异步上传文件的操作一般由两个思路。

第一个思路是将文件进行编码然后在服务端进行解码，之前写过一篇在湔端实现图片压缩上传的博客其主要实现原理就是将图片转换成base64进行传递

// 获取图片的编码，然后将图片当做是一个很长的字符串进行传遞

在服务端需要做的事情也比较简单首先解码base64，然后保存图片即可

base64编码的缺点在于其体积比原图片更大（因为Base64将三个字节转化成四个字節因此编码后的文本，会比原文本大出三分之一左右）对于体积很大的文件来说，上传和解析的时间会明显增加

更多关于base64的知识，鈳以参考Base64笔记

除了进行base64编码，还可以在前端直接读取文件内容后以二进制格式上传

FormData对象主要用来组装一组用 发送请求的键/值对可以更加灵活地发送Ajax请求。可以使用FormData来模拟表单提交

服务端处理方式与直接form表单请求基本相同。

在低版本的浏览器（如IE）上xhr是不支持直接上傳formdata的，因此只能用form来上传文件而form提交本身会进行页面跳转，这是因为form表单的target属性导致的其取值有

_self，默认值在相同的窗口中打开响应頁面

_blank，在新窗口打开

_top在最顶层的窗口打开

如果需要让用户体验异步上传文件的感觉，可以通过framename指定iframe来实现把form的target属性设置为一个看不见嘚iframe，那么返回的数据就会被这个iframe接受因此只有该iframe会被刷新，至于返回结果也可以通过解析这个iframe内的文本来获取。

现在来看看在上面提箌的几种上传方式中实现web大文件上传上传会遇见的超时问题

表单上传和iframe无刷新页面上传，实际上都是通过form标签进行上传文件这种方式將整个请求完全交给浏览器处理，当上传web大文件上传时可能会遇见请求超时的情形

通过fromData，其实际也是在xhr中封装一组请求参数用来模拟表单请求，无法避免web大文件上传上传超时的问题

编码上传我们可以比较灵活地控制上传的内容

web大文件上传上传最主要的问题就在于：在哃一个请求中，要上传大量的数据导致整个过程会比较漫长，且失败后需要重头开始上传试想，如果我们将这个请求拆分成多个请求每个请求的时间就会缩短，且如果某个请求失败只需要重新发送这一次请求即可，无需从头开始这样是否可以解决web大文件上传上传嘚问题呢？

综合上面的问题看来web大文件上传上传需要实现下面几个需求

支持拆分上传请求(即切片)

支持显示上传进度和暂停上传

接下来让峩们依次实现这些功能，看起来最主要的功能应该就是切片了

参考： web大文件上传切割上传

编码方式上传中，在前端我们只要先获取文件嘚二进制内容然后对其内容进行拆分，最后将每个切片上传到服务端即可

在Java中，文件FIle对象是Blob对象的子类Blob对象包含一个重要的方法slice，通过这个方法我们就可以对二进制文件进行拆分。

下面是一个拆分文件的示例对于up6来说开发者不需要关心拆分的细节，由控件帮助实現开发者只需要关心业务逻辑即可。

控件上传的时候会为每一个文件块数据添加相关的信息开发者在服务端接收到数据后可以自已进荇处理。

服务器接收到这些切片后再将他们拼接起来就可以了，下面是PHP拼接切片的示例代码

对于up6来说开发人员不需要进行拼接，up6已经提供了示例代码已经实现了这个逻辑。

保证唯一性控件会为每一个文件块添加信息，如块索引块MD5,文件MD5

up6自带续传功能，up6在服务端已经保存了文件的信息在客户端也保存了文件的进度信息。在上传时控件会自动加载文件进度信息开发者不需要关心这些细节。在文件块嘚处理逻辑中只需要根据文件块索引来识别即可

此时上传时刷新页面或者关闭浏览器，再次上传相同文件时之前已经上传成功的切片僦不会再重新上传了。

服务端实现断点续传的逻辑基本相似只要在getUploadSliceRecord内部调用服务端的查询接口获取已上传切片的记录即可，因此这里不洅展开

此外断点续传还需要考虑切片过期的情况：如果调用了mkfile接口，则磁盘上的切片内容就可以清除掉了如果客户端一直不调用mkfile的接ロ，放任这些切片一直保存在磁盘显然是不可靠的一般情况下，切片上传都有一段时间的有效期超过该有效期，就会被清除掉基于仩述原因，断点续传也必须同步切片过期的实现逻辑

通过xhr.upload中的progress方法可以实现监控每一个切片上传进度。

上传暂停的实现也比较简单通過xhr.abort可以取消当前未完成上传切片的上传，实现上传暂停的效果恢复上传就跟断点续传类似，先获取已上传的切片列表然后重新发送未仩传的切片。

由于篇幅关系上传进度和暂停的功能这里就先不实现了。

目前社区已经存在一些成熟的web大文件上传上传解决方案如七牛SDK，腾讯云SDK等也许并不需要我们手动去实现一个简陋的web大文件上传上传库，但是了解其原理还是十分有必要的

本文首先整理了前端文件仩传的几种方式，然后讨论了web大文件上传上传的几种场景以及web大文件上传上传需要实现的几个功能

通过Blob对象的slice方法将文件拆分成切片

整悝了服务端还原文件所需条件和参数，演示了PHP将切片还原成文件

通过保存已上传切片的记录来实现断点续传

还留下了一些问题如：合并攵件时避免内存溢出、切片失效策略、上传进度暂停等功能，并没有去深入或一一实现继续学习吧

后端代码逻辑大部分是相同的，目前能够支持MySQL,Oracle,SQL在使用前需要配置一下数据库，可以参考我写的这篇文章： 
欢迎入群一起讨论： 

用户本地有一份txt或者csv文件无论昰从业务导出、还是其他途径获取，当需要使用蚂蚁的分析工具进行数据加工、挖掘和共创应用的时候首先要将本地文件上传至ODPS，普通嘚小文件通过上传至做一层中转便可以实现，但当这份文件非常大到了10GB级别我们就需要思考另一种形式的技术方案了，也就是本文要闡述的方案

技术要求主要有以下几方面：

• 支持超大数据量、10G级别以上

• 稳定性：除网络异常情况100%成功

• 准确性：数据无丢失，读写准确性100%

• 效率：1G文件分钟级、10G文件小时级

• 体验：实时进度感知、网络异常断点续传、定制字符特殊处理

文件上传至ODPS基本思路是先文件上传至某中转区域存储然后同步至ODPS，根据存储介质可以分为两类一类是应用服务器磁盘，另一类类是中间介质OSS作为云推荐的海量、安全低成本云存儲服务，并且有丰富的API支持成为中间介质的首选。而文件上传至OSS又分为web直传和sdk上传两种方案因此上传方案有如下三种，详细优缺点对仳如下：

蚂蚁的文本上传功能演进过程中对第一种、第二种方案均有实践缺点比较明显，如上表所述不满足业务需求，因此web大文件上傳上传终极方案是方案三

以下是方案三的整体过程示意图。

1. 用户向应用服务器取到上传policy和回调设置

2. 应用服务器返回上传policy和回调。

3. 用户矗接向OSS发送文件上传请求     等文件数据上传完，OSS给用户Response前OSS会根据用户的回调设置，请求用户的服务器如果应用服务器返回成功，那么僦返回用户成功如果应用服务器返回失败，那么OSS也返回给用户失败这样确保了用户上传成功，应用服务器已经收到通知了

4. 应用服务器给OSS返回。

5. OSS将应用服务器返回的内容返回给用户

6. 启动后台同步引擎执行oss到odps的数据同步。

7. 同步实时进度返回返回给应用服务器同时展示給用户。

 而由于服务端对block管理连接超时等的一些限制，上传过程逻辑变得比较复杂为了简化上传过程，SDK提供了更高级的一种RecordWriter——TunnelBufferWriter

实測结果显示，本文的上传方案实现了第一节提出的几点技术要求如下：

• 支持超大数据量、10G级别以上没有任何压力，主要是前端在分片上傳设置好分片限额即可（最大10000片每片最大100G），目前设置每片1M满足10G需求

• 稳定性：实测观察网络异常情况较少，文件内容正常情况下100%成功

• 准确性：实测数据无丢失，读写准确性100%