系统架构设计师——【2024年上半年案例题】真题模拟与解析（二）
系统架构设计师——【2024年上半年案例题】真题模拟与解析（二）
试题三：微服务架构与缓存策略
题目背景：
某电商公司计划将其单体架构的系统重构为微服务架构，以应对日益增长的业务复杂性和用户并发请求。新系统划分为用户服务、订单服务、商品服务、支付服务等多个微服务。架构师王工负责设计整个系统的架构，并需要解决高并发下的数据一致性和性能问题。
问题 1：在微服务架构中，服务发现是至关重要的组件。请简述客户端发现模式和服务端发现模式的工作原理，并分别说明其优缺点。（8分）
参考答案与解析：
服务发现是微服务间相互定位和通信的基础机制。
- 客户端发现模式：
- 工作原理： 微服务实例启动后向服务注册中心注册自身网络地址（如IP和端口）。消费者服务（调用方）从注册中心查询所有可用服务实例的列表，并在本地使用负载均衡算法（如轮询、随机）选择一个实例直接发起请求。
- 优点： 架构简单，去除了中间代理，减少了网络跳数，性能较高；客户端可以灵活定制负载均衡策略。
- 缺点： 客户端与注册中心耦合，需要为不同编程语言实现服务发现逻辑，增加了客户端的复杂性。
- 服务端发现模式：
- 工作原理： 微服务实例同样向注册中心注册。消费者服务将请求发送到一个稳定的中间层（通常是负载均衡器或网关），由该中间层查询注册中心，并将请求转发到可用的服务实例。
- 优点： 客户端无需关注服务发现细节，实现更简单、更通用；负载均衡、熔断等策略可以集中管理和升级。
- 缺点： 需要额外部署和管理一个高可用的中间层系统（如AWS ALB、Nginx），架构更复杂，可能成为性能瓶颈和单点故障（需做高可用部署）。
问题 2：针对商品详情页的高并发读取场景，王工决定引入Redis作为缓存。请描述缓存穿透、缓存击穿、缓存雪崩这三个概念，并针对每种情况提出一种以上的解决方案。（9分）
参考答案与解析：
- 缓存穿透：
- 概念： 指查询一个一定不存在的数据（如不存在的商品ID）。由于缓存中不命中，请求会穿透到数据库，但数据库中也没有，因此不会回写缓存。这导致大量此类请求直接压到数据库上。
- 解决方案： 接口层校验： 对请求参数进行合法性校验（如检查ID格式、范围），拦截明显异常的请求。 缓存空值： 即使从数据库没查到，也将这个空结果（或默认值）进行缓存，并设置一个较短的过期时间（如1-5分钟），后续请求将命中缓存的空值，从而保护数据库。
- 缓存击穿：
- 概念： 指某个热点key在缓存中过期（失效）的瞬间，同时有大量请求这个key，这些请求发现缓存失效后，会同时去数据库查询并回写缓存，导致数据库瞬间压力过大。
- 解决方案： 设置热点数据永不过期： 对于极热点数据，可以设置为逻辑过期。后台任务定期异步更新缓存。 加互斥锁（Mutex Lock）： 当缓存失效时，只允许一个线程去查询数据库并回写缓存，其他线程等待。待缓存被重建后，其他线程即可从缓存中获取数据。分布式环境下需使用分布式锁（如Redis的
SETNX命令）。
- 缓存雪崩：
- 概念： 指在某一时段，大量缓存key同时过期（失效），导致所有请求都落到数据库上，造成数据库压力骤增甚至宕机。
- 解决方案： 差异化过期时间： 给缓存数据的过期时间加上一个随机值（如基础时间+随机1-5分钟），避免大量key在同一时间点过期。 构建高可用缓存集群： 通过Redis哨兵或集群模式，防止缓存系统本身宕机导致所有请求涌向数据库。 服务降级和熔断： 当检测到数据库压力过大时，对非核心业务进行服务降级或直接熔断，保护核心业务和数据库。
问题 3：在订单创建过程中，需要调用库存服务进行扣减。请简述在分布式（微服务）环境下，如何保证“扣减库存”和“生成订单”这两个操作的事务一致性。请列举两种常见的解决方案并简要说明其原理。（8分）
参考答案与解析：
在分布式系统中，难以使用传统的ACID事务（两阶段提交2PC复杂且性能差），通常采用最终一致性方案。
- TCC（Try-Confirm-Cancel）补偿事务：
- 原理： 将一个分布式事务拆分为两个阶段和三个操作： Try阶段： 尝试执行。完成所有业务的检查（如库存检查、账户余额检查），并预留必需的业务资源（如冻结部分库存）。 Confirm阶段： 确认执行。真正提交业务，使用Try阶段预留的资源（如扣减冻结的库存，生成订单）。要求Try成功则Confirm必定成功。 Cancel阶段： 取消执行。释放Try阶段预留的业务资源（如解冻冻结的库存）。
- 由事务管理器统一管理这些操作的执行和补偿，保证最终一致性。
- 基于消息队列的最终一致性：
- 原理： 订单服务在本地事务中创建订单（状态为“待确认”），并向消息队列发送一条“扣减库存”的消息。这是一个本地事务，保证订单创建和消息发送是原子性的。 库存服务订阅该消息，执行库存扣减操作。如果成功，则向消息队列发送一条成功应答。 订单服务消费到成功应答后，将订单状态更新为“已确认”。 如果库存扣减失败，或消息超时未得到处理，则由订单服务或一个补偿job根据“待确认”的订单进行取消或重试。
试题四：系统安全架构设计
题目背景：
某金融机构需要开发一个线上贷款申请系统，处理用户的敏感个人信息和金融数据。系统架构师陈工负责设计系统的安全架构，以确保数据 confidentiality（机密性）、integrity（完整性）和 availability（可用性）。
问题 1：请说明数字证书在SSL/TLS协议中的作用和工作原理。（6分）
参考答案与解析：
数字证书在SSL/TLS中用于实现身份认证和密钥交换。
- 作用：
- 身份认证： 向客户端证明服务器的真实身份，防止中间人攻击。客户端通过验证证书是否由可信的证书颁发机构（CA）签发，以及证书中的域名与应用的目标域名是否一致，来确认正在通信的是目标服务器。
- 密钥交换： 证书中包含了服务器的公钥。客户端在验证证书有效后，会使用该公钥加密一个预主密钥（Pre-Master Secret），并发送给服务器。只有持有对应私钥的服务器才能解密获得该预主密钥，从而双方可以基于此生成对称加密所需的会话密钥。
- 工作原理（简化）：
- 客户端向服务器发起HTTPS请求。
- 服务器将其数字证书发送给客户端。
- 客户端使用内置的可信CA公钥验证服务器证书的数字签名，确保证书真实有效且未被篡改。
- 验证通过后，客户端生成预主密钥，用证书中的服务器公钥加密后发送给服务器。
- 服务器用自己的私钥解密，得到预主密钥。
- 双方根据预主密钥生成相同的会话密钥，后续通信使用该对称会话密钥进行加密解密，保证通信安全。
问题 2：为防止SQL注入攻击，请说明在系统架构和编码层面可以采取哪些措施。（8分）
参考答案与解析：
| 层面 | 措施 | 说明 |
|---|---|---|
| 架构层面 | 1. 使用ORM框架（如MyBatis, Hibernate） | 框架使用预编译语句（Prepared Statements）和参数化查询，将用户输入永远视为数据而非SQL代码的一部分，从根本上杜绝SQL注入。 |
| 2. 部署Web应用防火墙（WAF） | 在网络边界对流入的HTTP流量进行检测和过滤，可以识别并阻断常见的SQL注入攻击模式。 | |
| 3. 实施最小权限原则 | 为数据库操作账户分配仅能满足其功能所需的最小权限，避免使用root或sa等高权限账户连接数据库，即使被注入也能减少损失。 | |
| 编码层面 | 1. 强制使用参数化查询（Prepared Statements） | 这是最重要最有效的手段。在编写SQL时，使用?或:name作为占位符，然后通过API设置参数值。 |
| 2. 严格的输入校验和过滤 | 对用户输入的数据类型、长度、格式（如邮箱、电话）进行严格校验。拒绝包含SQL敏感字符（如单引号、分号）的输入，或对其进行转义（但转义不如参数化查询可靠）。 | |
| 3. 避免动态拼接SQL语句 | 绝对不要将用户输入直接拼接到SQL查询字符串中。 | |
| 4. 安全的错误处理 | 不要将详细的数据库错误信息直接返回给前端用户，以免暴露数据库结构，为攻击者提供便利。应记录详细日志，并向用户返回通用错误信息。 |
问题 3：该贷款系统需要记录所有用户的关键操作（如登录、提交申请、审批通过/拒绝），请简述如何设计一个安全审计日志模块，需说明日志记录的内容、存储方式及安全保护措施。（11分）
参考答案与解析：
一个安全可靠的审计日志模块是满足合规性和事后追溯的关键。
- 日志记录内容：
- 基本事件信息： 事件发生时间（UTC时间戳）、事件唯一ID、事件类型/名称（如
USER_LOGIN,LOAN_APPLICATION_SUBMIT）。 - 主体信息： 操作用户的唯一标识（如用户ID）、IP地址、用户角色。
- 客体信息： 被操作的对象标识（如贷款申请ID）、操作对象的类型。
- 操作结果： 操作成功或失败的状态、失败的原因码。
- 详细上下文： 操作前后关键数据的变化详情（如审批前额度、审批后额度）。注意： 记录敏感信息（如身份证号、银行卡号）前需进行脱敏处理（如只显示后四位）。
- 基本事件信息： 事件发生时间（UTC时间戳）、事件唯一ID、事件类型/名称（如
- 日志存储方式：
- 实时写入： 日志产生后应立即写入目标系统，避免在应用内存中缓存，防止进程崩溃丢失日志。
- 集中化存储： 不应将日志存储在本地服务器。应使用日志采集代理（如Filebeat, Fluentd） 实时收集日志，并传输到集中式日志管理系统（如ELK Stack：Elasticsearch, Logstash, Kibana；或Splunk）中。这便于统一管理、查询和分析，也避免了单点故障。
- 长期归档： 根据合规要求（如至少保存6个月），将超过一定时间的日志从在线存储（如Elasticsearch）转移到更廉价的长期存储（如对象存储S3、HDFS或磁带库）中。
- 安全保护措施：
- 完整性保护： 对重要的审计日志计算其数字签名或哈希值（如使用HMAC），并定期校验，防止日志被篡改。
- 机密性保护： 对于包含极高敏感信息的日志，在存储和传输过程中应进行加密（如使用TLS传输，使用AES加密存储）。
- 访问控制： 对集中日志系统的访问必须实施严格的身份认证和权限控制。只有授权的安全审计员才能访问和查询日志数据，并且应根据职责分离原则，限制其操作权限（如只读）。
- 防篡改与防删除： 配置日志系统的只读（Read-Only）或只追加（Append-Only） 策略，防止任何人（包括系统管理员）随意修改或删除历史日志。