【中项第三版】系统集成项目管理工程师 | 第 4 章信息系统架构⑤

前言

第4章对应的内容选择题 和案例分析 都会进行考查，这一章节属于技术相关的内容 ，学习要**++++以教材为准++++**。本章分值预计在4-5分。

[4.8 云原生架构](#4.8 云原生架构)

[4.8.1 发展概述](#4.8.1 发展概述)

[4.8.2 架构定义](#4.8.2 架构定义)

[4.8.3 基本原则](#4.8.3 基本原则)

[4.8.4 常用架构模式](#4.8.4 常用架构模式)

[4.8.5 云原生案例](#4.8.5 云原生案例)

[4.9 本章练习](#4.9 本章练习)

4.8 云原生架构

"云原生"来自于Cloud Native的直译，Cloud就是指其应用软件和服务是在云端而非传统意义上的数据中心。Native代表应用软件从一开始就是基于云环境，专门为云端特性而设计，可充分利用和发挥云环境的弹性与分布式优势，最大化释放云环境生产力。

4.8.1 发展概述

++++DevOps++++ 出于协调开发和运维的"信息对称"问题而被推出。可以看作是开发、技术运营和质量保障三者的交集，促进他们之间的沟通、协作与整合，从而提高开发周期和效率。

4.8.2 架构定义

根据云原生技术、产品和上云实践，从技术的角度云原生架构是基于云原生技术的一组（++++架构原则++++ ）和（++++设计模式++++ ）的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（例如：弹性、韧性、安全、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备（++++轻量++++ ）、（++++敏捷++++ ）、（++++高度自动化++++ ）的特点。由于云原生是面向"云"而设计的应用，因此，技术部分依赖于云计算的3层概念，即（++++基础设施即服务IaaS++++ ）、（++++平台即服务PaaS++++ ）、（++++软件即服务SaaS++++）。

云原生的代码 通常包括三部分：++++业务代码++++ （核心）、三方软件、处理非功能特性的代码。

4.8.3 基本原则

云原生架构设计原则如下：

①**++++服务化原则++++** ：拆分为微服务架构。进行服务化拆分，包括拆分为微服务架构、小服务（MiniService）架构。

②**++++弹性原则++++** ：系统的部署规模可以根据业务量的变化而自动伸缩。

③**++++可++++** ++++观测原则++++ ：通过日志、链路跟踪和度量等手段，使得一次点击背后的多次服务调用的耗时、返回值和参数都清晰可见。

④**++++韧性原则++++** ：面对软硬件组件出现异常的抵御能力。核心目标是提升软件的平均无故障时间MTBF。

⑤**++++所有过程自动化原则++++** ：自动化交付工具。实现整个软件交付和运维的自动化。

⑥**++++零信任原则++++** ：默认不信任网络内部和外部的任何人/设备/系统。需要基于认证和授权重构访问控制的信任基础。架构从"网络中心化"走向"身份中心化"，其本质诉求是以身份为中心进行访问控制。

⑦**++++架构持续演进原则++++** ：业务高速迭代情况下的架构与业务平衡。架构具备持续演进的能力。

4.8.4 常用架构模式

常用的架构模式主要有服务化架构、Mesh化架构、Serverless、存储计算分离、分布式事务、可观测、事件驱动等。

1 服务化架构模式

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

服务化架构的典型模式是**++++微服务++++** 和**++++小服务模式++++** ，其中小服务可以看作是一组关系非常密切的服务的组合，这组服务会共享数据。小服务模式通常适用于非常大型的软件系统，避免接口的颗粒度太细而导致过多的调用损耗（特别是服务间调用和数据一致性处理）和治理复杂度。

2 Mesh化架构模式

Mesh（网格）化架构是把中间件框架 （如RPC、缓存、异步消息等）从业务进程中分离，让中间件的软件开发工具包(Software Development Kit, SDK）与业务代码进一步解耦，从而使得中间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件也对业务透明。分离后在业务进程中只保留很"薄"的Client部分，Client通常很少变化，只负责与Mesh进程通信，原来需要在SDK中处理的流量控制、安全等逻辑由Mesh进程完成。

3 Serverless模式

Serverless（无服务器）将"部署"这个动作从运维中"收走"，使开发者不用关心应用运行地点、操作系统、网络配置、CPU性能等。也就是把应用的整个运行都委托给云。

Serverless并非适用任何类型的应用：① 如果应用是有状态的，由于Serverless的调度不会帮助应用做状态同步，因此云在进行调度时可能导致上下文丢失；② 如果应用是长时间后台运行的密集型计算任务，会无法发挥Serverless的优势；③ 如果应用涉及频繁的外部I/O（包括网络或者存储，以及服务间调用等），也因为繁重的I/0负担、时延大而不适合。

Serverless非常适合于：事件驱动的数据计算任务、计算时间短的请求/响应应用、没有复杂相互调用的长周期任务。

4 存储计算分离模式

分布式环境中的CAP （一致性： Consistency；可用性： Availability；分区容错性：Partitiontolerance）困难主要是针对有状态应用，因为无状态应用不存在C （一致性）这个维度，因此可以获得很好的A （可用性）和P （分区容错性），因而获得更好的弹性。在云环境中，推荐把各类暂态数据（如session）结构化和非结构化持久数据都采用云服务来保存，从而实现存储计算分离。

5 分布式事务模式

微服务模式提倡每个服务使用私有的数据源，而不是像单体这样共享数据源，但往往大颗粒度的业务需要访问多个微服务，必然带来分布式事务问题，否则数据就会出现不一致。

架构师需要根据不同的场景选择合适的分布式事务模式。

①传统采用XA（扩展体系结构） 模式，虽然具备很强的一致性，但是性能差。

②基于消息的最终一致性 通常有很高的性能，但是通用性有限。

③TCC（Try---Confirm---Cancel，预留---确认---取消）模式 完全由应用层来控制事务，事务隔离性可控，比较高效；但是对业务的侵入性非常强，设计开发维护等成本很高。

④SAGA模式（补偿模式） （指允许建立一致的分布式应用程序的故障管理模式）与TCC模式的优缺点类似但没有Try这个阶段，而是每个正向事务都对应一个补偿事务，也使开发维护成本高。

⑤开源项目SEATA的AT模式 非常高性能，无代码开发工作量，且可以自动执行回滚操作，同时也存在一些使用场景限制。

6 可观测架构

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

Logging（日志）提供多个级别的详细信息跟踪，由应用开发者主动提供；

Tracing（追踪）提供一个请求从前端到后端的完整调用链路跟踪，对于分布式场景尤其有用；

Metrics（度量）则提供对系统量化的多维度度量。

架构决策者需要选择合适的、支持可观测的开源框架。由于建立可观测性的主要目标是对服务SLO(Service Level Objective,服务级别目标)进行度量，从而优化SLA(Service Level Agreement,服务水平协议），因此架构设计上需要为各个组件定义清晰的SLO，包括并发度、耗时、可用时长、容量等。

7 事件驱动架构

事件驱动架构(Event Driven Architecture,EDA)本质上是一种应用/组件间的集成架构模式。事件驱动架构不仅用于（微）服务解耦，还可应用于下面的场景中：增强服务韧性；CQRS（命令查询的责任分离）；数据变化通知；构建开放式接口；事件流处理；基于事件触发的响应。