一、前言

围绕 2025 年下半年系统架构设计师考试，梳理了企业集成分类、电子政务类型、原型种类、传统架构风格、微服务优势、质量属性分类、云原生架构原则与模式、SAAM 和 ATAM 区别、网络攻击类型、可靠性模型、局域网拓扑结构、嵌入式数据库分类、鸿蒙操作系统架构、备份方式对比、分区与分表差异、Kappa 与 Lambda 架构区别、数字孪生体、人工智能关键技术与应用共二十个核心问题。

二、思维导图

三、详细总结

一、企业集成分类

企业集成分类主要从集成点和传输方式两个维度划分，具体内容如下表所示：

分类维度	类型	集成点 / 特点	效果 / 说明
按集成点分	界面集成	界面	统一入口，产生 “整体” 感觉，最小代价实现一体化操作
	数据集成	数据	不同来源的数据逻辑或物理上 “集中”，是其他集成方法的基础
	控制集成	应用逻辑	调用其他系统已有方法，达到集成效果
	业务流程集成（过程集成）	应用逻辑	跨企业，或优化流程而非直接调用，提升企业间信息共享能力
	门户集成	-	将内部系统对接到互联网上，实现信息对外发布
按传输方式分	消息集成	数据量小，交互频繁，立即地，异步	适用于实时性要求高、数据量不大的场景
	共享数据库	交互频繁，立即地，同步	适用于系统间数据交互紧密且需实时同步的场景
	文件传输	数据量大，交互频度小，即时性要求低（月末，年末）	适用于大批量数据传输，如月末、年末的数据汇总

二、电子政务类型及应用

电子政务根据服务对象不同分为 6 类，各类别及对应应用如下表：

类型	应用场景
G2G	基础信息的采集、处理和利用（如人口信息、地理信息）；政府间计划管理、财务管理、通信系统、各级政府决策支持
G2B	政府给企业单位颁发各种营业执照、许可证、合格证、质量认证
B2G	企业向政府缴税；企业向政府供应各种商品和服务（含竞 / 投标）；企业向政府提建议、申诉
G2C	社区公安和水、火、天灾等与公共安全有关的信息；户口、各种证件和牌照的管理
C2G	个人应向政府缴纳的各种税款和费用；个人向政府反馈民意（征求群众意见）；报警服务（盗贼、医疗、急救、火警等）
G2E	政府内部管理系统

三、原型种类划分

在系统开发中，原型可从两个维度划分，具体分类及特点如下：

划分维度	原型类型	特点
按是否实现功能	水平原型（行为原型模型）	在一定程度上实现用户交互层的界面布局和界面流转逻辑；反映系统宽度，不深入细节；有助于理解系统能力范围、促进需求讨论、获得需求和设计决策认可；常用于分析早期阶段
	垂直原型（结构原型）	用于分析和设计的后期阶段，深入研究和详细说明特性或功能；本质更具技术性，通过真实数据连接数据库，与现有子系统接口，精确反映关键功能
按最终结果	抛弃式原型	主要用于界面设计；基本思路是先做简单界面设计，让用户有直观感受以提出需求，需求获取后可抛弃该界面原型
	演化式原型	会保留原型，通过不断演化，逐步形成最终产品

四、传统五大类架构风格

传统架构风格分为五大类，每类包含对应的子风格，具体如下表：

五大架构风格	子风格
数据流风格	批处理、管道 - 过滤器
调用 / 返回风格	主程序 / 子程序、面向对象、层次结构
独立构件风格	进程通信、事件驱动系统（隐式调用）
虚拟机风格	解释器、规则系统
仓库风格	数据库系统、黑板系统、超文本系统

五、反规范化相关内容

1. 反规范化的优缺点

维度	具体内容
优点	降低连接操作的需求；降低外码和索引的数目；可能减少表的数目；能够提高查询效率
缺点	数据重复存储，浪费磁盘空间；可能出现数据完整性问题；为保障数据一致性，增加数据维护复杂性；降低修改速度

2. 反规范化实现的技术手段

