快速了解云原生架构

阿里云云栖号

于 2021-02-01 11:09:23 发布

阅读量2.8k

点赞数

分类专栏：云栖号技术分享

本文链接：https://blog.csdn.net/yunqiinsight/article/details/113501651

版权

简介： 云原生架构本质上也是一种软件架构，最大的特点是在云环境下运行，也算是微服务的一种延伸。

起源

1. 云原生（Cloud Native）的由来

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

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

2. CNCF 基金会成立及云原生概念的演化

2015 年由 Linux 基金会发起了一个 The Cloud Native Computing Foundation（CNCF）基金组织，CNCF基金会的成立标志着云原生正式进入高速发展轨道，Google、Cisco、Docker 各大厂纷纷加入，并逐步构建出围绕 Cloud Native 的具体工具，而云原生这个的概念也逐渐变得更具体化。因此，CNCF 基金最初对云原生定义是也是深窄的，当时把云原生定位为容器化封装+自动化管理+面向微服务：

The CNCF defines “cloud-native” a little more narrowly, to mean using open source software stack to be containerized, where each part of the app is packaged in its own container, dynamically orchestrated so each part is actively scheduled and managed to optimize resource utilization, and microservices-oriented to increase the overall agility and maintainability of applications.

这主要因为 CNCF 基金会在当时的核心拳头软件就是 K8s，因此在概念定义上主要是围绕着容器编排建立起来的生态。其实这也是为什么我们可以看到 CNCF 定义云原生的时候有时感觉就是再说容器生态。

到了 2017 年, 云原生应用提出者之一的 Pivotal 在其官网上将云原生的定义概括为 DevOps、持续交付、微服务、容器四大特征，这也成了很多人对 Cloud Native 的基础印象。

而到 2018 年，随着 Service Mesh 的加入，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 在当前定义基础上加上了服务网格 (service mesh) 和声明式 API，这为云原生的概念阐述增加了更深一层的意义，也就是建立一个相对中立的开源云生态。这对云原生的生态定位是很重要的，也算 CNCF 最初成立的宗旨之一，打破云巨头的垄断。

解读：概念随着新的技术发展而演化

第一阶段：容器化封装+自动化管理+面向微服务
第二阶段：DevOps、持续交付、微服务、容器
第三阶段：DevOps、持续交付、容器、服务网格、微服务、声明式API

3. 对云原生的解构

对一个词的解读，除了看其历史发展背景，还有一种偏向于语言学的方法解读，也就是我们常说的从“字面意思”来理解。

Cloud Native，从词面上拆解其实就是 Cloud 和 Native，也就是云计算和土著的意思——云计算上的原生居民，即天生具备云计算的亲和力。

首先从 Cloud 来理解，云可以看作是一种提供稳定计算存储资源的对象。为了实现这一点，云提供了像虚拟化、弹性扩展、高可用、高容错性、自恢复等基本属性，这是云原生作为一种云计算所具备的第一层含义。第二层要从 Native 来看，云原生和在云上跑的传统应用不同。一些基于公有云搭建的应用是基于传统的 SOA 架构来搭建的，然后再移植到云上去运行，那么这些应用和云的整合非常低。

为什么低呢？云作为一种分布式架构，其“土著居民”也应该是基于分布式架构设计出来的，而微服务或 Serverless 这种将服务或函数拆分成一个个模块的松耦合系统，天然具备分布式设计的属性。这是 Native 的第一种表现。

其次云作为一种 PaaS 服务，这位“土著居民”从出生(设计)到成长(开发)，再到生活(部署)都应该是基于云的理念来实现的，那么就需要一套自动化的开发流程 CI/CD 来实现。这是 Native 的第二种表现。

而最后“土著居民”的特点希望做到能够适应所有云端，都能做到无缝的运行和连接。

解读：前面三节都是来自《什么是云原生？聊聊云原生的今生》这篇文章中。