深入了解云原生：定义与特征解析

文章目录

一、云原生概述
- 1.1 什么是云原生
- 1.2 云原生组成要素
- 1.3 补充资料
二、云原生的目标
- 2.1 云原生关键目标
- 2.2 云原生特性
三、云原生应用 VS 传统单体应用
参考资料

一、云原生概述

1.1 什么是云原生

(1)云原生定义

云原生(Cloud Native) 是一种软件架构和开发方法论，旨在充分利用云计算环境的优势，使应用程序更具有弹性、可伸缩性、可靠性和效率。其中，“Cloud Native” 应用程序通常采用微服务架构，使用容器技术进行部署，倡导自动化运维和持续集成/持续部署。整个设计思想旨在使应用程序能够更好地适应云环境中的快速变化和不断增长的需求。

“Cloud” 指的是云计算，是一种通过互联网提供计算资源和服务的模式；云计算服务提供商（如亚马逊AWS、微软Azure、谷歌Cloud等）提供了虚拟服务器、存储、数据库、网络等基础设施和服务，用户可以按需使用并根据实际使用量支付费用。云计算使得用户无需购买和维护昂贵的硬件，能够灵活、高效地利用计算资源。
“Native” 在这个上下文中表示与特定平台或环境相适应，即采用特定平台或环境提供的最佳实践和特性。“Cloud Native” 强调应用程序和服务在云环境中原生地设计和运行，充分利用云计算的特性。

具体点，云原生(Cloud Native)是一种专门针对云上应用而设计的方法，用于构建和部署应用，以充分发挥云计算的优势。**这些云上应用的特点是可以实现快速和频繁的构建、发布、部署，结合云计算的特点实现和底层硬件和操作系统解耦，可以方便的满足在扩展性，可用性，可移植性等方面的要求，并提供更好的经济性。同时通过拆解为多个小型功能团队来让组织更敏捷，让人员、流程和工具更好的结合，在开发、测试、运维之间进行更密切的协作。

需要注意的是，云原生没有确切的定义，云原生一直在发展变化之中，解释权不归某个人或组织所有。

(2)Pivotal的定义

Pivotal 是Cloud Native/云原生应用的提出者，并推出了Pivotal Cloud Foundry和Spring系列开发框架，是云原生的先驱者和探路者。

2015年，来自Pivotal公司的Matt Stine编写了一本名为《Migrating to Cloud Native Application Architectures 》（宋净超同学翻译的中文版迁移到云原生应用架构）的电子书，提出云原生应用架构应该具备的几个主要特征：符合 12 因素应用、面向微服务架构、自服务敏捷架构、基于API的协作、抗脆弱性；

2017年，在Pivotal最新的官方网站 https://pivotal.io/cloud-native 上，Pivotal在其官网上将云原生的定义概况为DevOps、持续交付、微服务、容器这四大特征：
在这里插入图片描述

在这里插入图片描述

在Pivotal看来，云原生是一种使用云计算方法和工具开发、部署和运行应用程序的方法。从根本上说，云原生是关于构建团队、文化、和技术，以利用现代架构和先进的自动化来管理复杂性并提高软件开发速度。

(3) CNCF 的定义

2015年CNCF建立，开始围绕云原生的概念打造云原生生态体系，起初CNCF对云原生的定义包含以下三个方面：

应用容器化(software stack to be Containerized)
面向微服务架构(Microservices oriented)
应用支持容器的编排调度(Dynamically Orchestrated)

2018年，云原生计算基金会CNCF 给出云原生定义 v1.0版本，内容如下：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

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

新的定义中，继续保持原有的核心内容：容器和微服务，但是非常特别的将服务网格单独列出来，而不是将服务网格作为微服务的一个子项或者实现模式，体现了云原生中服务网格这一个新生技术的重要性。而不可变基础设施和声明式API这两个设计指导理念的加入，则强调了这两个概念对云原生架构的影响和对未来发展的指导作用。
在这里插入图片描述

1.2 云原生组成要素