技术手段	具体说明
增加冗余列	在多个表中保留相同的列，通过增加数据冗余减少或避免查询时的连接操作
增加派生列	在表中增加可以由本表或其它表中数据计算生成的列，减少查询时的连接操作并避免计算或使用集合函数
重新组表	若许多用户需要查看两个表连接后的结果数据，则把这两个表重新组成一个表，以减少连接而提高性能
水平分割表	根据一列或多列数据的值，把数据放到多个独立的表中；主要用于表数据规模很大、表中数据相对独立或数据需要存放到多个介质上的场景
垂直分割表	对表进行分割，将主键与部分列放到一个表中，主键与其它列放到另一个表中；在查询时减少 I/O 次数

六、微服务的优势

微服务架构具有 7 大优势，具体如下：

1. 技术异构性：每个服务可选择适合自身的技术实现，如社交平台用文档型数据库存帖子、图数据存朋友圈关系；同时为新技术提供试验场，可先在单个微服务尝试，熟练后再推广。
2. 弹性：单块系统一部分故障可能导致整体问题，而微服务中每个服务可内置可用性解决方案与功能降级方案，弹性更强。
3. 扩展：单块系统扩展需整体进行，微服务可针对单个服务扩展，更灵活高效。
4. 简化部署：单块系统修改一行代码也需重新部署整个应用，风险高；微服务中每个服务部署独立，可快速对特定部分代码部署。
5. 与组织结构相匹配：解决大型团队管理难题，避免过大代码库，获得理想团队大小及生产力；服务所有权可在团队间迁移，避免异地团队问题。
6. 可组合性：系统开放多个接口供外部使用，情况变化时可通过不同方式构建应用；而整体化应用程序仅提供粗粒度接口。
7. 对可替代性的优化：单块系统删除代码关联性强，风险高；微服务中可轻易重写服务或删除不再使用的服务。

七、软件系统质量属性分类

基于软件系统的生命周期，质量属性分为开发期和运行期两类，具体如下表：

分类	包含类型	具体说明
开发期质量属性	易理解性	指设计被开发人员理解的难易程度
	可扩展性	指软件因适应新需求或需求变化而增加新功能的能力，也称为灵活性
	可重用性	指重用软件系统或某一部分的难易程度
	可测试性	指对软件测试以证明其满足需求规范的难易程度
	可维护性	指当需要修改缺陷、增加功能、提高质量属性时，识别修改点并实施修改的难易程度
	可移植性	指将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度
运行期质量属性	性能	指软件系统及时提供相应服务的能力，如速度、吞吐量和容量等的要求
	安全性	指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力
	可伸缩性	指当用户数和数据量增加时，软件系统维持高服务质量的能力（如通过增加服务器提高能力）
	互操作性	指本软件系统与其他系统交换数据和相互调用服务的难易程度
	可靠性	指软件系统在一定的时间内持续无故障运行的能力
	可用性	指系统在一定时间内正常工作的时间所占的比例；受系统错误、恶意攻击、高负载等影响
	鲁棒性（健壮性 / 容错性）	指软件系统在非正常情况（如用户非法操作、相关软硬件故障）下仍能正常运行的能力

八、常考质量属性及设计策略

质量属性	定义	代表参数	设计策略
性能	系统的响应能力，即对事件做出响应的时间或某段时间内处理事件的个数（如同时支持 1000 并发、响应时间小于 1s、显示分辨率达 4K）	响应时间、吞吐量	优先级队列、资源调度
可用性	系统能够正常运行的时间比例，常用两次故障间时间长度或故障恢复速度表示（如主服务器故障 1 分钟内切换至备用服务器、系统故障 1 小时内修复、支持 7×24 小时工作）	故障间隔时间	冗余、心跳线
安全性	系统向合法用户提供服务的同时阻止非授权用户使用或拒绝服务的能力，含机密性、完整性、不可否认性、可控性（如抵御 SQL 注入攻击、操作有完整记录、用户信息数据库授权 99.9% 可用）	-	追踪审计
可修改性（与可扩展性相近）	能够快速地以较高性能价格比对系统进行变更的能力，以具体变更代价衡量（如更改系统报表模块需在 2 人・周内完成、修改 Web 界面风格需在 4 人・月内完成）	-	信息隐藏（良好封装实现，也体现在安全性中）

九、云原生架构

