当云原生成为一种显学，对象存储和数据湖如何顺势而为

已经成为数字化时代显学的云原生并非单项技术，而是一种重塑了软件开发和和业务运行应用的设计思想，是一套技术体系和方法论。云原生“Cloud Native”的 Cloud 是指云平台，Native 则表示应用程序从设计之初即使用云环境、天生为云而设计，充分利用和发挥云平台的弹性+分布式优势。据相关机构（Gartner）预测，部署在云原生平台上的数字工作负载将由 2021 年的 30% 增长至 2025 年的 95%。对象存储作为最早的云服务，已广泛支持各种云业务，在数据湖领域更是成为统一存储的不二之选。

何为云原生

云原生定义

随着技术发展，云原生定义也在不断演进，如下是云原生计算基金会 (CNCF，Cloud Native Computing Foundation）目前的云原生定义：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

此描述的前一句阐述云原生的应用场景和目标，后一句则介绍云原生会使用到的相关技术。目前，以容器、微服务、DevOps 为代表的云原生技术已在金融、电信、互联网等多个行业得到实践和验证，为企业提供了具有弹性、韧性及拓展性的用户体验。

云原生技术特征

根据云原生的技术架构，它可以广泛部署到公共云、私有云、混合云等云环境。

通过 CI/CD 持续集成实现敏捷应用开发。

采用容器的轻量化运行环境降低资源开销、优化成本，基于服务网格（例如 Istio）来管控应用的各模块、实现灵活调度，通过微服务架构理念将应用切分多个模块化服务，基于分而治之的方法让多团队快速迭代开发。

不可变基础设施，则是通过容器镜像（Docker Images）来交付软件，将软件和运行环境打包发布，减少环境适配的复杂度；而提供软件包，再到客户环境部署、调试、运行的方案，则需要考虑各种兼容情况，非常复杂。某些场景下，基于镜像的部署时间只有基于软件包部署时间的 1/10，极大优化软件交付。

声明式 API，类似 K8S（Kubernetes）只需提交定义好的 API 接口来“声明”，表示所期望的最终状态，一次调用就可完成。而软件包部署方式下，需要通过执行命令实现一步一步交互，最终完成发布，这种“命令式 API”相较于 K8S 的“声明式 API”效率低下。所以，通过“声明式 API”可以让系统之间的交付更加简单，无需关注过程细节。

云原生对存储的需求

在上述的云原生技术架构下，对存储提出了诸多需求，包括：

• 容器的安全性

不管是 CI/CD，还是容器、微服务，通常都运行在虚拟网络（VPC）环境中，如何实现 VPC 容器下的安全数据访问是基础要求。

• 微服务的隔离性

基于服务网格、微服务架构，应用需要划分为众多的子服务，降低子服务间的干扰、实现子服务间的数据访问隔离至关重要。

• 弹性扩展能力

微服务架构中的子服务模块会引入突发流量，例如 10,000+ 的容器并发访问数据将会带来访问洪峰。而不可变基础设施的容器镜像批量启动风暴，也会带来集中的瞬时流量，因此需要存储提供弹性扩展能力。

• 高可用、高可靠

微服务架构会产生大量的子服务，它们都需要高可用、高可靠的底层存储，从而实现企业级应用要求的 5 个 9 可用性。

• 单位存储密度的性能，可预期的带宽、时延、OPS

容器化的细粒度运行环境，在公共云上实现了秒级计费能力，比弹性计算服务器的小时级更精细。所以，存储提供单位密度的带宽规格（每 TB 的 Gbps 带宽能力）、稳定的请求时延和 OPS（99.99% 的请求在指定时间 T 内完成），可以有效地帮助微服务评估使用存储的时长，从而可以按需释放容器，获得最合适的性价比。

对象存储如何支持云原生

对象存储符合云原生定义

对象存储作为数据存放的平台，天然支持构建和运行可弹性扩展的应用。而且容器、服务网格、微服务在设计开发的早期就使用对象存储来存放数据，容器镜像数据存放的常用技术也是对象存储。对象存储的 Restful API 完全匹配声明式 API 要求，因此对象存储是云原生数据存储的理想之地。

云原生给对象存储带来的挑战

对象存储应用到云原生，是典型的存算分离架构；同时对象存储作为数据底座，它的高可靠、高可用以及弹性扩展能力，已在云上得到广泛认可。

云原生应用正在引领各个应用领域实现云原生化的同时，也在深刻改变着应用服务的方方面面。对象存储作为应用运行的基石，在服务云原生化过程中遇到了更多的挑战。安全性、隔离性、单位密度的性能，都是对象存储的面临的新挑战，需要集中解决。

对象存储该做些什么

• 加强针对 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 能力，被云原生应用集成。

• 可编排和调度的资源

云原生通过编排和调度实现应用的灵活部署和管理，对象存储需要提供编排和调度的接口，并整合到云原生平台中，从而让存储资源按需快速可用。

云原生充分释放了云计算的红利，未来将有更多的业务应用生于云，长于云。因此，随着云原生架构的应用拓展到更多的领域，新需求将如雨后春笋般涌现，在这样的背景下，数据湖将会不断演进，进而更好满足业务的实际需求。

当云原生成为一种显学，对象存储和数据湖如何顺势而为