在云原生计算基金会CNCF 给出的云原生定义 v1.0版本中，云原生的组成要素包括：

容器：
- 容器是一种轻量级、可移植的软件单元，包括应用程序及其所有依赖项和配置。容器化技术（例如Docker）提供了一种将应用程序和其环境打包成容器的方式，使其在不同环境中能够一致运行。
服务网格：
- 服务网格是一种基础设施层，用于管理微服务架构中服务之间的通信。它提供了流量管理、安全性、监控和其他功能，以简化和增强微服务之间的通信。常见的服务网格包括Istio和Linkerd。
微服务：
- 微服务是一种软件架构模式，将应用程序拆分成小型、独立的服务单元，每个服务单元负责一个特定的业务功能。这种架构提倡松耦合、独立部署、可伸缩性和更容易维护的特点。
不可变基础设施：
- 不可变基础设施是指在部署后不再修改或直接更改的基础设施。相反，任何变更都通过替换整个组件来实现。这种方法提高了可重复性、可维护性和稳定性，适合于自动化和云原生环境。
声明式API：
- 声明式API是一种描述系统状态或期望状态的方式，而不是指定系统如何达到该状态的具体步骤。在云原生环境中，Kubernetes是一个例子，其配置文件以声明式的方式描述应用程序的部署、服务和其他资源。

1.3 补充资料

云原生领域的技术和项目的可视化图谱（由CNCF维护），展示了云原生生态系统中各种工具、框架和项目的关系和分类。云原生领域图谱网站为：

Cloud Native Landscape (cncf.io)

云原生常见概念查询网站，帮助我们理解云原生领域中的一些陌生概念：

Tanzu (vmware.com)
Cloud Native Glossary (cncf.io)

CNCF年报会分析整个云原生当年的发展情况，帮助我们更好理解云原生的发展情况：

CNCF Annual Report 2021 | CNCF

二、云原生的目标

2.1 云原生关键目标

根据资料云原生的目标 | 云原生学习笔记 (skyao.io)，对云原生出现背景的分析，以及对不同时期云原生定义的回顾总结，云原生的关键目标主要有：

可用：通过各种机制来实现应用的高可用，以保证服务提供的连续性。
敏捷：快速响应市场需求
成本：充分有效的利用资源
规模：要求云原生服务能够适应不同的规模（包括但不限于用户规模/部署规模/请求量），并能够在部署时动态分配资源，以便在不同的规模之间快速和平滑的伸缩。典型场景如：初创公司或新产品线快速成长，用户规模和应用部署规模在短时间内十倍百倍增长；促销、季节性、节假日带来的访问量波动，高峰时间段的突发流量等。

在这里插入图片描述

在这四个核心目标之间，存在彼此冲突的情况：

在这里插入图片描述

因此，云原生的关键目标是：云原生应用必须要在同时满足规模、成本和敏捷这三个目标的前提下，还要实现成本控制。

2.2 云原生特性

将这四个云原生核心目标拆解为多个云原生特性：

特征	规模（Scale）	可用（Available）	敏捷（Agility）	成本（Cost）
隔离性(Isolation)	✔️	✔️	✔️
模块化(Modularity)	✔️		✔️	✔️
可组合(Composable)			✔️	✔️
容器化(Containerized)	✔️		✔️	✔️
弹性(Resiliency)	✔️	✔️
可替换性(Replaceability)	✔️	✔️
自动化(Automation)	✔️	✔️	✔️	✔️
可观测性(Observability)		✔️	✔️
可测试性(Testability)		✔️	✔️
可移植性(Portability)	✔️	✔️		✔️
安全(Security)		✔️
移动性(Mobility)	✔️

云原生特性的更多具体细节，查看资料概述 | 云原生学习笔记 (skyao.io)

三、云原生应用 VS 传统单体应用

在网站What is Cloud Native? | Tanzu (vmware.com)中，Pivotal给出了云原生与传统单体应用的详细区别

