前面的文章介绍过：什么是云原生和云原生学习的一些基本方法，今天主要介绍云原生全景图以及云原生中应用定义及部署。什么是云原生

目录

1、CNCF背景

1.1 CNCF的由来

1.2 CNCF云原生全景图

2、云原生全景图构成

3、App Definition and Development 应用定义及部署

4、Database 数据库

5、Streaming & Messaging 流与消息

6、Application Definition & Image Build  应用定义和镜像构建

7、Continuous Integration & Delivery 持续集成 (CI) 和持续交付 (CD)

---

关注公众号 + 输入[面试题] + 免费领取面试资料!  Java技术300+面试题

1、CNCF背景

CNCF(全称Cloud Native Computing Foundation), 云原生计算基金会。他是Linux旗下的非盈利组织，成立于2015年，主要致力于云原生应用的推广和普及。

1.1 CNCF的由来

当年谷歌内部一直用于编排容器的Borg项目开源了，为了该项目更好的发展，谷歌与Linux基金会一起创办了CNCF。

Borg是谷歌内部的大规模集群管理系统，在谷歌内部经历数十年的打磨，应该是与谷歌三驾马车（MR,GFS,BigTable）的同时代产物，据说，Borg之前号称是Google内部和PageRanking相提并论的同等重量级的东西。后来，谷歌把Borg用Go语言重写后，更名为Kubernetes并捐赠到CNCF。

1.2 CNCF云原生全景图

传送门：https://landscape.cncf.io/?fullscreen=yes

云原生全景图是由云原生基金会提供。它的规模相当庞大, 囊括了众多的软硬件类别和如技术。云原生全景图主要由八大板块构成，后续可能在此基础上继续添加。

2、云原生全景图构成

接下来，从全景图顶层开始，至上而下逐一分析每一个层级以及每一层个模块的功能以及引入云原生的意义。

说明：由于内容较多，将内容总共划分为9小结进行讲解。（8小节概念、1小节实践）。

3、App Definition and Development 应用定义及部署

该层为云原生景观最顶层，主要作用是让程序定义和开发者专注于业务本身，使工程师能够快速构建自动的应用程序。

这一层是容器平台上运行的具体应用和工具，可以理解为容器平台的应用商店。根据应用以及使用场景不同，可以大致分为以下4种类型：

1）数据库，主要用于数据存储和检索。常见工具如 MySQL、Orcale、mongoDB、TiDB等。

2）流处理和消息队列，主要用于服务间通信交互。常见工具如Spark、Storm、Flink、RocketMQ、Kafka、RabbitMQ等。

3）应用和镜像制作，主要用于将应用封装成标准镜像，使应用能在标准的容器平台上运行。常见工具如 Helm、Docker Composer、Packer等。

4）持续集成(CI)和持续交付(CD)，在敏捷迭代的基础上，快速交付满足客户可运行产品。常见工具如 Jenkins、Bamboo。

结构图如下，

4、Database 数据库

我们知道，数据库主要为应用程序存储和检索数据提供了一个通用接口。开发人员可以使用这些标准接口和查询语言对数据进行存储、查询和检索。

该存储层目前支持两种类型的数据结构: 

1) 结构化查询语言 (SQL) 数据库

2) 非SQL 数据库。

具体使用哪种数据结构，应该由需求和约束来驱动。

引入云原生的意义

意义所在：根据工作负载优化一些节点来提高数据库性能。

随着 Kubernetes 的兴起及其支持有状态应用程序的能力，我们已经看到新一代数据库利用了容器化，各大厂目前都有结合开源工具扩展出来的基于云原生的弹性数据库。

这些新的云原生数据库，旨在将 Kubernetes 的可扩展性和可用性优势带入数据库，可根据工作负载优化一些节点来提高数据库性能。

5、Streaming & Messaging 流与消息

流和消息，主要用于在不同系统之间传输消息，以此来实现服务之间互相通信。

通过这种方式可以很好的实现系统之间高度解耦并互不影响。这种消息机制，通常存在两类消息角色：

1）消息发布者，也就是通常我们所说的生成者，主要作用是输出消息。

2）消息订阅者，者也就是通常所说的消费者，主要用于接收发布者锁传递过来的消息数据。

具体使用哪种消息角色，需要结合应用功能的业务场景。

引入云原生的意义

意义有两点：

1）提供成熟的云原生消息系统 

2）标准化消息格式

其实消息传递和流这一类工具，早在云原生概念出现之前就已经存在了。

