1.1　云原生应用概述

最早提出“云原生”概念的是Pivotal公司的Matt Stine。他在2013年首次提出云原生的概念，在2015年出版的Migrating to Cloud-Native Application Architectures（《迁移到云原生应用架构》）一书中定义了云原生应用架构的一些特征，包括12要素应用、微服务、使用API协作等。

CNCF（云原生计算基金会）在2019年给出云原生v1.0的定义：云原生技术使组织能够在现代化和动态的环境下（如公共云、私有云和混合云）构建和运行可扩展的应用程序。云原生典型的技术包括容器、服务网格、微服务、不可变基础设施和声明性API等。

不同机构给出的云原生定义不尽相同，但都体现了在云中开发、部署和运维应用的核心要点。这类“向云而生”的应用，整个生命周期都在云端，通常被称为“云原生应用”（Cloud Native Applications）。云原生技术是现代化应用的基石，云原生应用的涌现能帮助企业进行数字化转型和升级。如上所述，云原生应用的强势崛起，是由用户新生的需求和主流计算基础设施共同驱动的。

云原生引入了不少新的概念和思维方式，也影响了应用所采用的实现技术。归纳来说，云原生应用主要采用的技术有虚拟化、容器、微服务架构、服务网格等，开发流程采用持续集成和交付及DevOps开发运维一体化的理念。为了便于读者理解，下面对这些技术进行简单介绍。

1.虚拟化

云计算的本质是池化资源的共享和交付。因为虚拟化技术可以使硬件资源池化和隔离，并能够通过软件实现自动化的资源供给和回收，所以虚拟化技术成为云计算服务不可或缺的“底座”。绝大多数云服务平台都是基于虚拟化技术实现的。

2.容器

容器是云原生应用的基础性技术，实质上是面向应用的封装和交付方式，具有轻量、可移植性和不可改变性等特点。软件生命周期中的开发、测试、部署、运维等不同阶段的交付成果都使用相同的容器标准，将大大缩短迭代的周期，使从源代码到构建再到运维构成一个完整的过程。

3.微服务架构

在互联网时代到来之前，应用的主要架构为单体（monolithic）模式。每个应用都是大而全的实例，包含了界面展现、业务逻辑和数据服务等所有功能。单体架构的不足之处较明显：业务逻辑紧耦合，新功能的开发测试涉及诸多模块，发布周期长，扩展应用时不灵活。

为满足应用快速迭代及运行中的弹性伸缩等需求，微服务架构逐渐兴起，它把应用拆分为一组独立的小型服务，每个服务只实现单一的功能，运行自己的进程并采用轻量级机制（如HTTP API）进行相互通信。这些服务围绕业务功能构建，并且可以单独部署和扩展，如图1-1所示。

图1-1

云原生应用产生的初衷是应对市场不断改变的需求和用户规模的急剧扩大，微服务架构能够较好地应对这些挑战，因此，微服务架构成为云原生应用首选的构建方式。在实现微服务架构时，因为每个微服务的独立性，用轻量级容器封装单个微服务成为非常自然的选择，每个容器实例都对应一个微服务实例。微服务的扩展也相对简单，一般只需启动多个封装该服务的容器实例即可。因此，容器成为微服务架构落地的主要方式。

4.服务网格

云原生应用中微服务实例的数量可能很惊人，从数十到成百上千，相互之间有着复杂的依赖或调用关系，这给开发和运维管理带来了新的难题。为此，一种新的服务网络基础架构渐渐形成，叫作“服务网格”（Service Mesh），专门负责处理微服务之间通信相关的问题，如服务发现、负载均衡、监控追踪、认证授权和数据加密等。服务网格可以用边车（sidecar）容器的形式一对一地附着在微服务的容器上，形成网络的代理层与其他微服务容器交互（见图1-2）。服务网格的出现，不仅令开发人员专注于业务逻辑而无须为每个服务重复编写通信功能，也使运维人员更容易地监测和排查应用故障，服务网格也因此成为微服务架构中的重要实现方式。

图1-2

5.持续集成和持续交付

持续集成允许开发团队高频率地合并新代码到代码库中，并通过测试保证代码的正确性。持续交付确保代码始终处于可部署状态，开发团队对代码的所有更改随时都可以部署到生产环境下。持续集成和持续交付是使应用快速迭代、平稳上线的重要自动化流程，是云原生应用迅速响应需求变化必备的技术手段，也是DevOps理念主要的实现方法。通过容器镜像可以确立流水线上各个阶段的交付标准，促进高度自动化的持续集成和持续交付流程。

从上面的介绍可以看到，容器在实现微服务架构、服务网关、持续集成和持续交付等方面都发挥着重要的作用，成为云原生领域的支撑性技术。后续章节将深入介绍容器的特性。