一、这篇到底在讲什么从考试视角看这一篇并不是把一堆新技术拼在一起而是在讲两个扩张问题云原生在解决“应用怎么更快交付、更稳运行、更容易扩缩容”大数据在解决“数据量上来之后怎么采集、存储、计算和服务化输出”把它们放到一个真实场景里会更容易理解。以电商平台为例订单、支付、库存这些业务服务需要频繁发版、自动扩容、灰度发布这是云原生问题订单流、日志流、埋点流需要实时计算、离线分析、搜索检索这是大数据问题所以这一篇本质上是在回答两个问题应用规模扩大后系统该怎么部署和治理数据规模扩大后系统该怎么存储和计算二、知识点总述1. 云原生知识点总览云原生这一侧案例题真正关心的知识点主要有 6 个知识点核心作用在案例题里的本质出题点微服务把大系统拆成可独立演进的小服务为什么单体系统开始难以迭代和扩展容器统一运行环境标准化交付为什么环境不一致、部署慢、扩容慢Kubernetes大规模容器编排与自动化管理为什么有了容器还不够服务网格统一处理服务间通信治理为什么治理逻辑不能继续散在业务代码里DevOps / CI/CD缩短开发到上线的交付链路如何把构建、测试、发布、回滚流程化声明式 API用目标状态驱动平台自动收敛为什么云原生强调“声明我要什么”而不是“手工执行步骤”这几个点不是并列孤立的而是有因果关系的微服务让系统拆小了但部署对象变多了容器解决了部署对象怎么标准化打包K8s 解决了大量容器怎么自动调度和管理服务网格解决了大量服务之间怎么统一治理DevOps 解决了这些服务怎么高频、稳定地交付声明式 API 解决了平台如何按目标状态自动维护系统也就是说考试里如果题干同时出现“微服务 容器 自动扩缩容 灰度发布 服务治理”本质上就是在考一个完整的云原生治理链而不是单点名词解释。2. 大数据知识点总览大数据这一侧案例题通常围绕 5 类知识点展开知识点核心作用在案例题里的本质出题点分布式存储与计算解决海量数据存储和并行处理数据量上来后单机为什么撑不住批处理与流处理分别解决离线分析与实时处理实时性和准确性如何平衡Lambda / Kappa组织实时与离线链路的整体架构要不要维护两套链路如何处理重算大数据组件选型针对不同场景选择不同工具Kafka、HBase、ES、Spark、Flink 各自解决什么问题数据仓库 / 数据湖解决分析口径和原始数据沉淀问题为什么有的场景强调建模有的场景强调先接入如果把它们串成一条数据链路可以这样理解先有业务数据、日志数据、行为数据不断产生再用消息队列或采集链路把数据接进来然后落到分布式存储里保存再用批处理或流处理引擎做加工计算最后输出到报表、检索、推荐或实时看板所以考试里大数据不是考“背 Hadoop 家族”而是在考面对不同数据特征和业务目标架构应该怎样分层、组件应该怎么选。3. 云原生和大数据之间的关系很多人复习时容易把两部分分开记但案例题里它们常常出现在同一业务背景下。例如一个互联网平台可能同时存在业务服务层订单、支付、库存等微服务跑在容器和 K8s 上数据接入层业务事件和日志进入 Kafka实时计算层Flink 处理订单流和监控流离线计算层Spark 生成离线分析结果数据服务层HBase 提供明细查询ES 提供日志检索数仓提供 BI 报表因此你在考试里不能把“应用架构”和“数据架构”完全割裂。很多题目其实考的是上层业务系统怎么云原生化下层数据系统怎么大数据化二者如何一起支撑业务增长。4. 这一篇最重要的几个对比关系这篇内容真正容易出题的往往不是定义本身而是相近方案之间的边界对比项核心区别案例题常见问法容器 vs 虚拟机轻量和交付效率 vs 强隔离和完整虚拟化为什么新系统更适合容器化K8s vs 手工运维自动编排和自愈 vs 人工管理成本高为什么规模一大必须上编排平台服务网格 vs 业务代码治理治理能力下沉到基础设施 vs 每个服务重复实现为什么服务多了以后治理会失控Lambda vs Kappa双链路兼顾实时和准确 vs 单链路简化架构如何在准确性、复杂度、重算能力之间取舍HBase vs ES高吞吐随机读写 vs 检索与聚合分析海量明细查询和日志检索该怎么选数据仓库 vs 数据湖统一口径分析 vs 原始多源沉淀为什么企业往往两者并存如果这些边界说不出来案例题就容易从“知道技术名词”变成“不会落答案”。5. 这一篇通常要求掌握到什么深度系统架构师案例题在这一篇里通常不要求你写源码级、协议级或底层实现级细节但这不等于只写概念即可。它真正要考的是你能不能把题干中的业务问题翻译成架构问题再把架构方案翻译成卷面答案。很多人失分不是因为不懂Kubernetes、Kafka、Flink这些技术而是因为答案停留在“知道名词”没有继续往下写到“为什么是它、它解决什么、它的代价是什么、为什么不是另一个方案”。所以这一篇真正要求的深度可以拆成下面 5 个层次来理解。5.1. 能从题干症状判断应该落到哪类架构或组件这句话不是指“看到Pod就写Kubernetes”这么简单而是说你要能把题干里的业务现象识别成对应的架构问题。例如题干写“发布依赖人工、扩容慢、故障恢复慢”你就要判断这是云原生 / 容器编排问题题干写“既要实时结果又要最终准确”你就要判断这是Lambda / Kappa取舍问题题干写“日志要支持全文检索和聚合分析”你就要判断这是Elasticsearch选型问题也就是说考试不是问你“什么是某技术”而是在问你这些题干信号最终指向什么架构方向。答到位的标准是你能先说清题目暴露的核心矛盾再把这个矛盾准确归到某一类架构问题常见失分点是见到一个关键词就机械套技术名词没有先解释题目问题是什么就直接写方案5.2. 能写出方案解决的核心问题而不是只说“性能更高”这是案例题里非常关键的一层。很多答案的问题不在于“错”而在于“空”。例如你写“Kubernetes可以提高效率”这句话不能说错但得分很低因为它没有说明到底提高了什么效率也没有说明它是怎么解决问题的。更有得分点的写法应该是Kubernetes解决的是大规模容器的自动部署、统一调度、自愈恢复和滚动更新问题服务网格解决的是服务间通信治理逻辑散落在业务代码中的问题Kafka解决的是高吞吐数据接入、缓冲削峰和消息重放问题也就是说你写的不是“它很好”而是“它到底替系统解决了什么原本做不到或做不好的事情”。答到位的标准是能明确写出“原问题是什么”“该方案通过什么能力解决这个问题”常见失分点是只写“性能更高”“效率更高”“更先进”没有说明改造前后的问题变化5.3. 能写出至少 2 到 3 个收益和 2 到 3 个代价这意味着你不能把答案写成单边宣传稿。系统架构师案例题很少存在“纯收益、无代价”的方案。凡是值得考的架构都一定有取舍。你如果只写优点往往说明你只记了概念没有理解架构决策。例如上Kubernetes的收益可以写自动扩缩容、自愈、滚动更新、统一管理上Kubernetes的代价可以写集群运维更复杂、网络与存储治理更复杂、平台门槛更高上服务网格的收益可以写统一治理、统一安全、统一观测、降低业务侵入上服务网格的代价可以写代理开销增加、调用链变长、平台维护成本上升为什么这里要求“至少 2 到 3 个”因为只写 1 个收益、1 个代价往往说明你理解得还不够完整。考试更希望看到你知道这不是“要不要上”的问题而是“上了以后具体换来什么又付出什么”的问题。答到位的标准是收益不是一句空话而是具体能力例如弹性、自愈、统一治理、低延迟代价也不是一句空话而是具体成本例如双链路维护、平台复杂度、资源开销、运维门槛常见失分点是只写优点不写缺点代价写成一句“成本更高”但不说明高在哪5.4. 能做相近方案比较而不是只会单点介绍这一层决定了你是不是在“做架构选择”而不是“做名词解释”。因为案例题真正喜欢考的不是孤立问一个技术而是让你在两个相近方案之间做判断。例如容器和虚拟机怎么选Lambda和Kappa怎么选Spark和Flink怎么选HBase和Elasticsearch怎么选数据仓库和数据湖怎么选或者为什么要同时建设这类题如果你只是把两个概念分别解释一遍往往还是拿不到高分。高分答案一定会出现这种句子当前场景更强调实时响应因此更适合Flink而不是偏离线分析的Spark当前场景更强调海量明细随机读写因此更适合HBase而不是偏检索分析的Elasticsearch也就是说你不仅要知道“它是什么”还要知道“为什么这里选它而不是另一个”。答到位的标准是至少比较 2 到 3 个维度例如实时性、复杂度、数据访问模式、治理目标最后能给出明确结论而不是模糊地说“两个都可以”常见失分点是把两个方案各讲一遍但没有做结论只写“场景不同”却不说到底哪里不同5.5. 能把答案落到业务场景而不是停留在口号层面这是最后一层也是最像系统架构师思维的一层。因为考试最终不是在考你背了多少技术定义而是在看你能不能把技术语言翻译成业务语言。例如说云原生不要只写“自动化”要落到“发布更快、恢复更快、资源利用率更高”说服务网格不要只写“治理下沉”要落到“多团队、多语言服务可以统一治理”说Lambda不要只写“双链路”要落到“运营需要实时看数据财务需要最终准确报表”说数据仓库不要只写“面向主题建模”要落到“稳定 BI 报表和统一口径分析”也就是说好的卷面答案应该让阅卷人看到你不是在背术语而是真的知道这个方案为什么会被企业采用。答到位的标准是技术能力能对应到业务收益架构代价能对应到管理成本或工程成本常见失分点是全篇都在讲技术名词没有一句落到业务目标答案像百科词条不像架构分析所以简单把这一篇的考试深度概括成一句话还不够。更准确地说这一篇真正要求你做到的是先识别题干里的业务矛盾再选择对应的架构方向再说明这个方案具体解决什么问题再补足收益、代价和适用边界最后把技术语言翻译成业务语言如果把这 5 步都写出来你的答案才真正达到系统架构师案例题想要的深度。否则就很容易停留在“懂技术但不会答题”的层面。6. 高频题型速查表如果你想在短时间内先建立“看到题干就知道往哪答”的感觉可以先记下面这张表题型题干高频信号首先想到的答题方向必须补的一层深度云原生整体题人工部署、环境不一致、扩容慢、恢复慢传统部署向云原生演进不只写自动化还要补治理成本容器题标准化打包、迁移困难、部署慢容器解决环境和交付问题不只写优点还要写为什么后续需要 K8sKubernetes 题Pod、Service、Deployment、自愈、扩缩容容器编排与声明式管理不只写概念还要写为什么手工运维失效服务网格题重试、熔断、限流、链路追踪、安全策略难统一治理能力下沉到基础设施层不只写 Sidecar还要写统一治理价值与代理代价CI/CD 题发布频繁、测试慢、回滚难、上线不稳构建自动化交付闭环不只写效率提升还要写测试和权限前提Lambda / Kappa 题既要实时又要准确、要不要双链路、历史重算准确性、复杂度、重放能力三者取舍不只写定义还要明确为什么选其一Spark / Flink 题报表统计 vs 实时预警、批处理 vs 持续事件流离线计算还是实时流处理不只写产品名还要落到实时性要求Kafka / HBase / ES 题消息接入、明细查询、全文检索按数据访问模式做组件选型不只写“大数据组件”还要写为什么不用另外两个数仓 / 数据湖题统一口径、原始沉淀、多源异构、探索分析治理优先还是接入优先不只写概念区别还要写企业为什么并存建设三、案例题总的考法1. 出题人通常怎么设问这一篇常见的出题方式大概有四类先给现有系统瓶颈让你判断应该引入什么架构先给一套目标能力让你反推应该采用什么技术组合给两个相近方案让你比较优缺点和适用场景给一条业务或数据链路让你说明各层组件分工所以你看到题目时第一反应不应该是“定义是什么”而应该是题目暴露的问题在哪里出题人希望你答哪一层架构这道题最可能要求你补什么取舍2. 标准答题结构这类题最稳的写法一般是四步先归纳问题再提出方案、方案收益最后补方案代价和适用边界可以直接套成一句话该场景的核心问题是 xxx因此可采用 xxx 架构或组件它主要解决 xxx 问题能够带来 xxx、xxx 等收益但同时也会带来 xxx、xxx 等成本结合题干中的 xxx、xxx、xxx可以判断这里的出题点是 xxx。如果你担心考场上写散可以把这四步进一步固定成“每句对应一个动作”第一句只做诊断题目当前的瓶颈和矛盾是什么第二句只给方案建议采用什么架构、平台或组件第三句只写收益解决什么问题、带来哪些直接能力第四句只补边界增加什么复杂度、适合什么场景、不适合什么场景这样写的好处是卷面结构会非常稳定不容易漏掉“代价”和“边界”这两个高频得分点。3. 这一篇容易失分的地方这部分最常见的低分写法有四种只堆术语不对应题干中的业务问题只写优点不写成本和边界只说“提升性能、提升效率”不落到具体能力只说选某个组件却不说明为什么不选其他组件高分答案通常有三个特征先把题目的本质矛盾说出来再把收益和代价写完整最后把相近方案的边界讲清楚四、云原生部分在案例题里怎么考1. 云原生整体题这类题一般不会直接问“什么是云原生”而是通过现象来设问例如系统发布依赖人工效率低且容易出错高峰期扩容慢故障恢复依赖人工干预多环境配置不一致线上问题难复现服务越来越多部署、升级、治理变得混乱当题干出现这些信号时说明出题点通常落在“从传统部署走向云原生”。可直接写成下面这种答案当前系统在部署与运维上主要存在人工操作多、环境不一致、扩容依赖人工、故障恢复慢等问题传统方式已经难以支撑业务持续发布和弹性扩展。因此可引入云原生架构对应用进行容器化封装并基于容器编排平台实现自动部署、弹性伸缩、自愈恢复和声明式管理从而提升交付效率、运行稳定性和资源利用率。但云原生架构也会带来集群治理、镜像管理、配置管理、监控告警和运维体系建设等额外成本因此更适合服务规模较大、发布频繁、需要弹性扩缩容的业务场景。如果题目问“为什么要云原生化”答案至少要落到这 4 个得分点先点出现状问题人工部署、多环境不一致、扩容和恢复效率低再点出核心方案容器化 编排平台 自动化交付 声明式管理再写业务收益发布更快、扩容更快、运行更稳、资源利用更高最后补代价和边界平台复杂度、运维门槛、治理成本会上升最容易失分的写法是只写一句“云原生提高效率”这类表述太空不能直接形成卷面得分点。2. 容器题容器题常见信号有环境不一致应用迁移困难部署慢扩容慢服务需要标准化打包这里案例题一般不是考 Docker 命令而是考你是否知道容器解决什么、不解决什么。可直接写成下面这种答案容器技术的核心作用是将应用程序及其依赖环境统一封装为标准化镜像从而解决开发、测试、生产环境不一致的问题并提高应用部署和迁移效率。与虚拟机相比容器启动速度更快、资源开销更小更适合微服务场景下的快速交付和弹性扩缩容。但容器的隔离性相对较弱状态数据和持久化管理也更复杂。当业务服务数量持续增加后仅靠容器本身无法解决调度、扩容、自愈和统一管理问题因此通常还需要进一步引入 Kubernetes 等编排平台。这类题最好按“价值 - 边界 - 演进方向”来写价值统一环境、标准化交付、启动快、适合弹性部署边界隔离性弱于虚拟机持久化和状态管理更复杂演进方向容器多了以后必须继续解决编排和治理问题如果答案没有写出“为什么后面还要上 K8s”容器题通常只能拿到一半左右的分。3. Kubernetes 题K8s 是这篇里最稳定的高频考点之一。题干出现下面这些词时基本就该往 K8s 上靠Pod、Service、Deployment、Ingress自动扩缩容、自愈、滚动更新容器编排、集群调度、声明式部署可直接写成下面这种答案Kubernetes 是面向生产环境的容器编排平台主要用于解决大量容器实例的自动部署、统一调度、弹性扩缩容、故障自愈和滚动更新问题。当系统中的容器数量增多后单纯依靠人工运维已经无法满足上线效率和运行稳定性要求因此需要通过 Kubernetes 对容器集群进行统一管理。其中Pod 是最小调度单元Deployment 负责副本和升级策略Service 提供稳定访问入口这使系统能够在实例动态变化的情况下仍保持服务可用。与此同时Kubernetes 也会带来网络、存储、配置、安全和监控治理复杂度上升的问题因此适用于服务规模较大、交付频繁、需要自动化运维的场景。K8s 题要尽量写出下面 5 个固定得分点为什么需要它容器规模大后人工管理失效它解决什么调度、自愈、扩缩容、滚动更新、服务发现为什么 Service 很重要实例会变访问入口不能跟着变它体现什么思想声明目标状态由平台自动收敛它的代价是什么平台能力增强但治理和运维复杂度明显上升这里的高分点不是背概念而是把“K8s 为什么会出现”讲清楚容器解决了打包问题但没有解决大规模运行管理问题。4. 服务网格题服务网格题在案例题里一般不会让你讲 Istio 的安装过程而是通过治理问题来设问例如重试、超时、熔断逻辑散落在各个服务里多语言服务治理能力不一致服务间安全、观测、流量控制难统一微服务数量增长后治理策略难维护可直接写成下面这种答案当微服务数量持续增加后重试、超时、熔断、限流、链路追踪和服务间安全等治理逻辑如果继续分散在各个业务服务中会导致代码重复、治理策略不一致、跨语言维护困难等问题。因此可引入服务网格将服务间通信治理能力下沉到基础设施层。其典型实现方式是 Sidecar 代理模式即在每个业务服务旁部署代理组件由代理统一处理流量治理、安全控制和观测能力。服务网格的核心价值在于统一治理、语言无关和降低业务代码侵入但同时也会引入代理转发开销、调用链复杂度上升和平台维护成本增加的问题。服务网格题最好直接写出这 4 句原问题治理逻辑散在业务代码里重复且难统一解决方式通过 Sidecar 代理把治理能力下沉到基础设施层核心价值统一治理、统一安全、统一观测、语言无关主要代价代理开销、链路更长、平台运维复杂这类题最容易失分的地方就是把服务网格写成“提升性能的技术”。这个说法不准核心价值其实是统一治理。5. DevOps / CI/CD 题这类题经常和云原生一起出现。题干会强调发布频繁测试和上线流程长回滚困难交付质量不稳定可直接写成下面这种答案DevOps / CI/CD 的核心目标是打通开发、测试、发布和运维之间的交付链路通过自动构建、自动测试、自动部署和自动回滚减少人工操作提高软件交付效率和上线稳定性。对于发布频繁、版本迭代快的系统引入 CI/CD 流水线后可以使发布过程标准化、可追踪、可回退并与容器镜像、镜像仓库和 Kubernetes 编排平台形成自动化交付闭环。但其前提是需要建设完善的流水线、测试体系、配置管理和权限控制机制否则自动化越强错误扩散速度也越快。这类题卷面上最好出现下面这些关键词自动构建自动测试自动部署自动回滚可追踪可重复这里不要只写“提升研发效率”而要落到“构建、测试、部署、回滚、追踪”这些具体能力上。6. 声明式管理题声明式管理经常作为 K8s 的一个延伸考点出现。出题人真正想考的是传统方式依赖人工执行命令云原生平台更强调描述目标状态系统自动把当前状态收敛到目标状态可直接写成下面这种答案声明式管理的核心思想不是人工逐条执行部署命令而是先描述系统期望达到的目标状态再由平台持续将实际状态收敛到目标状态。例如运维人员只需声明服务副本数、镜像版本和资源配置平台即可自动完成调度、部署、失败重建和状态恢复。相较于命令式运维方式声明式管理更适合云原生场景下的大规模自动化运维因为它具有可配置、可版本化、可回滚和可自动收敛的特点。这类题通常写清楚下面 3 点就够命令式是“告诉系统怎么做”声明式是“告诉系统最终要什么状态”平台负责持续比对现状和目标并自动纠偏五、大数据部分在案例题里怎么考1. 大数据整体题大数据整体题通常不是让你背 Hadoop 生态而是让你说明为什么单机数据库和单机计算开始不够用为什么需要把采集、存储、计算、服务拆成多层为什么不同业务场景要使用不同类型的组件如果题干强调“海量数据、多源异构、实时统计、离线分析、检索查询并存”说明它考的不是单个产品而是整体数据架构分层能力。可直接写成下面这种答案大数据架构的核心目标是解决海量、多源、异构数据的采集、存储、计算和服务化输出问题。随着业务数据规模持续增长单机数据库和单机计算方式已经难以满足容量、性能和实时性要求因此需要构建分层的大数据处理架构。一般可按“数据接入层、存储层、计算层、服务层”进行设计数据首先通过日志采集或消息队列进入平台随后存储到分布式存储系统中再由批处理或流处理引擎进行加工计算最后为报表分析、搜索检索、实时看板和业务查询提供数据服务。该架构的优势是能够支撑海量数据处理和多类型分析需求但也会带来链路变长、组件增多、运维和治理复杂度上升的问题。这类题最好按链路作答不要散着写数据从哪里采集进入什么接入层存到什么存储层由什么计算层处理最终输出到什么服务层2. Lambda / Kappa 题这是这一篇里最典型的“取舍型”题目。Lambda 题的题干常见信号是既要实时结果又要最终准确同一份数据既用于实时看板也用于离线报表历史数据需要全量重算Kappa 题的题干常见信号是希望统一流处理链路希望架构更简单可以依靠消息重放处理历史数据可直接写成下面这种对比答案如果业务场景既要求实时结果又要求最终报表绝对准确则更适合采用 Lambda 架构。Lambda 通过批处理层保证最终准确性通过速度层提供低延迟结果再将两部分结果进行合并因此适合实时监控与离线校准并存的场景。但 Lambda 需要维护两套处理链路系统复杂度和运维成本较高。如果业务更关注统一处理链路、降低系统复杂度并且消息系统具备较强的保留与重放能力则可采用 Kappa 架构。Kappa 通过单一流处理链路同时承担实时计算和历史重放任务架构更简洁但前提是流处理能力足够成熟且历史重算可以通过消息重放方式完成。Lambda / Kappa 题至少要比较这 3 个维度实时性和最终准确性如何兼顾是单链路还是双链路历史重算靠批处理还是靠消息重放这类题最核心的深度不是“谁更先进”而是当前业务到底更重视准确性、实时性还是系统简化。3. Spark / Flink 题这类题常通过“实时性要求”来区分。如果题干强调周期性离线统计批量处理第二天报表SQL 分析和离线计算一般更容易落到 Spark。如果题干强调毫秒级或秒级处理持续事件流实时监控实时预警复杂事件处理一般更容易落到 Flink。可直接写成下面这种对比答案Spark 更适合离线批处理、周期性统计和大规模数据分析场景优势在于生态完整、批处理能力强、适合报表和离线计算任务。Flink 更适合实时流处理、事件驱动计算和低延迟预警场景优势在于原生流处理能力强、延迟更低更适用于实时监控、实时风控和实时推荐等业务。因此在选型时不能简单比较二者谁更流行而应根据题目中的实时性要求、处理模式和业务目标进行判断偏离线分析一般选 Spark偏实时事件流一般选 Flink。Spark / Flink 题至少要答出 3 个点处理模式不同批处理为主还是原生流为主实时性要求不同分钟小时级还是秒级毫秒级业务目标不同报表分析还是实时响应4. Kafka / HBase / Elasticsearch 选型题这类题在考试里非常高频核心不是记组件定义而是会不会按场景选型。可以先记住三个最常见的映射关系高吞吐消息接入、事件流、消息重放优先想到Kafka海量明细、高吞吐随机读写、按 RowKey 查询优先想到HBase全文检索、日志搜索、多维聚合分析优先想到Elasticsearch可直接写成下面这种选型答案如果题目强调高吞吐消息接入、事件流处理、消息积压缓冲和消费重放能力应优先选择 Kafka因为它适合承担大规模数据接入和流式传输任务。如果题目强调海量明细数据存储、高并发随机读写、按主键快速查询则应优先选择 HBase因为它更适合海量稀疏数据的高吞吐存储与查询。如果题目强调日志检索、全文搜索、关键词匹配和多维聚合分析则应优先选择 Elasticsearch因为它基于倒排索引更擅长搜索和聚合分析场景。这类题卷面上最好按下面 4 句来写先写业务需求是什么再写该组件解决什么问题再写为什么选它最后补一句为什么不选另一个相近组件例如可以直接这样写该场景需要承接海量日志并支持消息重放因此应选Kafka因为其吞吐高、支持分区和消费位点管理更适合作为数据接入与缓冲组件而不是检索组件。该场景需要保存海量订单明细并支持高并发随机查询因此应选HBase因为其适合海量稀疏数据的高吞吐读写而不适合复杂全文检索。该场景需要支持日志关键词搜索和聚合分析因此应选Elasticsearch因为其基于倒排索引擅长搜索与聚合而不适合作为高吞吐主存储。这里最容易失分的点是把三个组件都写成“适合大数据场景”。这太泛了必须写到数据访问模式上。5. 数据仓库 / 数据湖题这类题考的重点通常不是某个湖仓产品名而是数据组织和治理思路。如果题干强调统一主题建模稳定报表口径BI 分析结构化分析通常偏数据仓库。如果题干强调原始数据沉淀多源异构数据汇聚图片、日志、埋点、文本等多类型数据探索式分析和机器学习通常偏数据湖。可直接写成下面这种对比答案数据仓库更强调面向分析主题进行建模并在入库前完成数据清洗、整合和口径统一因此更适合 BI 报表、经营分析和 OLAP 场景。数据湖更强调先接入和沉淀原始多源异构数据包括结构化、半结构化和非结构化数据因此更适合探索式分析、机器学习和原始数据留存场景。如果企业同时建设数据湖和数据仓库通常是由数据湖负责承接原始数据、保留数据多样性再由数据仓库负责沉淀统一主题模型和稳定分析口径从而同时满足灵活探索和标准分析两类需求。这类题至少要比较下面 3 组区别建模时点仓库偏先建模数据湖偏先接入治理目标仓库偏统一口径数据湖偏原始沉淀使用场景仓库偏报表分析数据湖偏探索分析和算法训练六、这一篇答案要写到什么深度如果你已经懂技术复习这一篇时最重要的不是再背一遍定义而是记住每类题的作答深度。1. 卷面答案至少要有 4 句话这一篇的大多数题都可以强制自己写出下面 4 句话第一句题目当前的问题是什么第二句建议采用什么架构或组件第三句它能带来什么收益第四句它会带来什么代价或边界例如不能只写可采用 Kubernetes而要写成由于容器实例数量增加后人工运维无法满足扩缩容、自愈和滚动升级需求因此可采用 Kubernetes 进行容器编排它可以提供自动调度、自愈、服务发现和声明式管理能力提高上线效率和运行稳定性但同时也会带来集群治理、配置管理和运维复杂度上升的问题。只有写到这个层次才算是案例题有效答案。2. 对比题必须补一句“为什么不用另一个”案例题里很多分数来自比较能力。比如为什么这里选 HBase 而不是 ES为什么这里选 Lambda 而不是 Kappa为什么这里选服务网格而不是继续在代码里做治理所以在卷面上最好再补一句与 xxx 相比当前场景更强调 xxx因此选择 xxx 更合适。也就是说考试不只看你知不知道这个方案更看你会不会排除其他方案。3. 不要把答案写成百科介绍百科式答案的问题在于讲了很多定义但没有对应题干矛盾没有落到业务收益和工程代价看起来懂很多但得分点不集中更好的写法始终是围绕题干中的业务目标和系统约束去写。你可以把自己每一段答案都检查一遍有没有写出“为什么要用”、 “用了能解决什么”、 “会付出什么代价”。4. 考场速写清单如果你在考场上时间紧可以在下笔前先用下面这张清单快速自检。只要能勾住其中大部分答案通常就不会太空我有没有先写清题干的核心矛盾而不是直接写技术名词我有没有明确写出采用什么架构或组件而不是只说“优化”“改进”我有没有写出该方案到底解决什么问题而不是只写“性能更高”我有没有至少写出 2 个收益和 2 个代价我有没有补一句“为什么不用另一个相近方案”我有没有把技术能力翻译成业务结果例如发布更快、恢复更快、口径更统一、实时性更强如果一段答案里只有“方案”和“优点”没有“代价”和“边界”那通常就还没达到系统架构师案例题想要的深度。七、最后给一个通用答题模板遇到这一篇的案例题可以优先套下面这个框架题干反映的核心问题是 xxx例如 xxx、xxx、xxx。针对该问题可采用 xxx 架构或组件。该方案主要通过 xxx 机制解决 xxx 问题能够带来 xxx、xxx、xxx 等收益。但与此同时它也会引入 xxx、xxx 等代价或限制因此更适用于 xxx 场景。结合题干中的 xxx、xxx、xxx 关键信号可以判断本题考查的是 xxx。如果是对比题再补一句与 xxx 相比xxx 更适合当前场景因为当前业务更强调 xxx而不是 xxx如果题目更强调 xxx则应优先考虑 xxx。如果你希望在卷面上直接套用可以再压缩成 4 句模板该系统当前存在 xxx 问题。因此建议采用 xxx 架构或组件。该方案可以解决 xxx并带来 xxx、xxx 等收益。但该方案也会带来 xxx、xxx 等代价因此适用于 xxx不适用于 xxx。这样写出来的答案基本就已经是“可直接上卷面”的表述而不是泛泛的复习提示。如果是对比型题目可以直接在第三句和第四句之间再插一句与 xxx 相比当前场景更强调 xxx因此选择 xxx 更合适。如果是整体架构题可以再补最后一句收口该方案本质上是通过 xxx 方式解决系统在 xxx 阶段暴露出的扩张问题。这样一来不管题目问的是云原生整体、大数据整体还是具体组件选型你都能保持答案结构统一不容易写散。