云原生数据库技术有哪些？云原生技术及概念说明

云原生的概念和演进都是围绕云计算的核心价值展开的，比如弹性、自动化、韧性，因此云原生技术领域比较丰富，本文主要介绍容器、DevOps、微服务、Serverless、开放应用模型、Service Mesh、分布式消息队列、云原生数据库、云原生大数据、云原生 AI、云端开发和云原生安全等方面

容器技术

背景和价值

容器作为标准化软件单元，可用于将应用及其所有依赖项整体打包，使应用不再受到环境的限制，从而可以在不同计算环境之间快速、可靠地运行

Docker 容器引擎开源后，才真正意义上降低了容器技术使用的复杂性，加速了容器技术的普及。Docker 容器基于系统虚拟化技术，具有共享操作系统内核、轻量、无资源损耗、秒级启动等优势，极大提升系统的应用部署密度和弹性。同时，Docker 提出创新的应用打包规范，即 Docker 镜像，实现了应用与运行环境的解耦，使应用可以在不同计算环境间一致、可靠低运行

Kubernetes 开源后，凭借优秀的开放性、可扩展性以及活跃的开发者社区，在容器编排中脱颖而出，成为分布式资源调度和自动化运维的事实标准。Kubernetes 屏蔽了底层架构的差异，以优良的可移植性，帮助应用在包括数据中心、云端、边缘计算等不同环境中运行时保证一致性

容器技术的三个最受用户关注的核心价值

敏捷：容器技术极大提升了企业产品交付效率，如此企业不仅可以更快地迭代产品，而且可以降低业务的试错成本

弹性：通过容器技术，企业可以充分发挥云计算的弹性优势

可移植性：容器已成为分发和交付的标准技术，可实现应用与底层运行环境的解耦，Kubernetes 可以屏蔽 IaaS 层架构的差异性，帮助应用平滑地运行在不同的基础设施上

典型的容器技术

1、容器编排

Kubernetes 已成为资源调度和容器编排的事实标注，用于自动部署、扩展和管理容器化应用中，它提供了分布式应用管理的核心能力

资源调度：根据应用请求的资源量在集群中选择合适的节点来运行应用

应用部署和管理：支持应用的自动发布和回滚以及与应用相关的配置管理，同时可以自动化编排存储卷，让存储卷和容器应用的生命周期相关联

自动修复：可以监测集群中所有的宿主机，当宿主机或 OS 出现故障，节点健康检查会自动迁移应用，同时还支持应用的自愈，极大低简化了运维管理的复杂度

服务发现与负载均衡：通过 Service 资源发现各种服务，结合 DNS 和多种负载均衡机制，支持容器化应用之间的相互通信

弹性伸缩：用于监测业务上所承担的负载，如果负载过高，会自动扩容该业务

2、Kubernetes 控制平面包含四个主要组件

API Server

Controller Manager

Schedule

Etcd

Kubernetes 在容器编排中的几个关键设计理念

声明式 API

可扩展性架构

可移植性2、安全容器

结合隔离技术实现的安全容器方案，主要包括

用户态内核：典型代表是 Google 的 gVisor，一种进程虚拟化增强的容器，通过实现独立的用户态内核，捕获和代理应用所有系统调用，隔离非安全的系统调用，间接达到安全的目的。但 gVisor 的应用兼容性和系统调用方面的性能比普通 RunC 容器差，同时不支持 virtio 等虚拟框架，扩展性较差，且不支持设备热插拔

LibOS：以 UniKernel、Nabla-Container 为代表，技术本质上是针对应用内核的一个深度裁剪和定制，因为需要与应用编译打包一起，但兼容性比较差，应用与 LibOS 的捆绑编译和部署会增加 DevOps 实现的难度

MicvroVM：是对传统虚拟化技术的裁剪，有非常优秀的扩展能力，典型代表是 Kata-Containers 和 Firecracker

3、边缘容器

基于 Kubernetes 构建的边缘容器，通过“云管边”架构，大大提升了云计算向边缘扩展的效率，并降低了边缘计算的成本，鉴于设备及业务场景的特殊性，边缘应用对容器技术提出了新的需求

资源协同

应用协同

智能协同

数据协同

轻量化

特点

对原生 Kubernetes 零侵入

无缝转换

系统开销低

DevOps 技术

Development + Operations 作为一组过程、方法与系统的统称。旨在促进开发、技术运营和质量保障部门质检的沟通、协作与整合

