简述云原生基础定义及关键技术

云原生是什么

云原生是面向“云”而设计的应用，因此技术部分依赖于传统云计算的 3 层概念，基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS）。

例如，敏捷的不可变基础设施交付类似于 IaaS，用来提供计算网络存储等基础资源，这些资源是可编程且不可变的，直接通过 API 可以对外提供服务；有些应用通过 PaaS 服务本来就能组合成不同的业务能力，不一定需要从头开始建设；还有一些软件只需要“云”的资源就能直接运行起来为云用户提供服务，即 SaaS 能力，用户直接面对的就是原生的应用。

原生就是土生土长的意思，我们在开始设计应用的时候就考虑到应用将来是运行云环境里面的，要充分利用云资源的优点，比如️云服务的弹性和分布式优势。

微服务

微服务解决的是我们软件开发中一直追求的低耦合+高内聚，记得有一次我们系统的接口出了问题，结果影响了用户的前台操作，于是黎叔拍案而起，灵魂发问：“为啥这两个会互相影响？！”

微服务可以解决这个问题，微服务的本质是把一块大饼分成若干块低耦合的小饼，比如一块小饼专门负责接收外部的数据，一块小饼专门负责响应前台的操作，小饼可以进一步拆分，比如负责接收外部数据的小饼可以继续分成多块负责接收不同类型数据的小饼，这样每个小饼出问题了，其它小饼还能正常对外提供服务。

DevOps

DevOps 的意思就是开发和运维不再是分开的两个团队，而是你中有我，我中有你的一个团队。我们现在开发和运维已经是一个团队了，但是运维方面的知识和经验还需要持续提高。

持续交付

持续交付的意思就是在不影响用户使用服务的前提下频繁把新功能发布给用户使用，要做到这点非常非常难。我们现在两周一个版本，每次上线之后都会给不同的用户造成不同程度的影响。

容器化

容器化的好处在于运维的时候不需要再关心每个服务所使用的技术栈了，每个服务都被无差别地封装在容器里，可以被无差别地管理和维护，现在比较流行的工具是 docker 和 k8s。

所以你也可以简单地把云原生理解为：云原生 = 微服务 + DevOps + 持续交付 + 容器化

起源

云原生（Cloud Native）的由来

云原生的概念最早开始于 2010 年，在当时 Paul Fremantle 的一篇博客中被提及，他一直想用一个词表达一种架构，这种架构能描述应用程序和中间件在云环境中的良好运行状态。因此他抽象出了 Cloud Native 必须包含的属性，只有满足了这些属性才能保证良好的运行状态。当时提出云原生是为了能构建一种符合云计算特性的标准来指导云计算应用的编写。

后来到 2013 年 Matt Stine 在推特上迅速推广云原生概念，并在 2015 年《迁移到云原生架构》一书中定义了符合云原生架构的特征：12 因素、微服务、自服务、基于 API 协作、扛脆弱性。而由于这本书的推广畅销，这也成了很多人对云原生的早期印象，同时云原生也被 12 要素变成了一个抽象的概念。Matt Stine 认为在单体架构向 Cloud Native 迁移的过程中，需要文化、组织、技术共同变革。 解读：**云原生架构本质上也是一种软件架构，最大的特点是在云环境下运行，也算是微服务的一种延伸。

什么是云原生

云原生架构本质上也是一种软件架构，最大的特点是在云环境下运行，也算是微服务的一种延伸。
云原生计算加速了应用与基础设施资源之间的解耦，通过定义开放标准，向下封装资源，将复杂性下沉到基础设施层；向上支撑应用，让开发者更关注业务价值。此外，云原生计算提供统一的技术栈，动态、混合、分布式的云原生环境将成为新常态。

云原生的定义

云原生（Cloud Native）是一个组合词，“云”表示应用程序运行于分布式云环境中，“原生”表示应用程序在设计之初就充分考虑到了云平台的弹性和分布式特性，就是为云设计的。

可见，云原生并不是简单地使用云平台运行现有的应用程序，它是一种能充分利用云计算优势对应用程序进行设计、实现、部署、交付和操作的应用架构方法。

云原生概念

云原生（Cloud Native）是一种新兴的技术体系，它强调应用程序应该针对云计算环境设计，以便利用云计算的优势如弹性和分布式特性。云原生的核心要素包括：

云：应用程序应运行在分布式云环境中，这意味着它们可以在公有云、私有云或混合云等多种环境下部署和使用。

原生：指应用程序在设计时就应该考虑到云的特性，特别是其弹性和分布式特点，确保应用程序是为云计算优化的。

计算：涉及使用现代的计算技术和工具，如容器化和微服务架构，以提高应用的灵活性、可靠性和效率。

