来源：大数据DT

导读：随着公有云和私有云的广泛部署，云计算基础设施成为企业部署新业务的首选。可以说，云计算已进入下半场，各大云计算服务商的厮杀日益激烈，新的概念也层出不穷。

近年来，云原生计算（Cloud Native Computing）越来越多地出现在人们的视野中，可以说云原生是云计算时代的下半场，或许我们可以称之为云计算2.0。云原生的出现是云计算不断与具体业务场景融合，与开发运营一体化碰撞的结果，是一场由业务驱动的对云端基础设施、编排体系的重构。

00 云原生是什么？

近年来，云计算模式逐渐被业界认可和接受。在国内，包括政府、金融、通信、能源在内的众多领域的大型机构和企业，以及中小企业，均对其托管业务的基础设施进行了不同程度的云化。

但它们大多数利用开源或商业的IaaS系统构建云计算平台，只是简单地将传统物理主机、平台或应用转为虚拟化形态。这种方式所带来的好处是整体资源的利用更加合理，且集约式的运营会降低成本，提升整体运营效率和成熟度。但总体而言，这样的上云实践只是“形”上的改变，还远没有达到“神”上的变化。

在云计算的下半场，应该充分利用云计算弹性、敏捷、资源池和服务化等特性，解决业务在开发、运行整个生命周期中遇到的问题。毕竟，业务中出现的问题才是真正的问题。

比如，传统应用有升级缓慢、架构臃肿、无法快速迭代等问题，于是云原生的概念应运而生。笔者认为云原生就是云计算的下半场，谁赢得云原生的赛道，谁才真正赢得了云计算。

谈到云原生，不能不提始终推动云原生发展的CNCF（Cloud Native Computing Foundation，云原生计算基金会）。CNCF是一个孵化、运营云原生生态的中立组织。截止到2020年，CNCF共有371个开源项目、1402个项目和组织，可以说是一个覆盖面相当广的云计算组织。

CNCF对云原生的见解是：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统做出频繁和可预测的重大变更。

云原生提倡应用的敏捷、可靠、高弹性、易扩展以及持续更新 。在云原生应用和服务平台的构建过程中，近年兴起的容器技术凭借其高弹性、敏捷的特性以及活跃、强大的社区支持，成为云原生等应用场景下的重要支撑技术。无服务、服务网格等服务新型部署形态也在改变云端应用的设计、开发和运行，从而重构云上业务模式。

不同于以虚拟化为基础的传统云计算系统，云原生系统一般有如下特征。

01 轻、快、不变的基础设施

在云原生环境中，支撑基础设施通常是容器技术。容器生命周期极短，大部分是以秒或分钟为单位，占用的资源也比虚拟化小得多，所以容器的最大特点就是轻和快。

而正是因为容器有轻和快的特点，在实践中通常不会在容器中安装或更新应用，而是更新更为持久化的镜像，通过编排系统下载新镜像并启动相应的容器，并将旧的容器删除。这种只更新镜像而不改变容器运行时的模式称为不变的基础设施（immutable infrastructure）。从不变的基础设施就能看出，云原生的运营与传统虚拟机运营方式截然不同。

02 弹性服务编排

云原生的焦点是业务，而非基础设施，而业务的最核心之处是业务管理和控制，如服务暴露、负载均衡、应用更新、应用扩容、灰度发布等。服务编排（orchestration） 提供了分布式的计算、存储和网络资源管理功能，可以按需、弹性地控制服务的位置、容量、版本，监控并保证业务的可访问性。

服务编排对应用层隐藏了底层基础设施的细节，但又提供了强大的业务支撑能力，以及让业务正常运行的容错、扩容、升级的能力，使开发者可以聚焦业务本身的逻辑。

03 开发运营一体化

开发运营一体化（DevOps） 是一组将软件开发和IT运营相结合的实践，目标在于缩短软件开发周期，并提供高质量软件的持续交付。虽然DevOps不等同于敏捷开发，但它是敏捷开发的有益补充，很多DevOps的开发理念（如自动化构建和测试、持续集成和持续交付等）来自敏捷开发。

与敏捷开发不同的是，DevOps更多的是在消除开发和运营侧的隔阂，聚焦于加速软件部署。

当前，很多云原生应用的业务逻辑需要及时调整，功能需要快速丰富和完善，云端软件快速迭代，云应用开发后需要快速交付部署，因而开发运营一体化深深地融入云原生应用整个生命周期中。

04 微服务架构

传统Web应用通常为单体应用系统，如使用WebSphere、WebLogic或.Net Framework等，从前端到中间件再到后端，各个组件一般集中式地部署在服务器上。

