阿里雲物件儲存服務（Object Storage Service，簡稱 OSS），是阿里雲提供的海量、安全、低成本、高可靠的雲端儲存服務。您可以通過呼叫 API，在任何應用、任何時間、任何地點上傳和下載資料，也可以通過 Web 控制檯對資料進行簡單的管理。OSS 適合存放任意型別的檔案，適合各種網站、開發企業及開發者使用。按實際容量付費真正使您專注於核心業務。

1 基本概念介紹

1.1 儲存空間（Bucket）

儲存空間是您用於儲存物件（Object）的容器，所有的物件都必須隸屬於某個儲存空間。您可以設定和修改儲存空間屬性用來控制地域、訪問許可權、生命週期等，這些屬性設定直接作用於該儲存空間內所有物件，因此您可以通過靈活建立不同的儲存空間來完成不同的管理功能。

• 同一個儲存空間的內部是扁平的，沒有檔案系統的目錄等概念，所有的物件都直接隸屬於其對應的儲存空間。
• 每個使用者可以擁有多個儲存空間。
• 儲存空間的名稱在 OSS 範圍內必須是全域性唯一的，一旦建立之後無法修改名稱。
• 儲存空間內部的物件數目沒有限制。

儲存空間的命名規範如下：

• 只能包括小寫字母，數字和短橫線（-）。
• 必須以小寫字母或者數字開頭。
• 長度必須在3-63位元組之間。

1.2 物件/檔案（Object）

物件是 OSS 儲存資料的基本單元，也被稱為 OSS 的檔案。物件由元資訊（Object Meta），使用者資料（Data）和檔名（Key）組成。物件由儲存空間內部唯一的 Key 來標識。物件元資訊是一個鍵值對，表示了物件的一些屬性，比如最後修改時間、大小等資訊，同時使用者也可以在元資訊中儲存一些自定義的資訊。

根據不同的上傳方式，物件的大小限制是不一樣的。分片上傳 最大支援 48.8TB 的物件大小，其他的上傳方式最大支援 5GB。

物件的生命週期是從上傳成功到被刪除為止。在整個生命週期內，物件資訊不可變更。重複上傳同名的物件會覆蓋之前的物件，因此，OSS 不支援修改檔案的部分內容等操作。

OSS 提供了 追加上傳 功能，使用者可以使用該功能不斷地在Object尾部追加寫入資料。

物件的命名規範如下：

• 使用UTF-8編碼。
• 長度必須在1-1023位元組之間。
• 不能以“/”或者“\”字元開頭。
• 物件名稱需要區分大小寫。如無特殊說明，本文件中的物件、檔案稱謂等同於 Object。

1.3 Region（區域）

Region 表示 OSS 的資料中心所在的區域，物理位置。使用者可以根據費用、請求來源等綜合選擇資料儲存的 Region。一般來說，距離使用者更近的 Region 訪問速度更快。詳細請檢視 OSS 已經開通的 Region。

Region是在建立 Bucket 的時候指定的，一旦指定之後就不允許更改，該 Bucket 下所有的 Object 都儲存在對應的資料中心，目前不支援 Object 級別的 Region 設定。

1.4 Endpoint（訪問域名）

Endpoint 表示 OSS 對外服務的訪問域名。OSS 以 HTTP RESTful API 的形式對外提供服務，當訪問不同的 Region 的時候，需要不同的域名。通過內網和外網訪問同一個 Region 所需要的 Endpoint 也是不同的。例如杭州 Region 的外網 Endpoint 是 oss-cn-hangzhou.aliyuncs.com，內網 Endpoint 是 oss-cn-hangzhou-internal.aliyuncs.com。具體的內容請參見 各個 Region 對應的 Endpoint。

1.5 AccessKey（訪問金鑰）

