查看原文
其他

云原生时代的系统软件

风轻扬 冷技术热思考 2024-04-14

系统软件发展将走入云原生时代

1


据最近信通院的统计,就连中国这样一个很多企业不敢上公有云的地方,公有云的体量都很快就会赶上私有云,当然欧美公有云早就更占主流了。增长率方面,公有云也早就大幅超过私有云。此外,私有云市场还很可能被AWS Outpost这类公有云架构私有化的方案侵蚀。公有云上的裸金属服务虽有IBM、腾讯、华为等提供,但不是主流,成本高,且网络能力也受限,将来也必然是小众市场。


因此,这个世界将很快变成一个公有云占据明显主流的世界,而且是以提供虚拟的资源基础设施为架构特征的公有云。对于基础软件和中间件等系统软件来说,公有云提供了一个技术和成本特性非常不同的环境。总的来说提供了很多便利,如容量无限的弹性计算和存储资源,如对象存储开创了一种低成本、非常可靠的存储品类,另一方面也带来一定的约束。


另一方面,应用与系统软件间的松耦合一直是架构领域的追求。20年前的J2EE希望将应用放到应用服务器沙盒中,10多年前以GAE为代表的App Engine技术做了再次努力。虽然上述努力都不太成功,但服务网格技术很可望将创造一个应用与系统软件间更松耦合且全面的边界,使得系统软件的演化更加自由。


第三,Kubernetes成为编排的事实标准,Operator进一步增强了K8S的编排能力。Redis、TiDB、Couchbase等众多的Operator如雨后春笋般涌现,用较少的投入就实现了系统软件的部署和自维护能力,这大幅简化了系统软件管控逻辑的实现,也降低了其推广成本。

以上三方面都为系统软件提供了一个新的、更便利、支撑能力更强的发展条件。系统软件要充分抓住这些趋势变化实现跨越式发展,也必须这么做,否则就可能因为不适配新的环境从而被淘汰。因为这些因素都与云相关,因此借用当前大家比较熟悉的云原生概念,可以说,系统软件将走入云原生时代,但是本文所说的云原生概念特别强调基于公有云的基础架构。


云原生带来的核心变化

2

与系统软件(除了操作系统本身)最相关的技术环境是资源基础设施、操作系统和应用架构。首先看资源基础设施。云原生所带来的最大变化是存储环境的变化。


1、高可靠虚拟块存储-云盘

高可靠、低成本的虚拟块存储和与之相对的不可靠、高成本的本地存储形成云时代块存储产品的强烈对比。大多数云产商的本地存储规格完全由计算实例规格决定,导致本地存储的使用非常受限。阿里云虽然提供灵活可配的本地存储,但价格比同等大小的云盘更贵。


除了AWS,其他主流云产商的云盘产品都已经采用三副本复制保证了数据可靠性,这使得在系统软件层面再进行数据复制没有必要。当前大量的系统软件都自己做数据复制,在云原生时代可能都要大改。我们可以称这类自身不再做数据复制的架构设计模式成为replication-free架构。


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

大家知道,系统软件最常见的两种分布式架构是share-nothing和share-disk。一般来说share-nothing架构是实现分布式可水平伸缩系统软件的主流架构,share-disk架构是实现垂直伸缩的高可用架构。


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


基于对象存储的share-storage架构可以大幅简化系统软件的设计,在share-nothing架构下需要的数据复制、数据分布、存储的扩缩容、数据恢复、数据迁移和重分布、编码(如纠删码)等一系列复杂的存储管理功能,大部分都可以使用对象存储自然实现。上述存储管理功能非常难以高质量实现,如即便是当前应用最普遍的Ceph存储在集群扩容、数据恢复、数据重分布等情况下仍将导致性能的大幅波动。而在采用share-storage架构时,根据BigTable和Snowflake的经验,只需要设计一定的本地数据缓存、读写路径唯一或黏连机制就可以了。简单的说,采用share-storage架构时,系统软件不再需要做存储的管理,而只需要做缓存的管理。相比采用高可靠云盘自身不做复制的设计,基于对象存储的share-storage架构的简化力度更大。云盘只能解决数据复制的问题,但不能解决数据分布、扩缩容、数据迁移和重分布的问题。


使用对象存储的第二大优势在于成本优势。主要的几家公有云大厂对象存储原始的每GB.月价格是虚拟块存储的1 / 3至1 / 2。这是因为虚拟块存储产品都是采用三副本技术的(除了AWS EBS),而对象存储都采用了纠删码(除了AWS可能不是)。考虑到块存储按分配量计价而非使用量计价,实际的对象存储成本大约只用块存储的1 / 4至1 / 3。特别的,AWS的虚拟块存储产品EBS的可靠性远远达不到系统软件的要求(年故障率0.1~0.2%),因此如果存储使用EBS,还需要再做多副本,这导致基于EBS和S3的成本差异更是达到5倍以上。作为世界最大的公有云厂商,AWS的这一存储产品特征势也将进一步导向share-storage的设计。


