2025年架构试题库及答案

2025年架构试题库及答案一、微服务架构1.微服务架构中，服务拆分的核心原则有哪些？如何避免过度拆分导致的复杂度激增？核心原则包括：①业务边界驱动，基于领域驱动设计（DDD）划分限界上下文，确保服务对应独立业务功能；②独立演进，每个服务具备独立的生命周期，支持单独部署与版本迭代；③松耦合，服务间通过接口而非实现依赖，降低修改传播风险；④高内聚，服务内部聚焦单一业务能力，避免功能冗余。避免过度拆分需：①通过领域事件分析业务流程的强依赖关系，仅拆分强独立的子域；②建立服务契约（如OpenAPI）并实施自动化测试，确保接口稳定性；③定期进行架构评审，评估服务间调用复杂度（如调用链长度、跨服务事务占比），合并低价值的微小服务。2.微服务治理中，服务熔断与服务降级的核心区别是什么？实际部署中如何协同配置？熔断是故障隔离机制，当服务A调用服务B的失败率超过阈值（如5分钟内错误率≥80%），触发熔断，后续请求直接返回预设错误，避免A因B故障耗尽资源。降级是功能取舍策略，在系统过载时（如CPU利用率≥90%），暂时关闭非核心功能（如推荐模块），优先保障核心业务（如支付）。协同配置时，需先通过熔断阻断故障传播，再通过降级释放资源。例如：对用户详情服务设置熔断阈值（错误率≥70%触发），同时对评论查询功能设置降级规则（QPS≥5000时返回缓存的简化数据），确保核心的用户登录流程不受影响。二、云原生架构3.云原生场景下，Kubernetes的HorizontalPodAutoscaler（HPA）与VerticalPodAutoscaler（VPA）的核心作用有何不同？如何结合使用以优化资源效率？HPA基于负载动态调整Pod数量（如CPU利用率≥80%时扩容），解决水平扩展问题；VPA根据资源使用情况自动调整Pod的CPU/内存请求与限制，解决垂直资源分配问题。结合使用时，VPA为每个Pod设置合理的资源上下限（避免资源浪费或不足），HPA在此基础上根据实时负载增减实例。例如：对订单服务配置VPA，将内存请求从2Gi动态调整为1.5Gi（当平均使用量为1.2Gi时），同时配置HPA（CPU≥70%时从3个Pod扩容至5个），既保证单Pod资源充足，又能应对流量高峰。4.服务网格（如Istio）如何实现服务间通信的可观测性？关键技术包括哪些？服务网格通过在每个服务旁部署Sidecar代理（如Envoy）拦截所有流量，自动收集指标（请求数、延迟、错误率）、日志（完整请求路径）和链路追踪数据（提供全局TraceID）。关键技术包括：①流量镜像，将一定比例的流量复制到分析系统；②元数据注入，在请求头中添加服务版本、实例ID等信息；③分布式追踪，通过B3协议（TraceID、SpanID）关联跨服务调用链路。例如：用户下单请求经API网关→订单服务→库存服务，Sidecar会为整个调用链提供同一TraceID，在Jaeger中展示各环节耗时，快速定位慢调用。三、分布式系统设计5.分布式一致性协议中，Raft与Paxos的核心差异是什么？生产环境中如何选择？Raft通过强领导（Leader）简化共识过程，将一致性问题分解为领导选举、日志复制两个阶段，更易理解和实现；Paxos包含Prepare、Accept、Commit多阶段，允许无固定领导，理论更普适但实现复杂。选择时：①需快速落地的场景（如内部缓存集群）优先Raft（etcd即基于Raft）；②需处理更复杂网络分区的场景（如分布式数据库）可考虑Paxos（如GoogleChubby）；③对维护成本敏感时，Raft因实现简单更具优势。6.分布式事务中，Seata的AT模式与TCC模式的适用场景有何不同？各自的实现限制是什么？AT模式基于数据库本地事务和回滚日志，自动提供补偿操作，适用于业务逻辑简单、数据库支持回滚日志（如MySQL的undolog）的场景（如电商下单扣库存）。限制：需数据库支持行锁，且事务未提交时会占用锁资源，长事务可能导致锁超时。TCC模式要求业务方显式实现Try（预留资源）、Confirm（提交资源）、Cancel（释放资源）接口，适用于跨服务、跨数据库的复杂事务（如订单支付+积分扣减+优惠券使用）。限制：需改造业务代码，且Confirm/Cancel需保证幂等性（多次调用结果一致）。四、架构设计原则与实践7.领域驱动设计（DDD）中，聚合根（AggregateRoot）的核心职责是什么？如何通过聚合根控制业务边界？聚合根是领域模型中的核心实体，负责：①封装聚合内的所有实体与值对象，确保内部业务规则的一致性；②作为外部访问的唯一入口，外部只能通过聚合根操作聚合内的对象；③维护聚合的生命周期（如创建、删除）。控制业务边界时，聚合根通过限制跨聚合的直接数据访问，强制通过领域事件（如OrderCreatedEvent）传递变更，避免不同聚合间的紧耦合。例如：订单聚合根（Order）包含订单项（OrderItem），库存服务不能直接修改OrderItem的数量，需通过Order聚合根触发“库存扣减”事件，由库存服务消费事件后更新自身库存聚合。8.高并发系统中，如何通过“流量削峰”策略降低系统压力？请列举至少三种技术方案并说明适用场景。①消息队列缓冲：将请求写入Kafka队列，业务系统按自身处理能力消费（如每秒处理1000单），适用于非实时性要求高的场景（如日志收集）。②令牌桶限流：通过Redis分布式令牌桶控制每秒请求数（如限制API网关QPS为5000），适用于需保护核心服务的场景（如支付接口）。③延迟处理：将非核心请求（如用户评论审核）标记为“待处理”，夜间低峰时批量处理，适用于业务允许延迟的场景（如内容审核）。五、安全架构9.零信任架构中，“持续验证”的核心实现方式有哪些？云环境下如何结合IAM与微隔离增强安全性？持续验证包括：①设备可信验证（检查终端是否安装杀毒软件、系统版本是否合规）；②用户行为分析（通过机器学习识别异常登录地点、操作频率）；③会话动态评估（定期重新认证，如支付操作需二次验证）。云环境中，IAM（身份与访问管理）通过细粒度策略（如“开发人员仅能读取测试环境日志”）控制权限，微隔离通过网络策略（如KubernetesNetworkPolicy）限制服务间横向访问（如订单服务仅允许调用库存服务的8080端口），两者结合实现“最小权限+动态控制”的安全模型。10.API安全设计中，如何防止接口被恶意爬取？请结合具体技术方案说明。方案包括：①签名验证，请求携带时间戳+APIKey+随机数的HMAC签名，服务端校验签名有效性（防止重放攻击）；②频率限制，通过Redis记录IP或用户ID的请求次数（如每分钟≤100次），超限返回429；③行为检测，分析请求特征（如短时间内大量不同参数请求），触发验证码或封禁IP。例如：对商品详情接口，要求请求头包含X-Sign（timestamp+nonce+secret的SHA256哈希），同时限制单个IP每分钟最多请求200次，异常请求需完成滑动验证码后才能继续访问。六、性能优化与容量规划11.数据库性能优化中，索引设计的常见误区有哪些？如何通过执行计划（EXPLAIN）验证索引有效性？误区：①过度索引（增加写操作开销）；②索引列选择不当（如对低基数列[性别]建索引，区分度低）；③忽略复合索引顺序（未按查询条件的最左匹配原则排序）。通过EXPLAIN分析：①检查type字段，理想值为“ref”或“eq_ref”（表示使用索引查找），若为“ALL”则全表扫描；②查看key字段，确认是否使用预期索引；③关注rows字段，评估扫描行数（行数越少索引越有效）。例如：查询“SELECTFROMordersWHEREuser_id=123ANDstatus=’paid’”，若复合索引为(user_id,status)，则EXPLAIN的key应显示该索引，rows应远小于表总记录数。12.容量规划中，如何基于历史数据预测未来6个月的系统资源需求？关键步骤包括哪些？步骤：①数据收集，提取过去1年的QPS、CPU/内存利用率、数据库IOPS等指标；②趋势分析，用时间序列模型（如ARIMA）预测业务增长（如QPS月均增长15%）；