Minio 为什么没有 POST 接口?

Minio 为什么没有 POST 上传接口?

Minio 是著名的开源的 S3 存储项目,实现了完整的 S3 协议。仔细看了下实现,会发现 Minio 没有实现 PostObject 的接口?为什么?

Minio 实现的完整对象 S3 接口如下:

// Object operations
// HeadObject
bucket.Methods(http.MethodHead).Path("/{object:.+}").HandlerFunc(httpTraceAll(api.HeadObjectHandler))
// CopyObjectPart
bucket.Methods(http.MethodPut).Path("/{object:.+}").HeadersRegexp(xhttp.AmzCopySource, ".*?(\\/|%2F).*?").HandlerFunc(httpTraceAll(api.CopyObjectPartHandler)).Queries("partNumber", "{partNumber:[0-9]+}", "uploadId", "{uploadId:.*}")
// PutObjectPart
bucket.Methods(http.MethodPut).Path("/{object:.+}").HandlerFunc(httpTraceHdrs(api.PutObjectPartHandler)).Queries("partNumber", "{partNumber:[0-9]+}", "uploadId", "{uploadId:.*}")
// ListObjectPxarts
bucket.Methods(http.MethodGet).Path("/{object:.+}").HandlerFunc(httpTraceAll(api.ListObjectPartsHandler)).Queries("uploadId", "{uploadId:.*}")
// CompleteMultipartUpload
bucket.Methods(http.MethodPost).Path("/{object:.+}").HandlerFunc(httpTraceAll(api.CompleteMultipartUploadHandler)).Queries("uploadId", "{uploadId:.*}")
// NewMultipartUpload
bucket.Methods(http.MethodPost).Path("/{object:.+}").HandlerFunc(httpTraceAll(api.NewMultipartUploadHandler)).Queries("uploads", "")
// AbortMultipartUpload
bucket.Methods(http.MethodDelete).Path("/{object:.+}").HandlerFunc(httpTraceAll(api.AbortMultipartUploadHandler)).Queries("uploadId", "{uploadId:.*}")
// GetObjectACL - this is a dummy call.
bucket.Methods(http.MethodGet).Path("/{object:.+}").HandlerFunc(httpTraceHdrs(api.GetObjectACLHandler)).Queries("acl", "")
// GetObjectTagging - this is a dummy call.
bucket.Methods(http.MethodGet).Path("/{object:.+}").HandlerFunc(httpTraceHdrs(api.GetObjectTaggingHandler)).Queries("tagging", "")
// SelectObjectContent
bucket.Methods(http.MethodPost).Path("/{object:.+}").HandlerFunc(httpTraceHdrs(api.SelectObjectContentHandler)).Queries("select", "").Queries("select-type", "2")
// GetObject
bucket.Methods(http.MethodGet).Path("/{object:.+}").HandlerFunc(httpTraceHdrs(api.GetObjectHandler))
// CopyObject
bucket.Methods(http.MethodPut).Path("/{object:.+}").HeadersRegexp(xhttp.AmzCopySource, ".*?(\\/|%2F).*?").HandlerFunc(httpTraceAll(api.CopyObjectHandler))
// PutObject
bucket.Methods(http.MethodPut).Path("/{object:.+}").HandlerFunc(httpTraceHdrs(api.PutObjectHandler))
// DeleteObject
bucket.Methods(http.MethodDelete).Path("/{object:.+}").HandlerFunc(httpTraceAll(api.DeleteObjectHandler))

我们看到关于对象上传的操作只有:

  1. PutObjectPart:上传分段(PUT请求)
  2. PutObject:普通上传(PUT请求)

根本就没有 PostObject

S3 上传协议

S3 上传的方式基本分为两种:

  1. 普通上传
  2. 分段上传

普通上传按照 HTTP Method 的不同,又可以分为两种:

  1. PutObject
  2. PostObject

Post 请求也就是我们常见的表单上传的模式,这是一种流式的上传,一般浏览器上传文件最常见。这种方式上传,在 HTTP Headers 可以不携带 Content-Length ,传输格式一般用 chunked 的特殊格式来标识传输结束位置。

一般请求的头部格式如下:

POST / HTTP/1.1
. . .
Content-Type: multipart/form-data; boundary=9431149156168
Content-Length: length <非强制,可选>

在 S3 协议里,PutObject 请求是要求头部必须携带 Content-length 的,这样对象存储系统就能知道这次 S3 上传需要多大的空间,但是 PostObject 上传的方式就特殊了,再数据上传完之前,后端根本无法知道数据有多大,这种情况就会带来复杂性。

要理解为什么没有 PostObject 接口,首先得明白为什么 Content-length 。

为什么需要 Content-length ?