share-storage架构目前面临的挑战是在在线处理领域能否高效实现。AWS的EMR显示HBase可以跑在S3上,只是需要借助基于EBS的HDFS写WAL和EC2的本地存储做缓存。RocksDB Cloud项目显示了将RocksDB架设在S3之上的可能性,而MySQL、Cassandra又都可以架设在RocksDB之上。这些案例都显示了基于对象存储实现高效的数据处理系统软件的可能性。高速网络和DPDK等高性能低延迟网络通信技术的发展,将降低share-storage架构datapath变长带来的性能影响。


当前还无法为对象存储给系统软件带来的影响做准确的预测,但鉴于其简化架构和降低成本的巨大优势,share-storage架构的潜力是巨大的。


3、弹性计算、弹力设计和多租户

再说计算。云带来了按需分配、按需计费的弹性计算资源,这驱使系统软件实现高弹力的设计。走到极致还会产生无服务的系统软件,也就是说系统软件不再需要预设资源规格(如AWS Aurora Serverless)甚至完全没有资源规则(如BigTable),计费模式也变成按实际的处理量或预设的处理能力计费。


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


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


4、编排技术和应用市场

K8S大杀四方,谁也不知道它什么时候才会停。OpenStack和K8S已经是我中有你你中有我般难舍难分;大数据生态的Spark和Flink早已出轨K8S,只留给YARN一个人老珠黄的MapReduce;AI生态的TensorFlow本来就是K8S的亲弟弟。这个世界必将是K8S的。


K8S的威力在于编排。K8S原生的编排能力已经比较强大了,编排起无状态的分布式架构再复杂也毫无压力。CoreOS贡献的Operator进一步允许自定义控制器和配置(CRD)。算法(控制器)+ 数据结构(CRD)= 程序,这个二合一的组合大大简化了系统软件的部署、升级更新、扩缩容、监控等运维或控制逻辑的实现。自从Operator开源以来,短短不到一年,operatorhub.io上已经有了60个各类系统软件的Operator实现,其中Spark、MongoDB、Redis、CockroachDB、Couchbase等知名软件赫赫在列。


未来,K8S及其编排机制将为系统软件带来一个无所不在、开源免费且内含架构支撑能力的超级应用市场。与当前各云产商提供的封闭分散且缺乏架构支撑能力(云产商的应用市场最关心的是收费)的应用市场相比,K8S应用市场的价值显然更大。


5、微服务和服务网格(Service Mesh)

应用架构正在快速走向微服务。短短五年,中大型互联网企业已经全面应用了微服务技术,从去年开始,非互联网行业也明显开始向微服务转型,可以预计五年后微服务将成为各行业应用架构技术的主流。


微服务带来两大变化。首先就是服务,就是拆拆拆,拆成一个一个很小的应用(有多小?平均每人一个应用很常见)。系统软件嫁鸡随鸡也跟着拆拆拆,这就导致上文说的多租户实现模式的转变。第二个是DevOps,开发人员权利觉醒,要求环境控制权,自然,也就产生了成熟的DevOps支撑技术。


有了系统软件的拆分和DevOps支撑技术,系统软件的敏捷迭代已经不远了,而服务网格为此扫除了最后的障碍,这是因为服务网格实现了应用和系统软件(特别是中间件)间的松耦合。

微服务架构中,服务和服务之间采用基于HTTP的REST API、RPC或消息队列异步通信机制,实现了各服务的独立维护、优雅升级。但服务和系统软件间却仍然普遍采用内嵌SDK、客户端与服务端直连(不经过代理或网关)的方式紧耦合,导致系统软件的升级困难。


服务网格作为应用与系统软件之间的代理,可望有效支持系统软件的灰度发布、蓝绿发布等低风险发布模式,使得系统软件也可以实现敏捷迭代。


云原生时代系统软件的发展趋势

3

根据前文关于云原生带来的核心变化的分析,可以小结云原生时代系统软件的发展趋势如下:

  • 高可靠、低成本的云盘将驱使系统软件采取replication-free架构,将数据复制交给云的存储层实现。

  • 可靠且更低成本的对象存储带来了新的share-storage架构模式,降低了系统软件特别是数据处理类系统软件的实现难度。

  • 弹性计算使得系统软件易于实现高弹力甚至是无服务的设计。

  • 微服务、弹性计算和编排技术的协同作用降低了系统软件的多租户需求,降低了实现难度。

  • 服务网格实现了应用和系统软件的松耦合,使得系统软件的敏捷迭代成为可能。

  • K8S及其编排机制将为系统软件带来一个无所不在、开源免费的超级应用市场,为新系统软件的加速普及创造了前所未有的条件。

综合以上几点可以看出,云原生时代下,系统软件的创新实现难度和应用普及难度都大幅下降,可望带来一个系统软件发展的新时代。


继续滑动看下一个
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存