前言：
已經成爲數字化時代顯學的雲原生並非單項技術，而是一種重塑了軟件開發和和業務運行應用的設計思想，是一套技術體系和方法論。雲原生“Cloud Native”的Cloud 是指雲平臺，Native則表示應用程序從設計之初即使用雲環境、天生爲雲而設計，充分利用和發揮雲平臺的彈性+分佈式優勢。據相關機構（Gartner）預測，部署在雲原生平臺上的數字工作負載將由 2021 年的 30%增長至 2025 年的 95%。對象存儲作爲最早的雲服務，已廣泛支持各種雲業務，在數據湖領域更是成爲統一存儲的不二之選。
一、何爲雲原生
1.1 雲原生定義
隨着技術發展，雲原生定義也在不斷演進，如下是雲原生計算基金會 (CNCF，Cloud Native Computing Foundation)目前的雲原生定義：
“雲原生技術有利於各組織在公有云、私有云和混合雲等新型動態環境中，構建和運行可彈性擴展的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API。
此描述的前一句闡述雲原生的應用場景和目標，後一句則介紹雲原生會使用到的相關技術。目前，以容器、微服務、DevOps 爲代表的雲原生技術已在金融、電信、互聯網等多個行業得到實踐和驗證，爲企業提供了具有彈性、韌性及拓展性的用戶體驗。
1.2 雲原生技術特徵
根據雲原生的技術架構，它可以廣泛部署到公共雲、私有云、混合雲等雲環境。
通過CI/CD持續集成實現敏捷應用開發。
採用容器的輕量化運行環境降低資源開銷、優化成本，基於服務網格（例如Istio）來管控應用的各模塊、實現靈活調度，通過微服務架構理念將應用切分多個模塊化服務，基於分而治之的方法讓多團隊快速迭代開發。
不可變基礎設施，則是通過容器鏡像（Docker Images）來交付軟件，將軟件和運行環境打包發佈，減少環境適配的複雜度；而提供軟件包，再到客戶環境部署、調試、運行的方案，則需要考慮各種兼容情況，非常複雜。某些場景下，基於鏡像的部署時間只有基於軟件包部署時間的1/10，極大優化軟件交付。
聲明式API，類似 K8S（Kubernetes）只需提交定義好的 API 接口來“聲明”，表示所期望的最終狀態，一次調用就可完成。而軟件包部署方式下，需要通過執行命令實現一步一步交互，最終完成發佈，這種“命令式API”相較於K8S的“聲明式API”效率低下。所以，通過“聲明式API”可以讓系統之間的交付更加簡單，無需關注過程細節。
1.3 雲原生對存儲的需求
在上述的雲原生技術架構下，對存儲提出了諸多需求，包括：
- 容器的安全性
不管是CI/CD，還是容器、微服務，通常都運行在虛擬網絡（VPC）環境中，如何實現VPC容器下的安全數據訪問是基礎要求。
- 微服務的隔離性
基於服務網格、微服務架構，應用需要劃分爲衆多的子服務，降低子服務間的干擾、實現子服務間的數據訪問隔離至關重要。
- 彈性擴展能力
微服務架構中的子服務模塊會引入突發流量，例如10,000+的容器併發訪問數據將會帶來訪問洪峯。而不可變基礎設施的容器鏡像批量啓動風暴，也會帶來集中的瞬時流量，因此需要存儲提供彈性擴展能力。
- 高可用、高可靠
微服務架構會產生大量的子服務，它們都需要高可用、高可靠的底層存儲，從而實現企業級應用要求的5個9可用性。
- 單位存儲密度的性能，可預期的帶寬、時延、OPS
容器化的細粒度運行環境，在公共雲上實現了秒級計費能力，比彈性計算服務器的小時級更精細。所以，存儲提供單位密度的帶寬規格（每TB的Gbps帶寬能力）、穩定的請求時延和OPS（99.99%的請求在指定時間T內完成），可以有效地幫助微服務評估使用存儲的時長，從而可以按需釋放容器，獲得最合適的性價比。
二、對象存儲如何支持雲原生
2.1 對象存儲符合雲原生定義
對象存儲作爲數據存放的平臺，天然支持構建和運行可彈性擴展的應用。而且容器、服務網格、微服務在設計開發的早期就使用對象存儲來存放數據，容器鏡像數據存放的常用技術也是對象存儲。對象存儲的Restful API完全匹配聲明式API要求，因此對象存儲是雲原生數據存儲的理想之地。
2.2 雲原生給對象存儲帶來的挑戰
對象存儲應用到雲原生，是典型的存算分離架構；同時對象存儲作爲數據底座，它的高可靠、高可用以及彈性擴展能力，已在雲上得到廣泛認可。
雲原生應用正在引領各個應用領域實現雲原生化的同時，也在深刻改變着應用服務的方方面面。對象存儲作爲應用運行的基石，在服務雲原生化過程中遇到了更多的挑戰。安全性、隔離性、單位密度的性能，都是對象存儲的面臨的新挑戰，需要集中解決。
2.3 對象存儲該做些什麼
- 加強針對VPC環境的容器訪問對象存儲安全性
實現VPC運行環境和對象存儲桶的安全訪問綁定能力。限定在VPC內只能訪問指定的對象存儲桶，避免“內鬼”從企業VPC將企業的對象存儲數據拷貝到個人的對象數據桶，這需要對象存儲提供VPC Endpoint功能；也需要限定對象存儲桶只能被指定的VPC訪問能力，避免外部黑客盜取密鑰後導致數據泄漏，需要對象存儲提供Bucket Policy功能。
- 微服務的PoD級訪問對象存儲桶的靈活權限
類似雲計算服務器綁定訪問存儲的Access Token，需要爲PoD綁定訪問存儲的Access Token，通過Token的臨時性，避免Access Key這樣的長期密鑰被盜取，從而帶來影響巨大的安全風險。
- 面向微服務的隔離性
訪問隔離。應用的不同子服務，可以使用同一個數據存儲桶，但需要爲每個子服務提供不同的訪問域名，並綁定不同的訪問策略，控制訪問路徑、權限，實現訪問隔離，需要對象存儲提供Access Point功能。
- 流控隔離
爲應用的子服務，提供用戶級、子用戶級、對象存儲桶級的流量控制能力，限制子服務能使用的帶寬，避免應用被異常流量沖垮。
- 提供單位存儲密度性能的規格
通過不同存儲類型，提供差異化的單位存儲密度性能。例如高性能存儲類型，爲每TB容量提供不同帶寬能力，帶寬性能規格越強，價格越高。從而能夠根據實際性能需求，爲應用選擇不同的存儲類型。
- 保證穩定可預期的時延和OPS
存儲的數據訪問時延存在波動，即使大部分時候都是低時延，但少量的長尾高時延，也足以讓雲原生應用的運行時長不可預期，只能按照最壞的長尾高時延設計。所以，對象存儲的各種存儲類型都應該提供穩定的時延和QPS，而不是一味追求極致低時延。
- 熱點數據性能加速
容器批量啓動風暴和並行計算框架，都會帶來大量熱點數據的重複讀。提供靠近容器可用區（AZ）部署的對象存儲熱點數據加速器，可以提高容器加載速度和快速完成並行計算任務。
三、如何做好雲原生下的數據湖
數據湖是解決大數據存儲與利用的有效手段。如下圖所示，爲了更好地適配雲原生應用，數據湖除了更強的高可靠性、高可用、彈性擴展需求外，還需要在安全性、隔離性、支持計算引擎的接口和功能上提供更強的功能。爲了更好的利用雲原生容器的細粒度運行環境，還需要單位存儲密度的性能，實現可預期的帶寬、時延和OPS，以及性能加速能力，從而讓微服務的數據訪問時長可建模計算，使得應用可以精確申請和釋放容器，達到成本優化。
除了這些變化外，還需要關注如下的點：
- 數據湖支撐雲原生計算的接口適配
雲原生理念被廣泛接受，基於雲原生架構構建的數據分析計算引擎遍地開花。而基於對象存儲的數據湖，要支持豐富的計算引擎，包括存量的歷史引擎（如Hadoop生態）、以及新的引擎（如Spark、Iceberg、Hudi、Delta Lake等）。數據湖要支持額這些引擎，就必須要適配數據訪問接口，特別是歷史的Hadoop生態訪問的HDFS接口。
- 可觀測的運維
由於雲原生採用微服務架構，應用通常由多個微服務組成，它簡化了部署難度，但隨着數據鏈路增加，也增大了排查問題、分析性能、度量系統的運維難度。因此雲原生需要架構相關模塊提供可觀測的運維，對象存儲作爲數據存儲也需要提供可觀測運維的Log/Metric/Trace能力，被雲原生應用集成。
- 可編排和調度的資源
雲原生通過編排和調度實現應用的靈活部署和管理，對象存儲需要提供編排和調度的接口，並整合到雲原生平臺中，從而讓存儲資源按需快速可用。
雲原生充分釋放了雲計算的紅利，未來將有更多的業務應用生於雲，長於雲。因此，隨着雲原生架構的應用拓展到更多的領域，新需求將如雨後春筍般湧現，在這樣的背景下，數據湖將會不斷演進，進而更好滿足業務的實際需求。
本文爲阿里雲原創內容，未經允許不得轉載。