云原生技术有助于构建和运行可弹性扩展的应用程序，这些应用程序具有良好的容错性、易于管理和观察，并且它们的系统结构松耦合，使得工程师能够轻松地进行频繁且可预测的系统变更。此外，云原生还提倡采用新的工作方法和标准，如容器化和服务网格，以及持续集成和持续部署（CI/CD）流程，从而简化应用程序的开发、部署和管理过程。

云原生技术的概念自提出以来，已经成为互联网行业的关注焦点，并且在多个行业中得到实践。随着更多的企业和组织认识到云原生带来的优势，它们正在逐步将自己的IT基础设施向云原生的方向演进。

值得注意的是，尽管存在对云原生确切定义的不同观点，但目前业界最具影响力的组织之一云原生计算基金会（CNCF）给出了较为统一的定义，即云原生是通过特定的技术集合来构建可弹性扩展的应用程序，这些应用程序能够在多种环境中运行，并充分利用云计算的能力。

云原生技术一直在不断地变化和发展，关于云原生的定义也在不断地迭代和更新，不同的社区组织或公司对云原生也有自己的理解和定义。

Pivotal 公司是云原生应用架构的先驱者和探路者，云原生的定义最早也是由 Pivotal 公司的 Matt Stine 于 2013 年提出的。Matt Stine 在 2015 年出版的 Migrating to Cloud-Native Application Architectures 一书中提出，云原生应用架构应该具备以下几个主要特征，如下表所示。

2017 年 Matt Stine 对云原生的定义做了一些修改，认为云原生应用架构应该具备 6 个主要特征：模块化、可观测性、可部署性、可测试性、可处理性和可替换性。截至本文发布时，Pivotal 公司对云原生的最新定义为 4 个要点：DevOps、持续交付、微服务、容器。

除了对云原生技术发展做出巨大贡献的 Pivotal 公司，另一个不得不提的云原生技术推广者就是云原生计算基金会（Cloud Native Computing Foundation，CNCF）。CNCF 是由开源基础设施界的翘楚 Google 等多家公司共同发起的基金会组织，致力于维护一个厂商中立的云原生生态系统，目前已经是云原生技术最大的推动者。

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

云原生关键技术

1. 容器
   容器技术是一种相对于虚拟机来说更加轻量的虚拟化技术，能为我们提供一种可移植、可重用的方式来打包、分发和运行应用程序。容器提供的方式是标准化的，可以将不同应用程序的不同组件组装在一起，又可以将它们彼此隔离。

容器的基本思想就是将需要执行的所有软件打包到一个可执行程序包中，比如将一个 Java 虚拟机、Tomcat 服务器以及应用程序本身打包进一个容器镜像。用户可以在基础设施环境中使用这个容器镜像启动容器并运行应用程序，还可以将容器化运行的应用程序与基础设施环境隔离。

容器具有高度的可移植性，用户可以轻松地在开发测试、预发布或生产环境中运行相同的容器。如果应用程序被设计为支持水平扩缩容，就可以根据当前业务的负载情况启动或停止容器的多个实例。

Docker 项目是当前最受欢迎的容器实现，以至于很多人通常都将 Docker 和容器互换使用，但请记住，Docker 项目只是容器技术的一种实现，将来有可能会被替换。

因为具备轻量级的隔离属性，容器技术已然成为云原生时代应用程序开发、部署和运维的标准基础设置。使用容器技术开发和部署应用程序的好处如下：

• 应用程序的创建和部署过程更加敏捷：与虚拟机镜像相比，使用应用程序的容器镜像更简便和高效。
• 可持续开发、集成和部署：借助容器镜像的不可变性，可以快速更新或回滚容器镜像版本，进行可靠且频繁的容器镜像构建和部署。
• 提供环境一致性：标准化的容器镜像可以保证跨开发、测试和生产环境的一致性，不必为不同环境的细微差别而苦恼。
• 提供应用程序的可移植性：标准化的容器镜像可以保证应用程序运行于Ubuntu、CentOS等各种操作系统或云环境下。
• 为应用程序的松耦合架构提供基础设置：应用程序可以被分解成更小的独立组件，可以很方便地进行组合和分发。
• 资源利用率更高。
• 实现了资源隔离：容器应用程序和主机之间的隔离、容器应用程序之间的隔离可以为运行应用程序提供一定的安全保证。
• 容器技术大大简化了云原生应用程序的分发和部署，可以说容器技术是云原生应用发展的基石。

2. 微服务

微服务是一种软件架构方式，我们使用微服务架构可以将一个大型应用程序按照功能模块拆分成多个独立自治的微服务，每个微服务仅实现一种功能，具有明确的边界。

为了让应用程序的各个微服务之间协同工作，通常需要互相调用 REST 等形式的标准接口进行通信和数据交换，这是一种松耦合的交互形式。

