1.引言
已经成为数字化时代显学的云原生并非单项技术，而是一种重塑了软件开发和和业务运行应用的设计思想，是一套技术体系和方法论。云原生“Cloud Native”的Cloud 是指云平台，Native则表示应用程序从设计之初即使用云环境、天生为云而设计，充分利用和发挥云平台的弹性+分布式优势。据相关机构（Gartner）预测，部署在云原生平台上的数字工作负载将由 2021 年的 30%增长至 2025 年的 95%。对象存储作为最早的云服务，已广泛支持各种云业务，在数据湖领域更是成为统一存储的不二之选。
2.何为云原生
2.1 云原生定义
随着技术发展，云原生定义也在不断演进，如下是云原生计算基金会 (CNCF，Cloud Native Computing Foundation)目前的云原生定义：
“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
此描述的前一句阐述云原生的应用场景和目标，后一句则介绍云原生会使用到的相关技术。目前，以容器、微服务、DevOps 为代表的云原生技术已在金融、电信、互联网等多个行业得到实践和验证，为企业提供了具有弹性、韧性及拓展性的用户体验。
2.2 云原生技术特征
根据云原生的技术架构，它可以广泛部署到公共云、私有云、混合云等云环境。
通过CI/CD持续集成实现敏捷应用开发。
采用容器的轻量化运行环境降低资源开销、优化成本，基于服务网格（例如Istio）来管控应用的各模块、实现灵活调度，通过微服务架构理念将应用切分多个模块化服务，基于分而治之的方法让多团队快速迭代开发。
不可变基础设施，则是通过容器镜像（Docker Images）来交付软件，将软件和运行环境打包发布，减少环境适配的复杂度；而提供软件包，再到客户环境部署、调试、运行的方案，则需要考虑各种兼容情况，非常复杂。某些场景下，基于镜像的部署时间只有基于软件包部署时间的1/10，极大优化软件交付。
声明式API，类似 K8S（Kubernetes）只需提交定义好的 API 接口来“声明”，表示所期望的最终状态，一次调用就可完成。而软件包部署方式下，需要通过执行命令实现一步一步交互，最终完成发布，这种“命令式API”相较于K8S的“声明式API”效率低下。所以，通过“声明式API”可以让系统之间的交付更加简单，无需关注过程细节。
2.3 云原生对存储的需求
在上述的云原生技术架构下，对存储提出了诸多需求，包括：
- 容器的安全性
不管是CI/CD，还是容器、微服务，通常都运行在虚拟网络（VPC）环境中，如何实现VPC容器下的安全数据访问是基础要求。
- 微服务的隔离性
基于服务网格、微服务架构，应用需要划分为众多的子服务，降低子服务间的干扰、实现子服务间的数据访问隔离至关重要。
- 弹性扩展能力
微服务架构中的子服务模块会引入突发流量，例如10,000+的容器并发访问数据将会带来访问洪峰。而不可变基础设施的容器镜像批量启动风暴，也会带来集中的瞬时流量，因此需要存储提供弹性扩展能力。
- 高可用、高可靠
微服务架构会产生大量的子服务，它们都需要高可用、高可靠的底层存储，从而实现企业级应用要求的5个9可用性。
- 单位存储密度的性能，可预期的带宽、时延、OPS
容器化的细粒度运行环境，在公共云上实现了秒级计费能力，比弹性计算服务器的小时级更精细。所以，存储提供单位密度的带宽规格（每TB的Gbps带宽能力）、稳定的请求时延和OPS（99.99%的请求在指定时间T内完成），可以有效地帮助微服务评估使用存储的时长，从而可以按需释放容器，获得最合适的性价比。
3.对象存储如何支持云原生
3.1 对象存储符合云原生定义
对象存储作为数据存放的平台，天然支持构建和运行可弹性扩展的应用。而且容器、服务网格、微服务在设计开发的早期就使用对象存储来存放数据，容器镜像数据存放的常用技术也是对象存储。对象存储的Restful API完全匹配声明式API要求，因此对象存储是云原生数据存储的理想之地。
3.2 云原生给对象存储带来的挑战
对象存储应用到云原生，是典型的存算分离架构；同时对象存储作为数据底座，它的高可靠、高可用以及弹性扩展能力，已在云上得到广泛认可。
云原生应用正在引领各个应用领域实现云原生化的同时，也在深刻改变着应用服务的方方面面。对象存储作为应用运行的基石，在服务云原生化过程中遇到了更多的挑战。安全性、隔离性、单位密度的性能，都是对象存储的面临的新挑战，需要集中解决。
3.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）部署的对象存储热点数据加速器，可以提高容器加载速度和快速完成并行计算任务。
4.如何做好云原生下的数据湖
数据湖是解决大数据存储与利用的有效手段。如下图所示，为了更好地适配云原生应用，数据湖除了更强的高可靠性、高可用、弹性扩展需求外，还需要在安全性、隔离性、支持计算引擎的接口和功能上提供更强的功能。为了更好的利用云原生容器的细粒度运行环境，还需要单位存储密度的性能，实现可预期的带宽、时延和OPS，以及性能加速能力，从而让微服务的数据访问时长可建模计算，使得应用可以精确申请和释放容器，达到成本优化。
除了这些变化外，还需要关注如下的点：
- 数据湖支撑云原生计算的接口适配
云原生理念被广泛接受，基于云原生架构构建的数据分析计算引擎遍地开花。而基于对象存储的数据湖，要支持丰富的计算引擎，包括存量的历史引擎（如Hadoop生态）、以及新的引擎（如Spark、Iceberg、Hudi、Delta Lake等）。数据湖要支持额这些引擎，就必须要适配数据访问接口，特别是历史的Hadoop生态访问的HDFS接口。
- 可观测的运维
由于云原生采用微服务架构，应用通常由多个微服务组成，它简化了部署难度，但随着数据链路增加，也增大了排查问题、分析性能、度量系统的运维难度。因此云原生需要架构相关模块提供可观测的运维，对象存储作为数据存储也需要提供可观测运维的Log/Metric/Trace能力，被云原生应用集成。
- 可编排和调度的资源
云原生通过编排和调度实现应用的灵活部署和管理，对象存储需要提供编排和调度的接口，并整合到云原生平台中，从而让存储资源按需快速可用。
云原生充分释放了云计算的红利，未来将有更多的业务应用生于云，长于云。因此，随着云原生架构的应用拓展到更多的领域，新需求将如雨后春笋般涌现，在这样的背景下，数据湖将会不断演进，进而更好满足业务的实际需求。
