一.云原生架构定义
从技术的角度，云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大剥离，从而让云设施接管应用中原有的大量非功能特性，使业务不再有非功能性业务终端困扰的同时，具备轻量、敏捷，高度自动化的特点。云原生技术部分依赖与传统云计算的三层概念，及基础设施即服务（IaaS）,平台即服务（PaaS）和软件即服务（SaaS）。
云原生的代码通常包括三部分：业务代码，三方软件，处理非功能特性的代码。其中业务代码是指业务逻辑的代码，三方软件指业务代码依赖库的所有三方库，包括业务库和基础库；处理非功能性的代码指实现高可用，安全，可观测性等非功能性能力的代码，三部分中，只有业务代码是核心，对业务真正带来价值的，另外两个部分都只算附属物。云原生架构相比较传统的架构，从业务代码中剥离大量非功能特性到IaaS和PaaS中，从而减少业务代码开发人员你的技术关注范围。
1.代码结构发生巨大变化
云原生架构产生的最大影响就是让开发人员的编程模型发生了巨大变化。在云的环境中，如何获取存储变成了若干服务，包括对象存储服务、快存储服务和没有随机访问的文件存储服务。云把三方软硬件的能力升级成了服务，开发人员的开发复杂度和运维人员的运维工作量都得到极大降低。如果这样的云服务用得越多，那么开发和运维人员的负担就越少。
2.非功能特性大量委托
任何应用都提供两类特性，功能特性和非功能特性。功能性特性是真正为业务带来价值的代码，非功能特性是没有给业务带啦直接业务价值，但通常又是必不可少的特性。
虚拟机：当虚拟机检测到底层硬件发生异常时，自动做热迁移，迁移后的应用不需要重启仍然具备对位服务的能力，应用对整个迁移过程都不会有任何感知。
容器：容器通过监控检查探测到进程状态异常，从而实施异常节点的下线、 新节点上线和生产流量的切换等操作，整个过程自动完成而无需运维人员干预。
云服务：如果应用把有状态部分交给云服务，加上全局对象的持有小型化或具备重磁盘快速重建能力，由于服务本身是具备极强的高可用能力，那么应用本身会变成很薄的无状态应用，高可用故障带来的业务中断会将至分钟级别。
3.高度自动化的软件交付
基于云原生的自动化软件交付相比于人工软件交付是一个巨大的进步。以微服务为例，应用微服务化以后，往往被部署到成千上万个结点上，如果系统不具备高度的自动化能力，任何一次新业务的上线，都会带来极大的工作量挑战。
二.云原生架构原则
云原生架构本身作为一种架构，也有若干架构原则作为应用架构的核心架构控制面，通过遵从这些架构原则可以让技术主管和架构师在做技术选择时不会出现大量偏差。
1.服务化原则
当代码规模变大时，就有必要进行服务化拆分了，包括拆分为微服务架构、小服务架构，云原生架构强调使用服务化的目的还在于从架构层面抽象化业务模块之间的关系，标准化服务流量的传输，从而帮助业务模块进行基于服务流量的策略控制和治理。
2.弹性原则
弹性原则是指系统的部署规模可以随着业务量的变化而自动伸缩，无须根据事先的容量规划准备固定的硬件和软件资源。
3.可观测原则
分布式环境下需要对多个主机上的信息做关联，可观测性是在云这样的分布式系统中，主动通过日志，链路跟踪和度量等手段，使得一次点击背后的多次服务调用的耗时，返回值和参数都清晰可见，甚至可以下钻到 第三方软件调用，SQL请求，节点拓扑、网络响应等，这样的能力可以使运维、开发和业务人员实时掌握软件运行情况，并结合多个维度的数据指标，获得前所未有的关联分析能力，不断对业务健康度和用户体验进行数字化衡量和持续优化。
4.韧性原则
韧性代表了当软件所依赖的软硬件组件出现各种异常时候，软件表现出来的抵抗能力。韧性从多个纬度诠释了软件持续提供业务服务的能力，核心目标是提升软件的平均无故障时间。
5.所有过程自动化原则
通过IaC(Infrastructure as Code)、GitOps、OAM(Open Application Model)、Kubernetes
Operator和大量自动化交付工具在CI/CD 流水线中的实践，一方面标准化企业内部的软件交付过程，另一方面在标准化的基础上进行自动化，通过配置数据自描述和面向终态的交付过程， 让自动化工具理解交付目标和环境差异，实现整个软件交付和运维的自动化。
6.零信任原则
默认情况下不应该信任网络内部和外部的任何人/设备/系统，需要基于认证和授权重构访问控制的信任基础。
7.架构持续演进原则
云原生架构本身必须是一个具备持续演进能力的架构，而不是一个封闭式架构。除了增量迭代、目标选取等因素外， 还需要考虑组织(例如架构控制委员会)层面的架构治理和风险控制，特别是在业务高速迭代情况下的架构、业务、实现平衡关系。
三.主要架构模式
1.服务化架构模式
服务化架构是云时代构件云原生应用的标准架构模式，要求以应用模块为粒度划分一个软件，以接口定义彼此业务关系，以标准协议确保彼此的互联互通，结合领域模型驱动，测试驱动开发，容器化部署提升每个接口的代码质量和迭代速度。
通过服务化架构，把代码模块关系和部署关系进行分离，每个接口可以部署不同数量的实例，单独扩缩容，从而使得整体的部署更经济。
2.Mesh化架构模式
Mesh化架构是把中间件框架从业务进程中分离，让中间件SDK与业务代码进一步解耦，从而使得中间件升级对业务没有影响，甚至迁移到另外一个平台的中间件也对业务透明。
3.Serverless模式
Serverless将部署这个动作从运维中收走，使开发这不用关系应用运行地点、操作系统、网络配置、CPU性能等，从架构抽象上看，当业务流量到来/业务事件发生时，云会启动或调度一个已启动的业务进程进行处理，处理完后自动关闭调度业务进程，等待下一次触发，也就是把整个运行都委托给云。
4.存储计算分离模式
在云环境中，推荐把各类暂态数据(如session)、 结构化和非结构化持久数据都采用云服务来保存， 从而实现存储计算分离。
5.分布式事务模式
微服务模式将每个服务使用私有的数据源，而不是像单体这样共享数据，但往往大颗粒度的业务需要访问多个服务，必然带来分布式事务问题，否则数据就会出现不一致。
6.可观测架构
可观测架构包括Logging、Tracing、Metrics三个方面，其中Logging提供多个级别 (verbose/
debug/warning/error/fatal) 的详细信息跟踪，由应用开发者主动提供； Tracing提供一个请求从前 端到后端的完整调用链路跟踪，对于分布式场景尤其有用；Metrics则提供对系统量的多维度度量。
四.典型的云原生架构反馈模式
企业做云原生架构演进的时候，会重复考虑根据不同的场景选择不同的技术，下面是一些典型的云原生架构反模式。
1.庞大的单体应用
当业务模块可能存在多人开发的时候，就需要考虑通过服务化进行一定的拆分，梳理聚合根， 通过业务关系确定主要的服务模块以及这些模块的边界、清晰定义模块之间的接口，并让组织关系和架构关系匹配。
2.单体应用硬拆为微服务
服务的拆分需要适度，过分服务化拆分反而会导致新架构与组织能力的不匹配，让架构升级得不到技术红利。
3.缺乏自动化能力的微服务
软件规模进一步变大后，自动化能力的缺失还会带来更大的危害。由于接口增多会带来测试用例的增加，更多的软件模块排队等待测试和发布，如果缺乏自动化会造成软件发布时间变长，在多环境发布或异地发布时更是需要专家来处理环境差异带来的影响。