DevOps 重视软件开发人员 Dev 和 IT 运维技术人员 Ops 之间沟通合作的文化、习惯和方式

自动化软件交付和架构变更的流程，可以使软件的构建、测试和发布变得更加快捷、频繁和可靠

背景和价值

基本思想是持续交付（Continuous Delivery，CD），让软件的构建、测试和发布变得更加快捷可靠，尽量简化系统变更流程，缩短从提交到最终安全部署到生产系统的时间

云原生给 DevOps 提供便利条件

容器技术和 Kubernetes 服务编排技术的结合，解决应用部署自动化、运维化、配置化的问题

促进 DevOps 的演进

原则和技术

1、原则

文化：DevOps 解决的核心问题是人与业务、人与人的问题，即如何提高研发效率、加强跨团队协作

自动化：DevOps 目标是小不快跑、快速迭代、频繁发布

度量：用于对各个活动和流程进行分析，找到工作中存在的瓶颈和漏洞，并在发生危机情况时及时报警，从而能够根据分析结果调整团队的工作和系统，提升效率，形成完整闭环

共享：共享知识可以使团队共同进步

可见度：了解团队其他人的工作，相互反馈使问题尽早暴露并得到解决

透明性：明白共同目标，缺乏透明性会导致工作安排失调

知识共享：解决个人成为单点的问题，同时提高团队的集体能力

2、工具链

项目协作

代码管理

构建

测试

制品库

交付

流水线

运维

微服务

传统软件是各种独立系统的堆砌，导致扩展性差、可靠性低、维护成本高

对着开发技术的发展以及 SOA 引入，上述问题得到一定的环节，但早期 SOA 使用总线模式，与某种技术栈具有强绑定关系，导致遗留系统很难对接，切换时间太长，成本太高，稳定性的收敛也需要时间

微服务将应用构造为一组松散耦合的服务，在微服务体系架构中，服务是细粒度的，协议是轻量级的

背景和价值

微服务模式通过分布式架构对应用进行水平扩展和冗余部署，从根本上解决了单体应用在拓展性和稳定性上存在的先天架构缺陷。但需要注意的是，微服务模式也面临着分布式系统的典型挑战，例如，如何高效调用远程方法、如何实现可靠的系统容量预估、如何建立负载均衡体系、如何监控和调试分布式服务、如何面向松耦合系统进行集成测试、如何面向大规模复杂关联应用进行部署与运维等

设计约束原则

微服务个体约束

微服务模式通过分布式架构对应用进行水平扩展和冗余部署，从根本上解决了单体应用在拓展性和稳定性上存在的先天架构缺陷。但需要注意的是，微服务模式也面临着分布式系统的典型挑战，例如，如何高效调用远程方法、如何实现可靠的系统容量预估、如何建立负载均衡体系、如何监控和调试分布式服务、如何面向松耦合系统进行集成测试、如何面向大规模复杂关联应用进行部署与运维等

从组织上来说，微服务对应的团队更小，开发和协同效率也更高

微服务还应该具备正交分解特性，在职责划分上专注于特定业务并将之做好，即遵守SOLID原则中的单一职责原则（Single Responsibility Principle，SRP）。微服务修改或发布时，不应该影响到同一系统中另一个微服务的业务交互

微服务与微服务之间的横向关系

在合理划分好微服务之间的边界后，我们主要从微服务的可发现性和可交互性两个方面来处理服务间的横向关系

微服务的可发现性是指，当服务A发布或扩缩容时，依赖服务A的服务B如何在不重新发布的前提下自动感知到服务A的变化

微服务的可交互性是指，服务A需要采用什么样的方式才可以调用服务B

微服务与数据之间的纵向约束

微服务领域提倡数据存储隔离（Data Storage Segregation，DSS）原则，即数据是微服务的私有资产，必须通过当前微服务提供的API来访问数据，否则数据层就会产生耦合，违背高内聚低耦合的原则。同时，出于性能考虑，建议采取读写分离方式，分离高频的读操作和低频的写操作

全局视角下的微服务分布式约束

高效运维整个系统，技术上要准备全自动化的CI/CD流水线，以满足对开发效率的诉求，并在这个基础上支持蓝绿部署、灰度发布、金丝雀发布等不同发布策略，以满足对业务发布稳定性的诉求

面对复杂系统，全链路、实时和多维度的可观测能力成为标配

Serverless

