再谈云原生时代的系统软件，创造一个开放、无锁定、低成本的技术体系

公有云和K8S将成为未来系统软件的标准底座，系统软件将面临非常不同的技术环境，也要考虑公有云垄断资源之后的市场环境。系统软件应采取多云、开源的市场策略，采取跨区域复制、replication-free、share-storage等设计，充分借助云环境优势。

系统软件可望出现一波云原生的创新高潮，并带来一个更加开放、无锁定、成本更低的技术体系。未来云原生设计的系统软件可望将存储成本降低75%至90%。

前文云原生时代的系统软件介绍了云计算的发展趋势及其为系统软件发展带来的技术环境上的变化，汇总了技术趋势，但对技术落地思路、经济模式等方面未做全面覆盖，本文希望能够从更多的视角再谈一谈这个话题。

云原生下的技术环境

1

虽然云原生没有标准的定义（甚至云都没有），但云做了这么多年，技术架构和市场格局大致已定，所以我们只需要看当前实际情况来分析云原生的技术环境具备哪些主要特征，并分析如何应对。

首先我认为未来主流的云原生技术架构是趋同的，就是当前主要几家公有云厂商的架构，原因在于：

1. 公有云很快会成为主流。欧美早就是主流，就连中国这样一个很多企业不敢上公有云的地方，据最近信通院的统计，公有云也很快会赶超私有云。另外公有云的增长率大幅超过私有云。

2. 未来可能一些超大的企业仍会部署私有云，但技术特征会跟公有云的架构一致，因为这个世界很难再造出一套不一样的大规模云架构。这些企业很可能是AWS Outposts这类公有云架构的私有化部署，抑或类似的开源云系统的部署。

因此，这个世界不久将变成一个公有云架构占据明显主流的世界。这套架构体系与非云环境有很大的不同。对系统软件（除了操作系统本身）来说，最相关的技术环境是资源基础设施、操作系统和应用架构。

首先看资源基础设施，云带来以下主要变化：

1. 高可靠、低成本的虚拟块存储（云盘）。大多数云产商（除了AWS）都提供了采用三副本复制保证数据可靠性的云盘，还比本地存储更便宜。本地存储在云环境下已经成为一种边缘产品，大多数云产商的本地存储规格完全由计算实例规格决定，导致本地存储的使用非常受限。阿里云虽然提供灵活可配的本地存储，但价格比同等大小的云盘更贵。系统软件如果采用本地存储，一般还需要再做三副本，因此采用云盘的成本只有本地存储的1 / 3。

2. 更高可靠、更低成本的对象存储。对象存储是云时代的创新产品。对象存储可靠性极高，空间无限且无需扩缩容，支持多终端高并发访问，成本极低。主要的几家公有云大厂对象存储的价格是虚拟块存储的1 / 3至1 / 2。这是因为虚拟块存储产品都是采用三副本技术的（除了AWS EBS），而对象存储都采用了纠删码（除了AWS可能不是）。考虑到块存储的空间利用率因素，实际的对象存储成本大约只用块存储的1 / 4至1 / 3。

3. 按需分配、按需计费的弹性计算资源。当前的主流是虚拟机，但裸金属服务也有可能有不小的市场，这是因为后续计算资源调度的主体是K8S和容器（还有一些留给VMWare），虚拟机不再有价值且还会带来开销。

操作系统是系统软件的运行环境，云环境的操作系统的核心变化是K8S及其编排能力：

1. K8S将统治资源调度。OpenStack和K8S已经是我中有你你中有我般难舍难分；大数据生态的Spark和Flink早已出轨K8S，只留给YARN一个人老珠黄的MapReduce；AI生态的领头羊TensorFlow本来就是K8S的亲弟弟。这个世界必将是K8S的。