这个很容易理解,因为你需要知道这次 S3 上传请求需要多大的空间。存储后端拿到这个 Content-length 之后,就能首先把这部分空间分配出来,然后把数据往这部分空间写入即可。如果你不知道该分配多少空间,又怎么知道该怎么写入呢?

首先看下 Minio PutObject 是怎么实现的?

object-handlers.go 文件是函数 PutObjectHandler 的实现:

func (api objectAPIHandlers) PutObjectHandler (w http.ResponseWriter, r *http.Request) {

    /// if Content-Length is unknown/missing, deny the request
    size := r.ContentLength

    // size 校验

    // 确认分片数量,条带深度等;

    // 用 size new 一个 reader;

    // 写数据到存储系统    
}

从这个实现也能看到,Minio 的 Putobject 是必须要求 Http 头部携带 Content-length 的。获取的 Content-length 也就是我们所谓的对象 size ,这样你就能知道分配多少物理空间,如果做了条带化,就能知道每个条带的深度,在数据上传之前,需要的元数据是已经明确的。

举个例子,存储系统假设是 3+2 的 EC 模式,现在知道对象 size 30 M,我只需要准备好 5 个 10M 大小的存储块就够了,先分配好,然后数据往里面写,并且数据传输之前,元数据的大小和模式也是固定的。

没有 size ,怎么存储数据?

那么,如果我们数据传输之前拿不到对象 size 大小,那么就不能上传了吗?也有办法,只不过有些复杂,也有些人为的限制条件。

方法一:一小段一小段的数据收,收完一段存一份元数据,最后汇总;

这种方法可能元数据可能会比较多(需要优化),并且内部实现也会比较复杂。

举个例子,在一个 3+2 EC 存储系统中,如果提前不知道一个请求占用多大,那么先收取 1M,然后把这 1M 的数据 EC 化得到一个元数据,然后继续收取 1M,EC 存储,最后元数据汇总,然后向用户返回结果。由于拆分了很多步骤,并且实现终点不可知,所以要处理的异常就会很多。

还有一个最重要的限制:用户数据部分 file 字段必须在最后一个。 后面如果还有 field 是直接丢弃不解析的。AWS 就明确限制了这一点:

c81fb765c29fc197543dbe2367c22ca9.png

有了这个限制之后,当存储后端读完 HTTP Header 之后,拿到 file 字段,就认为后面的全都是数据,就走数据存储流程去了。

方法二:后端在 buffer 里面收完整个请求,自然就能计算出 size,然后再把数据存储到后端;

这种方式实现最简单,也通用,不要求 file 字段是最后一个字段,缺点是性能太差,相当于写两遍,时延 2 倍。

func PostObject (  ) {
    
    // 解析 post 请求
    // request.ParseMultipartForm
    
    // 拿到请求 size
    
    // 分配空间
    
    // 存储后端
}

golang 自带的 request.ParseMultipartForm 要慎用,因为这个方法会读完整个 body ,然后解析完 POST 请求再返回,所以这个方法要慎用,可能请求会很慢。

func parsePostForm(r *Request) (vs url.Values, err error) {

    ct, _, err = mime.ParseMediaType(ct)
    switch {
    // 解析完所有的请求
    case ct == "application/x-www-form-urlencoded":
        var reader io.Reader = r.Body
        maxFormSize := int64(1<<63 - 1)
        if _, ok := r.Body.(*maxBytesReader); !ok {
            maxFormSize = int64(10 << 20) // 10 MB is a lot of text.
            reader = io.LimitReader(r.Body, maxFormSize+1)
        }
        // 读完整个 body
        b, e := ioutil.ReadAll(reader)
        if e != nil {
            if err == nil {
                err = e
            }
            break
        }
        if int64(len(b)) > maxFormSize {
            err = errors.New("http: POST too large")
            return
        }
        vs, e = url.ParseQuery(string(b))
        if err == nil {
            err = e
        }
    case ct == "multipart/form-data":
    }
    return
}

公有云关于这里的隐藏知识点

我们再去分析下公有云厂商的实现:

AWS

b3a3d57a7690cbd10c4ea8116657f92b.png

腾讯云

ba5fc3bd64ce7392e70059418cc40aa4.png

阿里云

becac709b2488cfb2369c392273f25af.png

从这里来看,多家公有云都是实现了 PostObject 这个接口,因为都是公有云厂商,是要跟上大部队的,谁没有这个接口谁就吃亏。内部实现我们不得而知,但是从各家 file 字段的限制来看,应该都是解析完 Http 头部,就直接走数据存储了,因为这样的性能是最好的。

总结

分析来看,PostObject 对系统的架构要求会更高一些,因为会给系统带来更多的复杂性。Minio 作为一个开源的 S3 存储项目,为了自身架构的简单化,直接就摒弃了这个接口也是一种考量。


坚持思考,方向比努力更重要。关注公众号:奇伢云存储,获取更多干货。 关注我公众号, 获取更多干货