揭秘“云原生”:它到底是什么?

发表时间: 2020-04-22 16:42

到底什么是“云原生”?



作为云计算领域的一个新兴概念,`云原生`现在频繁出现在我们的视野中。参加各种运维或者IT技术大会,基本上也绕不开这个话题,`云原生`已经是当前的当红辣子鸡!

究竟什么是“云原生”?它会给我们带来什么改变?

云原生的起源

介绍云原生之前,我们先介绍一下CNCF。

CNCF,全称为Cloud Native Computing Foundation,中文译为“云原生计算基金会”。这个基金会成立于2015年12月11日,属于Linux基金会旗下,CNCF致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。所以说,`CNCF是云原生领域影响力最大最有话语权的组织`

说起CNCF的故事,还要从Cgroups(control groups,控制组群)开始说起。

十六年前,也就是2004年,谷歌开始使用容器技术。到了2006年,谷歌发布了Cgroups,最初叫Process Container(进程容器)。Process Container的目的非常直白,它希望能够像虚拟化技术那样,给进程提供操作系统级别的资源限制、优先级控制、资源审计能力和进程控制能力。带着这样的设计思路,Process Container发布后第二年就进入了Linux内核主干。因为在Linux内核中,容器(container)这个名词有许多不同的意义,为避免混乱,就更名为Control Groups,也就是Cgroups。`2013年,Docker项目正式发布,2014年,K8s项目也正式发布。`K8s项目的初衷,就是提供一种方式去帮助大家方便、快速、优雅地管理容器。(K8s是云原生的基石,后面会细讲。)在Google和Redhat发布了K8s之后,这个项目的发展速度非常之快。

2015年,由Google、Redhat以及微软等大型云计算厂商以及一些开源公司共同牵头成立了CNCF云原生基金会。CNCF成立之初,就有22个创始会员,而且K8s也成为了CNCF托管的第一个开源项目。CNCF一直保持高速发展。截止2020年2月,已有433个会员。


云原生的定义

我们先来看看CNCF是如何定义云原生的呢?

翻译过来大致是这样:

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。`云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。`这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。云原生计算基金会(CNCF)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。按CNCF的定义,云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。除了CNCF之外,网络上还流传着另一个版本的“云原生”定义和来源。这种说法认为,是Pivotal公司的Matt Stine,于2013年首次提出云原生概念。2015年,云原生刚推广时,Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征:`12因素、微服务、自敏捷架构、基于API 协作、扛脆弱性`。

到了2017年,Matt Stine改了口风,将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6特质。而Pivotal官网对云原生概括为4个要点:`DevOps+持续交付+微服务+容器`。

`MattStine认为云原生它是一个思想的集合`,包括DevOps、持续交付(Continuous Delivery)、微服务(MicroServices)、敏捷基础设施(Agile Infrastructure)、康威定律(Conways Law)等。

云原生既包含技术(微服务,敏捷基础设施),也包含管理(DevOps,持续交付,康威定律,重组等),可以说是一系列云技术、企业管理方法的集合。



不可变基础设施

在传统的可变服务器基础架构中,服务器会不断更新和修改。使用此类基础架构的工程师和管理员可以通过SSH连接到他们的服务器,手动升级或降级软件包,逐个服务器地调整配置文件,以及将新代码直接部署到现有服务器上。换句话说,这些服务器是可变的。它们可以在创建后进行更改。

可变基础设施通常会导致以下问题:

  • 在灾难发生的时候,难以重新构建服务。持续过多的手工操作,缺乏记录,会导致很难由标准初始化后的服务器来重新构建起等效的服务。
  • 在服务运行过程中,持续的修改服务器,就犹如程序中的可变变量的值发生变化而引入的状态不一致的并发风险。这些对于服务器的修改,同样会引入中间状态,从而导致不可预知的问题。

不可变基础架构是另一种基础架构范例,其中服务器在部署后永远不会被修改。

程序设计中不可变变量(ImmutableVariable)就是在完成赋值后就不能发生更改,只能创建新的来整体替换旧的。由于具有这样的特性这种变量可以在并发环境下安全的使用。对于基础设施的不可变性,最基本的就是指运行服务的服务器在完成部署后,就不再进行更改。

不可变基础架构的好处,包括基础架构中更高的一致性和可靠性,以及更简单,更可预测的部署过程。它可以缓解或完全防止可变基础架构中常见的问题,例如配置漂移和雪花服务器。但是,有效地使用它通常包括全面的部署自动化,云计算环境中的快速服务器配置,以及处理状态或短暂数据(如日志)的解决方案。


声明式API

声明式(Declarative)的编程方式是相对于命令式(Imperative)来说的。在命令式 API 中,我们可以直接发出服务器要执行的命令,例如: “运行容器”、“停止容器”等;在声明式 API 中,我们声明系统要执行的操作,系统将不断向该状态驱动。

The Twelve Factors

12-Factors经常被直译为12要素,也被称为12原则,12原则由公有云PaaS的先驱Heroku于2012年提出[https://12factor.net](https://12factor.net/),目的是告诉开发者如何利用云平台提供的便利来开发更具可靠性和扩展性、更加易于维护的云原生应用。具体如下:

  1. 基准代码
  2. 显式声明依赖关系
  3. 在环境中存储配置
  4. 把后端服务当作附加资源
  5. 严格分离构建、发布和运行
  6. 无状态进程
  7. 通过端口绑定提供服务
  8. 通过进程模型进行扩展
  9. 快速启动和优雅终止
  10. 开发环境与线上环境等价
  11. 日志作为事件流
  12. 管理进程

另外还有补充的三点:

  • API声明管理
  • 认证和授权
  • 监控与告警

12原则依旧是业界最为系统的云原生应用开发指南。


最后

云原生可以实现快速迭代、自动部署、独立高效,可以打通微服务开发、测试、部署、发布的整个流程环节。采用云原生所开发的应用都且具备极强的可扩展性。