1. 云原生架构设计原则

原则	具体说明
服务化原则	使用微服务架构拆分系统
弹性原则	可根据业务变化自动伸缩资源
可观测原则	通过日志、链路跟踪和度量监控系统状态
韧性原则	具备面对异常的抵御能力，保障系统稳定
所有过程自动化原则	采用自动化交付工具，提升部署效率
零信任原则	默认不信任网络内部和外部的任何人、设备、系统
架构持续演进原则	在业务高速迭代情况下，保持架构与业务平衡

2. 云原生架构模式

模式	具体说明
服务化架构模式	典型代表为微服务，服务拆分使维护压力大增
Mesh 化架构模式	把中间件框架（RPC、缓存、异步消息）从业务进程中分离，由 Mesh 进程完成
Serverless 模式	非常适合于事件驱动的数据计算任务
存储计算分离模式	各类暂态数据（如 session）用云服务保存
分布式事务模式	解决微服务模式中多数据源事务问题
可观测架构	包括 Logging（日志）、Tracing（链路跟踪）、Metrics（度量）三个方面
事件驱动架构	本质上是一种应用 / 组件间的集成架构模式

十、SAAM 和 ATAM 的区别

对比维度	SAAM（Scenarios-based Architecture Analysis Method）	ATAM（Architecture Tradeoff Analysis Method）
评估目标	对描述应用程序属性的文档，验证基本体系结构假设和原则；评估架构对特定系统需求的适用能力，也可比较不同架构	在考虑多个相互影响的质量属性的情况下，从原则上提供理解软件体系结构能力的方法；确定多个质量属性之间折中的必要性
质量属性	最初用于分析架构的可修改性，后来也用于可移植性、可扩充性等非功能质量属性	主要针对性能、实用性、安全性和可修改性
评估活动	包含五个步骤：场景开发、体系结构描述、单个场景评估、场景交互、总体评估	分为四个主要活动领域：场景和需求收集、体系结构视图和场景实现、属性模型构造和分析、折中

十一、网络攻击类型

网络攻击分为被动攻击和主动攻击，具体如下表：

攻击类别	攻击名称	描述
被动攻击（以收集信息为主，破坏保密性）	窃听（网络监听）	用各种合法或非法手段窃取系统中的信息资源和敏感信息
	业务流分析	通过对系统长期监听，利用统计分析方法研究通信频度、信息流向、通信总量变化等参数，发现有价值信息和规律
	非法登录	有些资料将这种方式归为被动攻击方式
主动攻击（破坏可用性、完整性、真实性）	假冒身份	通过欺骗通信系统（或用户），使非法用户冒充合法用户，或特权小的用户冒充特权大的用户；黑客多采用此方式攻击
	抵赖	来自用户的攻击，如否认自己曾经发布过的某条消息、伪造对方来信等
	旁路控制（旁路攻击）	在密码学中，绕过对加密算法的繁琐分析，利用密码算法硬件实现运算中泄漏的信息（如执行时间、功耗、电磁辐射），结合统计理论快速破解密码系统
	重放攻击	截获某次合法的通信数据拷贝，出于非法目的重新发送；加时间戳能识别并应对该攻击
	拒绝服务（DOS）	对信息或其它资源的合法访问被无条件地阻止

十二、可靠性模型

1. 好的可靠性模型应具备的特性

1. 基于可靠的假设；
2. 模型简单易懂；
3. 能够计算一些有用的量；
4. 给出未来失效行为的好的映射；
5. 可广泛应用于不同场景。

2. 可靠性模型的分类

可靠性模型大致分为 10 类，具体如下表：

