2025年软考系统架构设计师经典案例分析题含答案.docxVIP

2025年软考系统架构设计师经典案例分析题含答案

【案例背景】

2025年3月，某东部沿海城市“智慧海事”二期工程启动，目标是整合船舶交通管理系统（VTMS）、港口国监督检查系统（PSC）、航运公司安全管理系统（SMS）以及气象、海关、边检等12个异构系统，形成统一的海事数据中台，支撑“一图统览、一网统管、一脑调度”。项目总投资3.8亿元，建设周期18个月，采用“政府主导、企业建设、购买服务”模式，承建方为中科软海（联合体），监理方为交通部信息中心。项目核心指标：

1.峰值并发≥5万艘次/小时，数据延迟≤200ms；

2.7×24可用性≥99.98%，RPO≤15s，RTO≤5min；

3.支持三级等保2.0（含商用密码应用安全性评估）；

4.支持亿级AIS（船舶自动识别系统）动态数据实时关联分析；

5.预算偏差≤±5%，进度偏差≤±3%。

项目组织架构：

决策层：市海事局副局长（甲方总指挥）

管理层：项目管理办公室（PMO）

执行层：总架构师（乙方）、分系统架构师、安全架构师、数据架构师、运维架构师

外部干系人：航运企业、船级社、引航站、运营商、云厂商（阿里云为IaaS提供方）

【试题一】（25分）

阅读下列说明，回答问题1至问题4，将解答填入答题纸的对应栏内。

【说明】

总架构师李工在需求评审会上提出：传统“烟囱式”系统导致数据重复采集、口径不一致，二期必须建立“海事主题数据模型”，实现“一数一源、一源多用”。经多轮研讨，团队决定采用“领域驱动+数据湖+API网关”融合架构，技术栈如下：

实时层：Kafka3.6+Flink1.17流处理，毫秒级摄取AIS、雷达、摄像头视频结构化数据；

批处理层：Spark3.4onK8s，每日凌晨运行T+1批量修正；

数据湖：Iceberg1.3onOSS，保存原始、清洗、聚合三层数据；

服务层：SpringCloud2023.x+Dubbo3.2，暴露REST与gRPC双协议；

前端：WebGL+数字孪生，三维渲染5万艘船舶模型，帧率≥30fps；

安全：国密SM2/SM3/SM4全链路加密，零信任架构，动态细粒度访问控制。

【问题1】（6分）

李工要求“数据湖内原始区禁止任何DDL操作”，请从数据治理角度说明该约束的三条核心理由，并指出对后续ETL流程的影响。

【答案】

理由1：防止原始数据被意外修改或删除，确保数据血缘可追溯，满足审计合规要求；

理由2：保证“一次采集、多次消费”，任何下游清洗逻辑变更均需在清洗区完成，避免污染唯一真相源；

理由3：阻断直接对原始区建表、加列等操作，强制团队通过版本化的ETL代码（Git）管理结构变更，实现InfrastructureasCode。

影响：所有字段解析、类型转换、代码值映射必须在清洗区落地；ETL任务失败时无法通过回滚DDL修复，必须重跑整个FlinkJob并回放KafkaTopic，要求Kafka开启LogCompaction且保留期≥7天。

【问题2】（7分）

峰值场景下，KafkaTopic“ais_realtime”写入吞吐达280MB/s，Partition24个，副本因子3。经监控发现，Flink消费延迟偶发飙升至3s。李工拟调整参数，请给出三项最可能产生立竿见影效果的Kafka端调优配置，并说明原理。

【答案】

1.提高num.io.threads=16（默认8），增加网络线程，缓解Broker端磁盘IO等待；

2.调大replica.fetch.max.bytes=10MB（默认1MB），降低Follower拉取延迟，缩短ISR列表抖动；

3.开启log.segment.bytes=2GB（默认1GB）并调小log.roll.ms=600000（10min），减少Segment文件数量，降低文件句柄压力，提升顺序写吞吐。

原理：高峰流量下，Broker成为瓶颈，增大IO线程与单次Fetch字节可提升网络利用率；Segment策略优化减少PageCache竞争，降低磁盘随机IO。

【问题3】（6分）

数据湖Iceberg表“dwd_ais_clean”采用隐藏分区（bucket(ship_id,16)）+时间分区(day)。现需支持“按船名模糊查询+时间范围”组合条件，查询延迟要求≤800ms。请给出一种索引或文件布局优化方案，并估算其存储膨胀率。

【答案】

方案：在Iceberg元数据层新增Parquet布隆过滤器（BloomFilter）列“ship_name”，并启用Par