【系统架构师】14. 案例特训-架构设计篇

阅读数: 2025-04-25

课程内容提要

软件架构风格

质量属性与架构评估

这类题是该考试中案例分析题中为数不多几乎可以拿满分的题。

可用性：出现故障能迅速修复的能力

可修改性：修改的难易程度，通常衡量为人天（工作量）

c是敏感点 g是权衡点（安全和性能是明显的权衡点）i是非风险点（xxx是可以实现的，典型的非风险点）

j是安全性（容易理解成可用性，但是这是授权可用性，而不是系统可用性，此时系统可能依旧可用）

k是风险点（注意不是可修改性，非功能性都不是质量属性）

m是可测试性（可调试是典型的可可测试性）

Web架构综合考察

单机到应用与数据分离

集群与负载均衡

越靠上层效率越低，因此传输层的效率更高

硬件复杂均衡就是一个硬件预装了负载均衡的软件

F5 是美国 F5 Networks 公司的硬件负载均衡产品，是一种网络设备。它能把网络流量按一定规则（如轮询、最少连接数等）均匀分配到多个服务器上，避免单个服务器压力过大。

同时，F5 还能检查服务器状态，若有服务器故障就停止给它分流量。它也具备应用优化和安全防护功能，比如压缩数据让应用访问更快，抵御 DDoS 攻击等。常用于大型网站、数据中心等对网络性能要求高的场景。

集群与有状态无状态服务

1 和 4 是有状态服务，其他都是无状态服务

持久化技术

数据库读写分离

主从数据库同步指的是将主数据库上的数据变更同步到从数据库，以保证数据的一致性。以下是常见的主从数据库同步方式：

基于日志的同步

二进制日志（Binlog）同步 - 以 MySQL 为例

原理：主数据库会将所有对数据进行修改的操作记录到二进制日志中。从数据库通过连接主数据库，请求主数据库发送二进制日志，然后从数据库会读取这些日志，并将其中的操作在自己的数据库上重新执行一遍，以此实现数据同步。

优点：这种方式可以精确地记录所有的数据变更，而且对主数据库的性能影响较小，因为记录日志的操作是异步的。

缺点：如果主从数据库的版本不一致，可能会存在兼容性问题。同时，当主数据库的日志量非常大时，从数据库同步可能会有一定的延迟。

预写式日志（WAL）同步 - 以 PostgreSQL 为例

原理：主数据库在对数据进行修改之前，会先将修改操作记录到预写式日志中。从数据库通过复制这些预写式日志，并在本地重新执行其中的操作，从而实现与主数据库的数据同步。

优点：提供了较高的数据一致性和可靠性，因为日志记录是在数据修改之前进行的，即使系统崩溃，也可以通过日志恢复数据。

缺点：可能会增加主数据库的磁盘 I/O 负担，因为需要频繁地写入日志文件。

基于触发器的同步

原理：在主数据库上设置触发器，当主数据库中的数据发生变化时，触发器会被触发，然后执行相应的操作将数据变更同步到从数据库。例如，当主数据库中的某个表插入一条新记录时，触发器会将这条记录插入到从数据库的相应表中。

优点：实现相对简单，不需要依赖数据库的日志系统，适用于一些对日志系统依赖较小的场景。

缺点：触发器会增加主数据库的额外开销，因为每次数据变更都需要触发相应的同步操作。而且，如果触发器的逻辑复杂，可能会影响主数据库的性能。同时，触发器的维护和管理相对复杂，特别是在数据量较大和业务逻辑复杂的情况下。

基于时间戳的同步

原理：在主从数据库的表中添加一个时间戳字段，用于记录数据的最后修改时间。主数据库在数据发生变更时，会更新相应记录的时间戳。从数据库定期检查主数据库中时间戳大于自己的记录，并将这些记录同步到本地。

优点：实现简单，不需要依赖数据库的特定功能，适用于各种类型的数据库。

缺点：同步的实时性较差，因为从数据库是定期检查更新，可能会存在一定的延迟。而且，当数据量较大时，定期检查的开销也会比较大。

基于消息队列的同步

原理：主数据库在数据发生变更时，将变更信息发送到消息队列中。从数据库作为消息队列的消费者，从队列中获取变更信息，并将其应用到本地数据库中。常见的消息队列有 Kafka、RabbitMQ 等。

优点：具有较高的灵活性和可扩展性，可以方便地实现多个从数据库的同步。同时，消息队列可以对数据变更进行缓冲，减轻主从数据库之间的压力。

缺点：引入了额外的组件（消息队列），增加了系统的复杂性和维护成本。而且，如果消息队列出现故障，可能会影响数据同步的正常进行。