云原生架构设计

本博客地址：https://security.blog.csdn.net/article/details/136734086

一. 云原生架构基础概念

1、云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化地剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。

2、基于云原生架构的应用特点包括：

● 代码结构发生巨大变化 ：不再需要掌握文件及其分布式处理技术和复杂的网络技术

● 非功能性特性大量委托给云原生架构来解决 ：比如高可用能力、容灾能力、安全特性、可运维性、易用性、可测试性、灰度发布能力等。

● 高度自动化的软件交付 ：基于云原生的自动化软件交付可以把应用自动部署到成千上万的节点上。

3、云原生具有以下原则： 服务化原则 、 弹性原则 、 可观测原则 、 韧性原则 、 所有过程自动化原则 、 零信任原则 、 架构持续演进原则 。

4、 服务化架构模式 ：要求以应用模块为颗粒度划分一个应用软件，以接口契约（例如 IDL）定义彼此业务关系，以标准协议（HTTP、gRPC 等）确保彼此的互联互通，结合领域模型驱动（DDD）、测试动开发（TDD）、容器化部署提升每个接口的代码质量和迭代速度。

5、 Mesh 化架构模式 ：Mesh 化架构是把中间件框架（如 RPC、缓存、异步消息等）从业务进程中分离，让中间件 SDK 与业务代码进一步解耦，从而使得中间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件也对业务透明。

6、 Serverless 模式 ：业务流量到来/业务事件发生时，云会启动或调度一个已启动的业务进程进行处理，处理完成后云自动会关闭/调度业务进程，等待下一次触发。开发者不用关心应用运行地点、操作系统、网络配置、CPU 性能等，将应用的整个运行都委托给云。Serverless 模式适合 事件驱动的数据计算任务 、 计算时间短的请求/响应应用 、 没有复杂相互调用的长周期任务 。

7、 存储计算分离模式 ：分布式环境中的 CAP 困难主要是针对有状态应用，由于 一致性 、 可用性 、 分区容错性 三者无法同时满足，最多满足其中两个。所以无状态应用不存在一致性这个维度，可以获得很好的可用性和分区容错性，因而获得更好的弹性。

8、 分布式事务模式 ：由于业务需要访问多个微服务，所以会带来分布式事务问题，否则数据就会出现不一致。因此架构师需要根据不同的场景选择合适的分布式事务模式。常用的有： XA 模式 （性能差）、 基于消息的最终一致性 （通用性有限）、 TCC 模式 （对业务侵入性强，设计开发维护等成本高）、 SAGA 模式 （开发维护成本高）、 开源项目 SEATA 的 AT 模式 （存在使用场景限制）。

9、 可观测架构 ：可观测架构包括 Logging、Tracing、Metrics，其中 Logging 提供多个级别跟踪，例如 INFO/ DEBUG/WARNING/ERROR；Tracing 收集一个请求从前端到后端的访问日志聚合，形成完整调用链路跟踪；Metrics 则提供对系统量化的多维度度量，包括并发度、耗时、可用时长、容量等。

10、 事件驱动架构 ：是一种应用/组件间的集成架构模式。适用于增强服务韧性、数据变化通知、构建开放式接口、事件流处理、命令查询的

责任分离（CQRS）把对服务状态有影响的命令用事件来发起，而对服务状态没有影响的查询才使用同步调用的 API 接口等。

11、常见的云原生反模式（和云原生模式相对立的模式）： 庞大的单体应用 、 单体应用硬拆为微服务 、 缺乏自动化能力的微服务 。

二. 云原生架构相关的技术

1、容器技术。容器作为标准化软件基础单元，它将应用及其所有依赖项打包发布，由于依赖项齐备，应用不再受环境限制，在不同计算环境间快速、可靠地运行。

2、容器编排技术。容器编排技术包括资源调度、应用部署与管理、自动修复、服务发现与负载均衡、弹性伸缩、声明式 API、可扩展性架构、可移植性。

3、微服务。微服务模式将后端单体应用拆分为松耦合的多个子应用，每个子应用负责一组子功能。这些子应用称为微服务，多个微服务共同形成了一个物理独立但逻辑完整的分布式微服务体系。这些微服务相对独立，通过解耦研发、测试与部署流程，提高整体迭代效率。微服务设计约束如下：

● 微服务个体约束 ：微服务应用的功能在业务领域划分上应是相互独立的。

● 微服务与微服务之间的横向关系 ：从 可发现性 和 可交互性 处理微服务间的横向关系。 可发现性 是指当服务 A 发布和扩/缩容的时候，依赖服务 A 的服务B 在不重新发布的前提下，能够自动感知到服务 A 的变化。 可交互性 是指服务 A 采用什么样的方式可以调用服务 B。

● 微服务与数据层之间的纵向约束 ：提倡 数据存储隔离（DSS）原则 ，对于数据的访问都必须通过相对应的微服务提供的 API 来访问。

● 全局视角下的微服务分布式约束 ：高效运维整个系统，从技术上实现全自动化的 CI/CD流水线满足对开发效率的诉求，并在这个基础上支持蓝绿、金丝雀等不同发布策略，以满足对业务发布稳定性的诉求。

4、无服务器技术的特点：

● 全托管的计算服务 ：客户只需要编写代码构建应用，无须关注同质化的、负担繁重的基于服务器等基础设施的开发、运维、安全、高可用等工作。

● 通用性 ：结合云 BaaS（后端云服务）API 的能力，能够支撑云上所有重要类型的应用。

● 自动弹性伸缩 ：让用户无须为资源使用提前进行容量规划。

● 按量计费 ：让企业的使用成本有效降低，无须为闲置资源付费。

5、无服务器技术的关注点是： 计算资源弹性调度（容错、资源利用率、性能、数据驱动） 、 负载均衡和流控 、 安全性 。

6、无服务器技术的特点如下：

● 全托管的计算服务 ：客户只需要编写代码构建应用，无须关注同质化的、负担繁重的基于服务器等基础设施的 开发 、 运维 、 安全 、 高可用 等工作。

● 通用性 ：结合云 BaaS API 的能力，能够支撑云上所有重要类型的应用。

● 自动弹性伸缩 ：让用户无须为资源使用提前进行容量规划。

● 按量计费 ：让企业的使用成本有效降低，无须为闲置资源付费。

7、服务网格：旨在将那些微服务间的 连接 、 安全 、 流量控制 和 可观测 等通用功能下沉为平台基础设施，实现应用与平台基础设施的解耦。例如：服务 A 调用服务 B 的所有请求，都被其下的服务代理截获，代理服务 A 完成到服务 B 的服务发现、熔断、限流等策略，而这些策略的总控是在控制平面上配置。

8、服务网格的主要技术： Istio 、 Linkerd 、 Consul 。