随着云计算的不断发展，越来越多的企业把应用和环境中很多通用的部分变成服务。Serverless的出现，更是带来了跨越式的变革。Serverless把主机管理、操作系统管理、资源分配、扩容甚至应用逻辑的全部组件都外包了出去，把它们看作某种形式的服务

随着云计算的不断发展，越来越多的企业把应用和环境中很多通用的部分变成服务。Serverless的出现，更是带来了跨越式的变革。Serverless把主机管理、操作系统管理、资源分配、扩容甚至应用逻辑的全部组件都外包了出去，把它们看作某种形式的服务

背景和价值

基础设施即服务（Infrastructure as a Service，IaaS）和容器技术是云的基础设施，可以为上层应用的运行提供海量低成本的计算资源

Serverless消除了服务器等底层基础设施的运维复杂度，让开发人员能够更好地专注于业务逻辑的设计与实现。Serverless计算包含如下特征

全托管的计算服务

通用性

自动的弹性伸缩

按量计费

FaaS（Function as a Service，功能即服务）是Serverless中最具代表性的服务形态。它把应用逻辑拆分为多个函数，并通过事件驱动的方式触发执行每个函数，适合事件驱动的数据处理、API服务等场景

典型技术和架构

1、计算资源弹性调度

为了实现精准、即时的实例伸缩和放置，需要把应用负载的特征作为资源调度的依据，使用“白盒”调度策略，由Serverless平台负责管理应用所需的计算资源。平台要能够识别应用负载的特征，在负载快速上升时，及时扩容计算资源，保证应用性能的稳定性；在负载下降时，及时回收计算资源，加快资源在不同账户函数间的流转，提高数据中心的利用率。因此，更实时、更主动、更智能的弹性伸缩能力是函数计算服务获得良好用户体验的关键。计算资源的弹性调度，可以帮助用户实现指标收集、在线决策、离线分析、决策优化的闭环

2、流量控制

多租户环境下，流量控制是保证服务质量的关键。以函数计算为例，当函数调用量超过预期值时，如果问题是函数逻辑错误导致大量的非预期调用，那么系统应当及时进行流量控制，以确保用户的费用可控。函数计算允许用户配置最大函数运行实例数来限制应用负载。当应用负载上升、系统扩容时，如果函数实例数到达配额上限，那么系统将停止扩容并返回流控错误

3、安全性

Serverless 计算平台的定位是通用计算服务，要能够执行任意用户代码，因此安全是不可逾越的底线。系统应当从权限管理、网络安全、数据安全、运行时安全等各个维度全面保障应用的安全性。轻量安全容器等新的虚拟化技术实现了更小的资源隔离粒度、更快的启动速度以及更小的系统开销，使数据中心的资源使用变得更加细粒度和动态化，大幅提升了资源的使用效率

开放应用模型

开放应用模型（Open Application Model，OAM）是描述应用程序及其实现的解耦的规范。开放应用模型旨在为云端应用开发者、运维人员、云基础设施管理人员和云平台构建一套标准化应用架构与管理体系，提升云端应用交付与运维的效率和体验。在实施DevOps时通常需要维护开发（Dev）和部署（Ops）之间的描述，以帮助协调交付工作流，而 OAM 规范的目标就是要促进这一过程。OAM 的既定目标是“让简单的应用程序变得更简单，让复杂的应用程序更易于管理”。

背景和价值

OAM 为应用开发人员提供了一整套用于描述应用的标准规范。对于任何一个支持该模型的云平台，开发和运维人员都可以通过这个标准的应用描述进行协作，轻松实现应用的“一键安装”“一键升级”“模块化运维”等，而无须纠结于繁杂的云服务开通配置和接入工作

OAM 的目标：作为用于描述应用程序的范式，OAM 旨在将应用程序描述与应用程序在基础设施中的部署及管理方式区分开来。其本质是为了解耦 Kubernetes 中现存的各种资源，让每个角色的关注点更加集中和专注。将应用程序定义与集群运营细节区分开来，能够确保开发人员专注于应用程序中的关键元素，而不必为部署场景的运营细节而分神

典型原则

1、开放应用模型的核心技术思想

• 提出云原生应用概念，OAM 既规范了 Kubernetes 中的标准“应用定义”，也帮助封装、组织和管理着 Kubernetes 中的各种“运维能力”。在具体设计上，OAM 的描述模型是基于 Kubernetes API 的资源模型（Kubernetes Resource Model）来构建的，它强调一个应用是多个资源的集合，而非一个简单的工作负载。OAM把这个应用所需的“运维策略”也看作应用的一部分

