[系统架构设计师]云原生架构
一.云原生架构
云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性，韧性，安全，可观测性，灰度等），使业务不再有非功能性业务中中断困扰的同时，具备轻量，敏捷，高度自动化的特点。
云原生的代码通常包括三部分：业务代码，三方软件，处理非功能特性的代码。从业务代码中剥离非功能性特性（不会是所有，比如易用性还不能剥离）到IaaS和PaaS中，从而减少业务代码开发人员的技术关注范围，通过云厂商的专业性提升应用的非功能性能力。
具备云原生架构的应用可以最大程度利用云服务和提升软件交付能力，进一步加快软件开发。其特点包括：代码结构发生巨大变化，非功能性特性大量委托，高度自动化的软件交付。
二.云原生架构原则
（1）服务化原则
拆分为微服务架构，小服务架构，分别迭代。
（2）弹性原则
系统的部署规模可以随着业务量的变化而自动伸缩，无须根据事先的容量规划准备固定的硬件和软件资源。
（3）可观测性原则
通过日志，链路跟踪和度量等手段，使得一次点击背后的多次服务调用的耗时，返回值和参数都清晰可见。
（4）韧性原则
当系统所依赖的软硬件组件出现各种异常时，软件表现出来的抵御能力。
（5）所有过程自动化原则
一方面标准化的企业内部的软件交付过程，另一方面在标准化的基础上自动化，通过配置自描述和面向终态的交付过程，让自动化工具理解交付目标和环境差异，实现整个软件交付和运维的自动化。
（6）零信任原则
默认情况下不应该信任网络内部和外部的任何人/设备/系统，需要基于认证和授权重构访问控制的信任基础，以身份为中心。
（7）架构持续演进原则
云原生架构本身也必须是一个具备持续演进能力的架构。
三.主要架构模式
1.服务化架构模式
典型模式是微服务和小服务模式。通过服务化架构，把代码模块关系和部署关系进行分离，每个接口可以部署不同的实例，单独扩缩容，从而使得整体的部署更经济。
2.Mesh化架构模式
把中间件框架（如RPC，缓存，异步消息等）从业务中分离，让中间件SDK和业务代码进一步解耦，从而使得中间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件也对业务透明。分离后在业务进程中只保留很"薄"的Client部分，Client通常很少变化，只负责与Mesh进程通信，原来需要在SDK中处理的流量控制，安全逻辑由Mesh进程完成。
3.Serverless模式
将”部署“这个动作从”运维“中收走，使开发者不用关心应用运行地点，操作系统，网络配置，CPU性能等，从架构抽象上看，当业务流量到来/业务事件发生时，云会启动或调用一个已启动的业务进程进行处理，处理完成后云会自动关闭/调度业务进程，等待下一次触发，也就是把应用的整个运行都委托给云。
4.存储计算分离模式
在云环境中，推荐把各类暂态数据（如session），结构化和非结构化持久化数据都采用云服务来保存，从而实现存储计算分离。
5.分布式事务模式
大颗粒度的业务需要访问多个微服务，必然带来分布式事务问题，否则数据就会出现不一致。架构师需要根据不同的场景选择合适的分布式事务模式。
6.可观测架构
可观测架构包括Logging，Tracing，Metrics三个方面，其中Logging提供多个级别的详细信息跟踪，由应用开发真主动提供；Tracing提供一个从前端到后端的完整调用链路跟踪，对于分布式场景尤其有用；Metrics则提供对系统量化的对维度度量。
7.事件驱动架构
本质上是一种应用/组件间的集成架构模式。可用于服务解耦，增强服务韧性，数据变化等场景中。