2. K8S也将统治编排。K8S原生的编排能力很够很好的管理无状态的分布式架构，CoreOS贡献的Operator进一步允许自定义控制器和配置（CRD），简化了系统软件的部署、升级更新、扩缩容、监控等运维或控制逻辑的实现。自从Operator开源以来，短短不到一年，[OperatorHub](https://operatorhub.io)上已经有了60个各类系统软件的Operator实现，其中Spark、MongoDB、Redis、CockroachDB、Couchbase等知名软件赫赫在列。

应用架构方面的核心变化是微服务和服务网格：

1. 微服务架构。短短五年，中大型互联网企业已经全面应用了微服务技术，从去年开始，非互联网行业也明显开始向微服务转型，可以预计五年后微服务将成为各行业应用架构技术的主流。微服务带来两大变化，一是应用的拆分并进而导致系统软件也跟着做拆分，二是DevOps技术的成熟。

2. 服务网格。一直以来服务和系统软件间普遍采用内嵌SDK、客户端与服务端直连（不经过代理或网关）的方式紧耦合，导致系统软件的升级困难。服务网格作为应用与系统软件之间的代理，可望有效支持系统软件的灰度发布、蓝绿发布等低风险发布模式，使得系统软件也可以实现敏捷迭代。

云原生下的市场环境

2

公有云巨头将来会垄断硬件资源、部分的操作系统能力和客户资源，向上发展进入到系统软件领域有很多有利条件。

但市场环境对独立的系统软件产商也有有利因素：

1. 客户对产商锁定的担心及对多云的诉求。根据RightScale的统计，企业采用多云的比例高达81%，Forrester的调研更高，86%。

2. K8S为多云管理奠定了基础。K8S为应用和系统软件都提供了标准的、各大云产商都支持的管理界面。Google Anthos和Rancher演示的路径虽然还属早期，但很可能是可行的，相比之前限于IaaS层的CMP有很大的进步。

3. K8S的Operator和Helm为系统软件提供了一个无所不在且标准的交付渠道，相当于系统软件有了App Store。

4. 系统软件只需要在少量的公有云平台上部署，管理成本降低很多。

针对这样的市场环境，独立的系统软件可以采取以下策略：

1. 天生支持多云。系统软件应该支持在多个云环境中调整分配负载，即便这样的机制只是作为保底措施，很少用。

2. 开源。即便不提Redhat，Redis、MongoDB、ElasticSearch、Confluent等大数据明星企业的成功证明了开源模式是可行的，当然在版权上要杜绝云产商揩油。

如果有开源和多云的支持，在同等产品力下，独立的系统软件产商往往比云产商巨头们更具竞争力。

未来系统软件的单位成本肯定是要下降的，但云普及后带来的市场规模增加和统一化总体上将为系统软件带来一个更大的市场。

云原生系统软件的设计思路

3

1、面向多云的设计

支持多云是独立系统软件产商与云巨头竞争的核心市场策略。多云不是IaaS层能解决的，K8S和系统软件能解决按业务分离的多云场景，但更复杂的场景，要用领先互联网企业都英雄所见略同的单元化多活架构解决。单元化是终极解决方案，这是因为单元化符合高内聚、低耦合的原则，也符合微服务的精神，且能够最好的避免被云巨头锁定，这是因为流量能自由切换，云间也能自由切换。对系统软件来说，这意味着需要良好的配合数据复制 / 订阅系统实现跨地域异地同步、支持数据分片、支持流量路由等设计。但主流不会是Spanner那样延时和成本都很高的设计，我不认为多云可以做成高度透明的。

2、利用高可靠云盘的replication-free架构

除了AWS，其他主流云产商的云盘产品都已经采用三副本复制保证了数据可靠性，在系统软件层面不应该再做数据复制，这可以降低2 / 3的存储成本。我称这类自身不再做数据复制的架构设计模式成为replication-free架构。当前大量的系统软件都自己做数据复制，在云原生时代可能都要大改。

3、对象存储及share-storage架构

系统软件最常见的两种分布式架构是share-nothing和share-disk，share-nothing架构越来越常见。但Google GFS及基于GFS的BigTable、Spanner等系统软件的设计，带来了一种新的架构模式：share-storage，其特征是系统软件全权将存储管理职能交给底层的存储系统。而后S3开创了云上的对象存储时代，提供了一种云环境下非常可靠、低成本、空间无限的新存储模式。Snowflake、EMR等再次验证了share-storage架构在分析场景下的优势。虽然当前share-storage存储模式还很小众，但随着公有云的进一步普及，这一模式将呈现很大的吸引力。

除了大幅降低存储成本（前文已经分析对象存储成本大约只用块存储的1 / 4至1 / 3），share-storage架构可以大幅简化系统软件的设计，数据复制、数据分布、存储的扩缩容、数据恢复、数据迁移和重分布、编码（如纠删码）等一系列复杂的存储管理功能，大部分都可以使用对象存储自然实现。根据BigTable和Snowflake的经验，只需要设计一定的本地数据缓存、读写路径唯一或黏连机制就可以了。简单的说，采用share-storage架构时，系统软件不再需要做存储的管理，而只需要做缓存的管理。

4、高弹力和无服务架构

云提供的弹性资源能力使得系统软件可以实现高弹力的设计。走到极致还会产生无服务的系统软件，也就是说系统软件不再需要预设资源规格（如AWS Aurora Serverless）甚至完全没有资源规则（如BigTable），计费模式也变成按实际的处理量或预设的处理能力计费。

5、云原生的简化多租户架构

弹性计算也将带来系统软件多租户实现模式的转变，简单的说系统软件很可能将不在自身的软件层实现多租户特性，而更多的依赖底层云平台的能力管理各租户独立的集群，同时保持弹性和低成本。这一转变的驱动因素还有微服务和编排技术。微服务架构的兴起推动系统软件往隔离的方向发展（在标准的微服务架构中，各个服务的数据库都是独立的），编排技术使得管理大量系统软件集群的复杂性降低。

因此在微服务的驱动下，在弹性计算和编排技术的支撑下，系统软件自身需要实现权限、隔离、限流、优先级等多租户特性的需求大幅下降。这也降低了系统软件的实现难度。

云原生数据库系统设计示例

4

作为云原生系统软件的示例，我们可以考虑采用以下的思路改造TiKV，将存储成本降低75%至90%。

TiKV是一个优秀的KV存储引擎，支持水平伸缩、分布式事务和高可靠，是当前CNCF唯一孵化中的KV数据库项目，项目的开发也非常活跃。但TiKV假设使用不可靠的本地存储，因此自己做了三副本复制，存储成本高达1.4～1.8 / GB.月（原始成本0.9 / GB.月，假设利用率50～70%；成本数据都采用阿里云，其他平台的成本也类似）。可以考虑改造为如下的云原生KV存储引擎：

• TiKV普通云原生版，面向高负载、低延迟场景：将RocksDB数据存储在三副本云盘上，不做Raft复制。成本约0.35～0.5 / GB.月（原始存储成本0.24，假设利用率50～70%）。数据可靠性稍差（9个9）但也满足大多数场合。需要注意的是AWS没有高可靠的云盘，导致无法实现云原生版。

• TiKV低成本云原生版，面向低负载、高延迟场景：使用RocksDB Cloud代替RocksDB，将数据存储在对象存储上，使用云盘写WAL，使用本地盘做缓存。不做Raft三副本复制。成本预估0.15 / GB.月（对象存储本身0.12），约是普通版的30～40%。数据非常可靠（11个9）。

以上两种设计的共同点是不再做Raft复制从而大幅降低成本。原始的TiKV如果使用本地盘再做三副本，改造后的低成本云原生版、普通云原生版的成本分别相当于原始版的10%和25%。

可据此进一步实现云原生的Redis、MySQL和Cassandra。这三个系统都可以用RocksDB，也就都可以改造为使用上述的低成本的云原生TiKV。事实上已经有[Tidis](https://github.com/yongman/tidis)和[Titan](https://github.com/distributedio/titan)这样的项目基于TiKV实现了Redis兼容系统。

小结

5

公有云和K8S将成为未来系统软件的标准底座。系统软件面临的是高可靠低成本云盘、更低成本的对象存储、K8S标准化的资源调度和编排、微服务和服务网格等非常不同的技术环境，也要考虑公有云垄断资源之后的市场环境。系统软件应采取多云、开源的市场策略，采取跨区域复制、replication-free、share-storage、高弹力及无服务、简化的多租户架构等设计，充分借助云环境优势。

系统软件可望出现一波云原生的创新高潮，并带来一个更加开放、无锁定、成本更低的技术体系。