Serverless雲平台提供的極致彈效能力，為相關基礎設施帶來巨大的壓力和挑戰，因此阿里雲Container Service聯合多個產品，提供以ECI為例的資料訪問最佳化方案。本文介紹Serverless資料訪問面臨的挑戰以及資料訪問最佳化方案。
Serverless資料訪問面臨的挑戰
Serverless雲平台為使用者提供秒級彈性的核心能力，包括資源和應用（業務）等的秒級彈性，即使用者開始擴容到應用真正就緒提供服務的端到端時間。計算資源能夠實現秒級，甚至毫秒級彈性擴容，因此相關基礎設施面臨巨大的壓力。儲存是最常見的基礎設施，如果儲存系統的IO吞吐能力達不到執行個體變化的速度，例如對於業務來說，容器執行個體2秒完成了擴容，但還需要花幾十秒甚至幾分鐘等待從儲存下載資料，則無法滿足秒級彈性的需求。
Serverless容器化的技術體系對於傳統的儲存系統提出了新的挑戰：
高密訪問：計算資源無儲存能力，資料完全下沉到儲存系統，導致並發資料訪問壓力陡增。不僅影響儲存系統的穩定性，還會使儲存系統服務頻寬利用率達到100%。
網路延時：計算儲存分離架構拉長了儲存訪問鏈路，跨網路通訊資料和中繼資料訪問的額外延遲。
IO吞吐能力的Auto Scaling：傳統分布式儲存頻寬與吞吐僅和資料使用容量成正比，但是以應用為中心的資源彈性會建立大量的容器並發的訪問儲存系統的資料，觸發儲存系統訪問限流。因此造成計算資源極致彈性與儲存系統有限頻寬之間的矛盾。
資料訪問最佳化方案
為了支援Serverless情境，阿里雲Container Service團隊聯合基礎軟體和作業系統團隊、彈性計算ECI團隊和資料湖儲存團隊，提供了以ECI為例的資料訪問最佳化方案。 該方案遵循以下原則：
沿用已有標準保障使用者一致性體驗，例如通過Kubernetes中Sidecar、Device Plugin等標準作為開放介面。
精細化Linux特權控制。
核心及容器底層修改與社區保持同步，按照與社區一致的原則進行設計。
Fluid在Serverless情境的架構包括資料平面（Data Plane）和控制平面（Control Plane）。
資料平面：由不同Runtime對應的Fuse Container組成，Fuse Container以Sidecar的形式和應用一起部署，Sidecar負責接管應用訪問資料的功能。
管理平面：由Injector、Cache Runtime Controller和Application Controller三部分組成。
Injector：負責將不同資料訪問、Runtime實現資訊轉換為Sidecar可以識別的資訊，注入到讀取資料的應用中，同時控制應用中容器的啟動順序。該應用不限於Pod，還包括類似Spark、TFJob、MPIJob等巨量資料AI情境下常見的工作負載。
Cache Runtime Controller：結合Fuse Sidecar中的資料吞吐效果控制資料緩衝彈性，同時管理資料存取權限。
Application Controller：對於類似BatchJob、TFJob、SparkJob等任務類型負載，當其中的使用者任務容器退出後，需要同一個Pod內的Fuse container也可以自動主動退出。