传统系统架构中，为了集中管理关键业务事件类型的组件， 于是组织并构建了服务总线的概念。

而在云原生环境中所说的消息传递和流，通常指的是指由云提供的消息队列（RabbitMQ、Kafka）等工具。这些组件的共同点是所借助云原生优势充分发固有能力。

我们知道，云原生环境中的应用程序交互是经过编排和精心设计的。

因此，消息传递和流系统为精心设计的应用系统提供了一个信息交流的中心。而消息总线提供了一个集中统一管理的位置，所有应用程序都可以通过发布消息来告诉其他人他们在做什么，或者通过订阅消息来查看正在发生的事情。

在现有消息系统中，NATS 和 Cloudevents 已成为CNCF 孵化项目。其中，NATS 提供了成熟的消息传递系统，而Cloudevents 致力于标准化系统之间的消息格式。

6、Application Definition & Image Build  应用定义和镜像构建

应用程序定义和映像构建是一个广泛的概念，具体可以分为两个部分：

1）以开发人员为中心的工具，可帮助其将应用程序代码快速构建到容器或 Kubernetes中。

2）以标准化方式部署应用程序并集运营为一体的统一管理工具。

不论你是想加速或简化你现有的开发环境，提供一套标准化的方式来部署第三方应用程序，还是希望简化编写新的 Kubernetes 扩展的过程，这两个类别都可以作为许多项目和优化 Kubernetes 开发人员和操作人员的参考依据。

引入云原生的意义

意义所在：

1）极大地简化应用程序的构建和部署方式 。

2）借鉴现有工具来满足不同需求。

我们知道，Kubernetes和普通的容器化环境一样，都具有非常灵活和强大的特点。

然而，这种灵活性也带来了一定的复杂性，主要表现为多种配置选项以及对各种场景的多种需求会不尽相同。

开发人员在容器化代码时，有时可能需要创建多套镜像。比如，运营商需要的是一种标准化的方式将应用程序部署到容器环境中，平台团队需要提供工具来简化内部和第三方应用程序的镜像创建和应用程序部署。

如果在开发云原生应用程序遇到需要大量不同的工具来简化应用程序的构建和部署。那么你可以请寻找此类别中的工具作为参考和借鉴。

7、Continuous Integration & Delivery 持续集成 (CI) 和持续交付 (CD)

我们知道，持续集成 (CI) 和持续交付 (CD) 工具可通过嵌入式来实现快速高效的开发。

其中，CI 通过立即构建和测试代码来自动化代码更改，确保它产生可部署的工件。而CD是对持续集成的延伸，经过开发环境、测试环境、准生产环境里的持续验证，满足了客户需求和质量目标，成为可交付给客户的产品。

引入云原生的意义

大致有两点：

1）更早的发现错误并且更容易排除故障。

2）快速交付用户可使用的产品，节约开发成本，早日投入市场，从而提升企业竞争力。

通过定期集成代码，可以及早发现错误并且更容易排除故障。毕竟，在几行代码中发现错误要比在几百行代码中发现错误容易得多。

另外，Kubernetes 还提供有关应用程序运行状况的信息，使云原生 CI/CD 工具能够更轻松地确定给定更改是否成功或应该回滚。

虽然 Kubernetes 等工具为运行和管理应用程序提供了极大的灵活性，但它们也为 CI/CD 工具带来了新的挑战和机遇。

云原生 CI/CD 系统能够利用 Kubernetes 本身来构建、运行和管理 CI/CD 流程，通常称为管道。

管道举例：假设开发人员更改了应用程序的某些代码。这时CI 系统会看到代码更改，然后构建并测试该应用程序的新版本。而CD 系统采则用该新版本并将其部署到开发、测试、准生产和最终生产环境中，它会在流程的每个步骤之后测试已部署的应用程序时执行此操作。所有这些系统共同代表了该应用程序的 CI/CD 管道。

CI 工具可确保开发人员引入的任何代码更改或更新都自动且持续地构建、验证并与其他更改集成。每次开发人员添加更新时，都会触发自动化测试，以确保只有好的代码才能进入系统。

那么CD相当于扩展了CI流程，包括将 CI 过程的结果推送到准生产环境和生产环境中。

总结：本节内容介绍了云原生全景图以及它的庞大规模。我们从中也看到了其囊括了如此众多的类别和技术，要完成如此规模的工程，其复杂性也可想而知。那在架构设计和应用部署中，固然也会区别于我们传统的本地化方式。如何充分发挥云原生能力是需要我们不断深入思考的内容。

下一节：云原生的编排及管理。