本节介绍云原生的概念,以及几个平台对云原生的定义。
第一次听到“云原生”这3个字是在2018年,在Qcon大会结束后,有一个小型的闭门会,会上有一个主题是——云原生(Cloud Native)。听了演讲嘉宾的讲解后,我发现云原生包含的无非就是微服务、DevOps、持续集成、持续部署、容器化,这些都是工作中很熟悉的内容,只是这个名字起得太过“高深莫测”。
有的人认为云原生就是“云”,比如国内几朵云的基础设施。相比于传统机房,云有更多的应用封装,云上服务器、云存储、云数据库、云缓存等,把IaaS层全部封装起来,大大降低了基础设施的运维成本。有的人认为云原生就是容器化。相比于通用的物理机、虚拟机,容器化技术使基础设施具有更大的使用率和弹性。
相比于容器化,在大家的印象中,云原生的一个代名词可能是Kubernetes。随着Kubernetes这几年的爆发性增长,很多工程师认为云原生就是Kubernetes。而Sidecar概念的普及,又使不少人认为,云原生等价于服务网格(Service Mesh)。
从字面上看,还是将云原生按照其英文拆成“云”(Cloud)和“原生”(Native)两部分更直观一些。“云”与本地IDC(Internet Data Center,互联网数据中心)相对,在云计算大潮风卷残云之前,大部分企业服务都是运行在IDC中的,也就是大家常说的“本地服务”。随着阿里云、腾讯云、AWS、Azure等云厂商的崛起,越来越多的企业应用都迁移到“云端”,也就是我们常说的企业上云。
以阿里云为例,它基本包含了企业应用需要的IaaS、PaaS、SaaS三层所有资源,如图1-1所示。
图1-1 阿里云云原生应用平台示意图
得益于云生态的日趋丰富和完善,综合运维的复杂性和成本越来越低,很多企业逐步放弃了自研基础设施,直接利用云的优势,达到业务快速迭代的目的。
个人认为上云有以下几个优势。
应用上云解决了IT系统及基础设施更新迭代难、故障率高、风险大的问题。云将基础设施全部标准化,有着规范的版本、类型、升级管理,企业基本不用担心因为系统升级带来的故障。
云的冷热部署、潮汐调度能够使单机房、单机架、单服务器的使用率充分发挥其规模优势,达到高利用率的效果。
一方面云设施提供了丰富的可操作UI界面,另一方面云厂商提供了强大的后台技术、客服资源支持。上云后,企业基本不需要投入庞大的运维资源支持。
一般而言,企业的基础设施都会经历单机房、同城双机房、异地多机房的发展阶段。而在企业发展的中前期,基本都是把业务放在第一位,安全性、容灾性一定不是当前阶段考虑的首要因素,这就意味着这个阶段的应用程序基本都是“裸奔”的。云服务允许用户定制各种级别的灾备方案,省去安全、稳定性建设方面的大量成本。
云计算的分布式特性让我们对虚拟机基础设施的认知有所改变。读者可能听过“牛与宠物”的比喻:将容器比作牲畜而不是宠物,以此重塑人们对容器和基础设施本质的看法。
容器及其基础设施都是不可变的。一般而言,容器或服务器部署后,我们就再也不会对其进行修改。由于云基础设施不与特定资源相关联,因此云基础设施被视为短暂的和一次性的。云服务器更像是牛而不是宠物,人们并不认为家庭中需要小牛并且要保证它的健康,一旦云服务器遇到问题,不会进行分析并尝试修复它。相反,出问题的云服务器会被终止,并快速被另一个云服务器替代。
传统的基础设施既昂贵又个性化,是可更改的。当它们遇到问题时,我们会通过实际管理来评估、诊断和护理它们,直到它们恢复健康。我们会将它们视为“家庭”的一部分,类似宠物。
不可变基础设施是可编程的,我们可以实现自动化。基础设施即代码(Infrastructure As Code,IAC)是基础设施的关键属性之一,不可变基础设施、容器编排、基于IAC的自动化等技术,为云环境下应用程序的管理提供了很高的灵活性和扩展性。
了解了“云”之后,我们再看“原生”,“原生”的含义是让架构师从一开始设计应用的时候就考虑到应用未来是在云环境下运行的,可以充分利用云的先天优势,比如弹性、快速迁移和拉起新服务。
云原生的使用最早可以追溯到2005年,在谷歌前后经历了如图1-2所示的几个关键时期。
2004~2007年,Google已在内部大规模使用Cgroups这类容器技术。
2006年,亚马逊成立AWS。
2009年,阿里云成立。
2010年,NASA发布了OpenStack,相对于AWS和阿里云,用户可以用其架构搭建自己的私有云。同年,Paul Fremantle在一篇博客中提到云原生应该具备的一些特性,如分布式、动态插拔、弹性、多租户、自服务、精确计量及计费、增量部署和测试。
图1-2 云原生发展路线图
2013年,伴随着Cloud Foundry项目的开源,云计算正式从IaaS时代进入PaaS时代,开发者只需要上传自己的应用到Cloud Foundry服务器,就可以对外提供服务。为了解决Cloud Foundry打包难的问题,Docker项目的镜像解决方案横空出世,并且在几个月内迅速崛起,成为PaaS社区的当红项目。同年,Matt Stine在推特上迅速推广云原生概念。
2014年,Kubernetes项目正式发布。有了容器和Docker之后,就需要有一种方式去帮助大家方便、快速、优雅地管理这些容器,这是Kubernetes项目诞生的初衷。
2015年,CNCF(Cloud Native Computing Foundation,云原生计算基金会)成立,标志着云原生正式进入高速发展轨道,Google、Cisco、Docker各大厂商纷纷加入,并逐步构建出围绕云原生的具体工具,而云原生这个概念也逐渐变得更具体。Kubernetes成为CNCF托管的第一个开源项目。同年,《迁移到云原生应用架构》(Migrating to Cloud-Native Application Architectures)一书出版,其中提到了符合云原生架构的特征,包括12要素、微服务、自服务、基于API协作、抗脆弱性。
2017年,CNCF快速发展,包括170个成员和14个基金项目。云原生应用的提出者之一——Pivotal在其官网上将云原生的定义概括为DevOps、持续交付、微服务、容器这4个特征。
2018年,CNCF成立3周年时,共有195个成员、19个基金项目和11个孵化项目,服务网格开始崭露头角。CNCF对云原生的定义也发生了改变,增加了服务网格和声明式API。
2020年、2021年,云原生已经被各大一线互联网公司认同和使用。
2015年,Pivotal的高级产品经理Matt Stine在《迁移到云原生应用架构》一书中探讨了云原生应用架构的5个主要特征,即应用符合12要素、面向微服务架构、自服务敏捷架构、基于API的协作和抗脆弱性。
同年,Google作为发起方成立CNCF,并阐述了云原生的定义。
·应用容器化
·面向微服务架构
·应用支持容器的编排调度
随着云计算的不断发展,云原生的内涵不断丰富和明确,它的定义也经历了几次修正。云原生的拥趸者越来越多,这一体系在反复的修正与探索中逐渐成熟。截至2021年,CNCF官网对云原生的最新 定义如下。
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统做出频繁和可预测的重大变更。
CNCF致力于培育和维护一个厂商中立的开源生态系统来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。
2019年,VMware以27亿美元的价格收购Pivotal,几乎同一时间,VMware发布新产品Tanzu,基于Kubernetes实现了Tanzu应用现代化战略——帮助客户构建现代化应用程序,使用Kubernetes运行它们,并在单一控制面上进行管理。
VMware官网的VMware Tanzu界面上关于云原生应用的介绍如下。
云原生是一种方法,用于构建和运行充分利用云计算优势的应用。云计算不再将重点放在资本投资和员工上来运行企业数据中心,而是提供无限制的按需计算能力和根据使用情况付费的能力,从而重新定义了绝大多数行业的竞争格局。IT开销的减少意味着入行的壁垒更低,这一竞争优势使得各团队可以快速将新想法推向市场,这就是初创公司正在使用云原生方法来颠覆传统行业的原因。
但是,企业需要一个构建和运行云原生应用和服务的平台,来自动执行并集成DevOps、持续交付、微服务和容器等技术。
下面介绍云原生的4个核心要点——DevOps、持续交付、微服务、容器,如图1-3所示,这4个核心要点被众多开发者看作对云原生的最佳诠释。
图1-3 云原生的4个核心要点
结合CNCF的定义,我认为“不可变基础设施和声明式API”属于云相关的技术,与企业自身的关系不大。同时,微服务更多属于架构升级的层面,大部分企业在微服务架构下才会去尝试新的架构。在我看来,对于企业来说,更重要的是容器化、持续交付(持续交付是DevOps的关键落地,因此这里没有单独来讲DevOps)、服务网格,本书将重点从这3个维度来阐述企业级云原生落地的最佳实战。