对象存储项目小记

上传文件时候的处理

对象存储alpha版本

• 实现方式：分为4种手段，小文件的普通上传、中等文件的分片上传、大文件的分片多线程上传、超大文件的工具上传。这里的大小其实没有明确的定义，是根据服务器的用户数目以及服务器的负载能力划分的，按照当时的版本，与上面描述对应的大小为：0~5M、5~100M、100~300M、>300M。
• 设计想法：这个其实也是最近在做微服务架构改造的时候才想通的，由于之前组内人员离职严重，导致的交接问题，好多东西都要自己去和其他厂商产品对标然后自己去悟。前面的3种方式不想过多讨论，主要疑惑在工具上传这，工具上传实际上是指用户在上传300M以上大小的文件的时候，不能再通过控制台界面进行上传了，（先声明此时的架构是单体架构），原因是当用户上传过大的文件的时候，很可能将公有云项目部署的服务器的带宽整个吃满，这会导致整个公有云瘫痪，其他产品也都会无法使用了。但是使用工具上传，是让用户通过配置直接连接后台的rgw网关，不需要走公有云部署的那台服务器了，这样就不会对整个公有云项目产生影响了。

对象存储3.0版本

• 实现方式：在相对较小的文件上传这里没什么不同，主要问题还是在过大的文件上传的处理这块。
• 设计想法：1.依然和之前一样，通过工具上传，这个是华为云的处理方式；2.通过前端js处理，即上传时直接从浏览器发送到rgw网管，不再走Java后端，这里调研了下，aws是有js的sdk的；3.由于当前版本采用的是微服务架构，所以对象存储项目可以作为单独的服务直接部署到rgw这里，这样虽然也是需要将文件走Java后端，但是不需要再走互联网再绕到业务内网这里了

20180906：根据对腾讯、阿里的调研，当前设计的实现方式是在前端进行文件的分片，然后将分片文件和partNum发送到rgw网关，不走Java后端的代码。

Token认证的问题

这里其实之前的版本存在问题，明明S3中已经有com.amazonaws.auth.BasicSessionCredentials这个类了，为什么还要修改com.amazonaws.auth.BasicAWSCredentials导致了大量的类进行了修改，我不是很理解这种做法。所以在token这里，S3源码是已经提供了支持的了。然后当用户量上去之后，实际上token服务器的负载会存在瓶颈，这里的改造方案是使用OpenStack的keystone认证，然后构建高可用服务器，keystone的效率要比我们自己的好很多。总之当前的主要方案是使用OpenStack全家桶，后台的ceph存储也要改成OpenStack的swift，toekn认证也要改成OpenStack的keystone。
20180819：修改BasicAWSCredentials我看出了一点端倪，在发送HTTP请求给rgw的时候，会传递ClientIP和username的参数，也就是token服务器的IP以及对象存储用户名，但是我觉得这里设计不合理，这个token服务器IP就是一个配置信息，现在我每次发一个请求都要存一遍，直接在rgw侧读取配置不就好了么；还有username，这个应该封装到token里面了，怎么还要用username去识别？我觉得不合理。
20180829： token问题的最后结果就是不使用token去验证，因为目前前端统一使用keycloak进行用户管理，在请求发送到java后端的时候，token是否合法已经经过验证了，而之前rgw这里添加token的原因是因为，下载操作的时候会将rgw的ip暴露出来，但是如果将rgw完全封到内网中，就没必要加token进行二次验证了（accessKey和secretKey本身就有加密功能）
20180907：在实际操作的过程中发现，rgw是可能会暴露自己的域名的，那么只是用s3自带的accessKey和secretKey的话，正常使用是没问题的，但是由于分享文件链接的时候，链接组成非常简单，假如有人故意试验，是可能试出这个桶内其他文件的url的，如果url加上了token后，这个url就变得几乎不可破解了，增强了安全性。

业务API和第三方API的封装

业务API的用处主要是提供给前端界面工程的（因为前后端分离了么）；第三方的API支持标准S3协议，是提供给想要购买公司服务的第三方企业，他们需要用到我们的业务逻辑，包括资源用量统计、计费业务等等。

• 业务API：可以看到图上前端向后端发送请求的地方打个问号，这是因为具体实现还没确定，领导的意思是将业务API和第三方API最好能用一套方案实现，但是这个可行性我觉得很低，原因是由于业务API必定会包含很多我们自定义的参数，如果采用的报文头传参的话，那么会有很多自定义的报文头；然后另一种考虑是，既然实现为一套API的可能性不大，那么为什么还要那么麻烦，采用报文的形式传参，然后将我们自定义的报文头转化为亚马逊的报文头（PRD人员说不能使用带有amz字段的报文头，要改成oss这种），饶了一大圈，还不如使用原来直接传参的形式，这样使用接收到的参数经过业务处理直接调用S3的接口不就行了。当然这也是我个人考虑，没啥经验，也没啥安全。架构、或者维护方面的考量，加上原组长离职，这些东西谁也不是搞得很清楚，只有试的时候才知道，我真心需要个人为我解惑。当前境地很尴尬。
• 第三方API：如图上所示，第三方可能已经实现了自己的前端界面，不用我们提供的界面，他们又支持标准的S3协议，想要买过来直接能用。这里我之前一直理解成原子API那一层，直到开会的时候我提出后，同事告诉我他们需要用我们的业务，也就是计费啊，用户啊，统计啊这些东西，所以它还是属于业务API的东西。这里想了想，因为要支持标准S3协议，不能再有自定义的报文头参数等等，所以好多东西只能在后端内部转化，也就是以S3里面的参数信息为查询的引子。这个是腾讯云的文档、这个是阿里云的文档

20180907：在具体理解了项目内容后，我觉得做的这个产品是个没希望的产品：

1. 领导对对象存储的业务基本不熟悉，而且本次是平台整体重构，精力不够，我们5个人想做出和华为、腾讯2、30人做出的效果，我觉得异想天开
2. 组内成员能力问题，大家心不齐，做出的东西也肯定是垃圾
3. 方案变动非常频繁，要啥接口没啥接口，编程进度缓慢
4. 产品设计人员理不清用户需求和体验，想要先提供出直接对接第三方的s3报文格式的接口，但是我们还没有sdk，需要用户自己去写，我要是用户，我绝对不用这么不成熟的产品。