• 提供更高层级的应用层抽象和关注点分离的定义模型

2、开放应用模型的核心概念

• 应用组件依赖：OAM 定义和规范了组成应用的组件

• 应用运维特征：OAM 定义和规范了应用所需的运维特征的集合

• 应用配置：OAM 定义和规范了应用实例化所需的配置机制，从而能够将上述这些描述转化为具体的应用实例

Service Mesh 技术

Service Mesh 又称服务网格。之所以称为服务网格，是因为每台主机上同时运行了业务逻辑代码和代理，此时，这个代理被形象地称为 Sidecar（业务代码进程相当于主驾驶，共享一个代理相当于边车），服务之间通过 Sidecar 发现和调用目标服务，从而在服务之间形成一种网络状依赖关系，然后通过一种独立部署的称为控制平面（Control Plane）的独立组件来集中配置这种依赖调用关系，以及进行路由流量调拨等操作

背景和价值

在 Service Mesh 出现之前，微服务软件架构所带来的问题都是采用框架思维解决，即将服务连接、安全、控制和可观测性等能力以 SDK（Software Development Kit，软件开发工具包）的形式提供给应用开发人员。随着技术的发展和业务规模的不断增长，框架思维的瓶颈逐渐凸显。其一，单一编程语言无法有效实现所有业务需求，多编程语言场景的出现导致相同功能的SDK需要用不同的编程语言重复开发，且不同编程语言的SDK需要同时维护和迭代，共享困难。其二，SDK 与应用在同一个进程中紧密耦合，这种强绑定关系使它们无法独立快速演进，从而陷入了基础技术与业务发展相互制约的困境

Service Mesh 的出现使得解决问题的思路从之前的框架思维变成了平台思维，将之前 SDK 中非常固定的内容（比如编程 API、协议编解码等）仍然保留在SDK中，其他内容则全部剥离至完全独立的 Proxy（即 Sidecar）进程中。Proxy 的热升级技术将让平台功能的变更对应用完全无感，从而最大程度解决了过去应用与 SDK 因深度耦合而无法独立演进的问题。此外，SDK 中相关功能的剥离实现了应用的轻量化，让应用能够更好地聚焦于业务逻辑本身

典型技术和架构

分布式消息队列

在云原生时代，消息队列作为一种和RPC同样重要的通信机制和架构模式，对解决业务流量的“削峰填谷”、解耦分布式组件、建立事件驱动架构、流式数据处理、系统间集成等都起着关键作用

背景和动机

分布式消息系统是一种利用高效可靠的消息传递机制进行平台无关的数据交互，并基于数据通信进行分布式系统集成服务的系统

消息队列是在消息传输过程中保存消息的容器。消息队列管理器在将消息从源中继到目标时充当中间人的角色，消息队列的主要目的是提供路由并保证消息的可靠传递；如果发送消息时接收者不可用，那么消息队列会保留消息，直到可以成功传递为止。分布式消息系统通过提供消息传递和消息排队模型，可以在分布式环境下扩展进程间的通信，并支持多通信协议、语言、应用程序、硬件和软件平台，实现应用系统之间的可靠异步消息通信，并保障数据在复杂网络中的传输高效、稳定、安全、可靠，以及分布式网络环境下的高可用性和一致性，常用于应用解耦、异步通信、流量削峰、日志收集、缓存更新、数据同步、事务最终一致性等典型场景

典型技术

当前主流的消息队列有 RocketMQ、Kafka、Pulsar、RabbitMQ 等，其中比较有代表性的是 RocketMQ 与 Kafka

RocketMQ，作为一款低延迟、高可靠、可伸缩、易于使用的消息中间件，由阿里巴巴研发并贡献给了 Apache 基金会，并于 2017 年成为顶级开源项目。RocketMQ 是用 Java 语言开发的，它采用“发布——订阅”模式传递消息，具有高效灵活的水平扩展能力和海量消息堆积能力

Kafka 是由 LinkedIn 开发的高吞吐量分布式消息系统，旨在为处理实时数据提供一个统一、高通量、低延迟的平台。Kafka 的最大特性是可以实时处理大数据以满足各种需求场景。Kafka 是用 Scala 语言开发的，其客户端在主流的编程语言里都有对应支持

分布式消息队列一般包含以下模块

• 客户端：提供了消息的接受与订阅 API，同时内置了重试、熔断等高可用功能

• 注册中心：提供了集群管理、元数据管理、路由和服务发现等功能

