一、 软件架构风格
这是架构考试中最基础也是最重要的部分，需要掌握各种风格的定义、优缺点及适用场景。
-
分层架构
-
定义：将系统垂直划分为若干层（如 MVC 的表现层、业务层、数据层）。
-
优点：结构清晰、职责分离、易于维护和扩展。
-
缺点 （重点记忆）：性能损耗 （请求必须穿过每一层）、级联修改（改底层可能影响上层）、代码冗余。
-
适用：企业级应用、Web 应用。
-
-
管道-过滤器风格
-
特征：强调数据像水流一样处理，处理过程有顺序性。
-
适用：批处理系统、编译器、信号处理。
-
-
微内核风格
-
特征 ：核心功能非常小（负责资源管理等最基础功能），扩展功能通过插件实现。
-
错题辨析 ：核心部分功能不庞大，庞大的是插件集合。
-
适用：操作系统（如 Minix）、IDE（如 Eclipse, VS Code）。
-
-
微服务架构 (Microservices)
-
特征：服务原子化、独立部署、去中心化治理。
-
对比单体：解决了单体的高耦合、扩展难问题，但带来了分布式系统的复杂性。
-
二、 质量属性与架构评估
架构设计的本质是权衡 (Trade-off)，即在不同的质量属性之间做取舍。
-
架构设计目标
-
核心目标：可维护性、可扩展性、性能、安全性、可靠性。
-
非目标：单纯增加功能数量（这是需求分析的事，不是架构设计的主要目标）。
-
-
架构评估
-
时机 ：越早越好，不应等到开发完成后。
-
方法 ：通常采用基于场景的评估方法（如 ATAM 架构权衡分析法）。
-
驱动力：通过质量属性场景（如"用户在1秒内收到响应"）来驱动评估。
-
-
可扩展性设计
-
原则：低耦合、高内聚、接口定义灵活。
-
反例：将所有功能集中在一个模块是扩展性的大忌。
-
三、 从单体到微服务的演进
这是当前架构设计中最热门的实战考点（对应 w9, w10 题）。
1. 单体架构的痛点
-
高耦合：牵一发而动全身，维护成本高。
-
扩展受限：只能整体扩容，无法针对瓶颈模块（如秒杀模块）单独扩容。
-
容错性差：一个模块崩溃可能导致整个进程挂掉。
-
部署慢：代码量大，编译启动慢，回滚风险大。
2. 优化/改造策略
-
业务拆分：基于 DDD（领域驱动设计）进行垂直拆分（用户服务、订单服务等）。
-
数据库优化：
-
读写分离：主写从读。
-
分库分表：解决海量数据存储和连接池瓶颈。
-
-
缓存机制：引入 Redis/Memcached 处理热点数据，减轻数据库压力。
-
异步解耦 ：引入消息队列 (MQ) 进行削峰填谷（如秒杀场景）。
3. 微服务架构面临的挑战
如果要实施微服务，必须解决以下问题：
-
服务划分：边界怎么定？粒度多大？
-
数据一致性：分布式事务（Saga, TCC, 最终一致性）。
-
通信机制：RESTful API (HTTP) 还是 RPC (Dubbo, gRPC)？
-
服务治理：
-
注册与发现 (Eureka, Nacos)
-
熔断与降级 (Sentinel, Hystrix)：防止服务雪崩。
-
全链路追踪 (SkyWalking, Zipkin)。
-
-
DevOps：自动化部署 (CI/CD)、容器化 (Docker/K8s)。
四、 系统安全性设计
遵循 "纵深防御" 原则，至少掌握以下三个层面的手段：
-
访问控制
-
认证：你是谁？（密码、生物识别、多因子）。
-
授权：你能干什么？（RBAC 角色访问控制, OAuth2.0）。
-
-
数据保护
-
加密：传输加密 (HTTPS/TLS)、存储加密。
-
完整性：防止篡改（数字签名、哈希校验）。
-
-
安全审计
- 日志监控：记录谁在什么时间做了什么，用于事后追责和异常发现。
五、 关键图表
-
模块图/包图：描述静态结构。
-
依赖图：描述模块间的依赖关系。
-
数据流图 (DFD)：描述数据如何在系统中流动和变换（结构化分析方法）。
备考建议
-
理解大于死记：特别是分层架构的优缺点和单体架构的问题，试着结合你做过的项目去理解。
-
关注"权衡"：在做选择题时，如果有选项说"某种架构完美无缺"，那通常是错的。架构总是有得有失（例如：微服务提高了扩展性，但降低了简单性）。
-
术语积累：熟悉 DDD（领域驱动设计）、MQ（消息队列）、Sharding（分片）、Cache（缓存）等专业术语。