云原生(OAM)简介 | 飙戈的博客

type

status

date

slug

summary

1、云原生是什么

我们先看一下 Priyanka Sharma（云原生计算基金会）对云原生的解释。

💡

基础系统监控的对象有磁盘/网络IO、CPU/内存等，JAVA项目中还包括JVM各项指标参数；应用层监控的对象有服务存活状态、健康状态、服务性能等；网络层面的监控对象有域名状态、流量状态、QPS等。在微服务架构中监控系统还可以分为日志类、调用链类、度量类三个方面。“云原生”是一种工程师和软件人员利用云计算来构建更快、更有弹性的技术，得以快速满足客户的需求。

看到这个解释，你可能仍一头雾水，似懂非懂。想理解云原生，首先我们要清楚什么是云计算。

什么是云计算？

一般来说，服务器提供计算能力和存储能力用于存储和共享数字信息。很长一段时间以来，大多数公司都购买了自己的物理服务器，通过增加或减少服务器的数量来调整自己的计算能力，但这需要内部 IT 技术部门及人力的支撑。

随着虚拟机的普及，事情变得简单了一些。有了虚拟机，公司可以用更少的物理服务器获得同样的计算能力。技术人员通过安装名为 hypervisors 的软件，将物理机变成了虚拟机。通过给多台机器安装 hypervisors，可以让虚拟机像一个大系统一样共享资源。这时出现了“云”的朦胧概念，即共享计算资源。那么，进一步通过网络“云”将巨大的数据计算处理程序分解成无数个小程序，然后通过多部服务器组成的系统进行处理和分析这些小程序得到结果并返回给用户，就是云计算。

什么是云原生？

云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。换而言之，云原生不是一门单一的技术。云原生（CloudNative）是一个组合词，Cloud + Native。

Cloud：表示应用程序位于云中（准确来说是放在云计算的环境），而不是传统的数据中心。

Native：表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性 + 分布式优势。

这就是广义上的云原生概念。那怎么实现云原生呢？

怎么实现云原生？

Pivotal 官网对云原生概括为 4 个要点，这也是大家对云原生最开始的印象：

微服务

容器

DevOps

持续交付

2015 年，Linux 基金会发起了云原生计算基金会（CNCF），CNCF 基金会的成立标志着云原生正式进入高速发展轨道，Google、Cisco、Docker 各大厂纷纷加入，逐步构建出围绕 Cloud Native 的具体工具，而云原生的概念也逐渐变得更具体化。起初 CNCF 对云原生（Cloud Native）的定义改成包含以下三个方面：

容器化封装

自动化管理

面向微服务架构

这主要因为 CNCF 基金会在当时的核心就是 Kubernetes，因此在概念定义上主要是围绕着容器编排建立起来的生态。

到了 2018 年，随着云原生生态的不断壮大，几乎所有主流云计算供应商都加入了 CNCF 基金会，CNCF 基金会中的会员以及容纳的项目越来越多，最初的定义已经限制了云原生生态的发展，CNCF 为云原生进行了重新定义，增加了以下内容：

服务网格（Service Mesh）

声明式API

不可变基础设施

可见，不同的人和组织对云原生有不同的定义，相同的人和组织在不同时间点对云原生也有不同的定义。这也是云原生这个概念这么难解释的原因。

为了方便理解，选一个最容易记住和理解的定义：云原生的实现 = 微服务 + 容器化编排 + DevOps + 持续交付 + 服务网格 + 声明式 API + 不可变基础设施。所以符合云原生架构的应用程序应该是：采用开源容器编排工具（Kubernetes）进行管理，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps 支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。

2、云原生的要素

微服务：将单体应用拆分为松耦合的小型服务，每个服务独立开发、部署和扩展。将应用的颗粒度做到最小，使之承担对外服务的职责，实现软件开发中一直追求的低耦合 + 高内聚。微服务架构的好处就是按功能拆分后，服务解耦，内聚更强，变更更易。

容器化编排：使用容器（如 Docker）打包应用及其依赖，使用 Kubernetes 等工具自动部署和管理容器，实现环境一致性、轻量化和快速部署。容器化的好处在于运维时无需再关注每个服务所使用的技术栈，因为每个服务都被无差别地封装在容器里，可以被无差别地管理和维护。现在比较常用的工具是 Docker 和 Kubernetes。Docker 是应用最为广泛的容器引擎，基于 LXC 技术而设计，容器化为微服务提供保障，起到应用隔离作用。Kubernetes 是容器编排系统，用于容器管理以及容器间的负载均衡。

DevOps：全称为“Development + Operations”，即开发和运维合体，通过 CI/CD 流水线（如 Jenkins、ArgoCD）实现自动化构建、测试和部署，强调开发与运维协作。DevOps 是一种敏捷开发思维和 IT 组织的沟通方法，可以促进开发、技术运营和质量保障部门之间的沟通、协作和整合，从而提高软件和服务的交付效率。

持续交付：在不影响用户使用服务的前提下频繁把新功能发布给用户使用。持续交付是不误时开发，不停机更新，小步快跑，反传统瀑布式开发模型，这要求开发版本和稳定版本并存，实际上需要很多流程和工具支撑。

服务网格（Service Mesh）：通过基础设施层（如 Istio、Linkerd）管理服务间通信，实现负载均衡、熔断、监控等。Kubernetes 中的应用将作为微服务运行，但是Kubernetes 本身并没有给出微服务治理的解决方案，比如服务的限流、熔断、良好的灰度发布支持等。服务网格（Service Mesh）是致力于解决服务治理的基础设施层，实现层面，通过一组轻量级网络代理（Sidecar proxy），与应用程序代码部署在一起，对应用程序透明，负责处理应用的网络通信。当前开源的流行的 Service Mesh 技术：Istio、Linkerd、Envoy 等。

声明式API：声明期望的状态，系统将不断地调整实际状态，直到与期望状态保持一致。声明式 API 描述最终运行环境的状态，由系统来决定如何来创建这个环境。例如，你的描述就变成“创建一个有三个Nginx的集群”，而不是把创建 Nginx 的命令运行三次组成一个集群。这样的好处是当运行环境与描述不符合时，系统能检测到差异，并自动修复，这样系统就有了自动容错的功能。Kubernetes 的 YAML 配置文件就是一种声明式 API。