- 云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度等），使业务不再有非功能行业务中断困扰的同事，具备轻量、敏捷、高度自动化的特点。
- 云原生的代码通常包括三部分：业务代码、三方软件、处理非功能特性的代码。从业务代码中剥离大量非功能性特性（不会是所有，比如易用性还不能剥离）到IaaS和PaaS中，从而减少业务代码开发人员的技术关注范围，通过云厂商的专业性提升应用的非功能性能力。
- 具备云原生架构的应用可以最大程度利用云服务和提升软件交付能力，进一步加快软件开发其特点包括：
- 代码结构发生巨大变化
- 非功能性特性大量委托
- 高度自动化的软件交付。
- 云原生架构原则
- 服务化原则：拆分为微服务架构、小服务架构，分别迭代。
- 弹性原则：系统的部署规模可以随着业务量的变化而自动伸缩，无须根据事先的容量规划准备固定的硬件和软件资源。
- 可观测原则：通过日志、链路跟踪和度量等手段，使得一次点击背后的多次服务调用的耗时、返回值和参数都清晰可见。
- 韧性原则：当软件所依赖的软硬件组件出现各种异常时，软件表现出来的抵御能力。
- 所有过程自动化原则：一方面标准化企业内部的软件交付过程，另一方面在标准化的基础上进行自动化，通过配置数据自描述和面向终态的交付过程，让自动化工具理解交付目标和环境差异，实现整个软件交付和运维的自动化。
- 零信任原则：默认情况下不应该信任网络内部和外部的任何人/设备/系统，需要基于认证和授权重构访问控制的信任基础，以身份为中心。
- 架构持续演进原则：云原生架构本身也必须是一个具备持续演进能力的架构。
- 主要架构模式
- 1.服务化架构模式：典型模式是微服务和小服务模式。通过服务化架构，把代码模块关系和部署关系进行分离，每个接口可以部署不同数量的实例，单独扩缩容，从而使得整体的部署更经济。
- 2.Mesh化架构模式：把中间件框架（如RPC、缓存、异步消息等）从业务进程中分离，让中间件SDK与业务代码进一步解耦，从而使得中间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件也对业务透明。分离后的业务进程中只保留很“薄”的Client部分，Client通常很少变化，只负责与Mesh进程通信，原来需要在SDK中处理的流量控制、安全等逻辑由Mesh进程完成。
- 3.Serverless模式：将“部署”这个动作从运维中“收走”，使开发者不用关心应用运行地点、操作系统、网络配置、CPU性能等，从架构抽象上看，当业务流量到来/业务事件发生时，云会启动或调度一个已启动的业务进程进程处理，处理完成后云自动会关闭/调度业务进程，等待下一次触发，也就是把应用的整个运行都委托给云。
- 4.存储计算分离模式：在云环境中，推荐把各类暂态数据（如session）、结构化和非结构化持久数据都采用云服务来保持，从而实现存储计算分离。
- 5.分布式事务模式：大颗粒度的业务需要访问多个微服务，必然带来分布式事务问题，否则数据就会出现不一致，架构师需要根据不同的场景选择合适的分布式事务模式。
- 6.可观测架构：可观测架构包括Logging、Tracing、Metrics三个方面，其中Logging提供多个级别的详细信息跟踪，由应用开发者主动提供；Tracing提供一个请求从前端到后端的完整调用链路跟踪，对于分布式场景尤其有用；Metrics则提供对系统量化的多维度度量。
- 7.事件驱动架构：本质上是一种应用/组件间的集成架构模式。可用于服务解耦、增强服务韧性、数据变化通知等场景中。
- 典型的云原生架构反模式：
- 庞大的单体应用
- 单体应用“硬拆”为微服务
- 缺乏自动化能力的微服务
- 容器技术
- 容器作为标准化软件单元，它将应用及其所有依赖项打包，使应用不再受环境限制，在不同计算环境间快速、可靠地运行。
- 通过容器技术，企业可以充分发挥云计算弹性优势，降低运维成本。一般而言，借助容器技术，企业可以通过部署密度提升和弹性降低50%的计算成本。
- Kubernets已经成为容器编排的事实标准，被广泛用于自动部署，扩展和管理容器化应用。
- Kubernetes提供了分布式应用管理的核心能力，包括：
- 资源调度
- 应用部署与管理
- 自动修复
- 服务发现与负载均衡
- 弹性伸缩
- 声明式API
- 可扩展性架构
- 可移植性
- Kubernetes提供了分布式应用管理的核心能力，包括：
- 云原生微服务
- 微服务模式将后端单体应用拆分为松耦合的多个子应用，每个子应用负责一组子功能。这些子应用称为“微服务”，多个“微服务”共同形成了一个物理独立但逻辑完整的分布式微服务体系。这些微服务相对独立，通过解耦研发、测试与部署流程，提高整体迭代效率。
- 微服务设计约束
- （1）微服务个体约束：功能在业务域划分上应是相互独立的，低耦合、单一职责。
- （2）微服务与微服务之间的横向关系：主要从微服务的可发现性和可交互性处理服务间的横向关系，一般需要服务注册中心。
- （3）微服务与数据层之间的纵向约束：在微服务领域，提供数据存储隔离原则，即数据是微服务的私有资产，对于该数据的访问都必须通过当前微服务提供的API来访问。
- （4）全局视角下的微服务分布式约束：故障发现时效性和根因精确性始终是开发运维人员的核心诉求。
- 主要微服务技术
- Apache Dubbo作为源自阿里巴巴的一款开源高性能RPC框架，特性包括基于透明接口的RPC、智能负载均衡、自动服务注册和发现、可扩展性高、运行时流量路由与可视化的服务治理。
- SPring Cloud作为开发者的主要微服务选择之一，为开发者提供了分布式系统需要的配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性Token、全局锁、决策竞选、分布式会话与集群状态管理等邓丽和开发工具。
- Eclipse MicroProfile作为Java微服务开发的基础编程模型，它致力于定义奇特Java微服务规范，MicroProfile提供指标、API文档、运行状况检查、容错与分布式跟踪等能力，使用它创建的云原生微服务可以自由地部署在任何地方，包括服务网格架构。
- Tars是腾讯将其内部使用的微服务框架，包含一整套开发框架与管理平台，兼顾多语言、易用性、高性能与服务治理，理念是让开发更聚焦业务逻辑，让运维更高效。
- SOFAStack是由蚂蚁金服开源的一套用于快速构建金融机构分布式架构的中间件，也是在金融场景里的最佳实践。
- DAPR（分布式应用运行时）是微软新推出的一种可移植的、无服务器的、事件驱动的运行时，它使开发人员可以轻松构建弹性、无状态和有状态微服务，这些服务运行在云和边缘上，并包含多种语言和开发框架。
- 无服务器技术（Serverless）
- 无服务器技术因为屏蔽了服务器的各种运维复杂度，让开发人员可以将更多精力用于业务逻辑设计与实现，而逐渐成为云原生主流技术之一。
- Serverless计算包含以下特征：
- （1）全托管的计算服务，客户只需要编写代码构建应用，无需关注同质化的、负担繁重的基于服务器等基础设施的开发、运维、安全、高可用等工作；
- （2）通用性，结合云BaaSAPI的能力，能够支持云上所有重要类型的应用；
- （3）自动弹性伸缩，让用户无需为资源使用提前进行容量规划；
- （4）按量计费，让企业使用成本有效降低，无需为闲置资源付费。
- 函数计算（FaaS）是Serverless中最具代表性的产品形态。通过把应用逻辑拆分多个函数，每个函数都通过实践驱动的方式触发执行。
- 无服务器技术关注点：
- 计算资源弹性调度
- 负载均衡和流控
- 安全性
- 服务网格（ServiceMesh）
- 服务网格是分布式应用在微服务软件架构之上发展起来的新技术，旨在将那些微服务间的链接、安全、流量控制和可观测等通用功能下沉为平台基础设施，实现应用与平台基础设施的解耦。
- 这个解耦意味着开发者无需关注微服务相关治理问题而聚焦于业务逻辑本身，提升应用开发效率并加速业务探索和创新。
- 服务网格是分布式应用在微服务软件架构之上发展起来的新技术，旨在将那些微服务间的链接、安全、流量控制和可观测等通用功能下沉为平台基础设施，实现应用与平台基础设施的解耦。