云原生似乎是一个显而易见的概念，与之相关的文章也层出不穷。

在我的工作中，目前负责云原生服务管理平台的研发（主要管理各种云原生基础设施、平台服务、第三方托管应用），但尽管云原生很难解释清楚对其他人来说很简洁，但我经常问自己，云原生到底是什么，我在做什么？

云原生究竟是什么

云原生是一个复合词，叫做云原生。

Pivotal（已被VMware收购）官网文章《什么是云原生？[1]》解释说，云原生是一种构建和运行应用程序的方式，涵盖了DevOps、持续交付、微服务和容器等概念。据说是整合的。内部的。

云原生计算基金会（CNCF）在cncf/toc[2]中提供了Cloud Native V1.0的定义。

云原生技术帮助组织在新的动态环境（例如公共云、私有云和混合云）中构建和运行可弹性扩展的应用程序。典型的云原生技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

这些技术能够构建容错、易于管理且易于观察的松散耦合系统。通过将云原生技术与可靠的自动化相结合，工程师可以轻松地对其系统进行频繁、可预测且重大的更改。

云原生计算基金会(CNCF) 致力于培育和维护供应商中立的开源生态系统，以推进云原生技术。我们通过尖端模型的民主化向大众提供这些创新。

结合官方的定义，我个人对云原生的简单理解是：云原生不是一项特定的技术，而是快速构建和运行应用程序的想法的集合，包括技术系统（容器、服务网格、微服务、不可变基础设施、声明式API）以及应用程序开发管理点（DevOps、持续交付，康威定律[3]）。遵循这个概念的应用程序可以称为云原生应用程序。

云原生技术体系

整个云原生技术体系其实是息息相关的，是从软件架构的逐步演进开始的。

所以，单体-微服务-基于k8s的微服务-服务网格

在单体架构中，所有功能都集成到一个项目中，使得在项目开发的早期阶段更容易测试和部署，即使需要对应用程序进行大规模更改也是如此。一旦您的实例开始运行，负载均衡器就可以轻松完成其工作。

随着时间的推移，成功的应用程序不可避免地会变得越来越臃肿，导致代码库相应变大，团队管理成本也不断增加。这就是通常所说的“整体地狱”。面对单体地狱，开发者很难理解所有代码，减慢了开发速度，延长了部署周期，而且横向扩展也带来了挑战。作为单个应用程序，它必须满足这些要求。

既然有问题，当然就有解决问题的办法。解决方案是微服务架构，一种云原生技术体系。单个应用程序将所有功能整合到一个项目中进行编译和部署，因此每个功能可以组合在一起（通常基于业务功能）或子域（子域围绕DDD 组织服务），并且每个拆分模块独立部署，如下所示：另一个服务（服务通常通过REST+JSON 或gRPC+ProtoBuf 进行通信）如果这些服务能够共同为整个应用程序提供功能，那不是很好吗？

然而，微服务并不是灵丹妙药。分布式系统要求开发者拥有各种独立于业务的基础设施级别，例如配置中心、服务发现、网关、负载均衡等。在业务层面上自己实现它。

例如，典型的微服务架构解决方案（图片来源Phoenix Architecture [4]）需要开发人员自行部署各种组件：

项目开发完成后，就该进入部署流程了。传统的早期方法是将应用程序直接部署到服务器上。然而，即使安装了新的应用程序，服务器的系统变量也会继续更改。与其他应用程序的冲突可能会导致问题，而且应用程序本身也必须随着用户系统环境的变化而改变。为了解决这个问题，喊出了不可变基础设施的口号。第一步是将服务部署为虚拟机，然后将打包为虚拟机映像的服务部署到生产环境。但我们都知道虚拟机太大了。为了减少开销，第二阶段将服务部署为容器，并将服务打包为容器镜像部署到生产环境。

不可变的基础设施：基础设施实例一旦创建，它就是只读的。如果您需要变更或升级，您必须将旧实例更换为新实例。容器镜像是不可变基础设施的具体实现。

容器现在是微服务的绝佳合作伙伴，其中服务实例是隔离的，资源可以轻松控制。因此，容器编排工具正在回归，并且基本上统一了容器。在编排市场，实现容器集群的自动部署、扩缩容、维护等功能。然而，Kubernetes 并不局限于容器编排。上述微服务架构要求开发人员解决一系列与基础设施层面无关的问题。这样，Kubernetes现在就可以解决大部分问题了。图中（图片来源Phoenix Architecture [5]）：

Kubernetes 的编码方式实际上是一种声明式API（这意味着您向工具描述想要实现的目标状态；然后该工具在内部计算如何使事物达到目标状态）。

到目前为止，我们已经讨论了云原生技术系统中的四种类型的容器：服务网格、微服务、不可变基础设施和声明式API。只剩下一个服务网格。吸一口气然后继续。

事实上，你会发现增量开发强调业务和基础设施的分离，让开发者可以快速开发自己的业务，而无需担心底层基础设施。 Service Grid 也希望如此，并希望将更多与业务无关的功能集成到其基础设施中，即微服务2.0。

服务网格的核心是将客户端SDK 分离出来，并将其作为代理组件作为单独的进程运行。每个服务还部署此代理组件，通过该组件处理和转发所有传出和传入流量。该组件称为sidecar。

Sidecar只负责网络通信。我们还需要一个组件来统一管理所有sidecar的配置。在服务网格中，负责配置管理的部分称为控制平面，负责网络通信的部分称为数据平面。数据平面和控制平面共同构成了服务网格的基本架构。

我听说他们将更进一步，实现无服务器化。

云原生管理要点

DevOps（为开发和运营而创造）是一组流程、方法和系统的总称。与部门整合。 ——百度百科

DevOps 的两个核心概念是CI（持续集成）和CD（持续交付/部署）。

本文不涉及DevOps，但我们建议您查看Microsoft 的本教程[6]。

结尾

感谢您阅读本文。本文介绍了云原生的概念及其技术体系之间的关系。但是，如果您发现一些错误，请点击下面告诉我们。