模型类别	具体说明
种子法模型	预先有意 “播种” 一些设定的错误 “种子”，再看种子发现比例
失效率类模型	如 Jelinski-Moranda 的 De-eutrophication 模型、Schick-Wolverton 模型
曲线拟合类模型	用回归分析的方法研究软件复杂性、程序中的缺陷数、失效率、失效间隔时间
可靠性增长模型	预测软件在检错过程中的可靠性改进，用增长函数描述软件的改进过程
程序结构分析模型	根据程序、子程序及其相互间的调用关系，形成一个可靠性分析网络
输入域分类模型	选取软件输入域中的某些样本 “点” 运行程序，根据这些样本点在 “实际” 使用环境中的使用概率和测试运行时的成功 / 失效率，推断软件的使用可靠性
执行路径分析方法模型	先计算程序各逻辑路径的执行概率和程序中错误路径的执行概率，再综合出该软件的使用可靠性
非齐次泊松过程模型	以软件测试过程中单位时间的失效次数为独立泊松随机变量，预测在今后软件的某使用时间点的累计失效数
马尔可夫过程模型	如完全改错的线性死亡模型、不完全改错的线性死亡模型
贝叶斯分析模型	利用失效率的试验前分布和当前的测试失效信息，评估软件的可靠性

十三、常见的局域网拓扑结构

常见的局域网拓扑结构有星状结构、树状结构、总线结构、环形结构和网状结构，各类结构的特点与缺点如下表：

拓扑结构	特点	缺点
星状结构	每个结点设备以中心结点为中心，通过连接线与中心结点相连；数据传输需经中心结点；中心结点是控制中心，任意两结点通信最多两步；传输速度快、结构简单、建网容易、便于控制和管理	可靠性低，网络共享能力差；中心结点故障导致全网瘫痪
树状结构	又称分级的集中式网络；网络成本低，结构简单；任意两结点间无回路，链路支持双向传输；结点扩充方便、灵活，便于寻查链路路径	除叶结点及其相连链路外，任一工作站或链路故障都会影响整个网络系统正常运行
总线结构	各个结点设备和一根总线相连；所有结点设备通过总线进行信息传输	总线负载能力有限（由通信媒体物理性能决定）；总线故障影响总线上每个结点的通信
环形结构	各结点通过首尾相连的通信链路形成闭合环形结构网；各结点设备地位相同；信息按固定方向单向流动；两节点间仅有一条通路，无信道选择问题	网络不便于扩充；系统响应延时长，信息传输效率相对较低；任一结点故障导致物理瘫痪
网状结构	任何结点彼此之间均存在一条通信链路	网络布线繁琐，建设成本高；控制方法复杂

十四、嵌入式数据库分类

按照数据库存储位置不同，嵌入式数据库可分为三类，具体如下表：

类型	定义	特点
基于内存的数据库（MMDB）	实时系统和数据库系统的有机结合	支持实时事务的最佳技术；本质特征是以其 “主拷贝” 或 “工作版本” 常驻内存，活动事务只与实时内存数据库的内存拷贝打交道
基于文件的数据库（FDB）	以文件方式存储数据库数据，数据按一定格式储存在磁盘中；使用时由应用程序通过相应驱动程序甚至直接对数据文件进行读写	访问方式是被动式；了解文件格式即可直接读取，安全性很低；可满足嵌入式系统在空间、时间等方面的特殊要求
基于网络的数据库（NDB）	基于手机 4G/5G 移动通信基础之上的数据库系统；逻辑上可把嵌入式设备看作远程服务器的一个客户端	无需解析 SQL 语句；支持更多的 SQL 操作；客户端小、无需支持可剪裁性；有利于代码重用；由客户端、通信协议和远程服务器三部分组成（客户端提供接口，协议规范通信、解决并发，服务器维护数据）

十五、鸿蒙操作系统整体架构

鸿蒙操作系统整体遵从分层设计，从下向上分为内核层、系统服务层、框架层和应用层，且系统功能按 “系统→子系统→功能 / 模块” 逐级展开，多设备部署时可按需裁剪或增加子系统 / 功能模块，具体如下表：

架构层级	组成	功能说明
内核层	内核子系统、驱动子系统	内核子系统：采用多内核设计，支持针对不同资源受限设备选用合适的 OS 内核；驱动子系统：鸿蒙系统硬件生态开放的基础，提供统一外设访问能力和驱动开发、管理框架
系统服务层	系统基本能力子系统集、基础软件服务子系统集、增强软件服务子系统集、硬件服务子系统	鸿蒙系统的核心能力集合，通过框架层对应用程序提供服务
框架层	Java/C/C++/JS 等多语言用户程序框架、Ability 框架、各种软硬件服务对外开放的多语言框架 API	为鸿蒙系统应用程序提供多语言开发框架和 API；为搭载鸿蒙系统的电子设备提供 C/C++/JS 等多语言框架 API
应用层	系统应用、第三方非系统应用	系统应用包括桌面、控制栏、设置、电话等；第三方非系统应用为扩展应用；鸿蒙系统应用由一个或多个 FA（Feature Ability）或 PA（Particle Ability）组成

