【软考速通笔记】系统架构设计师⑬——云原生架构设计理论与实践

一、前言

笔记目录大纲请查阅：【软考速通笔记】系统架构设计师——导读

二、云原生架构基础知识

2.1 定义

云原生架构是基于云原生技术的一组架构原则和设计模式的集合。

旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能性（如弹性、韧性、安全、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。

2.2 特点

• 专注业务：不再需要掌握文件及其分布式处理技术，不再需要掌握各种复杂的网络技术，简化让业务开发变得更加敏捷，更快速。
• 非功能特性：高可用能力、容灾能力、安全特性、可运维性、易用性、可测试性、灰度发布能力等。
• 高度自动化：基于云原生的自动化软件交付可以把应用自动部署到成千上万的节点上。

2.3 原则

• 服务化原则：把不同生命周期的模块分离出来，分别进行业务迭代。
• 弹性原则：系统的部署规模可以随着业务量的变化而自动伸缩。
• 可观测原则：通过日志、链路跟踪和度量等手段，实现对多次服务调用的耗时、返回值和参数的全面监控和记录。
• 韧性原则：软件所依赖的软硬件组件出现各种异常时，软件应表现出强大的抵御能力。例如，通过容错机制、故障恢复技术等手段来提高系统的韧性。
• 所有过程自动化原则：让自动化工具理解交付目标和环境差异，实现整个软件交付和运维的自动化。这有助于提高效率、减少人为错误和降低运维成本。
• 零信任原则：不应该信任网络内部和外部的任何人/设备/系统，需要基于认证和授权重构访问控制的信任基础。这有助于确保系统的安全性，防止未经授权的访问和操作。
• 架构持续演进原则：将架构设计和开发过程视为一个持续演进的过程，随着需求和技术的变化不断调整和优化架构。

三、云原生架构模式

3.1 服务化架构模式

• 服务化架构模式，通常指的是微服务架构。
• 将单体应用构建成多个微服务，每个服务运行在自己的进程中，并通过轻量级的通信机制（如HTTP RESTful API或gRPC）进行交互。
• 这种模式提高了系统的可维护性、可扩展性和灵活性。

3.2 Mesh化架构模式

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

3.3 Serverless模式

Serverless模式，无服务器架构，无需购买、维护和管理服务器。

• 特性：
  • 无需管理服务器：Serverless模式让开发者无需关注底层的服务器和基础架构的管理，这些事情都交给提供Serverless的云平台负责。云平台负责管理应用程序的运行环境，包括底层的服务器、网络、存储、安全等，同时还提供了自动扩展、负载均衡、监控和日志等服务。
  • 按需分配资源：Serverless架构能够根据负载自动调整资源，实现按需计费。这种方式可以大大降低应用程序的运行成本，提高效率和成本效益。
  • 高可用性和灵活性：Serverless架构具备高可用性和灵活性，支持多种编程语言和框架。它可以根据应用程序的需求自动分配计算资源，提高了应用程序的可伸缩性和弹性。
• 优点：降低人力成本，提高开发效率，提高产品上线时间。
• 缺点：本地调试困难，对有状态的服务不够灵活，对复杂大型服务增加开发难度。
• 例子：
  • 亚马逊云科技提供了Amazon Lambda、Amazon S3、Amazon DynamoDB等无服务器服务；
  • 阿里云和微信小程序也提供了Serverless小程序、云函数等后端服务。

3.4 存储计算分离模式

存储计算分离模式将数据存储从计算资源中分离出来，使得两者可以独立扩展和管理。这种模式适用于需要高吞吐量读写操作的场景，如大数据应用，可以提高性能和可扩展性。

3.5 分布式事务模式

微服务模式提倡每个服务使用私有的数据源，而不是像单体这样共享数据源。

但往往大颗粒度的业务需要访问多个微服务，必然带来分布式事务问题，否则数据就会出现不一致。

架构师需要根据不同的场景选择合适的分布式事务模式，常见的有以下几种：