AccessKey，簡稱 AK，指的是訪問身份驗證中用到的 AccessKeyId 和AccessKeySecret。OSS 通過使用 AccessKeyId 和 AccessKeySecret 對稱加密的方法來驗證某個請求的傳送者身份。AccessKeyId 用於標識使用者，AccessKeySecret 是使用者用於加密簽名字串和 OSS 用來驗證簽名字串的金鑰，其中 AccessKeySecret 必須保密。對於 OSS 來說，AccessKey 的來源有：

• Bucket 的擁有者申請的 AccessKey。
• 被 Bucket 的擁有者通過 RAM 授權給第三方請求者的 AccessKey。
• 被 Bucket 的擁有者通過 STS 授權給第三方請求者的 AccessKey。

更多 AccessKey 介紹請參見 訪問控制。

1.6 強一致性

Object 操作在 OSS 上具有原子性，操作要麼成功要麼失敗，不會存在有中間狀態的Object。OSS 保證使用者一旦上傳完成之後讀到的 Object 是完整的，OSS 不會返回給使用者一個部分上傳成功的 Object。

Object 操作在 OSS 上同樣具有強一致性，使用者一旦收到了一個上傳（PUT）成功的響應，該上傳的 Object 就已經立即可讀，並且資料的三份副本已經寫成功。不存在一種上傳的中間狀態，即 read-after-write 卻無法讀取到資料。對於刪除操作也是一樣的，使用者刪除指定的 Object 成功之後，該 Object 立即變為不存在。

強一致性方便了使用者架構設計，可以使用跟傳統儲存裝置同樣的邏輯來使用OSS，修改立即可見，無需考慮最終一致性帶來的各種問題。

1.7 OSS與檔案系統的對比

OSS 是一個分散式的物件儲存服務，提供的是一個 Key-Value 對形式的物件儲存服務。使用者可以根據 Object 的名稱（Key）唯一的獲取該Object的內容。雖然使用者可以使用類似 test1/test.jpg 的名字，但是這並不表示使用者的 Object 是儲存在test1 目錄下面的。對於 OSS 來說，test1/test.jpg 僅僅只是一個字串，和a.jpg 這種並沒有本質的區別。因此不同名稱的 Object 之間的訪問消耗的資源是類似的。

檔案系統是一種典型的樹狀索引結構，一個名為 test1/test.jpg 的檔案，訪問過程需要先訪問到 test1 這個目錄，然後再在該目錄下查詢名為 test.jpg 的檔案。因此檔案系統可以很輕易的支援資料夾的操作，比如重新命名目錄、刪除目錄、移動目錄等，因為這些操作僅僅只是針對目錄節點的操作。這種組織結構也決定了檔案系統訪問越深的目錄消耗的資源也越大，操作擁有很多檔案的目錄也會非常慢。

對於 OSS 來說，可以通過一些操作來模擬類似的功能，但是代價非常昂貴。比如重新命名目錄，希望將 test1 目錄重新命名成 test2，那麼 OSS 的實際操作是將所有以 test1/ 開頭的 Object 都重新複製成以 test2/ 開頭的 Object，這是一個非常消耗資源的操作。因此在使用 OSS 的時候要儘量避免類似的操作。

OSS 儲存的 Object 不支援修改（追加寫 Object 需要呼叫特定的介面，生成的 Object 也和正常上傳的 Object 型別上有差別）。使用者哪怕是僅僅需要修改一個位元組也需要重新上傳整個 Object。而檔案系統的檔案支援修改，比如修改指定偏移位置的內容、截斷檔案尾部等，這些特點也使得檔案系統擁有廣泛的適用性。但另外一方面，OSS 能支援海量的使用者併發訪問，而檔案系統會受限於單個裝置的效能。

因此，將 OSS 對映為檔案系統是非常低效的，也是不建議的做法。如果一定要掛載成檔案系統的話，建議儘量只做寫新檔案、刪除檔案、讀取檔案這幾種操作。使用 OSS 應該充分發揮其優點，即海量資料處理能力，優先用來儲存海量的非結構化資料，比如圖片、視訊、文件等。

1.8 OSS 術語表