CLOUD NATIVE APPLICATIONS	TRADITIONAL MONOLITHIC APPLICATIONS
Predictable. Cloud native apps conform to a framework or “contract” designed to maximize resilience through predictable behaviors. The automated, container-driven infrastructure used in cloud platforms drives the way software is written. A good example of such a “contract” is illustrated by the 12 principles first documented as the 12-factor app.	Unpredictable. Traditional applications can’t realize all of the benefits of running on a cloud native platform due to the unique way each application is architected or developed. This type of application often takes longer to build, releases improvements in big, infrequent batches, scales up instead of out, and assumes the underlying infrastructure provides high availability.
OS abstraction. A cloud native architecture gives developers a means of abstracting away underlying infrastructure dependencies. Instead of configuring, patching, and maintaining operating systems, teams focus on software. The most efficient means of abstraction is a formalized platform.	OS dependent. Traditional application architecture requires developers to build close dependencies between the application and underlying OS, hardware, storage, and backing services. These dependencies make migrating and scaling the application across new infrastructure complex and risky.
Right-sized capacity. A cloud native application platform automates infrastructure provisioning and configuration, dynamically allocating and reallocating resources at deploy time based on the needs of the application. Building on a cloud native runtime optimizes application lifecycle management, including scaling to meet demand, resource utilization, orchestration across available resources, and recovery from failures with minimum downtime.	Over-sized capacity. Traditional IT designs a dedicated, custom infrastructure solution (“snowflake”) for an application, delaying deployment of the application. The solution is often over-sized and built to satisfy worst-case capacity estimates with little ability to scale beyond design limits to meet demand.
Collaborative. Cloud native architecture facilitates DevOps, a combination of people, process, and tools that increases collaboration between development and operations teams to speed and smooth the transfer of finished application code into production.	Siloed. Traditional applications utilize an over-the-wall handoff of finished application code from developers to operations. Organizational priorities take precedence over customer value, resulting in internal conflict, slow and compromised delivery, and poor staff morale.
CI/CD. IT teams make individual software updates available for release as soon as they are ready. Organizations that release software rapidly get a tighter feedback loop and can respond more effectively to customer needs. CI/CD works best with other related approaches such as test-driven development.	Waterfall development. IT teams release software periodically, typically at intervals of weeks or months, despite the fact that many components of a release may have been ready much earlier with no dependencies. Features that customers want or need are delayed and the business misses opportunities to compete, win customers, and grow revenue.
Independent. Microservices architecture decomposes applications into small, loosely coupled, independently operating services. These services map to smaller, independent development teams and make possible frequent updates, scaling and failover/restart without impacting other services.	Dependent. Monolithic architectures bundle many disparate services into a single deployment package, causing unnecessary dependencies between services and leading to a loss of agility during development and deployment.
Automated scalability. Infrastructure automation at scale eliminates downtime due to human error, consistently applying the same set of rules across any size deployment. Cloud native also goes beyond the ad-hoc automation built on top of traditional virtualization-oriented orchestration. A fully cloud native architecture is about automating systems, not servers.	Manual scaling. Manual infrastructure includes human operators that manually create and manage server, network, and storage configurations. At scale, operators are slow to correctly diagnose issues and fail to correctly implement solutions due to the level of complexity. Hand-crafted automation recipes have the potential to hard-code human errors into the infrastructure.
Rapid recovery. The container runtime and orchestrator provides a dynamic, high-density virtualization overlay, ideally matched to the microservices architecture. Orchestration dynamically manages placement of containers across a cluster to provide elastic scaling and recovery/restart in the event of app or infrastructure failure.	Slow recovery. VMs by themselves are a slower and less efficient foundation for microservice-based applications due to slower startup/shutdown and operating system overhead for each VM.
Streamline productivity. Developer experience (DevX) assesses how well developers interact with the systems and tools necessary for cloud native application development. A positive DevX allows developers to better deliver robust, scalable apps, ship software quickly in response to changing market dynamics or customer needs, and deliver business value.	Entrenched culture. Legacy platforms are significant obstacles to developer productivity. Many businesses tend to be reactive and treat software development as a “one-off” project, even while recognizing how important developer experience is to achieving positive business objectives.