云原生并不是一个新的概念，但因其在数字化转型中发挥着越来越重要的作用，又被推上了“风口浪尖”。

云原生是英文Cloud Native的直译。这意味着云原生应用是从云上生长出来，而不是布置在云上，更非依赖于数据中心。如果将云原生理解为基于云环境、专门为云特性而设计，未免偏颇。用英文表示是“IN CLOUD”，而不是“ON CLOUD”。尽管上云是第一步，云原生也只是云计算的一部分，但它已显示出最能发挥云计算平台的弹性与分布式布置的优势，并将云计算能力发挥到极致。

如果要追溯云原生的源头，从时间轴上，可以回到2006年，亚马逊正式推出弹性计算云服务EC2那个时候。但是云原生的概念则出现在2013年。这一年，Pivotal公司的Matt Stine首次将云原生定义为一系列云计算技术和开发管理方法的合集，包括DevOps、持续交付、微服务、敏捷基础设施和12要素等。似乎只要软件“上云”，或者说专门为“云”设计的软件应用，都可以称之为云原生应用。

从已取得的成果来看，对于企业，云原生释放出巨大的生产能力，在降本增效的同时，轻松承载几何量级的业务量与数据流；对于用户，即使在“双11”这样的流量请求高峰，已感觉不到延迟，或者出现所抢购物品不能及时呈现的情况。当然，大型视频直播、3D游戏的体验也更为顺畅，体验感提升。伴随着云原生的成长，不论是企业，还是用户，在数字化与智能化上所获得的成果都超出预期。

从企业数字化的升级过程中，可以更清楚地看到云原生在云计算中成长的过程。

企业数字化最早经历的是服务器阶段，之后是上云阶段，或者称为云化阶段。云上应用的数量迅速增加，导致企业的人力运维能力极为不足，形象的说法是人肉堆砌已经不能解决问题。云原生由此自然进化而来，云原生1.0开始，即云原生的最初阶段。所要解决的是企业数字化转型升级过程中，传统应用单体架构厚重、烟囱式架构等应用无法高效率成长的问题。

那么，上云出现的问题，当然要在云上解决。而云计算的内生业务能力，就是云原生，由此生于云、长于云、用于云、信于云的云原生进入2.0。生于云是指云原生技术、架构和服务都是企业应用的扩展；长于云是指企业应用和业务发展的成长性，推动企业数字化建设、业务智能升级；用于云是指所有的业务都以服务为核心，持续专注于解决企业应用升级中的问题；信于云是指云上运行值得信赖，安全可信。

概括而言，就是“资源高效、应用敏捷、业务智能、安全可信”。

具体而言，资源高效的实现，是由多元算力满足不同应用场景的个性化算力需求；由多云治理和边云协同，构建高效率、高可靠的分布式泛在计算平台，并构建包括容器、裸机、虚机、函数等多形态统一的计算资源能力；以“应用”为中心构建随时可调用的资源调度和管理平台，形成企业决策部署透明、感知应用智能、灵活可控的应用能力。

应用敏捷主要体现在应用迭代的速度日渐加快，关键在于开发与运维融为一体，即所谓“立而不破”，新旧业务平滑过渡、无缝对接，任何一次升级都不会影响到原有业务。这是通过 DevSecOps 应用开发模式实现的。

业务智能已经进入良性提升通道，企业的数据管理与应用能力，因为数据的资产化和数据的价值化，得以迅速放大，数据和AI技术的结合不断赋能企业应用扩展，就如植物得到所有的适宜条件而自然生长，不再需要一次次人为干预决策，智能升级是完全智能化的，新的应用技术同样内生出来。

安全可信度的提高，依赖于云原生的内生能力。安全服务和安全合规能力也是自带的，“外来物种”的入侵是被屏蔽掉的，应用在云上安全构建，业务在云上安全运行。

以上四点与云计算资源池化、弹性伸缩、安全可靠的特性一脉相承。

传统IT架构是按照业务领域划分，如开发、IT运营和质量保障等部门是各自独立的，开发与运营之间虽然进行着合作与沟通，但其间的信息“鸿沟”是存在的。即使是提供应用支撑的软件企业，也是如此运作的。难以快速响应用户需求，甚至人为拖延产品迭代周期，敏捷开发就是要解决这个问题，并将开发与运维完全打通，真正形成以用户为中心的新业务结构。在此基础上，为解决开发和运维“信息对称”的问题，DevOps应运而生。DevOps集开发、技术运营和质量保障为一体，从而提高开发效率，并缩短迭代周期，最终实现“持续交付”。所谓“持续交付”，不再是一套解决方案包打天下，仅做售后运维，而是确保持续更新，随时可以发布新版本。