• 计算节点：在消息队列的服务端 Broker 中，计算部分包含高性能的传输层以及可扩展的 RPC 框架，用于处理来自客户端的不同请求

• 存储引擎：Broker 的核心为存储引擎，某些消息队列可能会将存储引擎与计算节点拆分开来，主要是为消息提供高性能持久化，以队列方式组织消息，用以保证消息必达

云原生数据库技术

随着企业业务向数字化、在线化和智能化演进，面对呈指数级递增的海量存储需求和挑战，以及业务带来的更多热点事件、突发流量的挑战，传统商业数据库已经很难满足和响应快速变化和持续增长所带来的业务诉求，企业需要降本增效，做出更智能的数据决策

背景和价值

云原生数据库是一种通过云平台进行构建、部署并交付给用户的云服务

相较于其他类型的数据库，它最大的不同就是以云原生的形式进行交付，具备传统数据库所不具备的直接访问性和运行时可伸缩性，属于 DBaaS（DataBase as a Service，数据库即服务）平台。云原生数据库的易用性、高扩展性、快速迭代、节约成本等特性，为企业提供了增强的可靠性和可伸缩性，很好地解决了企业用户的核心诉求。从资源池化、弹性扩展、智能运维，到离线、在线一体化，利用云原生数据的这些核心特性，企业可以实现存储、管理和提取数据等多种目的

典型技术

1、云原生关系型数据库

云原生关系型数据库的快速发展与其架构优势密切相关，具体

• 资源池化、大容量、高性价比

• 极致弹性

• 强大的容灾能力及可靠性

• 完全托管

• 智能化 + 自动化管控平台

Polar 核心技术

• 计算存储分离技术

• 计算和存储分离架构为云原生数据库带来了计算和存储上的实时水平扩展能力，实现了计算能力上的极致弹性，Polar 采用了共享存储集群的数据架构，实现多个计算节点可以挂载同一份存储。计算节点可以单独扩展，支持一写多读集群的部署，且提供读扩展能力，支持在分钟级扩展到15个读节点

• 计算内存分离技术

• 数据库实例的CPU和内存资源可以部署在不同的物理机上，并通过 RDMA 高速互联。因此，CPU 和内存资源占比不再固定，而是可以根据业务负载动态变化。所有 CPU 和内存资源都可以在集群资源池的维度进行分配，利用业务的错峰和水位，有效提升资源的利用率，降低整体成本

• 引入了独立的分布式共享内存池。在此架构下，同一个数据库实例的内存可以由位于不同内存节点上的多块内存组成。因此，缓冲区的大小不再受物理机限制

• 在 CPU 和内存分离后，*** 数据库的计算进程不再包含大量内存，而是只有少量高速缓存。这使得计算进程变成了无状态的节点，从而实现了快速的跨物理机弹性

• 高可用及数据的一致性

• *** 通过 PolarFS 分布式文件系统实现了数据多副本及一致性。PolarFS 是国内首款面向 DB 应用设计的、采用了全用户空间 I/O 栈的低延迟高性能分布式存储系统。PolarFS 对 Raft 协议进行了优化，实现了Parallel-Raft算法，大幅提高了数据同步保证一致性的能力，以分布式集群的方式提供了优异的存储容量与存储性能的扩展能力。在一个主集群三个副本的基础上，*** 还包含了一个跨机房的备节点，以提供多机房容灾能力

• 数据及日志的复制技术

• *** 从架构设计开始就纳入了物理复制的思路。在代码实现中，*** 在内核层面实现了大量优化，从而可以更好地适配 PolarFS 和 PolarStore。比如，在 Redo Log 中加入一些元数据，以减少日志解析时的CPU开销。这个简单优化减少了 60% 的日志解析成本。另外，*** 也重用了一些数据结构，以减少内存分配器的开销

• 跨地域高可用技术

• 为满足双零需求，在设计上，数据库架构多采用异地多活的部署模式：将数据库系统跨越一定的物理距离部署在多个地域，要求多个地域内的数据保持一致，并在某个地域发生故障时可以切换到另外一个可用域，且该切换要做到数据不丢失、应用无感知。同城三中心、跨城五副本等架构正逐渐成为业务标配。在这些需求下，云数据库不但要做到地域内的多节点和多副本，更要支持跨区域的多点复制、迁移和服务功能

• Serverless 及多租户技术