此外，鸿蒙 OS 架构的系统安全性体现在分布式终端上，通过 “分布式多端协同身份认证” 保证 “正确的人”，“在分布式终端上构筑可信运行环境” 保证 “正确的设备”，“分布式数据跨终端流动时分类分级管理” 保证 “正确地使用数据”。

十六、冷备份和热备份及相关概念

1. 冷备份与热备份的优缺点

备份方式	优点	缺点
冷备份（静态备份）	备份方法快速（只需复制文件）；容易归档（简单复制即可）；容易恢复到某个时间点（只需将文件再复制回去）；能与归档方法结合，做数据库 “最佳状态” 的恢复；低度维护，高度安全	单独使用时，只能提供到某一时间点上的恢复；备份全过程中，数据库必须停止工作，不能做其他操作；若磁盘空间有限，只能复制到磁带等外部存储设备，速度慢；不能按表或按用户恢复
热备份（动态备份）	可在表空间或数据库文件级备份，备份时间短；备份时数据库仍可使用；可达到秒级恢复（恢复到某一时间点上）；可对几乎所有数据库实体做恢复；恢复快速	不能出错，否则后果严重；若热备份不成功，所得结果不可用于时间点的恢复；难于维护，需特别小心，不允许 “以失败告终”

2. 其他相关备份概念

概念	定义
完全备份	备份所有数据
差量备份	仅备份上一次完全备份之后变化的数据
增量备份	备份上一次备份之后变化的数据
日志文件（事务日志）	针对数据库改变所做的记录，可记录针对数据库的任何操作，并将记录结果保存在独立的文件中

十七、分区和分表的区别、联系及分区策略

1. 分区与分表的区别和联系

维度	分表	分区
核心区别	真正生成新的数据表，将一张大数据量表分成多个小表实现数据均衡	不生成新的数据表，将表的数据均衡分摊到不同硬盘、系统或服务器存储介质中，实际仍是一张表
联系	两者都针对数据表，通过将数据分布式存储，提高数据检索效率，降低数据库频繁 I/O 压力

2. 分区的优点

1. 相对于单个文件系统或硬盘，分区可以存储更多的数据；
2. 数据管理方便，如清理或废弃某年数据，可直接删除该日期的分区数据；
3. 精准定位分区查询数据，无需全表扫描，大幅提高数据检索效率；
4. 可跨多个分区磁盘查询，提高查询吞吐量；
5. 涉及聚合函数查询时，容易进行数据合并。

3. 分区的策略

策略类型	具体说明
范围分区（RANGE）	根据数据库表中某一字段的值的范围划分分区；如年份小于 2016 的分成一个区，其他分成另一个区
散列分区（HASH）	根据字段的 hash 值进行均匀分布，尽可能实现各分区散列的数据相等
列表分区（LIST）	明确指定根据某字段的某个具体值进行分区，而非按字段值范围划分；如长沙、武汉分成一个区，北京分成一个区

十八、Kappa 架构与 Lambda 架构的区别

对比内容	Lambda 架构	Kappa 架构
复杂度与开发、维护成本	需要维护两套系统（引擎），复杂度高，开发、维护成本高	只需要维护一套系统（引擎），复杂度低，开发、维护成本低
计算开销	需要一直运行批处理和实时计算，计算开销大	必要时进行全量计算，计算开销相对较小
实时性	满足实时性要求	满足实时性要求
历史数据处理能力	批式全量处理，吞吐量大，历史数据处理能力强	流式全量处理，吞吐量相对较低，历史数据处理能力相对较弱
使用场景	直接支持批处理，更适合对历史数据分析查询的场景，期望尽快得到分析结果，批处理可更直接高效满足需求	非 Lambda 的替代架构，而是简化版本；放弃对批处理的支持，更擅长业务本身为增量数据写入场景的分析需求
选择依据	需考虑业务需求、技术要求、系统复杂度、开发维护成本和历史数据处理能力；计算开销差异不大，不作为主要考虑因素

