什 么是云原生
云原生是最近几年的热门概念，然，呼声甚高，雷声甚大，知其所以然者，甚少。 原因在于云原生概念处于整个云计算技术栈上层，而云计算架构本身又比较复杂，因此在讲云原生之前，我们先了解一下它从那里来，再说他要到哪里去，我将与你姗姗道来。
单体服务时代
在古代，由于软硬件和网络技术不成熟，软件处理的业务复杂度较低，一般软件系统体量较小，单台服务器的计算和存储能力足以支撑其正常运行，我们称这种软件架构为单体应用(也称巨石应用）。
单体应用的优点是架构清晰，部署维护简单，易于测试。 随着业务复杂度逐渐提高，对计算和存储能力要求越来越高，单体应用只能靠不断优化软件算法和提高单台服务器的硬件配置来解决性能问题，于是整个系统的运行成本会越来越高，最终无法实现持续扩容。
集群服务时代
20世纪80年代以后，微型计算机开始普及， 单台计算机成本迅速下降，面对单体应用带来的扩容问题，终于有了物美价廉的解决方案: 对单体应用进行模块拆分部署，使用多主机分担性能压力。
由于不同业务模块对计算和存储的需求度不同，比如“数据管理模块”对存储资源的消耗多，而“数据分析模块”对计算资源的消耗多，可以根据业务需求将模块部署到单台或多台特定性能主机中，并对主机进行统一管理，形成服务器集群，我们称这种软件架构为集群应用。
集群应用很好的解决了单体应用中面临的扩容问题，通过配合均衡负载和反向代理等技术可以提供超大规模复杂业务的高并发访问和处理能力。
集群应用的优点是易扩容，部署灵活，系统可靠性高、业务承载能力强。
2010年开始，全球进入移动互联网时代，智能手机的普及，让互联网用户数量呈爆炸式增长。电商、社交、手游、短视频等线上业务迅速崛起，伴随而来的是互联网服务商的集群规模迅速扩大到数百台甚至上千台服务器。
由于大规模应用中服务器数量巨大，问题频发：
- 硬件老化损坏、网络故障、停电等不可控因素经常发生。
- 对某个业务的扩容或收缩，经常需要调整主机部署。
- 故障发生后响应速度慢，无法快速转移业务到其他主机运行。
- 由于业务部署和迁移速度慢，服务器性能不饱和，集群资源闲置大，利用率低。
因此运维难度越来越大。
云计算服务时代
云计算的基础是虚拟化技术，通过对硬件、操作系统、网络的虚拟化，使业务模块运行于虚拟环境之上中，而虚拟环境更可控，更容易运维。
在基于云计算的业务实现中，对不同模块的资源需求可以直接有针对性的使用不同的云服务。比如“数据管理模块”对存储资源的消耗多，可以使用S3存储和云数据库承载，“数据分析模块”对CPU的使用数量多，可以为运行此模块的虚拟系统分配更多的虚拟盘CPU数量。
通过将业务容器化运行，使用容器编排工具对其进行监控、扩容、收缩。让业务公司的运维人员和主机硬件分离，运维人员通常只需要管理虚拟资源，硬件的维护由专业的运营商和数据中心负责。
我们称基于云计算的虚拟资源构建的应用为云原生应用。
云原生应用的优点：
- 可以根据业务需要弹性扩容，省去业务公司前期设备成本压力。
- 由于硬件设备由专业运营商负责，运行可靠性极高。
- 容器化编排标准由Kubernetes确认后，借助编排工具对业务容器进行管理，运维成本低。
Pivotal 是云原生应用的提出者(2019年被vmware收购)，并推出了Pivotal Cloud Foundry云原生应用平台和 Spring 开源 Java 开发框架，成为云原生应用架构中先驱者和探路者。Pivotal 的技术产品经理 Matt Stine 写了一本名为《迁移到云原生应用架构》的文章，详细解释了云原生架构的定义和迁移指南。
当前，云原生已经不再仅仅是一个建立在云计算之上的概念，而是一系列先进的理念和方法论的整合，以指导软件公司实现从传统架构到云原生架构的过渡。
云原生应用建立在云平台基础之上，而云平台本身是分布式的，基于分布式的特性，云原生提出了微服务的架构理念，为了便于微服务的部署和管理，将服务容器化，使用Kubernetes进行统一编排和运维管理，微服务和容器化代表了云原生的基本模型。
云原生应用的实施和持续交付需要开发和运维人员更密切的协作，以DevOps理念为基础，指导业务开发人员和运维人员更好的协作沟通，配合敏捷开发方法论，帮助团队实现快速持续交付的目标。
未来，随着云计算对企业信息化的继续深入影响，基于更加完善的云计算基础设施，会有更多的服务型应用向云计算平台转移，云平台的各种协议标准已逐渐形成，云原生应用可以做到在所有的云端适配，不管是各厂商的公有云 像AWS、Azure、阿里云，还是各企业自己搭建的私有云平台，云原生应用都能做到无缝的对接和运行。云原生应用也将具备弹性扩展、高可用、高容错性、自恢复的云计算特征，为企业提供更稳定可靠的服务。
参考资料：
《Migrating to Cloud-Native Application Architectures》