• XA模式：虽然具备很强的一致性，但是性能差。
• 基于消息的最终一致性（base）：高性能，异步处理，但是通用性有限，且消息端只能成功而不能触发消息生产端的事务回滚。
• TCC模式：事务隔离性可控，可以根据业务需要来调整事务的隔离级别。事务隔离性可控，可以根据业务需要来调整事务的隔离级别。
• SAGA模式：与TCC模式的优缺点类似但没有try这个阶段，而是每个正向事务都对应一个补偿事务，也是开发维护成本高。
• SEATA的AT模式：非常高性能且无代码开发工作量，且可以自动执行回滚操作，同时也存在一些使用场景限制。

3.6 可观测模式

可观测架构包括Logging、Tracing、Metrics三个方面：

• Logging：提供多个级别（verbose/debug/warning/error/fatal）的详细信息跟踪。
• Tracing：提供一个请求从前端到后端的访问日志聚合，形成完整调用链路跟踪。
• Metrics：则提供对系统量化的多维度度量，包括：并发量、耗时、可用时长、容量等。

3.7 事件驱动架构

事件驱动架构（EDA，Event Driven Architecture）本质上是一种应用或组件间的集成架构模式。适用于：

• 微服务解耦
• 增强服务韧性
• 数据变化通知
• 构建开放式接口
• 事件流处理
• 命令查询的责任分离（Command Query Responsibility Segregation，CQRS），对服务状态有影响的命令用事件来发起，对服务状态没有影响的查询使用同步调用API接口。

3.8 反云原生模式

• 庞大的单体应用。
• 单体应用不合理的拆分。
• 缺乏自动化能力。

四、云原生技术

4.1 容器技术

容器技术是一种轻量级的操作系统虚拟化方法，它允许开发者将应用及其依赖打包在容器中。容器在隔离的环境中运行，具有自己的文件系统、网络配置和进程空间。

优点：

• 环境一致性：确保应用在不同环境间的高度一致性。
• 快速启动：容器启动速度快，适合动态扩展。
• 资源效率：容器共享宿主机的操作系统内核，资源利用率高。

常见的容器技术：

• Docker：最流行的容器化平台，提供容器的创建、部署和运行。
• Podman：一个无需守护进程的容器引擎，与Docker兼容。

4.2 容器编排技术

容器编排技术用于管理、调度和扩展容器化应用程序。

优点：

• 自动化部署：自动化容器的部署、扩展和回收。
• 服务发现：自动服务注册和发现。
• 负载均衡：自动分配网络流量。

常见的容器编排技术：

• Kubernetes：一个强大的开源容器编排平台，支持服务发现、负载均衡、自动扩展等。
• Docker Swarm：Docker内置的容器编排工具，提供集群管理和服务编排。

4.3 微服务

微服务架构模式将应用程序构建为一系列小型、独立的服务，每个服务实现特定的业务功能。

优点：

• 灵活性：每个服务可以独立开发、部署和扩展。
• 可维护性：服务之间的耦合性低，易于维护和更新。

微服务的技术：

• 分布式事务：需要处理跨服务的事务一致性问题。
• 服务发现：服务实例动态变化，需要有效的服务发现机制。

4.4 无服务器技术

无服务器技术（Serverless）允许开发者构建和运行应用程序，而无需管理服务器。

优点：

• 成本效益：按实际使用的资源付费，无需预留资源。
• 开发效率：开发者可以专注于代码，减少运维工作。

常见的无服务器平台：

• AWS Lambda：一个事件驱动的计算服务，无需管理服务器。
• Azure Functions：微软的无服务器计算服务。

4.5 服务网格

服务网格为微服务架构提供了一种可靠的服务间通信机制。

优点：

• 流量控制：提供流量路由、负载均衡和故障恢复。
• 安全性：内置服务间通信的加密和认证。

常见的服务网格技术：

• Istio：一个开源的服务网格，提供流量管理、策略执行和遥测数据收集。
• Linkerd：一个轻量级的服务网格，专注于性能和易用性。

---

若觉得文章对你有帮助，随手『点赞』、『收藏』、『关注』，也是对我的支持。