十九、数字孪生体及相关技术

1. 数字孪生体的定义

数字孪生体是现有或将有的物理实体对象的数字模型，通过实测、仿真和数据分析来实时感知、诊断、预测物理实体对象的状态，通过优化和指令来调控物理实体对象的行为，通过相关数字模型间的相互学习来进化自身，同时改进利益相关方在物理实体对象生命周期内的决策。

2. 数字孪生体的技术

技术类别	具体技术	说明
核心技术	建模	目的是将对物理世界的理解简化和模型化；是创建数字孪生体、实现数字孪生的源头和核心技术，也是 “数化” 阶段的核心
	仿真	与建模是伴生体；验证和确认对物理世界或问题理解的正确性和有效性；是创建和运行数字孪生体、保证其与物理实体有效闭环的核心技术；通过软件模拟物理世界，模型正确且输入信息完整时可准确反映物理世界特性和参数
	数字线程	与建模、仿真共同构成数字孪生体的三项核心技术
顶层框架技术	系统工程和 MBSE	能够统领建模仿真和数字线程，为数字孪生体提供顶层框架支持
底层伴生技术	物联网	为数字孪生体提供底层数据采集和连接支持
外围使能技术	云计算、机器学习、大数据、区块链	为数字孪生体的构建和运行提供辅助支持，增强其功能和性能
其他相关技术	VR、AR、MR 等增强现实技术	用于数字孪生体的可视化展示和交互，提升用户对数字模型的感知和操作体验

二十、人工智能关键技术的应用场景和人工智能技术应用开发

1. 人工智能关键技术的应用场景

关键技术	应用场景
自然语言处理（NLP）	教育行业：语言学习助手、智能辅导、自动作业批改医疗行业：医疗问答、智能导诊、病历分析政府办公系统：智能政策咨询、信访内容自动分类电商行业：智能客服、评论情感分析军事系统：语音指挥、多语种情报分析、战报自动生成
计算机视觉（Computer Vision）	教育行业：课堂行为监控、在线考试监考、AR 教学医疗行业：CT/MRI 影像分析、手术辅助、患者监控政府办公系统：人脸识别安防、档案数字化、城市监控、证件真伪识别电商行业：商品图像识别、物流监控军事系统：卫星图像目标识别、无人机自主导航、战场感知
知识图谱（Knowledge Graph）	教育行业：学科知识体系、知识点关系呈现、课程推荐医疗行业：疾病 - 基因 - 药物关系网络构建政府办公系统：跨部门数据关联分析（如企业信用评估）电商行业：商品属性关系推理（如搭配推荐）军事系统：作战知识库构建（地形 / 装备 / 敌情）
人机交互（HCI）	教育行业：智能白板、语音交互学习系统医疗行业：智能诊断界面、患者自助系统政府办公系统：智能政务终端、语音交互系统电商行业：智能搜索界面、语音购物助手军事系统：智能指挥界面、语音控制系统
虚拟现实 / 增强现实（VR/AR）	教育行业：虚拟实验室、历史场景沉浸式教学医疗行业：手术模拟、康复训练政府办公系统：城市规划模拟、应急演练电商行业：虚拟商店、AR 商品展示、虚拟试穿军事系统：作战模拟、战术训练
机器学习（ML）	教育行业：学习行为预测、个性化学习计划、知识点掌握度分析医疗行业：慢性病风险预测、药物分子筛选政府办公系统：舆情风险预警、反欺诈电商行业：销量预测、动态定价军事系统：战场态势预测、装备故障预判

2. 人工智能技术应用开发相关概念