• 云原生数据库的一个特点是能够提供按需分配的资源。随着资源的完全池化，整个数据中心（甚至多个数据中心）相当于现在的一台物理机，上面只有一个多租户的云原生数据库，每个用户都可以不受限制地扩展其读写能力：一个用户可以瞬间使用大量CPU或内存资源支撑起业务高峰。因为所有资源的完全池化，CPU、内存、存储使用率均可达到较高水平，所有资源都按量计费，相同的服务器资源可以支撑更多的用户业务，从而提升产品的竞争力

• HTAP

• 兼具 OLTP 和 OLAP 能力的 HTAP，Hybrid Transaction/Analytical Processing，混合事务/分析处理

• HTAP 数据库的核心技术包括列存储技术、行列混存技术、内存数据库技术、并行查询技术、面向混合负载的查询引擎技术和 SIMD 技术等

• *** 的 HTAP 主要通过全内存列存索引的方式实现。用户可以在行存表上定义全内存列存索引，而列存索引可以包括行存表的全部或部分列。系统会将行存表的数据自动实时同步更新到列存索引中

2、云原生多模数据库

NoSQL 数据库的成本掣肘体现

• 资源有效利用率

• 提升 NoSQL 的弹性能力，节点上的 CPU、存储和内存三大主要核心资源需要进行同比例的扩展

• 现实场景，能力短板由最弱的能力资源决定，有时只需扩展最弱的能力资源，而同比例扩展势必造成其他资源的冗余浪费

• 平衡三者的资源有效利用率变得越来越重要

• 数据的冷热存储

• NoSQL 往往存储着大量的数据，而数据也是有温度的：访问频次较高的热数据需要极强的硬件支撑，访问频次较低的冷数据只需要极低成本的存储方案即可

• 多套数据库冗余

• 由于数据类型多样，为了实现业务研发效率的最大化，会部署多套数据库产品

• 每套数据库为了保障稳定性，会预留出多份冗余资源，这在无形中又增加了成本开支。如何降低系统成本，已成为过去所有数据库应用都在考虑的核心问题

云原生 NoSQL 数据库能够将关系数据库的 IaaS 资源原生集成到内部架构之中。除了拥有与关系型数据库类似的计算和存储分离技术，也有云原生多模数据库所涉及的其他相关技术

• 多模计算技术

• 为了适应不断演进的业务需求，云原生NoSQL数据库必须具备多模的能力，成为云原生多模数据库：实现一种数据库服务多种数据模型的能力，并内置数据模型的转化与统一的访问语言

• 主流 NoSQL 多模数据库的实现方式通常是先将数据模型抽象为 KV 数据，再由 KV 数据通过存储引擎存储于硬件介质之上。以 KV 数据抽象为基础实现多模能力，工程复杂度低，但对于时序或者图这类具备显著数据特征的数据模型来说，却不能最大程度地发挥其能力优势

• 生态兼容能力

• 作为云原生的重要标志之一，Stream 既可以向外递送数据的增量修改，也可以从上游下拉数据变更，经过 ETL 写入数据库之中

• 云原生多模数据库还要具备向下兼容的能力，即兼容传统 NoSQL 数据库访问 API

• 数据库 Serverless 化

• Serverless 就是体现这种弹性能力的最好形式。它通过声明式API定义对数据库资源的要求，包括可用性、延迟、一致性、部署位置等，无须再为不确定的业务流量去评估存储和请求等资源，可将精力集中到业务开发中，加速数据应用的创新。实现数据库 Serverless 化的关键是隔离和调度，前者需要解决共享资源下的稳定性问题，以确保租户之间不会相互影响；后者需要解决资源的按需供应和高效利用，以确保集群负载均衡，并根据业务流量快速弹性伸缩

3、数据库安全

• 网络和账号访问控制

• 数据库访问传输加密

• 数据库透明加密和存储加密

• 端到端的全链路加密

• 备份容灾安全

云原生大数据

随着业务的发展，企业数据需求呈现出海量、类型多样化、处理实时化、智能化等特点，对数据分析系统提出了弹性扩展，结构化、半结构化或非结构化海量数据存储计算，一份存储、多种计算及低成本等核心诉求

背景和价值

企业对于海量、多样化的数据提出了实时化、智能化的处理需求。大数据结合云原生特性，为企业提供了远超以往的特性

• 弹性伸缩

• 简单易用

• 性能卓越

典型技术

1、数据仓库

现代化的数据仓库具备以下主要特点

• 统一平台，支持多使用场景