后来随着Web Service标准的推出，应用以标准的服务交付，应用间通过远程服务调用（RPC）进行交互，形成了面向服务的架构（Service-Oriented Architecture，SOA），极大提升了应用组件的标准化程度和系统集成效率。

在云原生应用设计中，应用体量更小，因而传统单体应用的功能被拆解成大量独立、细粒度的服务。

微服务架构使得每个服务聚焦在自己的功能上，做到小而精，然后通过应用编排组装，进而实现等价于传统单体应用的复杂功能。其优点是后续业务修改时可复用现有的微服务，而不需要关心其内部实现，可最大限度地减少重构开销。

05 无服务模型

无服务（Serverless） 是一种基于代码和计算任务执行的云计算抽象模型，与之相对的是基于服务器（虚拟机、容器）的计算模式。

无服务在公有云和私有云上都有相应的服务，如AWS Lambda、阿里云的函数计算、Kubernetes的Kubeless、Apache OpenWhisk等。无服务聚焦在函数计算，隐藏了底层复杂的实现方式，使开发者能够聚焦于业务本身。

小结

总体而言，云原生真正以云的模式管理和部署资源，用户看到的将不是一个个IT系统/虚拟主机，而是一个个业务单元，开发者只需要聚焦于业务本身。可以说微服务的设计、无服务的功能是云原生理念的核心体现，而容器、编排、服务网格均是实现云原生的支撑技术。

云原生架构是基于云原生技术的架构设计模式，阿里云发布的《云原生架构白皮书》中对云原生架构的定义：从技术的角度，云原生架构是基于云原生技术的一组架构原则和设计模式的集合。云原生架构使用云的产品以及云原生技术构建的IT架构，从而让开发者聚焦于业务，而不是底层技术。云原生能够帮助我们实现业务应用与基础设施解耦，云原生架构被看作新一代云计算的操作系统。云原生架构如下图所示：

 云原生架构在企业IT架构中应用主要在以下几个方面：

•业务导向、突出服务：基于业务架构与应用架构，并将业务服务和应用服务作为载体。

•顶层设计、迭代推进：微服务以整体的企业架构为指导，根据总体规划进行整体实施路线分解和迭代。

•技术前瞻、实用为本：要注重技术的先进性，同时关注业务和应用才是核心，服务是载体。

•开发运维、合二为一：开发和运维要一体化，并且包括测试交付、质量度量等，需要整体协调企业的微服务开发体系。

•基础抽象、共享下沉：在基础共享层上建立微服务的层次和等级，将共享服务作为其他业务调用的基石。

•组织适配、架构升级：在云原生应用上取得成功，依靠企业建立全面的视角，除了架构和基础设施决策，还有组织和过程决策。

云原生架构对企业架构具有重要的作用，我们从IT架构角度，来看看云原生架构的一些特点：

1.围绕资源，建立数据链接

云原生是围绕资源展开的，井通过资源相关的配置，进行对应的动作触发。云原生在资源内部通过编排来处理复杂的逻辑，并通过事件进行驱动。而事件流本身体现于日志，根据日志和相关的配置，以及依赖编排进行控制和驱动，从而建立可观测、可控制、可记录、可驱动的以资源为中心的管控体系。同时，云原生通过数据建立业务和应用的连接，并通过分布式管理来进行驱动，比如Kubernetes集群的中心化管理或者统一的配置中心管理等。

2.云原生管控面向终态，资源组合编排

云原生内部的管控是面向终态的，有明确的生命周期控制逻辑，将事件交给系统来管理。面向终态是Kubernetes的核心理念，也是云原生自动化运维的生命周期管理的体现，比如Pod应用、产品、解决方案等资源的运维。编排内部资源实现闭环调度，通过通用的声明式策略和配置赋能进行管理（监控、伸缩、可用性、路由等）。对于容器自闭环的编排管理，产生了 Kubernetes,对系统中的容器进行健康检查、自动扩容和缩容、自动重启、滚动发布等过程的编排。

3.思考原生模式，加速敏捷创新

云原生中原生模式的思想，比如我们已经使用云产品了，为什么我们的业务交付速度没有明显提升呢？这就需要我们的企业架构通过云原生的思想去规划、去设计。比如我们的业务架构，是否根据云原生的特性，将业务的能力梳理和迭代与研发模式紧密相连，而研发模式与对应的组织形态进行适配，同时基于企业的行业属 性对业务能力、服务流程、应用功能进行整体规划，并建立统一多维网络，构建体系化的产品和解决方案。基于云原生的技术体系，通过与业务的敏捷迭代，也进行技术的迭代和组合编排。云原生的最终目标是提高业务交付的效率，使业务更快地创新。