概念	说明
大模型	如基于 Transformer 的通用语言模型，能解决多任务语言处理问题（如 DeepSeek、ChatGPT）；用途包括对话、翻译、文本生成、代码生成
提示词	引导模型输出的指令，用于解决任务定制和输出控制问题
智能体（AI Agent）平台	自主决策系统，用于解决自动化任务和复杂决策问题（如 Coze、Dify、FastGPT、manus）
MCP（多模态处理技术）	解决跨模态理解和复杂场景推理问题（如 CLIP、Flamingo）
模型微调	在预训练大模型（如 GPT-4、Llama 等）基础上，用特定领域或任务的数据进行二次训练，使模型适应新场景；是迁移学习的核心方法，解决通用大模型在垂直领域表现不足的问题
RAG（检索增强生成）引擎	结合检索与生成，解决知识更新和领域特定问答问题（如 RAGFlow）；用途是建立本地知识库，优先用本地知识库解决问题，以解决 AI 幻觉问题

---

4. 关键问题

问题 1：在系统架构设计中，微服务架构相比传统单块架构，具备哪些核心优势？这些优势如何解决单块架构在实际应用中的痛点？

答案：微服务架构相比传统单块架构，核心优势及对单块架构痛点的解决如下：

1. 技术异构性：单块架构采用统一技术栈，尝试新技术时影响整体系统，风险高；微服务中每个服务可选适合自身的技术，如社交平台用文档型数据库存帖子、图数据存关系，还可在单个服务先试验新技术，熟练后推广，降低新技术应用风险。
2. 弹性：单块架构某部分故障可能导致整体瘫痪；微服务中每个服务可内置可用性与功能降级方案，部分服务故障不影响整体，提升系统稳定性。
3. 扩展：单块架构扩展需整体扩容，资源浪费严重；微服务可针对高负载单个服务扩展，如电商秒杀场景仅扩展订单服务，提高资源利用率。
4. 简化部署：单块架构修改一行代码也需重新部署整个应用，风险高、周期长；微服务每个服务独立部署，修改特定服务无需影响其他，加快部署速度、降低风险。
5. 与组织结构匹配：单块架构下大型团队管理难，代码库庞大易出问题，异地团队协作更复杂；微服务可按团队划分服务，避免过大代码库，服务所有权可迁移，适配团队结构，提升生产力。

问题 2：软件系统的质量属性按生命周期分为开发期和运行期两类，试分别阐述两类质量属性的具体内容，并说明在系统设计过程中，如何针对运行期的 “性能” 和 “安全性” 这两个关键质量属性制定设计策略？

答案：

一、开发期与运行期质量属性具体内容

1. 开发期质量属性：共 6 类，分别是：
   • 易理解性：设计被开发人员理解的难易程度，影响团队协作效率。
   • 可扩展性：软件适应新需求或需求变化时增加新功能的能力（灵活性），关系系统后期迭代。
   • 可重用性：重用软件系统或某部分的难易程度，可降低开发成本。
   • 可测试性：对软件测试以证明其满足需求规范的难易程度，影响测试效率与质量。
   • 可维护性：修改缺陷、增加功能、提高质量属性时，识别并实施修改的难易程度，影响系统运维成本。
   • 可移植性：将软件从一个运行环境转移到另一个不同环境的难易程度，影响系统部署灵活性。
2. 运行期质量属性：共 7 类，分别是：
   • 性能：系统及时提供相应服务的能力，如速度、吞吐量、容量，直接影响用户体验。
   • 安全性：系统向合法用户提供服务，同时阻止非授权使用的能力，含机密性、完整性等。
   • 可伸缩性：用户数和数据量增加时，系统维持高服务质量的能力，如通过增加服务器实现。
   • 互操作性：与其他系统交换数据和调用服务的难易程度，影响系统集成能力。
   • 可靠性：系统在一定时间内持续无故障运行的能力，关系系统稳定性。
   • 可用性：系统正常工作时间占比，受故障、攻击、高负载等影响。
   • 鲁棒性（健壮性 / 容错性）：系统在非正常情况（如非法操作、软硬件故障）下仍正常运行的能力。

二、运行期 “性能” 和 “安全性” 的设计策略

1. 性能设计策略：
   • 优先级队列：对请求按重要性或紧急程度排序，优先处理高优先级请求，如电商平台优先处理支付请求，避免关键业务因低优先级请求阻塞而响应缓慢。
   • 资源调度：合理分配 CPU、内存、网络等资源，如根据服务负载动态调整资源分配，对高负载服务分配更多资源，确保系统整体响应速度，例如对视频播放服务在高峰期分配更多带宽，保证播放流畅性。
