上传文件时候的处理
对象存储alpha版本
- 实现方式：分为4种手段，小文件的普通上传、中等文件的分片上传、大文件的分片多线程上传、超大文件的工具上传。这里的大小其实没有明确的定义，是根据服务器的用户数目以及服务器的负载能力划分的，按照当时的版本，与上面描述对应的大小为：0~5M、5~100M、100~300M、>300M。
- 设计想法：这个其实也是最近在做微服务架构改造的时候才想通的，由于之前组内人员离职严重，导致的交接问题，好多东西都要自己去和其他厂商产品对标然后自己去悟。前面的3种方式不想过多讨论，主要疑惑在工具上传这，工具上传实际上是指用户在上传300M以上大小的文件的时候，不能再通过控制台界面进行上传了，（先声明此时的架构是单体架构），原因是当用户上传过大的文件的时候，很可能将公有云项目部署的服务器的带宽整个吃满，这会导致整个公有云瘫痪，其他产品也都会无法使用了。但是使用工具上传，是让用户通过配置直接连接后台的rgw网关，不需要走公有云部署的那台服务器了，这样就不会对整个公有云项目产生影响了。
对象存储3.0版本
- 实现方式：在相对较小的文件上传这里没什么不同，主要问题还是在过大的文件上传的处理这块。
- 设计想法：1.依然和之前一样，通过工具上传，这个是华为云的处理方式；2.通过前端js处理，即上传时直接从浏览器发送到rgw网管，不再走Java后端，腾讯云好像是这种处理方式；3.由于当前版本采用的是微服务架构，所以对象存储项目可以作为单独的服务直接部署到rgw这里，这样虽然也是需要将文件走Java后端，但是不需要再走互联网再绕道业务内网这里了
Token认证的问题
这里其实之前的版本存在问题，明明S3中已经有com.amazonaws.auth.BasicSessionCredentials这个类了，为什么还要修改com.amazonaws.auth.BasicAWSCredentials导致了大量的类进行了修改，我不是很理解这种做法。所以在token这里，S3源码是已经提供了支持的了。然后当用户量上去之后，实际上token服务器的负载会存在瓶颈，这里的改造方案是使用OpenStack的keystone认证，然后构建高可用服务器，这里的具体细节还需要进一步讨论。总之当前的主要方案是使用OpenStack全家桶，后台的ceph存储也要改成OpenStack的swift，toekn认证也要改成OpenStack的keystone。
20180819：修改BasicAWSCredentials我看出了一点端倪，在发送HTTP请求给rgw的时候，会传递ClientIP和username的参数，也就是token服务器的IP以及对象存储用户名，但是我觉得这里设计不合理，这个token服务器IP就是一个配置信息，现在我每次发一个请求都要存一遍，直接在rgw侧读取配置不就好了么；还有username，这个应该封装到token里面了，怎么还要用username去识别？我觉得不合理。
业务API和第三方API的封装
业务API的用处主要是提供给前端界面工程的（因为前后端分离了么）；第三方的API支持标准S3协议，是提供给想要购买公司服务的第三方企业，他们需要用到我们的业务逻辑，包括资源用量统计、计费业务等等。
- 业务API：可以看到图上前端向后端发送请求的地方打个问号，这是因为具体实现还没确定，领导的意思是将业务API和第三方API最好能用一套方案实现，但是这个可行性我觉得很低，原因是由于业务API必定会包含很多我们自定义的参数，如果采用的报文头传参的话，那么会有很多自定义的报文头；然后另一种考虑是，既然实现为一套API的可能性不大，那么为什么还要那么麻烦，采用报文的形式传参，然后将我们自定义的报文头转化为亚马逊的报文头（PRD人员说不能使用带有amz字段的报文头，要改成oss这种），饶了一大圈，还不如使用原来直接传参的形式，这样使用接收到的参数经过业务处理直接调用S3的接口不就行了。当然这也是我个人考虑，没啥经验，也没啥安全。架构、或者维护方面的考量，加上原组长离职，这些东西谁也不是搞得很清楚，只有试的时候才知道，我真心需要个人为我解惑。当前境地很尴尬。
- 第三方API：如图上所示，第三方可能已经实现了自己的前端界面，不用我们提供的界面，他们又支持标准的S3协议，想要买过来直接能用。这里我之前一直理解成原子API那一层，直到开会的时候我提出后，同事告诉我他们需要用我们的业务，也就是计费啊，用户啊，统计啊这些东西，所以它还是属于业务API的东西。这里想了想，因为要支持标准S3协议，不能再有自定义的报文头参数等等，所以好多东西只能在后端内部转化，也就是以S3里面的参数信息为查询的引子。这个是腾讯云的文档、这个是阿里云的文档