云原生使得新基础设施之一的云计算硬件平等特性能很好发挥出来，不论是向下管理的各种异构硬件，还是向上屏蔽底层硬件，都是以应用为中心，而真正消弭了硬件差异性，或者说可以不考虑硬件的不同，无需针对特定硬件部署相应软件程序。如传统高性能计算(HPC)专用网络硬件成本高昂、组网规模不可扩展、技术演进缓慢，所导致的应用普及化难题，其高性能网络通讯协议被云原生拓展应用到云视频、金融交易等更广泛的领域之后，就得以解决，类似专有设备变为多用途的基础设备，尤其是云原生推动的应用爆炸式增长，设备的价格虽然不变，但被多应用快速摊薄。即应用的拓展速度，使得硬件的价格壁垒轰然坍塌。以容器为例，原在私有云、公有云和混合云上的核心应用，完全可以跨云应用，对于云服务商，业务部署能力增强，对于客户，业务连续性、降本增效等需求得以畅快满足。不仅如此，边缘计算技术将越来越多的应用在边缘侧设备实现，数据传输容量扩大、时延降低，减少了业务损耗。云原生又适时生长出泛在计算。

同时，云原生应用数量的快速增加，其对应用服务的流量治理、运行监控、访问安全以及发布等能力的诉求不断提升，管控微服务模式无以为继，应时蝶变为非侵入式微服务模式，应用是开放与开源的，随时提供解决方案，客户需求不再可能被置之不理。

云原生应用本身已具备云计算基因，许多应用特性具有重合性，如网络访问、远端部署、可扩展弹性、共享、自主服务、高可用、持续交付等。

这些应用是以微服务架构、容器、DevOps等关键技术为支撑的。

弹性是云计算的重要特征，理论上不受资源限制，可以无限占用和使用资源（当然需要按使用量付费）。实际上，弹性也应该是一切智能软硬件的特性，如容器的重要特性之一也是弹性。对于云原生，其弹性主要是指弹性使用资源和服务实例弹性扩展能力，所要解决的是单实例扩展资源达到瓶颈时，配合负载均衡机制实现弹性扩展。

云原生的这一特性，使得只有强力企业才可以解决弹性问题的专利，成为所有企业都可以获得弹性能力的普惠选项。

云计算的IaaS、PaaS、SaaS，可视为分三种类型。与之对应，就涉及三个层级的共享，即资源共享、平台共享、与应用共享。

云原生应用作为SaaS层服务，部署于IaaS或PaaS层。共享体现在一份基准代码，可以实现多份部署，这是应用开发的共享，而不是云应用意义上的共享。云应用是可以对所有人开放的，并共享云应用服务。

云应用部署与位置无关，或者说云应用部署没有确定位置，是随机的，但底层则是透明的。所以云原生应用的配置文件、后端服务等是和应用共生的，是一体的两面，完全具备自管理自治理能力。

微服务设计架构同样遵循自治原则。因此，微服务总是与云原生相伴生。这和云的分布式中心特性高度相关。好处是自成一体，自我管理，就像独立个体的人，必备自我管理能力。

云应用的构建可以在本地或者云端，但运行一定是在云端。这样就要按照一定的标准交付，为的是在云端的任何位置部署支持标准，不用考虑是什么环境。

容器就是这样被打造的标准运行工具，在容器内所有的应用都以标准化镜像的方式交付并运行。但容器本身又可以在任何地方运行，只提交镜像发布就可以满足业务需求频繁变动、快速迭代、随时发布的需求。

弹性、共享、自治等应用特性保证了高可用。容器可以满足敏捷启停、多实例布置等高可用性，但并不能保证所有应用的全天候稳定。如果需要稳定的高可用性，是否选择容器，就需要进行新的平衡，或者做出其他选择。

可监控性

这主要是指可监控审计。用户可以通过日志或者接口实时获取应用运行状态，以及应用访问调用数据等，作为计量计费、监控和后期审计等的依据。

用户可以根据自己的需求，通过网络访问，自助使用服务，不需要云应用管理人员授予权限。因为云应用服务目录简单明了，并附有使用说明，用户只需找到能满足自身需求的应用即可。即使不能满足，也可以随时提出需求，获得解决办法。

云应用往往依赖于配置中心，实现不同环境应用的部署运行。比如，开发、测试和生产环境，一些参数的配置往往是不一样的。因此，不可能把所有配置文件同应用一起打包，就要由配置中心来统一管理。这样，还有一个好处，可以实现运行时的参数更新。

