“云原生”和云原生应用的价值究竟是什么?

“云原生”是云计算中很重要的一个概念,不过对“云原生”的认识和解读各有侧重。我们觉得云原生围绕的是“云原生应用”这个核心,微服务、容器、DevOps等是实现云原生的工具和方法论,它们并不等价。澄清概念、厘清认知,是推动“云原生应用”落地实践的基础。

初次听到“云原生(Could Native)”的时候也是一头雾水,对云原生的十二要素也是不理解。随着项目的推进,对云计算理解的越来越多,也有了一些自己的体会,再次看云原生的概念的时候,有了新的认知。也总是看到很多人讨论云原生,有人说云原生是构建和运行应用程序的方法;有人说云原生是一套技术体系和方法论;有人说云原生应用;有人说云原生架构;也有人说云原生就是是持续交付、微服务、容器、DevOps等等不一而足。不能说是错的,也不能说对,不同的人所说的根本不在一个频道上。我们一向强调从整体上、全面的看待问题,不要有选择的只看一点。我们觉得很多人都或多或少的忽略了云原生的核心实质:Native。

一、 云原生(Cloud Native)

云原生概念到底是什么?

我们觉得对于新技术首先最重要的就是弄清楚它的概念和适用场景。先看Native在英语中的意思:天然的、天生的、本国的、土著的。Cloud Native就是天生的云,就是天生就具备云的基因,适合云环境。就像美国人的native language 是English一样,不是说美国人改变了国籍加入了其他国家的国籍,其native language就变了,native是一辈子都不会变的。

其核心是云原生应用,范围包括云原生应用生命周期过程的理论、工具和方法。云原生十二因素是判断是否是云原生的基本原则,也是实现云原生应用的基本理论指导(虽然这些因素并不完全准确)。至于持续交付、容器、微服务、DevOps是实现云原生应用或服务的方法、工具框架和环境支持。不是采用所谓的微服务、容器技术、DevOps就是云原生了,那只不过是一种实现方式而已。没有它们,换其他工具方法同样可以实现云原生。即便有了它们,用了它们也不一定就是云原生。

二、 云原生所应具备的特性

首先要明白云原生要具备云的天然基因,天生就是云的一部分。云原生不是为云而生,而是天生就是云,生而是云,所以它具有云的特性:通过网络访问、远端部署执行、可扩展弹性伸缩、共享、按需使用自助服务、高可用、可远程监控计费审计、标准化交付与位置无关等。

云原生十二因素中,基准代码是为共享;依赖、配置、后端服务、管理进程是自治自主服务范畴;构建、发布、运行以及端口绑定是标准化交付与位置无关范畴;端口绑定也是远程访问范畴;进程、并发是扩展弹性要求;易处理是高可用要求;日志是监控计费审计需求,作为事件流则是云应用与位置无关要求。

云原生十二因素虽然提出了云原生应用的大部分特性,但并没有明确云原生到底是什么?讨论云原生的时候到底该讨论什么?

三、 讨论云原生该关注什么?

我们在讨论云原生的时候到底该关注什么?是架构?体系?或是方法?

我们觉得讨论云原生最重要的是讨论云原生应用。这是所有讨论云原生的核心。云原生架构是云原生应用的架构,云原生方法论是实现云原生应用的方法论,云原生程序就是云原生应用,云原生体系就是构建、发布、运行云原生应用的理论、方法、工具、环境、流程、文化等等。最终目的是为了业务应用。云原生要素中第一条就是“一份基准代码,多份部署”,也已明确了是云原生应用。

应用可以是天生具备云基因,适合部署于云环境,或者通过改造之后适合云计算环境,但改造的应用不是云原生应用,因为它不是天然的云应用。云原生应用也不是为了迁云,传统应用改造为云应用才是为了迁云。这是我们在讨论云原生的时候需要厘清楚的概念,不能混为一谈。概念不清就会越谈越乱,越谈越糊涂。

四、 云原生应用

云原生应用,就是天生具备云计算基因,以云计算的思想构建并适用于云计算环境的应用。它应该具备我们提到的特性:可以通过网络访问、远端部署执行、可扩展弹性伸缩、共享、按需使用自主服务、高可用、可远程监控计费审计、标准化交付与位置无关等。有人说轻量、无状态是不是云原生的特征?我们并不认为是。轻量、无状态是容器的特征,容器非常适合部署微服务应用,但微服务应用并不一定是云原生应用。

应用云原生思想,可以采用微服务架构、容器、DevOps等技术构建轻量、无状态的云原生应用,使应用具备云端部署、可远程访问、弹性、共享、按需自助服务、高可用、与位置无关等特征,使之天生就具备云的基因,适合云环境部署运行。云原生十二因素更多的也是从构建云原生应用的角度讨论的。

(一) 弹性

弹性是云计算的重要特征,理论上不受资源限制,可以无限占用资源(当然需要按使用量付费)。容器之所以和云原生扯上关系,因为弹性也是容器的重要特征,采用容器很重要的是其弹性能力。弹性包括弹性使用资源和服务实例弹性扩展能力。在单实例扩展资源达到瓶颈,则配合负载均衡机制实现容器实例的弹性扩展。我们谈论云原生应用弹性,应该包括应用使用资源的弹性和应用实例弹性扩展的弹性。

