我们目前运用到的云原生技术有微服务、Kubernetes、Docker、Istio、Serverless, 今天我们就一起来聊聊。

近期在社区里看到很多人都在问什么是云原生，很有幸我是一位云原生技术的初级使用者，我们目前运用到的云原生技术有微服务、Kubernetes、Docker、Istio、Serverless, 今天我们就一起来聊聊。

云原生的起源

重量级嘉宾

在介绍云原生之前，我们先介绍一位重量级嘉宾，可以说是目前云原生领域影响力最大最有话语权的组织 CNCF。

CNCF，全称Cloud Native Computing Foundation(云原生计算基金会)，成立于 2015 年7月21日于美国波特兰OSCON 2015上宣布，其最初的口号是坚持和整合开源技术来让编排容器作为微服务架构的一部分，其作为致力于云原生应用推广和普及的一支重要力量。

再来一张 CNCF 的全景图：

云原生定义

CNCF 的定义

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

云原生计算基金会(CNCF)致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。

以上内容来源于：CNCF Cloud Native Definition v1.0 - github.com

Pivotal 的定义

2015年，云原生刚推广时，Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：12因素、微服务、自敏捷架构、基于API 协作、扛脆弱性。

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

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

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

我们暂且以 CNCF 官方的定义为准，按CNCF的定义，云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

云原生的代表技术

微服务

微服务可以从两个方面去理解：什么是“微”、什么是“服务”。

微，狭义来讲就是体积小。

服务，一定要区别于系统，服务一个或者一组相对较小且独立的功能单元，是用户可以感知最小功能集。

传统的单体架构，是以整个系统为单位进行部署。而微服务，则是以每一个独立组件(例如用户服务，商品服务)为单位进行部署。

对于单体应用，如果发现某一业务的请求量非常大，那么是无法单独扩展该业务的，只能拷贝整个单体应用，再部署一套环境，来实现集群。正因为单体应用的缺陷，才有了微服务。而近几年流行的Docker，为微服务架构提供了有效的容器。

容器

开源解决方案供应商红帽官网给出的容器定义：

Linux®容器是与系统其他部分隔离开的一系列进程。

运行这些进程所需的所有文件都由另一个镜像提供，这意味着从开发到测试再到生产的整个过程中，Linux 容器都具有可移植性和一致性。

容器提供进程级的隔离，可以将操作系统管理的资源划分到相互隔离的组中，在相互隔离的组之间解决资源使用存在冲突的问题。比如应用程序(Application)APP 1 ，只能在centos 操作系统上运行;APP2只能在Ubuntu操作系统上运行。而同一个操作系统同时运行APP1和APP2就产生冲突。容器技术则恰恰可以解决这类问题。目前主流的容器技术有Docker、LXD以及RKT等。

Docker

说到容器，就不得不说Docker。

2010年，几个大胡子的年轻人在美国旧金山成立了一家名叫“dotCloud”的公司。这家公司主要提供基于PaaS的云计算技术服务。具体来说，是和LXC有关的容器技术。

LXC，就是Linux容器虚拟技术(Linux container)。

后来，dotCloud公司将自己的容器技术进行了简化和标准化，并命名为——Docker。

Docker项目通过容器镜像，直接将一个应用运行所需的完整环境，即：整个操作系统的文件系统也打包了进去。

这种思路，可算是解决了困扰PaaS用户已久的一致性问题，制作一个“一次发布、随处运行”的Docker镜像的意义，一下子就比制作一个连开发和测试环境都无法统一的Buildpack高明了太多。

Docker项目大大降低了容器技术的使用门槛。轻量级，可移植，虚拟化，语言无关，写了程序扔上去做成镜像可以随处部署和运行，开发、测试和生产环境彻底统一了，还能进行资源管控和虚拟化。

Docker作为一种开源应用容器引擎，是为开发人员和系统管理员设计的用于构建、发布和运行分布式应用的平台，典型的Docker平台Kubernetes、OpenShift V3、Flynn、Deis等。

Docker允许开发人员将各种应用以及依赖包打包到一个可移植的Docker容器中，以Docker容器为资源分割和调度的基本单位，封装整个软件运行时的环境，然后发布到Linux机器上。

Kubernetes

有了容器，就需要编排管理容器的生命周期。这里不得不提一下 Kubernetes。

Kubernetes，这个单词来自于希腊语，含义是舵手或领航员。K8s是它的缩写，用“8”字替代了“ubernete”这8个字符。Kubernetes并不是一件全新的发明。它是谷歌根据其内部使用的Borg改造成的一个通用容器编排调度器，于2014年6月开源。

2015年，谷歌将其捐赠给Linux基金会下属的云原生计算基金会(CNCF)，Kubernetes也成为CNCF第一个项目。