微服务基于分布式计算架构，其主要特点可以概括为如下两点：

• 单一职责：微服务架构中的每一个服务，都应是符合高内聚、低耦合以及单一职责原则的业务逻辑单元，不同的微服务通过 REST等形式的标准接口互相调用，进行灵活的通信和组合，从而构建出庞大的系统。
• 独立自治性：每个微服务都应该是一个独立的组件，它可以被独立部署、测试、升级和发布，应用程序中的某个或某几个微服务被替换时，其他的微服务都不应该被影响。

基于分布式计算、可弹性扩展和组件自治的微服务，与云原生技术相辅相成，为应用程序的设计、开发和部署提供了极大便利：

• 简化复杂应用：微服务的单一职责原则要求一个微服务只负责一项明确的业务，相对于构建一个可以完成所有任务的大型应用程序，实现和理解只提供一个功能的小型应用程序要容易得多。每个微服务单独开发，可以加快开发速度，使服务更容易适应变化和新的需求。
• 简化应用部署：在单体的大型应用程序中，即使只修改某个模块的一行代码，也需要对整个系统进行重新构建、部署、测试和交付。而微服务则可以单独对某一个指定的组件进行构建、部署、测试和交付。
• 灵活组合：在微服务架构中，可以重用一些已有的微服务组合新的应用程序，降低应用开发成本。
• 可扩展性：根据应用程序中不同的微服务负载情况，可以为负载高的微服务横向扩展多个副本。
• 技术异构性：通常在一个大型应用程序中，不同的模块具有不同的功能特点，可能需要不同的团队使用不同的技术栈进行开发。我们可以使用任意新技术对某个微服务进行技术架构升级，只要对外提供的接口保持不变，其他微服务就不会受到影响。
• 高可靠性、高容错性：微服务独立部署和自治，当某个微服务出现故障时，其他微服务不受影响。

微服务具备灵活部署、可扩展、技术异构等优点，但需要一定的技术成本，而且数量众多的微服务也增加了运维的复杂度，是否采用微服务架构需要根据应用程序的特点、企业的组织架构和团队能力等多个方面来综合评估。

3. 服务网格

随着微服务逐渐增多，应用程序最终可能会变为成百上千个互相调用的服务组成的大型应用程序，服务与服务之间通过内部或者外部网络进行通信。如何管理这些服务的连接关系以及保持通信通道无故障、安全、高可用和健壮，就成了一个非常大的挑战。

服务网格（Service Mesh）可以作为服务间通信的基础设施层，解决上述问题。

服务网格是轻量级的网络代理，能解耦应用程序的重试/超时、监控、追踪和服务发现，并且能做到应用程序无感知。服务网格可以使服务与服务之间的通信更加流畅、可靠、安全，它的实现通常是提供一个代理实例，和对应的服务一起部署在环境中，这种模式我们称为 Sidecar 模式，Sidecar 模式可处理服务之间通信的任何功能，比如负载均衡、服务发现等。

服务网格的基础设施层主要分为两个部分，控制平面与数据平面，如图 1 所示。控制平面主要负责协调 Sidecar 的行为，提供 API 便于运维人员操控和测量整个网络。数据平面主要负责截获不同服务之间的调用请求并对其进行处理。

图 1 服务网格典型架构

与微服务架构相比，服务网格具有 3 个方面的优势：

• 可观测性：所有服务间通信都需要经过服务网格，所以在此处可以捕获所有调用相关的指标数据，如来源、目的地、协议、URL、状态码等，并通过API 供运维人员观测。
• 流量控制：服务网格可以为服务提供智能路由、超时重试、熔断、故障注入和流量镜像等控制能力。
• 安全性：服务网格提供认证服务、加密服务间通信以及强制执行安全策略的能力。

4. DevOps

DevOps（Development & Operations，开发和运维）是软件开发人员和 IT 人员之间的合作过程，是一种工作环境、文化和实践的集合，目标是高效地自动执行软件交付和基础架构更改流程。开发和运维人员通过持续不断的沟通和协作，可以以一种标准化和自动化的方式快速、频繁且可靠地交付应用。

开发人员通常以持续集成和持续交付（CI/CD）的方式，快速交付高质量的应用程序。

持续集成是指开发人员频繁地将开发分支代码合并到主干分支，这些开发分支在真正合并到主干分支之前，都需要持续编译、构建和测试，以提前检查和验证其存在的缺陷。持续集成的本质是确保开发人员新增的代码与主干分支正确集成。

持续交付是指软件产品可以稳定、持续地保持随时可发布的状态，它的目标是促进产品迭代更频繁，持续为用户创造价值。

