系统架构设计师题库

架构评审时，业务方只说“系统要高可用、响应快”。架构师进一步把需求写成：在促销高峰期，普通用户从移动端提交订单请求，订单服务在主库短暂抖动的环境下仍应返回明确结果，95% 请求在 2 秒内完成，失败请求进入可追踪补偿队列。这个写法主要是在补充（）。

某分布式缓存集群使用普通取模方式分配 key 到节点。每次新增或删除缓存节点时，大量 key 都会重新映射，造成缓存大面积失效。架构师希望节点变化时尽量只迁移少量 key，较适合采用（）。

某微服务调用下游库存服务时出现短暂超时。开发人员准备让所有失败请求立即无限重试，架构师认为这样可能在下游刚刚变慢时进一步放大压力，形成重试风暴。较合理的改进措施是（）。

某微服务系统对外需要统一入口，集中处理路由、认证、限流和协议转换；同时，服务之间的大量内部调用希望通过 Sidecar 代理统一处理熔断、重试、流量治理和可观测性。关于 API 网关和 Service Mesh 的分工，下列说法较合理的是（）。

某互联网系统上线新版本时，先让 2% 的用户访问新版本，观察错误率、延迟、订单转化等指标；若指标正常，再逐步扩大到 10%、30%、100%。这种发布策略更接近（）。

某微服务系统希望把数据库连接串、功能开关、限流阈值、第三方接口地址等运行配置集中管理，并支持按环境发布和必要时动态刷新。另一个组件则负责记录服务实例地址，供调用方找到可用服务。前者更接近（），后者更接近（）。

某订单系统通过消息队列异步通知积分服务。少量消息因为参数异常或下游服务错误，重试多次后仍无法成功处理。如果这些消息一直在主队列中反复重试，会影响后续正常消息消费。架构师希望把这类异常消息隔离保存，便于告警、排查和后续人工补偿。较合适的机制是（）。

某电商系统在秒杀开始后的几分钟内订单请求暴增，如果每个请求都同步写数据库和调用库存、支付等服务，下游系统很容易被瞬时流量压垮。架构师希望先把请求写入一个缓冲组件，再由后端消费者按可承受速率处理。较合适的设计是（）。

某图片和视频访问量很大的网站，把静态资源分发到离用户更近的边缘节点。用户访问时优先从边缘节点获取内容，只有未命中或内容过期时才回源站。该设计主要利用了（）。

某业务系统写入时需要严格校验业务规则和事务一致性，而查询侧需要面向报表、搜索和列表展示做复杂聚合。架构师将命令写入模型与查询读取模型分开设计，以便分别优化。该架构思想通常称为（）。

某电商系统中，商品服务、库存服务和推荐服务共享同一批调用线程。推荐服务偶发响应很慢时，大量线程被占用，商品和库存调用也被拖慢。架构师为不同下游服务配置独立线程池和容量限制，主要是为了实现（）。

某订单流程需要依次完成创建订单、扣减库存、扣款和发放权益。系统不希望长时间锁住多个服务的数据库，而是把大事务拆成一系列本地事务；如果后续步骤失败，则执行取消订单、恢复库存、退款等补偿动作。该思路更接近（）。

某微服务系统一次下单请求会经过网关、订单、库存、支付和通知等多个服务。用户反馈下单偶尔很慢，单看某一个服务日志很难判断时间耗在哪一段。为了把一次请求经过的服务、调用顺序和每段耗时串起来分析，较合适的能力是（）。

订单系统完成支付后，只发布“订单已支付”事件，库存、积分、通知等服务各自订阅该事件并独立处理。订单系统不需要同步调用每个下游服务，也不关心它们的内部实现。该设计主要体现了（）。

某系统上线新版本时，同时保留旧版本环境和新版本环境。流量先从旧环境切到新环境，如果新版本出现严重问题，可以迅速把流量切回旧环境。这种发布方式通常称为（）。

某微服务系统对外提供订单、库存、支付、会员等多个服务。架构师希望外部客户端不用分别了解每个服务地址，并希望在统一入口完成认证、路由、限流和日志记录。较合适的架构组件是（）。

第三方支付平台在未收到商户系统确认时，可能多次重试发送同一笔支付成功回调。如果商户系统每收到一次回调就重复发货或重复加款，风险很大。较合理的架构设计是（）。

某秒杀系统在活动开始前限制下单接口每秒最多接收一定数量的请求；另一个系统在下游库存服务连续超时后，暂时停止继续调用该库存服务，并返回兜底提示。上述两种措施分别更接近（）。

某电商系统中，攻击者不断请求大量根本不存在的商品 ID。由于缓存中查不到，数据库中也查不到，这些请求持续绕过缓存打到数据库，造成数据库压力升高。该现象更接近（）。

某微服务系统中，订单服务调用积分服务时经常超时，导致订单线程大量阻塞，进一步影响下单主流程。为了避免单个依赖故障拖垮整个链路，架构上较合适的措施是（）。

在分布式系统设计中，架构师讨论一致性、可用性和分区容错性之间的取舍。CAP 定理通常强调，在发生网络分区时，系统难以同时完全满足（）。

某 Web 系统访问量持续增长，单台应用服务器已经难以承受。架构师计划部署多台应用服务器，并把用户请求按策略分发到不同节点。该方案主要体现了（）。

某系统由两个必须同时正常工作的组件串联组成，组件 A 可用性为 0.99，组件 B 可用性为 0.98。假设两者独立，则系统总可用性约为（）。

某系统要求年可用率达到 99.9%。按一年 365 天、8760 小时粗略计算，该系统一年不可用时间约为（）。

在微服务架构中，服务实例数量和地址可能动态变化，调用方需要能够找到可用服务实例。用于解决该问题的机制通常称为（）。

某核心业务系统要求单个服务器故障时服务仍能继续对外提供能力。架构设计中更合适的措施是（）。

某大型业务系统被拆分为多个围绕业务能力构建的小服务，各服务可以独立开发、独立部署，并通过轻量级通信机制协作。这种架构风格通常称为什么？

某系统要求在部分节点故障时仍能继续对外提供服务，并尽量缩短故障恢复时间。该需求主要体现哪一种软件质量属性？

应用程序先查询缓存，缓存未命中时再访问数据库，并把查询结果写入缓存。后续请求优先从缓存读取。该模式通常称为什么？

分布式系统设计中，CAP 理论认为一致性、可用性和分区容错性三者在网络分区发生时通常不能同时完全满足。CAP 中的 P 指的是哪一项？

系统架构设计中，性能、可用性、安全性、可维护性等通常被称为什么？

将系统划分为表示层、业务逻辑层和数据访问层等层次，以降低耦合和提高可维护性，这属于哪种架构风格？

在微服务架构中，服务之间通过轻量级协议通信，并围绕业务能力进行拆分。下列说法较为合理的是？

在分布式系统中，CAP 理论中的 P 通常指的是什么？