Serverless云平台提供的极致弹性能力，为相关基础设施带来巨大的压力和挑战，因此阿里云容器服务联合多个产品，提供以ECI为例的数据访问优化方案。本文介绍Serverless数据访问面临的挑战以及数据访问优化方案。
Serverless数据访问面临的挑战
Serverless云平台为用户提供秒级弹性的核心能力，包括资源和应用（业务）等的秒级弹性，即用户开始扩容到应用真正就绪提供服务的端到端时间。计算资源能够实现秒级，甚至毫秒级弹性扩容，因此相关基础设施面临巨大的压力。存储是最常见的基础设施，如果存储系统的IO吞吐能力达不到实例变化的速度，例如对于业务来说，容器实例2秒完成了扩容，但还需要花几十秒甚至几分钟等待从存储下载数据，则无法满足秒级弹性的需求。
Serverless容器化的技术体系对于传统的存储系统提出了新的挑战：
高密访问：计算资源无存储能力，数据完全下沉到存储系统，导致并发数据访问压力陡增。不仅影响存储系统的稳定性，还会使存储系统服务带宽利用率达到100%。
网络延时：计算存储分离架构拉长了存储访问链路，跨网络通信数据和元数据访问的额外延迟。
IO吞吐能力的弹性伸缩：传统分布式存储带宽与吞吐仅和数据使用容量成正比，但是以应用为中心的资源弹性会创建大量的容器并发的访问存储系统的数据，触发存储系统访问限流。因此造成计算资源极致弹性与存储系统有限带宽之间的矛盾。
数据访问优化方案
为了支持Serverless场景，阿里云容器服务团队联合基础软件和操作系统团队、弹性计算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也可以自动主动退出。