与持续集成关注代码构建和集成相比，持续交付关注的是可交付的产物。持续集成只是对新代码与原有代码的集成做了检查和测试，在可交付的产物真正交付至生产环境之前，我们一般还需要将其部署至测试环境和预发布环境，进行充分的集成测试和验证，最后才会交付至生产环境，保证新增代码在生产环境中稳定可用。

使用持续集成和持续交付的优势如下：

• 避免重复性劳动，减少人工操作的错误：自动化部署可以将开发运维人员从应用程序集成、测试和部署等重复性劳动环节中解放出来，而且人工操作容易犯错，机器犯错的概率则非常小。
• 提前发现问题和缺陷：持续集成和持续交付能让开发和运维人员更早地获取应用程序的变更情况，更早地进入测试和验证阶段，也就能更早地发现和解决问题。
• 更频繁的迭代：持续集成和持续交付缩短了从开发、集成、测试、部署到交付各个环节的时间，中间有任何问题都可以快速“回炉”改造和更新，整个过程敏捷且可持续，大大提高了应用程序的迭代频率和效率。
• 更高的产品质量：持续集成可以结合代码预览、代码质量检查等功能，对不规范的代码进行标识和通知；持续交付可以在产品上线前充分验证应用可能存在的缺陷，最终提供给用户一款高质量的产品。

云原生应用通常包含多个子功能组件，DevOps 可以大大简化云原生应用从开发到交付的过程，实现真正的价值交付。

5. 不可变基础设施

在应用开发测试到上线的过程中，应用通常需要被频繁部署到开发环境、测试环境和生产环境中，在传统的可变架构时代，通常需要系统管理员保证所有环境的一致性，而随着时间的推移，这种靠人工维护的环境一致性很难维持，环境的不一致又会导致应用越来越容易出错。这种由人工维护、经常被更改的环境就是我们常说的“可变基础设施”。

与可变基础设施相对应的是不可变基础设施，是指一个基础设施环境被创建以后不接受任何方式的更新和修改。这个基础设施也可以作为模板来扩展更多的基础设施。如果需要对基础设施做更新迭代，那么应该先修改这些基础设施的公共配置部分，构建新的基础设施，将旧的替换下线。简而言之，不可变基础设施架构是通过整体替换而不是部分修改来创建和变更的。

不可变基础设施的优势在于能保持多套基础设施的一致性和可靠性，而且基础设施的创建和部署过程也是可预测的。在云原生结构中，借助 Kubernetes 和容器技术，云原生不可变基础设施提供了一个全新的方式来实现应用交付。

云原生不可变基础设施具有以下优势：

• 能提升应用交付效率：基于不可变基础设施的应用交付，可以由代码或编排模板来设定，这样就可以使用 Git等控制工具来管理应用和维护环境。基础设施环境一致性能保证应用在开发测试环境、预发布环境和线上生产环境的运行表现一致，不会频繁出现开发测试时运行正常、发布后出现故障的情况。
• 能快速、可靠地水平扩展：基于不可变基础设施的配置模板，我们可以快速创建与已有基础设施环境一致的新基础设施环境。
• 能保证基础设施的快速更新和回滚：基于同一套基础设施模板，若某一环境被修改，则可以快速进行回滚和恢复，若需对所有环境进行更新升级，则只需更新基础设施模板并创建新环境，将旧环境一一替换。

6. 声明式API

声明式设计是一种软件设计理念：我们负责描述一个事物想要达到的目标状态并将其提交给工具，由工具内部去处理如何实现目标状态。

与声明式设计相对应的是过程式设计。在过程式设计中，我们需要描述为了让事物达到目标状态的一系列操作，这一系列的操作只有都被正确执行，才会达到我们期望的最终状态。

在声明式 API 中，我们需要向系统声明我们期望的状态，系统会不断地向该状态驱动。在 Kubernetes 中，声明式 API 指的就是集群期望的运行状态，如果有任何与期望状态不一致的情况，Kubernetes 就会根据声明做出对应的合适的操作。

使用声明式 API 的好处可以总结为以下两点：

• 声明式 API 能够使系统更加健壮，当系统中的组件出现故障时，组件只需要查看API服务器中存储的声明状态，就可以确定接下来需要执行的操作。
• 声明式 API 能够减少开发和运维人员的工作量，极大地提升工作效率。

此文参考：
1、CNCF官网：https://www.cncf.io
2、CNCF官网定义云原生：https://www.cncf.io/about/faq/
3、官网定义云原生：https://tanzu.vmware.com/cn/cloud-native
4、百度百科：https://baike.baidu.com/item/%E4%BA%91%E5%8E%9F%E7%94%9F/53770166?fr=ge_ala
5、阿里云云原生架构白皮书
6、https://c.biancheng.net/view/9857.html

以上感谢！