CNCF中托管的一系列项目，即致力于云原生应用整个生命周期的管理，从部署平台、日志收集、Service Mesh(服务网格)、服务发现、分布式追踪、监控以及安全等各个领域通过开源软件为我们提供一整套解决方案。

Kubernetes作为云应用的部署标准，直接面向业务应用，大大提高了云应用的可移植性，解决云厂商锁定的问题，让云应用可以在夸云之间无缝迁移，甚至用来管理混合云，成为企业 IT 云平台的新标准。

服务网格

服务网格(Service Mesh)，是指用以处理服务与服务之间通信的基础设施层。

其最早由Buoyant公司(开发Service Mesh项目Linkerd的公司)提出，并在内部使用。该公司2016年9月29日第一次公开使用这个术语。

Service Mesh一般用于微服务应用的可配置基础架构层(configurable infrastructure layer)。Istio(由Google、IBM、Lyft公司在背后进行支持)是目前最广为人知的一款服务网格架构。

Docker和Kubernetes这样的工具已经“解决了部署问题”。但他们还没有解决运行时的问题，这就是服务网格的由来， 而 Service Mesh的出现，弥补了Kubernetes在微服务的连接、管理和监控方面的短板，为Kubernetes提供更好的应用和服务管理。

因此，Service Mesh的代表Istio一经推出，就被认为是可以和Kubernetes形成双剑合璧效果的微服务管理的利器，受到了业界的推崇。

不可变基础设施

在传统的可变服务器基础架构中，服务器会不断更新和修改。使用此类基础架构的工程师和管理员可以通过SSH连接到他们的服务器，手动升级或降级软件包，逐个服务器地调整配置文件，以及将新代码直接部署到现有服务器上。可变基础设施通常在灾难发生的时候，难以重新构建服务。持续过多的手工操作，缺乏记录，会导致很难由标准初始化后的服务器来重新构建起等效的服务。在服务运行过程中，持续的修改服务器，就犹如程序中的可变变量的值发生变化而引入的状态不一致的并发风险。这些对于服务器的修改，同样会引入中间状态，从而导致不可预知的问题。

而不可变基础架构是程序设计中不可变变量(ImmutableVariable)就是在完成赋值后就不能发生更改，只能创建新的来整体替换旧的。由于具有这样的特性这种变量可以在并发环境下安全的使用。对于基础设施的不可变性，最基本的就是指运行服务的服务器在完成部署后，就不在进行更改。其好处包括基础架构中更高的一致性和可靠性，以及更简单，更可预测的部署过程。它可以缓解或完全防止可变基础架构中常见的问题，例如配置漂移和雪花服务器。

声明式API

在声明式 API 中，我们可以声明系统要执行的操作，系统将不断向该状态驱动。有点“产品经理”和“开发”之间的关系，“产品经理”只负责提需求，而“开发”怎么实现的，他并不关心。

总结一下：

  • Kubernetes是整个云原生的基石，云原生的整个生态体系都是依靠Kubernetes建立起来的。

  • 容器(Container)是Kubernetes的底层引擎。

  • Docker是应用最广的容器工具。

  • 微服务是Docker的好搭档。

  • 服务网格是微服务的辅助，建立在k8s上的针对请求的扩展功能。

  • 不可变基础设施是现代运维的基石。

  • 声明式API是Kubernetes的编码方式。

云原生到底哪里好?

综合来说云原生可以打通微服务开发、测试、部署、发布的整个流程环节，在云原生架构下，底层的服务或者是API都由将部署到云中，等价于将繁重的运维工作转移给了云平台供应商， 但这也得益于云计算的基础设施更加廉价。详细来说一下个人认为的以下三个优势：

快速迭代

利用云原生应用程序开发，使得交付团队可以使用重复的自动化和编排来快速迭代，让开发人员有更多的精力聚焦于业务开发上。

自动部署

云原生方法远优于传统的面向虚拟化的业务流程，传统方法需要投入大量的精力来构建开发环境，以及软件交付过程中的其他不同环境。而云原生架构具备自动化和组合功能，并且依赖于可靠、经过验证和审核的已知良好流程的基础，交付十分敏捷，而不再需要人工干预重复执行。

独立高效

云原生带来了微服务化架构，一个微服务基本是一个能独立发布的应用服务，因此可以作为独立组件升级、灰度或复用等，对整个大应用的影响也较小，每个服务可以由专门的组织来单独完成，依赖方只要定好输入和输出口即可完全开发、甚至整个团队的组织架构也会更精简，因此沟通成本低、效率高。

写在最后，云原生的确给我们带来了很多便捷，但同时也对我们研发和运维人员提出了更高的要求，如何选择更合适的云原生技术来解决日益复杂的业务问题。

参考资料

  • https://github.com/cncf/landscape#trail-map。

  • https://github.com/cncf/toc/blob/main/DEFINITION.md。

  • https://www.bookstack.cn/read/kubernetes-handbook-201910/cloud-native.md。