云原生是云计算的2.0时代，笔者认为也是低代码和未来的AI等产业的基础。

云原生所代表或依托的技术包括容器技术与容器编排平台、服务网格式样的架构模式、微服务架构设计思想、依托容器技术在基础设施（硬件、虚机、OS）和应用层之间做隔离形成所谓不可变基础设施、以及与低代码平台产品类似的声明式API（笔者认为像阿里宜搭等低代码平台更侧重于产品层面提供快速开发小APP的平台、而声明式API相对其更为细粒度一些，前者的关键字是“配置”、“可视化操作”快速上线小应用产品，后者的关键字可能是“只写业务逻辑代码”、“不用管纯技术代码和中间件等”）。

可见，云原生时代的各种新姿势或多或少都要跟容器技术和Kubernetes有关，之前笔者对服务网格风格架构的实践、无论是进程内代理组件 + Consul、进程外代理 + Consul、其实都是为了实现业务应用与服务治理部分的能力的分离，将服务治理部分的能力作为云的原生的能力、而不是需要应用级架构师考虑的问题。

以上种种，在看过了业内一些头部公司的ServiceMesh方案和实践之后，虽然没完全搞清楚能落地实施的方案，笔者有种感觉在引入Kubernetes生态的技术后很多问题就会迎刃而解。

K8s不能不学，别无他法，《Kubernetes in Action》看起来！

 

原文正文：

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

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

 

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

但它们大多数利用开源或商业的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系统/虚拟主机，而是一个个业务单元，开发者只需要聚焦于业务本身。可以说微服务的设计、无服务的功能是云原生理念的核心体现，而容器、编排、服务网格均是实现云原生的支撑技术。