2. 安全性设计策略：
   • 追踪审计：记录系统所有操作，包括用户登录、数据修改、权限变更等，形成审计日志，便于事后追溯安全事件源头。如当发生数据泄露时，可通过审计日志查看哪些用户在何时访问或修改了敏感数据，同时也能对非法操作起到威慑作用，减少恶意行为。

问题 3：企业集成是系统架构中的重要环节，按集成点可分为界面集成、数据集成、控制集成、业务流程集成和门户集成五类，试对比这五类集成方式的集成点、核心效果及关键应用场景，并说明为何数据集成是其他集成方法的基础？

答案：

一、五类集成方式的对比

集成方式	集成点	核心效果	关键应用场景
界面集成	界面	统一系统入口，让用户产生 “整体” 使用感觉，无需切换多个系统界面	企业内部存在多个独立系统（如 OA 系统、财务系统、人事系统），用户需频繁切换系统操作，通过界面集成将各系统界面整合到统一平台，提升操作效率
数据集成	数据	实现不同来源数据在逻辑或物理上 “集中”，消除数据孤岛	企业需要进行数据分析决策，如销售数据分散在销售系统、库存数据在库存系统、财务数据在财务系统，通过数据集成将这些数据集中到数据仓库，用于生成销售报表、库存预警报表等
控制集成	应用逻辑	调用其他系统已有的方法或功能，实现系统间功能协同	电商平台下单流程中，订单系统需调用支付系统的支付接口、库存系统的扣减库存接口，通过控制集成实现各系统功能调用，完成下单全流程
业务流程集成（过程集成）	应用逻辑	跨企业或企业内部优化业务流程，而非直接调用单一功能，提升流程效率	供应链管理中，企业的采购系统需与供应商的发货系统、物流企业的物流跟踪系统协同，通过业务流程集成优化采购 - 发货 - 物流跟踪全流程，实现信息实时同步，减少沟通成本
门户集成	-	将企业内部系统对接到互联网，实现信息对外发布或外部用户访问内部系统	企业需要向客户提供自助服务，如银行将账户查询、转账等功能通过门户集成到互联网银行平台，客户可通过互联网访问银行内部系统相关功能，无需到线下网点

二、数据集成是其他集成方法基础的原因

数据是系统运行的核心基础，其他集成方式的实现均依赖于数据的有效流转和共享：

1. 界面集成：虽然表面是整合界面，但界面展示的内容本质是各系统的数据，若没有数据集成实现各系统数据的同步与共享，统一界面将无法准确展示完整、实时的信息，失去实际使用价值。例如整合 OA 和财务系统界面，若财务数据未与 OA 系统数据集成，OA 界面无法展示员工报销进度等财务相关信息。
2. 控制集成：调用其他系统功能时，通常需要传递输入数据并获取输出数据，数据集成保证了数据在不同系统间的格式统一和准确传输，确保功能调用的成功。如订单系统调用支付系统接口，需传递订单金额、订单号等数据，数据集成确保这些数据能被支付系统正确识别和处理。
3. 业务流程集成：跨流程的协同本质是多系统间数据的有序传递和处理，数据集成实现了各环节数据的实时同步，保证流程按预期推进。如供应链流程中，采购系统的采购订单数据需同步到供应商系统，供应商发货数据需同步到物流系统，若无数据集成，各环节数据孤立，流程将无法顺畅运行。
4. 门户集成：外部用户通过门户访问内部系统功能时，需获取内部系统数据或向内部系统提交数据，数据集成确保内外系统数据交互的准确性和安全性，实现门户功能的正常使用。如互联网银行门户向客户展示账户余额，需从银行内部核心系统获取数据，数据集成是实现该功能的基础。

因此，数据集成是其他集成方法实现的前提和基础，没有数据集成，其他集成方式将无法有效发挥作用。

四、写在最后

又是一年1024，去年的时候还在实习，现在已经成为真正的“牛马”了，想到下个月又要考系统架构师的考试，真的是忙成”陀螺“了。但是有什么办法呢，时间在向前走，自己总不能落后吧，”何时葡萄成熟，你要静候再静候“，共勉！！！