• 在传统数据仓库以 ETL/BI 为主要场景的基础上，增强了数据实时捕获、实时分析的能力，数据洞察由 T+1 转变为支持 T+0 的实时分析能力，并提供更实时的决策支持能力

• 融合高级分析能力。数据仓库借助机器学习等高级分析能力，从历史数据中获得更深入的洞察

• 处理多样化数据。企业新增的数据大多为半结构化和非结构化数据，现代化数据仓库通过数据类型扩展以及联邦外部数据源等方式，提供更友好、统一的半结构化、非结构化数据的处理能力

• 数据在线服务能力。数据仓库需要对大量的数据进行加工处理，之后再向线上业务提供服务，驱动线上业务智能化。加工处理后的数据无须迁移到其他服务，直接对外部提供高性能数据服务即可大大简化系统架构并降低平台总体成本投入

***推出了新一代云原生数据仓库服务，提供了独特的离线实时一体化平台能力。借助这些能力，企业将简化数据管理平台架构，构建符合当下数据管理需求的数据仓库服务，助力企业数字化转型

• 多租户安全体系

• 数据中心安全基础设施

• 数据仓库安全系统

• 数据治理类安全产品




2、数据湖

数据湖首要的功能是集中存储企业的全部数据，包括原始数据和加工数据，然后支持各种数据处理，包括离线ETL、实时分析和机器学习，对数据进行挖掘与分析，洞察数据的价值以支持业务决策。按照数据类型来区分，数据分为结构化数据（数据库表）、半结构化数据（日志）、非结构化数据（文档）甚至二进制数据（图像、音视频等）

数据仓库从实现上来看是一个更大型的数据库，其数据来源于企业内多个业务事务操作数据库的汇总和采集，属于关系数据。这些数据事先已经定义好了模式，经过清理和转换，主要支持 SQL 查询和分析。数据湖与数据仓库相比，具有如下几个重要特征

• 数据湖存储企业的全部数据，包括来自业务系统的关系数据以及来自移动应用程序、IoT 设备和社交媒体的非关系数据；而数据仓库只存储关系数据。数据湖直接存储全部原始数据，数据保真度高

• 数据湖收集数据时无须设计好数据结构，不需要像数据仓库那样事先定义模式，而是在分析时根据业务场景再给出模式，从而使数据收集更加敏捷

• 随着人工智能（Artificial Intelligence，AI）技术的发展和成熟，数据湖除了支持商业智能（Business Intelligence，BI）之外，逐步加大机器学习的比重。数据仓库主要支持SQL查询和分析，通常是周期性地采集数据。而数据湖由于实时计算技术的加持，可以做到数据实时入湖

数据湖架构：湖存储、湖加速、湖计算、湖管理

3、实时计算

想要迅速挖掘这些数据中的价值，就需要在技术上洞察流式处理中实时产生的数据。这就是实时计算技术，也称为流式计算

实时（流式）计算作为一项核心的大数据处理技术，广泛应用于查询连续数据流，并且能够在数据到达之后的很短一段时间内完成预定义的执行逻辑

4、数据治理

数据治理涵盖数据资产管理、数据地图、数据质量和资源优化等功能，提供数据资产概览和趋势分析能力，帮助数据资产管理者进行数据盘点；支持各种数据类型的数据目录构建、全局检索和数据分类等功能，助力数据的流通和使用；提供数据探查分析、数据质量监控、基于数据血缘的数据溯源和影响分析、数据使用审计和数据安全管控、数据脱敏保护等数据的集中管理和管控能力

数据治理在技术上的核心分层包括元数据采集层、存储层、计算层和服务层

• 元数据采集层

• 收集方式

• 钩子引擎

• 元数据采集器

• 元数据抓取和解析难点：考虑不同租户的资源隔离、复杂网络的打通、元数据抓取的性能、对目标数据源的负载保护

• 存储层

• 数据治理面向的是全种类数据，其中会涉及结构化、半结构化、非结构化各类元数据，涵盖大数据体系的各类存储、OLTP（联机事务处理）数据库、存储系统的元数据等。数据治理的难点在于存储系统数据结构设计的通用性

• 计算层

• 数据治理系统面临很多在线触发或周期触发的计算任务。计算任务之间又有依赖关系。这就要求整个系统需要有一个能够支持多租户、高可用性、海量扩展的工作流调度和资源调度系统

• 调度计算的典型任务包括

• 数据质量

• 数据探查

• 资源优化

• 血缘分析

• 服务层

