系统架构师考试主要考查哪些核心能力？

Question

系统架构师考试（软考高级）主要考查五大核心能力：**系统分析与建模能力**（如UML、领域驱动设计）、**架构设计与评估能力**（含微服务、云原生、高可用/可扩展架构选型与ATAM评估）、**技术决策与权衡能力**（性能vs成本、安全vs体验、新技术引入风险控制）、**工程治理能力**（DevOps流程、质量保障体系、技术债务管理）以及**跨域协同与沟通能力**（将业务需求精准转化为技术方案，并向干系人清晰阐述架构意图）。常见技术问题如：“如何为日活500万的电商App设计订单中心架构？请说明分库分表策略、最终一致性保障机制及降级预案”，该题即综合考查分布式架构设计、CAP权衡、容错设计与业务理解深度。考试强调“架构即决策”，重在考察解决真实复杂问题的系统性思维，而非单纯技术堆砌。

Answer 1

```html

一、系统分析与建模：从电商订单业务域出发的领域驱动设计（DDD）建模

面对日活500万的电商App，首先需剥离“订单”这一核心业务概念的语义边界。采用事件风暴（Event Storming）工作坊识别关键领域事件：OrderPlaced、PaymentConfirmed、InventoryDeducted、OrderShipped。据此划分限界上下文（Bounded Context），明确订单中心作为独立领域，与用户中心、库存中心、支付中心通过防腐层（ACL）交互。

使用UML活动图刻画下单主流程（含异常分支），并用类图建模聚合根OrderAggregate（含OrderId、OrderItems、Status等不变量约束）。该阶段输出《订单领域模型说明书》，为后续架构决策提供语义锚点。

二、架构设计与评估：基于ATAM的多维度架构权衡分析

质量属性	场景描述	架构响应	敏感点
可用性	支付回调超时导致订单状态卡滞	引入Saga模式+本地消息表+定时补偿任务	消息表写入延迟、补偿周期配置
可扩展性	大促期间订单创建TPS峰值达12,000/s	读写分离 + 分库分表（按userId % 64分库，orderId % 16分表）	分片键选择导致热点、跨库JOIN缺失

ATAM评估确认：放弃强一致性（牺牲C），保障AP下的高可用与分区容忍性；通过最终一致性达成业务可接受的SLA（如99.99%订单状态3秒内收敛）。

三、技术决策与权衡：CAP三角中的务实取舍与成本控制

• 性能 vs 成本：放弃全链路分布式事务（Seata AT模式），改用TCC+幂等校验——降低中间件运维复杂度，节省30%云数据库实例费用；
• 安全 vs 体验：订单详情页敏感字段（收货人手机号）前端动态脱敏（*号替换），而非服务端加密传输——规避加解密CPU开销，保障首屏渲染<800ms；
• 新技术风险：拒绝在核心链路引入Service Mesh（Istio），因团队无生产级eBPF调优经验；改用轻量级Sidecar（Envoy+自研控制面）灰度验证。

四、工程治理：DevOps流水线与技术债务可视化管控

graph LR
  A[Git Commit] --> B[静态扫描-SonarQube]
  B --> C{技术债务评级}
  C -->|高危| D[阻断流水线]
  C -->|中危| E[自动创建Jira Debt Ticket]
  E --> F[每月架构委员会评审]
  F --> G[债务偿还排期看板]

构建“技术债务热力图”，将分库分表后遗留的跨库统计SQL、未覆盖的Saga补偿失败路径等标记为P0级债务，并纳入迭代计划。质量保障体系要求：核心接口混沌工程注入失败率≥5%，全链路压测覆盖订单创建/查询/取消三主路径。

五、跨域协同与沟通：面向干系人的架构叙事与可视化表达

向CTO汇报时，聚焦ROI：分库分表方案使单库数据量从8TB降至120GB，RTO从4小时压缩至15分钟；向产品经理说明“订单状态最终一致”时，用状态机图展示Pending→Confirmed→Shipped→Completed流转及各状态超时自动升级规则；向测试团队交付《一致性验证手册》，定义12类异常组合场景（如“支付成功但库存扣减失败”）的预期行为与断言脚本。

所有架构决策文档均嵌入“决策日志（Decision Log）”元数据：日期、发起人、备选方案、否决理由、验证指标（如“降级开关生效后P99延迟≤200ms”）。

```