(二) 共享

云计算分三种类型:IaaS、PaaS、SaaS,这就涉及三个层级的共享:资源共享、平台共享、应用共享。云原生应用是SaaS层服务,部署于IaaS或PaaS层。应用有一份基准代码,多份部署,也是共享,是从应用开发角度考虑,但不是云应用共享意义。

云应用可以对所有人开放,大家共享云应用提供的服务。云应用需要部署在云计算平台上,使用云计算资源,这就实现了平台共享和资源共享。

(三) 自治

云应用部署与位置无关,你不知道它会被部署到什么位置,底层对用户透明。所以云原生应用的依赖包、配置文件、后端服务等就需要和应用一起同生共死,成为一个整体,实现自管理自治理。

微服务的设计也遵循自治原则,和云原生应用非常相似。这可能也是把它们放一起讨论的原因。因此我们在用微服务实现云原生应用的时候,自治是一个重要的判断标准。这是分布式中心的好处,自成一体。就像人,每个人都是一个分布式中心,具备自我管理的能力。

(四) 交付标准化,与位置无关

云应用构建可以在本地或者云端,运行一定在云端,那就要按照一定的标准交付,比如容器镜像,使交付标准化。标准交付就可以在云端任何支持标准的位置部署,或者根本不需要知道被部署到了什么位置运行,和环境无关。就像Java曾经宣称的那样: Write Once, Run Anywhere,实现Build Once, Run Anywhere。

容器的一个好处是应用运行工具标准化,所有的应用都以标准化镜像的方式交付,在标准化的容器里运行。容器可以运行在任何地方,或者也无需知道它运行在哪里,只需要提交镜像发布运行就可以了。

(五) 高可用性

多实例部署、弹性、自治等特性是高可用的保证。采用容器有时候并不能保证应用的稳定性,但可以是敏捷启停、多实例高可用的。如果需要稳定的高可用机制,容器可能不是最好的选择。

(六) 可监控审计

用户对应用的访问调用,应用的运行情况状态,不管通过日志或者接口能实时获取到这些信息,用于计量计费、监控和后期审计等。比如可以根据负载流量实现弹性伸缩。

(七) 按需访问自助服务

云应用部署在云端,根据客户自己的需求,通过网络访问,自助使用服务,不需要联系云应用管理人员。通常会有个云应用服务目录,每个应用服务都有使用说明,通过服务目录可以找到适合自己满足自身需求的应用。

(八) 可配置

云应用往往依赖配置中心,实现不同环境应用的部署运行。比如开发、测试和生产环境,一些参数的配置可能是不一样的。很多时候又不方便把所有的配置文件都和应用打包在一起,所以可以通过配置中心来统一管理应用配置文件,甚至可以实现运行时参数更新。

配置中心更多的是从应用运维的角度来考虑的。从自治角度来说,它并不是必须的。但是也是很重要的载体,就像人有大脑存储,但依然需要借助纸笔记忆一样。

(九) 敏捷

敏捷不管从应用开发部署角度或者运维运营角度,都是需要的。但我们觉得它不是云原生应用的关键特性。敏捷通常和轻量、微服务组件化相关,小了,轻了相对就敏捷多了。很多时候敏捷和架构相关,不只是技术架构,也和组织架构相关。敏捷更多的是流程、管理或体验的需求。

五、 微服务、容器和DevOps构建云原生应用

容器轻量、弹性;微服务小而专使开发、测试、更新效率提高,实现了敏捷;DevOps持续集成、持续部署、持续发布、持续监控、持续反馈、持续改进而形成应用生命周期管理的闭环。容器的轻量特性非常适合运行微服务化应用。微服务架构使应用设计架构思想发生了改变。采用小而专的微服务完成某一特定的业务单元工作;通过微服务的组合或编排而成一个业务应用,完成特定的业务流程;业务流程可以按需编排,实时部署;镜像使交付标准化,容器使运维调度标准化,镜像仓库使分发部署标准化。标准化使持续集成、部署、发布流程简化,服务编排使应用研发实现敏捷化,DevOps持续监控、反馈、改进使响应变化敏捷化。可以及时反映市场业务需求的变化和要求。

也因此容器、微服务和DevOps会被放在一起来共同构建轻量、无状态的云原生应用。

六、 应用改造和迁移

应用通过改造使其具备云原生的特性(重生),部署于云环境,可以简单的把它看到云原生应用。但是如果不做改造直接迁移到云环境,并不能成为云原生应用,即便具备云的某些特性,比如ESB服务,并不是云原生应用。

在考虑应用迁移时,需要考虑应用是否具备云原生应用的特性,如果不具备通常需要考虑改造,以使其能够具备云计算的优势。

添加微信免费咨询服务器配置选择建议
微信号:landuiYY

未经允许不得转载:云技术 » “云原生”和云原生应用的价值究竟是什么?

赞 (1)