前面提到敏捷开发可以打通开发与运维。实际上，敏捷更大程度上和轻量、微服务组件化相关，就如个体的人，小了轻了，自然轻巧敏捷。从这个角度说，云原生的敏捷特性只是一个方面，高度相关于整体架构，如技术架构、组织架构等。所以说，敏捷可以在流程、管理或体验中被感觉到。

敏捷甚至被视为基础设施，由Kubernetes驱动。Kubernetes可以很方便地拉取一套基础设施，满足用户开发，测试、发布等需求。

云原生具体应用是由微服务、容器、DevOps、服务网络、不可变基础、声明式API等关键技术所构建。

容器被认为是云原生应用的基石，微服务容器化被作为云原生应用的第一步。

云原生代码、依赖项等在运行时被打包到容器镜像文件中。镜像存储在镜像仓库。需要时，则将镜像转换为可运行的容器实例。该实例可在装有容器引擎的任何计算机上运行，并可以按需部署任意数量的容器实例。每个容器虽然可以共享基础主机操作系统，内存和处理器的一部分，但彼此隔离。容器的移植性保证了跨云应用的一致性。由此，微服务隔离并打包自己的依赖项、更改项，从而不影响整个系统，开发与发布可以随时进行。

因为共享底层操作系统和主机资源，容器所占用空间大大小于虚拟机，在一台主机上可以同时运行多个微服务。

有了容器之后，还需要对容器进行管理，这就是容器编排。目前，通行的容器编排调度器是Kubernetes，简称K8s。

业务架构的变化和演进，是和业务越来越复杂一同改变的。演进或变化的目的基本上都是为了突破业务痛点，上一代系统架构被新的一代所代替。

第一代单体架构把所有业务相关联的组件、库全部打包成一个执行程序。虽然满足了业务相互调用的需求，但却增加了系统复杂度，导致系统维护成本过高，局部修改可能影响全局。更为困难的是，系统的封闭性，导致即使内部组件也不能共享，更不用说产品能力的共享，结果是开发效率低下，迭代速度被掣肘。

第二代面向服务架构的SOA（Service Oriented Architecture）是一种设计方法，其中包含多个服务，且服务之间通过相互依赖，可提供一系列解决功能。一个服务通常以独立的形式存在，各个服务之间可以通过网络调用。

第三代微服务架构是对SOA的升级，业务需求被组件化和服务化，原有的单个业务系统被拆分为多个独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成，既可以单独调用，也可以多个并用，企业可以根据业务的不同或业务阶段的不同，进行合理引入与灵活调用。

服务与服务之间通过高内聚低耦合的方式交互。

服务网络（Service Mesh）被称为微服务2.0，解决了服务之间的通信，并解决了微服务1.0的技术门槛高、多语言支持不足、代码侵入性强等问题。

在Service Mesh架构中，非业务功能下层到Sidecar，用户只需要关联业务逻辑，而不用关联服务治理等非业务功能。

DevOps不是Dev（开发人员）与Ops（运维人员）的简单相加，而是两者的全新组合。

DevOps强调的是如何通过自动化的工具协作和沟通来完成软件的生命周期（开发、测试、运维）管理，从而更快速、更频密地交付更稳定的软件。

无服务架构由Serverless直译而来，但Serverless并不意味着没有服务器去运行代码，只是不再需要管理服务器，只专注代码，其余部分工作交由提供者处理。

对于开发者来说，Serverless架构可以将服务器端应用程序分解成多个，执行不同任务。

使用Serverless架构可以免除所有运维操作，开发人员可以更加专注于核心业务的开发，实现快速上线和迭代。

这里所说的“不可变”类似于程序设计中的“不可变”定义，即不可变变量完成赋值后就不能更改，只能创建新的进行整体替换。这也是快速迭代的设计之一。对于云原生来说，最基本的要求是服务器在完成部署后，就不再进行更改。这是因为，不仅基础设施的初始化及配置成本高昂，而且系统升级、配置修改以及补丁等会产生不可预估的副作用。可变基础设施还会导致在灾难发生时，难以重新构建服务；在服务运行过程中，持续的修改往往产生并发风险。而不可变基础设施可提升发布效率，方便快速扩展。

声明式API是与命令式API截然不同的一种编程方式。命令式 API可以直接向服务器发出执行命令：我要做什么，而声明式 API更像是一个指导，明示要执行什么操作：你要做什么。声明式API容许系统不断调整实际状态，直到与期望状态相一致。

云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。


编辑：薛姣