前言：
从技术的角度，云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中非业务代码的部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度等），使业务不再有非功能性业务中端困扰的同时，具备轻量、敏捷、高度自动化的特点。
编辑
上图展示了在代码中通常包括三部分：
业务代码、三方软件、处理非功能特性的代码。其中业务代码是指实现业务逻辑的代码；三方软件是业务代码中依赖的所有的第三方代码库，包括业务库和基础库；处理非功能性的代码指的是：高可用的、安全的、可观测性等非功能性能力的代码。
这三个部分中只有业务代码是核心，是对业务真正带来价值，另外两个部分都只算附属物，但是随着软件规模的增大，业务模块规模变大，部署环境的增多，分布式复杂性增强，使得今天的软件构建变得越来越复杂；对于开发人员的技术要求也越来越高。云原生相比传统架构进了一大步，从业务代码中剥离了大量非功能性特性（不会是所有，比如易用性还不能进行剥离）到lassh和paas中，从而减少了业务代码开发人员的技术关注范围，通过云厂商的专业性提示了应用的非功能性能力。
此外具备云原生架构的应用，可以最大化利用云服务和提升软件交付的能力，进一步的加快软件的开发。
1. 代码结构发生巨大大变化：云原生架构最有影响力的就是让开发人员的编程模型发生 巨大的变化。今天大部分的编程语言中，都有文件、网络、线程等元素，这些元素充分利用单机资源带来的好处，但是却带来了分布式编程的复杂性；因此大量的框架和产品涌现，来解决分布式环节中的网络调用问题、高可用的问题、cpu的争抢使用的问题，分布式存储的问题。
在云的环境中，如何获取存储变成了若干服务，比如对象存储服务，块存储服务和没有随机访问的文件存储服务，云不仅改变了开发人员获得这些存储能力的界面，还在于云产品在这些openapi或者开源的sdk背后把分布式场景中的高可用挑战、自动扩容挑战、安全挑战、运维调整等待都处理了。应用开发人员就不用在其代码中处理节点宕机后如何把本地保存的内容同步到远程的问题了。也不用除了当业务峰值到来的时候，如何对存储节点进行扩容的问题，而应用的运维人员不用再发现zero day安全的问题，紧急对三方存储软件进行升级。