• 数据治理的服务形态包括在线访问的 API、离线加工后的元数据、异步推送实时数据等。对于在线访问的API，云原生的微服务方式是最佳的输出方式。离线加工后的元数据可以供云上的企业结合自己的业务数据做进一步的统计分析。输出方式一般有云数据仓库授权、数据集成和同步数据等。异步推送实时数据的方式支持企业订阅感兴趣的数据，然后通过云原生消息服务将元数据、统计分析结果实时推送给企业

云原生 AI

企业的业务系统若必须连续分析海量数据，并在其上运行机器学习模型或者做自然语言处理和非结构化数据挖掘，就需要大量的存储、数据、计算。将存储、数据和计算集中在云端，借助云平台的海量资源实现业务需求的交付

典型技术

1、云原生 AI 训练平台

PAI-DLC

2、云原生在线推理服务平台

PAI-EAS

3、云原生 AI 服务编辑

PAI Studio

云端开发

随着“基础设施即代码”理念的逐渐深化，云服务提供了越来越多供开发人员使用的服务、产品，越来越多的配置化、通用化的代码被自动生成或直接隐藏，使开发人员可以将更多精力聚焦于业务逻辑的实现上

云端开发通常是指基于云平台完成编码、测试、发布等开发流程的闭环。更进一步地，完整的云端开发平台不仅提供了云端的开发环境，还提供了整套开发工具和配套设施，让开发人员做到在云端也可以完成应用程序的需求、编码、测试和运维的全生命周期管理

1、优势

• 开箱即用

• 弹性的计算资源

• 多人协作

2、困难

• 云上和本地的差异

• 编码和调试体验的差异

• 对大型复杂项目的支持

• 与本地工具的联动

• 陌生的开发生态

云原生安全

云原生安全作为一种新兴的安全理念，不仅解决了云计算普及带来的安全问题，更强调了以原生的思维构建云上安全建设、部署与应用，推动安全与云计算深度融合

背景和价值

安全机制一直是跟随IT基础设施和业务来提供服务的，其保护的对象就是使用云系统和云应用的流程机制。与传统企业网络安全机制显著不同的是，云原生安全的管理责任由云平台和企业共同承担

依托云原生安全思路，企业能够构建全面、完善的云原生安全体系。云原生安全产品适应云主机、容器等云上环境新安全需求：数据库审计、加密服务、敏感数据保护、密钥管理服务等云原生数据安全产品可以保障云上数据安全可靠；DDoS 防护、云防火墙、Web 应用防火墙等云原生网络安全产品可以有效抵御云上网络威胁；云安全中心等云原生安全管理产品可以应对云上安全管理新挑战

典型技术

1、零信任

零信任的核心思想是默认情况下不应该信任网络内部和外部的任何人、设备或系统，而是需要基于认证和授权重构访问控制的信任基础。诸如IP地址、主机、地理位置、所处网络等凭证均不能作为可信的凭证。零信任对访问控制进行理念上的颠覆，引导安全体系架构从“网络中心化”走向“身份中心化”，其本质诉求是以身份为中心进行访问控制

2、DevSecOps

DevSecOps同时从人、流程和技术维度入手，在提高敏捷性的同时保护系统免受攻击

• 人：角色与责任

• DevSecOps 就是要将安全角色纳入 DevOps 中，开发人员需要承担起安全的责任，人人都为安全负责，进而加快安全检查与处置的速度

• DevSecOps 中，安全工程师不再是独立于流程之外的审计师，而是将能力赋能于开发，制定高层安全策略，提供自动化工具以识别架构、代码、配置与运行时的风险，并提供改进与恢复措施

• 流程

• DevSecOps 主张将安全融入 CI/CD 的各个环节，以低侵入的方式覆盖全流程，以适应 DevOps 的快速迭代

• 技术

• DevSecOps的技术核心是建设自动化的安全检测与防御工具链

3、云原生安全可信

• 可信计算技术

• 可信计算（Trusted Computing，TC）是一项由 TCG（Trusted Computing Group，可信计算组织）推动和开发的技术。可信计算的核心目标之一是保证系统和应用的完整性，从而确定系统或软件运行在设计目标期望时的可信状态

• 加密计算技术

• 数据安全的角度看，数据的生命周期可以分为三种不同的状态：存储中、传输中、使用中

• 加密计算技术通过硬件加密运算指令建立可信任的执行环境（Trusted Execution Environment，TEE），以保护处于运算中的数据及代码