企业官网建设流程全解析

566｜系统架构设计师考试精华：系统架构基础篇

又一篇精华汇总！这次聚焦系统架构基础。

考试重点

1. 软件架构定义

软件架构 = 系统的基本结构 + 组件之间的关系 + 设计原则 关键点： - 架构决定系统的质量属性 - 架构影响开发效率和维护成本 - 架构需要平衡多方利益

2. 架构风格分类

3. 架构视图

4+1视图： - 逻辑视图：功能需求 - 开发视图：代码结构 - 进程视图：运行时进程 - 物理视图：硬件部署 - 场景视图：用例 TOGAF视图： - 业务架构 - 应用架构 - 数据架构 - 技术架构

4. 质量属性

可用性： - 指标：可用率 = MTBF / (MTBF + MTTR) - 技术：冗余、故障转移、监控 性能： - 指标：响应时间、吞吐量 - 技术：缓存、异步、集群 可扩展性： - 垂直扩展：增加单机资源 - 水平扩展：增加机器数量 安全性： - 机密性、完整性、可用性 - 认证、授权、审计

核心知识点速记

架构定义：结构 + 关系 + 原则 四大架构风格： - 分层：UI + 业务 + 数据 - 微服务：服务拆分、独立部署 - 事件驱动：发布订阅、异步 - 领域驱动：业务模型为核心 架构视图：逻辑 + 开发 + 进程 + 物理 + 场景 质量属性：性能、可用性、可扩展、安全性 架构决策：权衡 + 模式 + 风险

典型题目

题目：以下哪种架构风格最适合"高并发、频繁变更"的互联网应用？ A. 分层架构 B. 微服务架构 C. 管道过滤器 D. 事件驱动 答案：B 解析：微服务架构适合互联网应用， 特点：服务独立、可以独立部署和扩展， 适合需求频繁变更、高并发的场景。

567｜系统架构设计师考试精华：软件设计原则篇

考试重点

SOLID原则

S - 单一职责原则 一个类只负责一项职责 "一个类有且只有一个改变的原因" O - 开闭原则 对扩展开放，对修改封闭 "软件实体应该对扩展开放，对修改关闭" L - 里氏替换原则 子类可以替换父类 "所有引用基类的地方必须能透明地使用其子类的对象" I - 接口隔离原则 接口要小而专 "客户端不应该依赖它不需要的接口" D - 依赖倒置原则 依赖抽象，不依赖具体 "高层模块不应该依赖低层模块"

设计模式分类

GRASP原则

General Responsibility Assignment Software Patterns - Information Expert（信息专家） → 分配给拥有信息的类 - Creator（创建者） → 分配给创建某类实例的类 - Controller（控制器） → 处理系统事件的类 - Low Coupling（低耦合） → 最小化依赖 - High Cohesion（高内聚） → 类的职责单一

核心知识点速记

SOLID： 单一职责-一 开闭原则-开 里氏替换-换 接口隔离-小 依赖倒置-抽 设计模式分类： 创建型-工厂单例 结构型-适配器装饰器代理 行为型-观察者策略命令 GRASP： 信息专家有信息 创建者创建实例 控制器处理事件 低耦合少依赖 高内聚职责专

568｜系统架构设计师考试精华：分布式系统篇

考试重点

CAP定理

C - Consistency（一致性） A - Availability（可用性） P - Partition Tolerance（分区容错） 三者不可兼得，最多同时满足两个： CP：Redis、HBase、Zookeeper AP：Eureka、Cassandra、DynamoDB

BASE理论

Basically Available：基本可用 Soft State：软状态 Eventually Consistent：最终一致 是对CAP中AP的扩展， 适用于分布式系统

分布式事务

2PC： - 阶段1：投票 - 阶段2：提交/回滚 - 缺点：同步阻塞、单点故障 TCC： - Try：预留资源 - Confirm：确认执行 - Cancel：取消回滚 Saga： - 将长事务拆成多个短事务 - 失败时正向补偿

一致性协议

Paxos： - 少数服从多数 - 共识算法 - 用于分布式协调 Raft： - 简化版Paxos - Leader + Follower + Candidate - 选举 + 日志复制

核心知识点速记

CAP：C一致性 A可用性 P分区容错 最多选两个 Redis选CP，Eureka选AP BASE： 基本可用软状态 最终一致是目标 分布式事务： 两段提交要同步 TCC预留再确认 Saga链式补偿 一致性协议： Paxos共识难实现 Raft简化为选举

569｜系统架构设计师考试精华：微服务与云原生篇

考试重点

微服务特征

1. 服务独立部署 2. 服务可替换 3. 去中心化治理 4. 独立数据存储 5. 基础设施自动化 6. 容错设计 7. 智能端点与哑管道

微服务设计原则

1. 单一职责原则 2. 领域驱动设计 3. 先上下文，后微服务 4. 前缀并行，不要前期预测 5. 不惜一切代价避免单体

云原生特征

- 容器化 - 微服务 - 动态管理（K8s） - 面向敏捷 12-Factor App： 1. 基准代码 2. 依赖声明 3. 配置外部化 4. 后端服务当作资源 5. 构建、发布、运行分离 6. 无状态进程 7. 端口绑定 8. 并发 9. 易处理 10. 开发环境等价 11. 日志作为事件流 12. 管理进程一次性

K8s核心资源

Pod：最小调度单位 Deployment：管理Pod副本和版本 Service：服务发现和负载均衡 Ingress：HTTP入口 ConfigMap/Secret：配置管理 PV/PVC：持久化存储

核心知识点速记

微服务特征： 独立部署可替换 去中心化治理 独立数据存储 自动化基础设施 云原生： 容器微服务K8s 12因子要记牢 K8s： Pod是基本单位 Deployment管版本 Service做发现 Ingress做入口

570｜系统架构设计师考试精华：系统质量与运维篇

考试重点

可用性指标

可用率 = MTBF / (MTBF + MTTR) 99% = 87.6小时/年 99.9% = 8.76小时/年 99.99% = 52.6分钟/年 99.999% = 5.26分钟/年 MTBF：平均故障间隔时间 MTTR：平均恢复时间

可靠性设计

1. 冗余设计 - 冷备、温备、热备 - 主备、双主、集群 2. 负载均衡 - 硬件负载均衡 - 软件负载均衡 - 客户端负载均衡 3. 故障转移 - 自动故障检测 - 自动切换 - 数据一致性保证

高可用架构

主备模式： - 一主一备 - 主故障切换到备 集群模式： - 多节点协同 - 共识协议保证一致性 多活模式： - 同城多活 - 异地多活

运维监控

可观测性三支柱： - Logs（日志） - Metrics（指标） - Traces（链路） 监控层次： - 基础设施监控 - 中间件监控 - 应用监控 - 业务监控

核心知识点速记

可用性： 99%是一年87小时 999是一年8.7小时 9999是一年52分钟 99999是一年5分钟 可靠性设计： 冗余备份防单点 负载均衡分发 自动故障转移 高可用： 主备切换 集群共识 多活容灾 运维监控： 日志指标链路 三分支要记牢

板块四精华汇总篇（566-570）已完成！

这些精华篇涵盖了系统架构设计师考试的核心知识点，适合考前快速复习。