作者：阿里云智能高级技术专家 张敏(于期)
简介：目前在安全生产团队从事上云稳定性相关工作。曾在阿里数据库团队，先后主导完成数据库异地多活架构设计，容器化建设及弹性大促，同时也参与过阿里数据库产品和服务体系的商业化输出。
导语
伴随着云原生技术越来越热门，阿里内部关于 Cloud Native、Serverless 等相关文章和讨论非常多。不过，我发现无论是外部开发者还是阿里内部，对云原生定义、理解及实践还处于探索阶段，还没有一个明确通行的标准化定义。
本文尝试着对大家的各种讨论，实践，按通俗易于理解的方式加以总结，包含云原生的定义，特征，技术能力要求及当下集团围绕云原生目标而在做的一些事情，最后基于对云原生的一点理解及市场的机遇，对云原生时代下的数据库系统谈下个人的一些粗浅思考。
我眼中的云原生
云计算的出现与虚拟化技术的发展与成熟密不可分。基于虚拟化技术，云计算可为用户提供具有弹性的计算、存储、网络及其它基础资源服务，随着发展还提供了各类云产品，如：数据库、中间件等，基本上企业运行中所依赖的各类软件在云上都有相对应的产品。
用过云产品的人知道，云上提供的产品就像一块块独立的积木，还需要你自己动手拼接组装，能否搭建出稳定牢固的底座取决于你对产品是否熟悉，还是有一定的技术门槛，除此外运行过程中某块积木坏了，需要依赖人工进行介入，通过平台发起替换或修复。
总之企业可通过云提供的产品快速完成应用搭建，通过上云可把更多精力专注在业务上，但云计算要像水电煤气一样成为社会运转的基础设施，还有很多需要提升的地方，这里引发了大家对下一代云计算，也就是云原生架构的思考与定义。提到云原生，不得不提云原生后面的最大推手CNCF（云原生基金会）。目前，CNCF 已经完成了对云原生的初步定义并发布了 CloudNative Definition v1.0版本：
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers,
service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. These techniques enable loosely coupled systems that are resilient,
manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.
CNCF 列举了一些关键的实现手段，包括容器、服务网格、微服务、不可变基础设施和声明式 API，这些技术能够构架容错性好，易于管理和便于观察的松耦合系统。
而 Serverless 作为云原生领域中的一个细分技术，直译为“无服务器”，核心思想是让用户只关注于业务开发，平台自身提供部署，自动化运维，高可用及资源弹性能力，用户只为实际使用的资源付费。同样 CNCF 也对 Serverless 概念，适用场景等进行了定义，认为完整的 Serverless 服务包含 FAAS 和 BAAS 两种形态：
A serverless computing platform may provide one or both of the following:
1.Functions-as-a-Service (FaaS), which typically provides event-driven computing. Developers run and manage
application code with functions that are triggered by events or HTTP requests. Developers deploy small units of code to the FaaS, which are executed as needed as discrete actions,
scaling without the need to manage servers or any other underlying infrastructure.
2.Backend-as-a-Service (BaaS), which are third-party API-based services that replace core subsets of functionality in an application. Because those APIs are provided as a service
that auto-scales and operates transparently, this appears to the developer to be serverless.
来源：https://github.com/cncf/wg-serverless/tree/master/whitepapers/serverless-overview
抽象总结：FAAS 的典型代表就是 AWS Lambda，OpenFaaS 等开源项目，以及阿里云函数计算产品。而 BaaS 的范畴则更广泛比如未来云原生的数据库或者存储服务。
我认为的云原生关键能力
根据 CNCF 对云原生定义的参考及基于我自己的理解，云原生希望达成的目的是能够让云上的服务能最大程度的发挥出云的价值，从而让云的用户能最大程度的受益于云的能力，除此外还需要关注成本，相比自建成本足够低时才能吸引用户迁移到云上。为达成这个目标，从应用软件架构的设计，开发，构建，部署，交付，容量，监控及运维等整个应用生命周期各环节都需要被重塑，总结下来云原生需具备的一些能力或特性：
关键技术
- 弹性伸缩性：根据业务负载自动伸缩，做到秒级扩缩容能力，灵活动态分配或释放资源，结合弹性计费策略，这是降低用户费用重要手段之一，对服务而言需要的关键技术点，就是服务本身的轻量级容器化和以此为基础的“不可变基础设施”特征。
- 自动容错性：宕机迁移，故障隔离，异常流量自动调度，负载均衡，自动限流降级等。
- 安全隔离性：发挥规模效应，降低使用云的成本，计算，存储，网络等资源采用共享池化技术，以提高资源利用率，因此云产品在设计时必须要考虑多租户的安全隔离性，避免信息泄露或受攻击，除此外还有隔离的稳定性。
- 发布稳定性：为应对频繁变更带来的稳定性风险，需建立无人值守的变更发布系统，具备自动化的灰度、分批等发布策略，同时建立变更前中后的监控基线，具备异常变更的熔断和自动化回滚能力。
- 可观测性：丰富且细粒度的监控指标，秒级监控能力，可持久化的提供查询。
- 易于管理：需要从自助运维到自动运维的转变，具备自动化异常分析诊断能力，无需登录服务器。
- 弹性计费：支持按量（如流量，存储量，调用次数，时长等）、固定的如年/月/日/时...等多种定价策略，可根据业务情况灵活动态切换匹配出一个最优计量模式。
- 极致体验：包括应用分配/创建/资源申请/环境配置/开发测试/发布/监控报警/排障定位等需要做到通畅与简单，一站式体验，避免繁杂的搭积木式操作。
- 松耦合/移植性：松耦合，可移植性也是云产品追求的设计理念，避免单个产品输出需要整站搬迁的事情出现，那么这里就包含环境和系统依赖的解耦，跨平台的移植等，需具备标准化API接口抽象能力。
趋势的把握
- 混合云支持：公共云当前还存在安全等问题的挑战，特别对于传统企业还面临心智上的转变，但为了消除在这波数字化转型进程中而被遗弃的焦虑，所以企业非核心试水公共云，核心业务专有云或私有云部署的混合云模式过渡态，为做到混合云下对业务的透明访问及支持未来往公共云上的平滑迁移，因此产品需保持云上云下一套体系的设计原则。
- 多云选择：客户基于风险，灵活性，话语权，甚至一些行业法规等因素考虑，部分企业可能会选择多家云平台部署，这是一个不能忽视的潜在趋势。为消除客户因技术耦合而被捆绑的顾虑，导致市场被瓜分，同时也为能吸收友商所流失的客户，所以云产品设计之初需具备开放的心态，兼容开源生态标准或一些较成熟的商业软件，保持与客户技术栈保持兼容，具体来说就是拥抱 CNCF，掌握主动权。
- 边缘计算：随着海量终端的出现以及 5G 等网络基础设施的升级，传统“中心-终端”架构会面临高并发，大流量及高时延的挑战，为应对此挑战提出了“中心-边缘-终端”架构，将中心的计算、存储等服务能力下沉到边缘，而终端的业务逻辑上移到边缘，目前虽然关于边缘计算的定义和标准尚未清晰，但从之前接触过的几个外部项目观察，客户已经对云边端协同提出了需求，最先感知的就是能源、制造及风电等行业，因此云产品还需兼容并考虑到云边端一体化的设计。
我眼中的云原生化技术手段
为了支持云原生的这些关键能力，CNCF 也列举了一些关键的实现手段，包括容器、服务网格、微服务、不可变基础设施和声明式 API。下面结合集团和蚂蚁上云过程中目前正在做的一些实践，尝试着做一些简单描述与总结，让其看起来更有些体感，这些事情主要集中在应用层面。
拥抱Kubernetes，集成 Kubernetes
声明式的API与可扩展的编程接口，使其处于容器编排领域的领导者定位，成为容器平台的事实标准。而当前阿里集团也是“All in Kubernetes”，开始全面推进集团业务的 Kubernetes 化以实现“集团上云”。通过采用 Kubernetes 平台，与云原生靠拢，使基础设施更加标准化，复杂度降低，从而加速技术的演进，同时 Kubernetes 也简化了应用混合云，多云，边缘云的部署成本。
轻量级容器化
当前很多团队是把容器当做 VM 在用，这种模式严重阻碍了基础架构的演进，使发布/升级/扩缩容弹性/容错等变得极为困难（富容器里面太多依赖的东西，有太多不确定性因素，不敢动的），同时与环境的强耦合使得移植性较差，因此目前也是结合 Kubernetes 的能力推动轻量级容器化改造（如应用日志去状态化，去 IP 依赖，去 ssh 登录，应用镜像瘦身-非业务进程剥离到 sidecar，基础运维能力下沉等），通过这波改造会带动整个上下游系统实现面向终态化和不可变基础设施的升级（本质上就是应用容器确定性，一致性，轻量性）。
安全容器
由于应用端口号占用的一些限制，不得不独占物理机，虚拟化技术的出现使得机器资源利用率得到一定提升，但ECS不具备内存超卖能力，而且规格不灵活，加上 VM 技术自身的一些开销，因此整体来说资源利用率还不是很高，直到容器的出现，内存可超卖了，且规格变得非常灵活，使得混部密度进一步提高，资源利用率大幅度提升（其实还有离在线混部，内核的隔离，精细化的调度等综合结果，不过容器化技术是前提）。
普通的容器技术虽然轻量，但在安全隔离上不能满足多租户的诉求，而 ECS 虽然提供安全的隔离能力，但启动速度慢，不满足弹性伸缩的需求。因此安全容器技术就运用而生，结合了虚拟化的强隔离和容器的轻量级，比如 KataContainers，Google 开源的 gVisor 和后来 AWS 开源的 FireCracker 都是其中的代表。
集团和蚂蚁共建的 NanoVisor（做了很多安全加固和性能优化），阿里在 KataContainers 基础上开发的“袋鼠安全容器”，也都是这方向上的探索。
ServiceMesh
把一大堆和业务逻辑无关的实现如服务发现，路由，负载均衡，限流降级等从业务应用中剥离出来，下沉到基础设施的中间件(类似 TDDL 到 DRDS 的模式)，这种剥离收益使得应用与服务提供者解耦，减少系统变更带来的风险，同时更加利于全局服务治理/监控等，除此外还获得了另外一个收益就是应用瘦身，间接加快了启动速度，还有就是对多语言的支持。
日志无盘化
日志直接落入SLS，是解决应用去状态化的一个关键手段，成为不可变基础设施的重要前提，其次集中式的日志存储与查询服务，避免因 ssh 登录服务器而带来的稳定性隐患。目前蚂蚁团队正在推进打造日志无盘化项目，打造的分布式文件系统，直接 mount 目录写入 NAS，SLS 直接去 NAS 读（SLS 与 NAS 底层存储系统都是盘古，这里应该是有优化的，具体细节不太清楚，如有错误还请指正），显然相比常规写本地磁盘然后读一遍采集到 SLS 的方式，蚂蚁的方案更优。
应用启动加速
应用启动的提速对弹性非常关键。一些关键的瘦身手段如之前介绍的去富容器、ServiceMesh 技术，这里没提到的应用自身更细粒度微服务的改造等带来启动的优化外，中间件团队提供的 CSE 方案，在不改变镜像情况下，利用应用热复制技术将启动速度加速到了毫秒级，类似的加速技术相信后面会更多。
WebIDE
提供了云端构建、运行、调试的的环境，使得研发同学可以实现函数式编程，部署，测试和发布一体化体验，提升了研发效率。
计量计费
从面向基础设施资源转向云产品的计费模式，同时要打造面向大型企业客户的资源管理解决方案，要处理多种复杂的业务形态如混部等，整个计量系统非常复杂，这块细节不是太了解，就不展开了。
我对数据库云原生化的思考
应用层的形态差别太大，缺少标准与自动化的手段，且随着系统复杂性的上升，业务同学很大的时间在解决各种系统的对接与学习上，换了一个平台或系统又得重新来过，实际用到业务代码的开发时间被挤压得非常少，而不得不利用晚上加班填补，从上面解决问题中看到云原生也集中在应用层解决开发效率的问题。
对于数据库系统来说，相对而言基本通过 SQL 接口已经把后端实现屏蔽掉了，业务不用关注数据库的机器，高可用切换等，负担可能会小很多，那数据库的云原生到底是啥，解决什么问题呢？从 AWS 推出的各种云数据库产品来看更多的在于强调弹性与按需付费的结合上，如果单从这些方面观察感觉数据库云原生略显单薄，而且貌似已经具备 Serverless 的某些特征。
因此想从另外一些视角来阐述下当下我对数据库系统云原生的理解，当然也是围绕前面章节中所总结的云原生关键能力展开的，同时结合之前在数据库团队参与过一小段时间商业化过程的思考，谈谈个人的一些粗浅看法，但类似利用机器学习在数据库智能化及索引、查询优化上的应用等不在本文讨论范围中，主要还是聚焦在一些具象问题的讨论。
开源 VS 闭源
云原生核心的推动力就是防止被厂商锁定，而 CNCF 则是这个领域维持中立与平衡的事实标准。CNCF 中的核心项目和云原生的理念，已经影响了很多用户的心智，所以我建议数据库也要建立云原生生态和认可的标准，这样会为前线架构师节省很多教育用户的成本。当然开源自身不是目的，最主要的是把云上多年积累的技术经验借助开源赋能全社会，打造以阿里云数据库产品为标准的生态体系。
HTAP 能力的支持
简单的增删改查已不能满足在线业务的需求，兼具一定OLAP分析能力是接下来HTAP数据库发展的新方向。技术层面上我不认为单一的行列混合存储引擎是未来（Google Spanner 这么用的，简单说就是 page 逻辑切分为多个 mini page，record 按列切分到不同 mini page 中，可看论文），同一个集群混合行存和列存实例，Paxos/Raft 协议实现一致性复制，列存引擎提供 AP 查询（计算引擎可以再基于 spark 等），这才是我认为的 HTAP 未来架构。
当然这只是性能优化层面的解决方案，更多的还需做体验上的优化，如何做到用户 SQL 与底层能力的自动匹配很关键，无需用户标注，那么优化器能力的升级一定未来一个重要课题，根据 Query 特点自动根据 SQL 选择行存还是列存，或部分行存部分列存。
Scale out的分布式VS Scale up的单机数据库，融合是趋势
以 AWS Aurora、阿里云 PolarDB 及腾讯 CynosDB 为代表的单机数据库，通过存储与计算的分离，使数据库去状态化，可根据负载自适应的对计算或存储资源在线弹性伸缩，这是目前大部分市面上宣称的 Cloud Native Database，几个关键词：安全，易管理，高性能，高可靠，弹性扩展，自运维，兼容 PG/MySQL/Oracle。
而以 NewSQL 为代表的新型关系型分布式数据库，因具备传统单机关系型数据库 ACID 特性，提供 SQL 访问协议，同时基于一体化设计，零外部的组件依赖，实现自动选主与切换，自动水平扩展与负载均衡，使产品整体上具备自封闭能力，可大大降低运维复杂度，稳定性上更加可靠，因此被定义为下一代关系型数据库系统。此类产品有 Google Spanner，阿里云的 POLARDB-X，蚂蚁的 OceanBase，百度的 CRDB，开源产品 TiDB 和 CockroachDB。
而细心的读者发现，或用户能get到的信息就是两类产品都类似啊（懂行的人肯定知道差别，只是外在表现类似），弹性扩展、自运维…，我到底怎么选择？既然云服务的最大特点是用户只关注业务逻辑（业务 SQL 拼接，表结构设计），那么显然答案就非常简单了，复杂的选择全部留给云厂商，再者单机系统自身就是分布式系统的一个特殊形式而已，那么我觉得两者的融合是趋势，兼具单机系统的易管理、存储计算分离的 Scale out 和去状态化，水平扩展的分布式能力，再加上自运维能力，应该是后续数据库的一个重要演进方向。
默认或大部分情况下是单机形态（市场上大部分单机数据库足够了），根据业务负载自动支持弹性在线 Scale out 或 Scale up 能力，不过这里面临的一个挑战就是单机向分布式过渡的兼容能力，包含但不局限于：事物、隔离、并发控制、SQL 支持、性能，甚至包括 BUG 和 feature 的一致性等，因为用户的 SQL 和表结构定义不变，一旦遇到兼容性问题，反馈给用户的就是报错。问题之所以是问题，肯定是有一定的技术门槛，不过从侧面上也反应了其核心竞争力，这是可以与友商或竞品拉开代差的产品，所以我相信融合是未来的方向。
成本优化
存储计算分离是去状态化的标准方案，毫无例外数据库也借助了存储计算分离具备了与应用同等的弹性能力，通过数据库借助大量的软硬件一体化设计与优化等（如用户态文件系统，用户态存储网络 IO 技术 SPDK 与 DPDK，RDMA 网络技术，新硬件 NVMe SSD、3D XPOINT），使数据库在存储计算分离下达到甚至超越了本地磁盘的性能（在阿里云智能事业群合并前，集团数据库团队也借助盘古完美支持了大促，可见性能已然无需质疑），随着技术的发展，这些硬件成本会逐步降低，加上阿里云的规模效应，管理成本的收益等，所以数据库存储计算分离一定是当下综合评估后的最优方案，之前已列举了一些有代表性的产品 Aurora/PolarDB 等。
同时根据上个观点的判断，下一代关系型数据库也具备弹性计算分离形态，那么数据库的 3 副本与存储的 3 副本共 9 份副本，显然不符合云对成本优化的要求，目前存储通过 EC（Erasure Coding）技术可做到单副本 1.375 存储成本，再加上压缩技术等方案可进一步降低成本，但实际上这里还有很多的考量，就不再展开了。
数据库多副本+存储计算分离也是一个新方向，成本优化的问题虽然有一些解决方案，但是我认为还处于初步的实践探索阶段，相信未来一定会更加完善。
随着 lsm-tree 的引擎引入，为分层存储，冷热分离的实现提供了技术可行性，不过冷热数据的评估，业务查询的不确定性等可能会带来一定挑战，一旦遇到性能波动可能就会遭受质疑，不过相信技术的力量。数据库团队打造的 X-Engine 存储引擎就是为了解决这个问题而因运而生的。
建立生态
多个场合听到或看到阿里云对客户打法的一些定义：头部客户靠直销和生态，腰部客户靠生态渠道，尾部主要靠市场口碑体验驱动，前不久阿里云北京峰会上颠总提到的体术->产品->商业->生态的论述，可见生态对于云的重要性，得生态者得天下。云面临的困难在逐步转移，从开始的不知道做什么，做出来怎么买，目前面临着怎么做服务的问题了，对数据库这种具有一定门槛的领域来说更多体现在交付和售后支持的生态建设上，除了前面提到的建标准，产品的收敛融合等可以帮助到生态的建设外，保持被集成的设计理念也很重要，具体来说就是 API 接口的能力，除此外可能还需探索更多的办法，任重而道远。
打造数据库自治化生态
数据库产品面临的一个很大问题就是种类太丰富了，以至于客户迷茫，架构师也迷茫，能清楚定义出各产品的核心功能及特点真不是一件容易的事情，同时客户在架构师的帮助下选择了n多数据库产品分别满足各业务场景需求，对后期整体的维护成本简直就是一个灾难。
回到云原生的本质，用户只关注 SQL 和定义表结构，剩下的就交给云厂商，显然与理想状态差距太大。而云厂商需要努力通过技术手段去解决这个问题，数据库产品收敛融合我认为是一种比较好的方案，收敛为三个产品是一种理想状态（OTLP 领域，OLAP 领域，NoSQL 领域），多模数据库/HTAP 等已经体现了这么一种趋势的探索和实践，依靠产品的收敛解决了很多痛点问题，而且也是相对能落地的方案。
但作为云原生数据库肯定不甘于此，还是需要畅想下未来，能根据业务特点及负载匹配到最适合的数据库产品，自动完成数据的迁移且对业务透明（体现在迁移无感知，用户使用无感知），用户与数据库交互的唯一接口就是管控平台和查询语言 SQL，只要 这些接口 不变，在一个静态的状态下返回的结果一定是确定性的，不同的是给到用户更快的体感。那么这才是我认为的未来的云原生数据库，一个自治化的数据库生态体系。
还有一些其他方向，就不详细说明了，如：运维能力以 Operator 形式下沉至 Kubernetes。当然之前的模式也需要兼容的，毕竟不是外部所有客户基础设施都是 K8s，智能化管控运维、加密数据库，混合云/多云/边缘云等产品化支持等。
总结
以上就是我这段时间对云原生，数据库在云原生时代下的一些个人思考，内容略显啰嗦，能看到最后的肯定是真爱，同时文中对云原生的理解难免存在不当之处，欢迎大家指正与交流。关于云原生的定义和特征也在不断变化和调整中，同时随着云计算普及，相信最终会逐渐明朗。
