架构师全栈技术词典

01 前端框架主流

React

用于构建用户界面的 JavaScript 库，通过组件化 + 虚拟 DOM 来构建 SPA 和复杂交互页面

一句话比喻

"React就像乐高积木——每个组件是一块积木，你可以自由组合拼出任何想要的界面，而且积木可以复用，改一个地方自动更新所有用到它的地方"

⚛️

核心理念

组件化 + 虚拟DOM + 单向数据流

Facebook(Meta) 出品，2013年开源至今

🧩

组件化

可复用、易维护、易测试

🚀

虚拟DOM

Diff算法、批量更新

🎣

Hooks

函数式编程、状态复用

React 生态圈（需要自行搭配）

⚛️ React

视图层

+

Redux/Zustand

状态管理

+

React Router

路由

+

Next.js

SSR/SSG

+

React Query

数据请求

为什么选React？

• 生态极其庞大（npm下载量第一）
• 大厂标配（Meta/Netflix/Airbnb）
• React Native 一套代码多端运行

需要注意

• 只管视图，需要自己搭配全家桶
• JSX/Hooks 有一定学习曲线
• 选择太多可能导致决策疲劳

💼 典型场景：中大型 Web 应用、后台管理系统、React Native 移动端跨平台 | npm周下载量：2000万+

02 前端框架主流

Angular

Google 推出的企业级前端框架，使用 TypeScript，内置完整的 MV* 架构和一站式方案

一句话比喻

"Angular就像精装修的房子——
拎包入住，路由、表单、HTTP、测试全部内置，但装修风格固定，改起来费劲"

Angular 一站式架构

🔀 Router

路由

📝 Forms

表单

🌐 HTTP

请求

💉 DI

注入

🧪 Testing

测试

🎨 Material

UI库

全部内置，无需选择，开箱即用

Angular vs React vs Vue 对比

特性	Angular	React	Vue
类型	完整框架	UI库	渐进式
语言	TypeScript	JS/TS	JS/TS
学习曲线	陡峭	中等	平缓
适合团队	大型	中大型	中小型

Angular 常见痛点

📚

概念多

模块/组件/服务/管道

🔄

版本升级

大版本不兼容

📦

包体积大

需要tree-shaking

🎓

招人难

市场人才少

什么时候选Angular？

大型企业项目：需要统一规范
👥 团队>10人：需要强约束
🔒 金融/政企：稳定性优先
📋 复杂表单：响应式表单强大

最佳实践

✅ 严格遵循官方风格指南
✅ 使用Angular CLI脚手架
✅ 善用依赖注入解耦
✅ 使用懒加载优化性能

💼 典型场景：金融、电信、政企等大型前端项目 | 代表项目：Google Cloud Console

03 前端框架主流

Vue.js

渐进式前端框架，支持直接用 script 标签引入，也支持构建大型 SPA

一句话比喻

"Vue就像宜家家具——
简单的直接拼装就能用，复杂的可以自由组合，说明书（文档）写得特别清楚，而且价格亲民（上手成本低）"

🌱 Vue 渐进式架构

Vue Core

响应式

→

Vue Router

路由

→

Pinia

状态管理

→

Nuxt

SSR

按需引入，从简单到复杂逐步升级

Vue2 vs Vue3 迁移对比

特性	Vue 2	Vue 3	迁移难度
响应式	Object.defineProperty	Proxy	低
组合API	Options API	Composition API	中
状态管理	Vuex	Pinia	高
TypeScript	支持一般	原生支持	低

Vue 常见坑

🔄

响应式丢失

解构会丢失响应

📦

版本混用

Vue2/3库不兼容

🎯

this指向

Vue3已无this

🔁

循环依赖

组件相互引用

什么时候选Vue？

🇨🇳 国内团队：文档友好、社区活跃
🚀 快速上手：团队新人多
📱 小程序/H5：uni-app生态
后台系统：Element Plus成熟

最佳实践

✅ 新项目直接用Vue3
✅ 使用Composition API
✅ 状态管理用Pinia
✅ 配合TypeScript使用

💼 典型场景：电商后台、运营系统、H5、小程序 | 国内使用率：60%+

04 前端框架快速增长

Svelte

编译型前端框架，在构建阶段把组件编译成原生 JS 操作 DOM 的代码，运行时几乎无框架开销

一句话比喻

"Svelte就像预制菜——
在工厂（编译阶段）就把菜做好了，用户吃的时候（运行时）直接加热就行，不需要现场做饭（框架代码）"

编译时 vs 运行时

🔧

Svelte

编译成原生JS

~3KB

VS

📦

React/Vue

框架随应用加载

~40KB+

Svelte vs 主流框架对比

特性	Svelte	React	Vue
打包体积	极小	中等	中等
运行时开销	几乎无	有	有
生态成熟度	发展中	成熟	成熟
学习曲线	平缓	中等	平缓

Svelte 需要注意

📚

生态小

第三方库较少

👥

人才少

招聘困难

大厂少用

企业采用率低

🔄

版本变化

Svelte5 Runes

什么时候选Svelte？

📦 体积敏感：嵌入式小组件
⚡ 性能极致：动画/可视化
🎮 游戏/交互：低延迟场景
🧪 个人项目：尝鲜探索

最佳实践

✅ 配合SvelteKit使用
✅ 小项目/组件优先
✅ 避免大型企业项目
✅ 关注Svelte5新特性

💼 典型场景：嵌入小挂件、移动Web、交互可视化 | 代表项目：NYTimes、Spotify

05 后端运行时主流

Node.js

基于 V8 引擎的 JavaScript 运行时，用事件驱动 + 非阻塞 I/O 构建高并发后端

一句话比喻

"Node.js就像单线程咖啡店——
只有一个服务员（单线程），但他不会傻等咖啡机（非阻塞I/O），而是先接下一单，咖啡好了再回来送"

🔄 事件循环机制

📥

请求进入

→

⚙️

Event Loop

→

📤

回调响应

单线程 + 非阻塞I/O = 高并发

Node.js vs 传统后端

特性	Node.js	Java/Go	Python
并发模型	事件循环	多线程	GIL限制
I/O密集	极强	强	一般
CPU密集	弱	强	一般
全栈统一	✅	❌	❌

Node.js 常见坑

🔥

回调地狱

用async/await

💾

内存泄漏

闭包/全局变量

🔢

CPU阻塞

避免同步计算

🔄

版本碎片

用nvm管理

什么时候选Node.js？

💬 实时应用：聊天、推送、协作
🔗 API网关/BFF：聚合请求
🖥️ 全栈项目：前后端统一
⚡ 快速迭代：启动速度快

最佳实践

✅ 使用TypeScript
✅ PM2进程管理
✅ 用Cluster利用多核
✅ 配合Redis缓存

💼 典型场景：API网关、BFF、实时聊天、SSR | 代表项目：Netflix、PayPal、LinkedIn

06 后端运行时新兴

Bun

新一代 JS 运行时，使用 Zig 编写，内置打包器、测试、包管理器，目标是高性能替代 Node.js

一句话比喻

"Bun就像瑞士军刀——
运行时、打包器、测试器、包管理器全部内置，一个工具干所有事情，而且速度飞快"

性能对比（相对 Node.js）

4x

启动速度

3x

HTTP吞吐

25x

包安装

3x

打包速度

Bun vs Node.js vs Deno

特性	Bun	Node.js	Deno
引擎	JavaScriptCore	V8	V8
性能	极快	快	快
生态成熟度	发展中	成熟	中等
内置打包器	✅	❌	❌

Bun 需要注意

🔄

版本不稳定

API可能变化

📦

npm兼容

部分包不支持

🪟

Windows支持

还在完善中

📚

文档少

社区资源有限

什么时候选Bun？

🧪 个人项目：尝鲜体验
⚡ 开发环境：加速npm install
📦 简单API：小型后端
🔧 脚本工具：替代ts-node

使用建议

⚠️ 生产环境谨慎使用
✅ 可用于开发工具链
✅ 关注版本更新日志
✅ 先在非关键项目试用

💼 典型场景：开发环境加速、脚本工具、小型API | 状态：快速迭代中

07 容器编排主流

Kubernetes（K8s）

开源的容器编排平台，负责容器化应用的部署、伸缩和管理

一句话比喻

"K8s就像自动化工厂的车间主任——负责安排工人（容器）上下班、分配任务、处理请假（故障重启）、旺季加班（弹性扩容）"

K8s 核心概念层级

Cluster

集群

→

Node

节点(物理机/VM)

→

Pod

最小调度单元

→

Container

容器

📈

自动扩缩

HPA/VPA弹性伸缩

🔄

滚动更新

零停机部署

💊

自愈能力

故障自动重启

☁️

多云支持

避免厂商锁定

容器编排工具对比

工具	学习曲线	适用规模	托管服务	生态
☸️ Kubernetes	⭐⭐⭐⭐⭐	中大型	EKS/GKE/AKS	极丰富
🐳 Docker Swarm	⭐⭐	小型	Docker内置	基础
🚀 Nomad	⭐⭐⭐	中型	HashiCorp Cloud	中等

什么时候用K8s？

📈 弹性扩缩 → 流量波动大
🔄 频繁发布 → 每天多次部署
☁️ 多云策略 → 避免厂商锁定
⚠️ 不适合 → 小团队/单体应用

常见问题

❌ 概念太多 → 循序渐进学习
❌ 资源开销大 → 用托管服务
❌ 运维复杂 → GitOps自动化
❌ 调试困难 → 完善可观测性

💼 微服务集群、弹性扩容、高可用基础设施 | 托管推荐：EKS/GKE/AKS | 工具链：Helm、ArgoCD

08 批处理主流

Apache Hadoop

早期大数据基石，包括 HDFS（分布式文件系统）和 MapReduce 批处理模型

一句话比喻

"Hadoop就像大型仓储物流中心——HDFS是超大仓库（存PB级数据），MapReduce是分拣流水线（分而治之），YARN是调度中心（分配工人和设备）"

🐘 Hadoop 生态架构

💾

HDFS

分布式存储

⚙️

MapReduce

批计算引擎

🧵

YARN

资源调度

🐝

Hive

SQL查询

📊

HBase

列式存储

大数据批处理框架对比

框架	计算模型	性能	实时能力	适用场景
🐘 Hadoop MR	磁盘批处理	⭐⭐	❌	离线ETL
⚡ Spark	内存计算	⭐⭐⭐⭐⭐	微批	批+准实时
🌊 Flink	流批一体	⭐⭐⭐⭐⭐	真实时	实时+批

常见坑

🔥

小文件问题

HDFS不适合存储大量小文件，使用HAR/合并

💾

NameNode单点

配置HA高可用，使用ZK选举

⚠️

数据倾斜

合理设计分区键，使用Combiner

🔧

内存配置

JVM参数调优，避免OOM

什么时候用Hadoop？

💾 海量数据存储 → PB级以上
⏰ 离线批处理 → T+1报表
💰 成本敏感 → 廉价机器堆存储
⚠️ 不适合 → 实时/交互式查询

Hadoop 最佳实践

✅ 合并小文件（SequenceFile/CombineFileInputFormat）
✅ 用Spark on YARN替代原生MR
✅ 数据压缩（Snappy/LZ4）节省存储
✅ 配合Hive做数据仓库

💼 典型场景：离线ETL、数据仓库、日志归档 | 现状：HDFS仍是存储基石，计算引擎多用Spark/Flink替代

09 统一计算引擎主流

Apache Spark

通用大数据计算引擎，支持批处理、交互式查询、流处理、机器学习、图计算

一句话比喻

"Spark就像高性能赛车——把数据加载到内存（赛道）上飞奔，比MapReduce（马车在土路上）快100倍，而且一辆车能跑批处理、SQL、流、ML多种赛道"

🚀

100x

比 MapReduce 快

内存计算 + DAG优化

统一 API，五大能力

📊

批处理

🔍

Spark SQL

🌊

Streaming

🤖

MLlib

🕸️

GraphX

Spark vs Flink vs Presto 对比

引擎	核心优势	流处理	SQL能力	最佳场景
⚡ Spark	内存+统一API	微批(秒级)	⭐⭐⭐⭐	ETL/数仓
🌊 Flink	真实时流	事件驱动(ms级)	⭐⭐⭐⭐	实时风控
🔍 Presto/Trino	交互式查询	❌	⭐⭐⭐⭐⭐	Ad-hoc分析

Spark 常见坑

💾

OOM内存溢出

数据倾斜/缓存过多

🔀

Shuffle开销

宽依赖性能杀手

📊

小文件问题

写出时需合并

⏱️

调优复杂

参数100+

什么时候用Spark？

📊 批处理ETL → T+1数据清洗
🔍 数仓计算 → Spark SQL替代Hive
🤖 机器学习 → MLlib大规模训练
⚠️ 不适合 → 毫秒级实时场景

Spark 最佳实践

✅ 用DataFrame API替代RDD
✅ 避免collect()拉取全量数据
✅ 广播变量处理大表Join小表
✅ Parquet+Snappy存储格式

💼 典型场景：ETL、数仓计算、Spark SQL、MLlib训练 | 语言支持：Scala/Python/Java/R/SQL

10 流平台/MQ 主流

Apache Kafka

分布式流式平台，兼具高吞吐消息队列和持久日志的特性

一句话比喻

"Kafka就像工厂里的传送带——
货物（消息）放上传送带后会持久保存，多个工人（消费者）可以从不同位置同时取货，
传送带可以任意延长（水平扩展），历史货物也能回溯查看（消息回放）"

📨 Kafka 消息流转架构

📤

Producer

生产者

→

P0

P1

P2

Topic

Broker

分区持久化

→

📥

Consumer Group

消费者组

分区（Partition）—— Kafka高性能的秘密

Partition 0

[0][1][2][3]→

Consumer A

Partition 1

[0][1][2]→

Consumer B

Partition 2

[0][1][2][3][4]→

Consumer C

一个Topic分成多个Partition → 并行消费 → 吞吐量倍增

百万级

TPS 吞吐

顺序写磁盘

🔄

消息可回放

offset可重置

📊

水平扩展

加分区加Broker

🔗

多消费者解耦

发布订阅模式

💼 日志收集、埋点、实时数据管道、事件驱动架构 | LinkedIn开源 | 阿里双11：万亿消息/天

11 实时流计算快速增长

Apache Flink

针对流数据的分布式实时计算引擎，支持有界/无界数据

一句话比喻

"Flink就像24小时不停的流水线——数据像水流一样持续进来，立刻被处理（毫秒级延迟），还能记住之前的状态（有状态计算），遇到停电（故障）也能从断点恢复"

⚡

ms级

真实时延迟

🌊

流优先

批是流的特例

🎯

Exactly-Once

精确一次语义

💾

有状态

本地状态+Checkpoint

流处理引擎对比

引擎	处理模型	延迟	状态管理	窗口支持
🌊 Flink	事件驱动	毫秒级	⭐⭐⭐⭐⭐	灵活(Session)
⚡ Spark Streaming	微批(DStream)	秒级	⭐⭐⭐	滑动/滚动
📨 Kafka Streams	事件驱动	毫秒级	⭐⭐⭐⭐	较灵活

Flink 常见坑

💾

状态过大

需定期清理TTL

⏰

Watermark延迟

迟到数据处理

🔧

调优复杂

并行度/内存/网络

🐛

调试困难

分布式追踪

什么时候用Flink？

⚡ 毫秒级实时 → 风控/监控
💾 有状态计算 → 累计指标/会话分析
🎯 精确一次 → 金融/计费场景
⚠️ 不适合 → 简单ETL用Spark更轻量

Flink 最佳实践

✅ 增量Checkpoint减少IO开销
✅ 设置State TTL自动清理过期状态
✅ 用Flink SQL降低开发门槛
✅ 配合Kafka+RocksDB稳定生产

💼 典型场景：实时风控、实时监控、实时推荐、实时指标看板 | 国内大厂首选实时引擎

12 深度学习框架主流

TensorFlow

Google 开源的深度学习框架，基于计算图，可在 CPU/GPU/TPU 上运行

一句话比喻

"TensorFlow就像乐高工厂的生产线——先画好设计图（计算图），然后工厂按图批量生产（高效执行），还能把成品送到各个平台（服务器/手机/浏览器/TPU）销售"

🔶

TensorFlow

Google 出品

2015年开源 | Keras集成

全平台部署生态

🖥️

TF Serving

服务器

📱

TF Lite

移动端

🌐

TF.js

浏览器

⚡

TPU

Google云

TensorFlow vs PyTorch 对比

对比项	TensorFlow	PyTorch
计算图	静态图(2.x支持Eager)	动态图(原生)
部署生态	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
科研社区	⭐⭐⭐	⭐⭐⭐⭐⭐
适合场景	生产部署、移动端	科研、快速原型

什么时候用TensorFlow？

📱 移动端部署 → TF Lite成熟
🌐 浏览器运行 → TF.js唯一选择
⚡ TPU加速 → Google云首选
🏭 生产级部署 → TF Serving完善

TensorFlow 最佳实践

✅ 用Keras API简化开发
✅ TensorBoard监控训练
✅ SavedModel格式统一导出
✅ 分布式用MultiWorkerMirrored

💼 典型场景：生产部署、移动端AI、TPU训练、TensorBoard监控 | 大厂：Google、Intel、Nvidia

13 深度学习框架主流

PyTorch

Meta 开源的深度学习框架，以动态计算图、Python 友好著称

一句话比喻

"PyTorch就像科学家的实验室笔记本——边写边运行（动态图），想到什么写什么，改了马上看效果，Python怎么写它就怎么跑，非常适合快速实验和调试"

🔥

PyTorch

Meta 出品

科研首选 | 动态图

PyTorch 生态圈

🤗

Transformers

NLP首选

⚡

Lightning

训练框架

👁️

TorchVision

CV工具

🚀

TorchServe

部署服务

为什么科研爱PyTorch？

特性	PyTorch优势	科研价值
动态图	即写即执行	快速实验迭代
Pythonic	原生Python调试	pdb断点直接用
Hugging Face	NLP模型库集成	开箱即用BERT/GPT
论文复现	80%+论文用PyTorch	代码直接跑

什么时候用PyTorch？

🔬 科研/论文复现 → 社区标配
🚀 快速原型 → 动态图友好
🤗 NLP任务 → Transformers首选
⚠️ 移动端部署 → 考虑TF Lite

PyTorch 最佳实践

✅ 用Lightning规范训练代码
✅ torch.compile加速推理(2.0+)
✅ 混合精度(AMP)节省显存
✅ 生产用TorchScript或ONNX

💼 典型场景：科研论文、快速原型、NLP/CV实验 | 大厂：Meta、OpenAI、Tesla

14 基础模型快速增长

大型语言模型（LLM）

基于 Transformer、参数量超大的通用语言模型（如 GPT 系列、Claude、PaLM 等）

一句话比喻

"LLM就像读过万卷书的博学者——读遍互联网后能对答如流，但有时会'自信地胡说八道'（幻觉），需要RAG（让它翻书查资料）或微调（专业培训）来校准"

🧠 一个模型，多种能力

💬

对话

❓

问答

✍️

写作

💻

代码

🌐

翻译

📊

分析

LLM 适配方式对比

方式	成本	效果	适用场景
💬 Prompt Engineering	低	快速见效	通用任务/快速实验
📚 RAG	中	减少幻觉	知识库问答/企业文档
🔧 Fine-tuning	高	最深度定制	垂直领域/风格统一

LLM 常见问题

👻

幻觉问题

编造不存在的事实

💰

成本高昂

Token按量计费

🔒

数据安全

敏感数据泄露风险

⏱️

响应延迟

长文本生成慢

LLM 选型决策

企业敏感数据 → 私有部署/本地LLM
💰 成本敏感 → 小模型+RAG组合
🎯 高精度需求 → GPT-4/Claude Opus
⚡ 低延迟需求 → 边缘模型/缓存

LLM 最佳实践

✅ RAG优先解决幻觉问题
✅ 结构化输出(JSON)便于解析
✅ Guard Rails过滤不当内容
✅ 缓存+批处理降低成本

💼 典型场景：智能客服、代码助手、文档问答、内容生成 | 主流：GPT-4、Claude、Gemini、Llama

15 方法论主流

敏捷开发（Agile Development）

迭代式开发方法，将工作拆成多个短周期冲刺，频繁交付和获取反馈

一句话比喻

"敏捷开发就像边开车边看地图导航——不用一开始就规划完整路线，每走一段就重新定位调整，遇到堵车（需求变更）随时改道，最终更快到达目的地"

🔄 Scrum Sprint 循环

📋 Backlog

需求池

→

📝 Planning

计划会

→

⚡ Sprint

2-4周

→

🎯 Review

演示

→

🔍 Retro

回顾

→ 🔄

敏捷 vs 瀑布 vs Kanban 对比

对比项	敏捷(Scrum)	瀑布	Kanban
迭代周期	2-4周冲刺	一次性	持续流动
需求变更	拥抱变化	抵触变化	随时插入
适合项目	创新/探索型	固定范围	运维/支持型

敏捷常见坑

📝

形式主义

只有站会没有敏捷

📊

无法度量

进度不透明

📄

文档缺失

知识无法沉淀

🎯

范围蔓延

需求无限膨胀

什么时候用敏捷？

🔄 需求不确定 → 探索型项目
⚡ 快速验证 → MVP/创业产品
👥 跨职能团队 → 自组织能力强
⚠️ 不适合 → 固定预算/合规严格项目

敏捷最佳实践

✅ 每日站会15分钟同步进度
✅ 用户故事描述需求(As a...I want...)
✅ 燃尽图可视化Sprint进度
✅ 回顾会持续改进流程

最佳实践

✅ 每日站会：控制在15分钟内，聚焦阻塞问题
✅ Sprint周期：2周最佳，太短太长都有问题
✅ 评审必参：PO必须参与Sprint评审，及时反馈
✅ 回顾改进：每个Sprint必做回顾，落地改进项

💼 典型场景：互联网产品、创新项目、MVP验证 | 框架：Scrum、Kanban、XP、SAFe

16 工程文化/流程主流

DevOps

将开发（Dev）与运维（Ops）融合的一整套文化、实践和工具，核心目标是快速且可靠地交付软件

一句话比喻

"DevOps就像自动化流水线工厂——代码一提交就自动打包（Build）、自动测试（Test）、自动上线（Deploy），全程流水线作业，工人（开发者）'谁造的车谁负责开'（You build it, you run it）"

DevOps 无限循环

Plan

→

Code

→

Build

→

Test

→

Release

→

Deploy

→

Operate

→

Monitor

→ 🔄

DevOps 核心工具链

环节	工具	作用
版本控制	Git/GitHub/GitLab	代码管理+协作
CI/CD	Jenkins/GitLab CI/GitHub Actions	自动构建+部署
容器化	Docker/K8s	环境一致+编排
监控告警	Prometheus/Grafana/PagerDuty	指标+告警

DevOps 常见坑

组织壁垒

Dev和Ops仍是两个部门

🔧

工具堆砌

买工具不买文化

📊

没有度量

无法量化改进效果

🔒

安全滞后

忽视DevSecOps

DevOps 关键指标(DORA)

⏱️ 部署频率 → 越高越好(每天多次)
⏳ 变更前置时间 → 代码到上线时间
💔 变更失败率 → 越低越好(<15%)
🔧 恢复时间 → 故障恢复速度(<1h)

DevOps 最佳实践

✅ 一切代码化(IaC/GitOps)
✅ 流水线即代码(Jenkinsfile/YAML)
✅ 特性开关分离部署与发布
✅ 左移安全(DevSecOps)

最佳实践

✅ GitFlow分支：main/develop/feature/release/hotfix规范
✅ CI先行：每次提交触发构建，快速反馈
✅ 蓝绿部署：两套环境切换，秒级回滚
✅ 监控报警：设置合理阈值，避免告警疲劳

💼 典型场景：云服务、SaaS产品、高频迭代项目 | "You build it, you run it" | 进阶：SRE、Platform Engineering

17 单向推送

SSE（Server-Sent Events）

基于 HTTP 的单向服务器推送机制，浏览器通过 EventSource 建立连接

一句话比喻

"SSE就像广播电台——服务器持续播报，客户端只能收听不能说话。ChatGPT的流式输出就是用SSE实现的！"

📡 SSE 数据流

🖥️

Server

event: msg

→→→

🌐

Browser

🔗

HTTP长连接

🔄

自动重连

📝

纯文本流

🌐

原生API

优点

• 实现简单，无需额外库
• 浏览器原生支持
• 穿防火墙容易

缺点

• 单向推送，无法上行
• 仅支持文本
• 连接数限制（6个/域）

何时用SSE？

✅ 只需服务端→客户端
✅ 文本数据为主
❌ 需要双向 → WebSocket

常见坑

🔥

连接数限制

浏览器限制6个连接，使用HTTP/2

🔄

断线重连

实现自动重连机制，指数退避

⚠️

IE不支持

需要Polyfill或降级方案

💓

心跳机制

定期发送keep-alive，检测死连接

💼 ChatGPT流式输出、实时日志、监控面板、股票推送、通知推送

18 双向实时

WebSocket

HTTP握手后升级为独立协议，实现浏览器与服务器间全双工的持久连接

一句话比喻

"WebSocket就像打电话——双方都可以随时说话，不用挂断重拨。SSE是广播，WebSocket是通话！"

🔄 全双工通信

🖥️

Server

→→→

ws://

←←←

🌐

Client

实时通信三种方式对比

方式	方向	协议	数据	复杂度	适用场景
轮询	请求-响应	HTTP	文本	⭐	低频更新
SSE	单向推送	HTTP	文本	⭐⭐	流式输出
WebSocket	双向	ws://	文本/二进制	⭐⭐⭐	聊天/游戏

什么时候选WebSocket？

💬 实时聊天 → WebSocket首选
📊 实时数据推送 → WebSocket或SSE
🎮 在线游戏 → WebSocket必须
📡 单向通知 → SSE更简单

最佳实践

✅ 心跳检测：30秒ping/pong保活
✅ 断线重连：指数退避算法
✅ 消息确认：ACK机制防丢失
✅ 连接池：限制单用户连接数

常见坑

⏰

连接超时

设置心跳包，防止被代理关闭

📨

消息丢失

实现ACK确认机制，消息重传

🌊

重连风暴

大量客户端同时重连，使用随机延迟

💾

内存泄漏

及时清理断开的连接，释放资源

💼 聊天IM、在线协作、实时游戏、行情报价 | 推荐：Socket.IO、ws

19 HTTP接口主流

REST API

以资源URL + HTTP动词（GET/POST/PUT/DELETE）为主的接口风格

比喻

"REST就像图书馆借书——书架URL固定，借/还/查用不同动作"

🌐

无状态

📦

资源导向

🔗

统一接口

HTTP动词速查

动词	语义	示例	幂等
GET	获取	GET /users/123	✅
POST	创建	POST /users	❌
PUT	全量更新	PUT /users/123	✅
DELETE	删除	DELETE /users/123	✅

RESTful设计6条准则

1. URL用名词复数 /users
2. 用HTTP状态码表结果
3. 版本放URL /v1/users
4. 嵌套资源 /users/1/orders
5. 分页用query ?page=1&size=10
6. 过滤/排序用query参数

常见问题

❌ URL用动词 /getUser
❌ 所有请求用POST
❌ 状态码只返200
❌ 没有版本控制
✅ 用OpenAPI/Swagger文档化

常见坑

🔢

版本管理

URL路径版本 vs Header版本，保持兼容

🔄

幂等性

POST非幂等，PUT/DELETE需保证幂等

⏱️

超时设置

合理设置超时，避免连接池耗尽

🔐

认证泄露

Token不要放URL，使用Header

💼 对外开放API、后台管理、BFF层 | 工具：OpenAPI/Swagger、Postman

20 高性能RPC 增长中

gRPC

基于HTTP/2 + Protobuf的高性能RPC框架，Google出品

一句话比喻

"gRPC就像高速公路——比REST普通公路快10倍，但只有特定车辆（Protobuf）能跑"

核心技术栈

HTTP/2

多路复用

Protobuf

二进制序列化

IDL

强类型契约

gRPC vs REST 对比

对比项	gRPC	REST	胜出
性能	二进制+HTTP/2	JSON+HTTP/1.1	⚡gRPC
可读性	需工具解码	人类可读	🌐REST
浏览器	需gRPC-Web	原生支持	🌐REST

gRPC适用场景

🔗 内部微服务 → gRPC性能优
🌐 对外API → REST更通用
📱 移动端 → gRPC省流量
🔄 双向流 → gRPC原生支持

性能优化

✅ 连接复用：HTTP/2多路复用
✅ 负载均衡：客户端LB避坑
✅ 超时控制：设置合理deadline
✅ Proto演进：保持字段向后兼容

常见坑

🔍

调试困难

二进制协议难抓包，使用grpcurl

🌐

浏览器支持

原生不支持，需要gRPC-Web代理

⚖️

负载均衡

HTTP/2多路复用问题，用客户端LB

📝

Proto兼容

字段编号不能改，新增字段用optional

💼 微服务内部调用、高性能API、跨语言通信 | Protobuf、gRPC-Web

21 解耦/异步主流

消息队列（MQ）

生产者发送消息到队列，消费者异步消费的中间件

一句话比喻

"MQ就像快递驿站——寄件人放包裹就走，收件人有空再取，不用面对面交接"

📬 消息流

📤

Producer

→→→

📥

Queue

→→→

📩

Consumer

🔗

解耦

生产消费独立

📊

削峰填谷

高峰堆积平稳消费

⚡

异步

缩短响应时间

点对点 vs 发布订阅

模式	消费者	场景
点对点	一条消息一个消费	任务分发
发布订阅	广播给所有订阅者	事件通知

MQ常见坑

• 消息丢失：确认机制/持久化
• 重复消费：消费端幂等
• 消息堆积：消费能力跟不上
• 顺序性：分区/队列保序

最佳实践

✅ 消息确认：消费成功后ACK，失败进入重试队列
✅ 死信处理：配置死信队列，人工介入处理
✅ 幂等消费：消费者必须实现幂等，防重复消费
✅ 顺序保证：需要顺序时用单分区，或业务层排序

💼 下单后发短信、日志收集、异步任务 | Kafka、RabbitMQ、RocketMQ

22 MQ 主流

RabbitMQ

基于AMQP协议的开源消息中间件，Erlang编写

一句话比喻

"RabbitMQ就像邮局——Exchange是分拣中心，根据地址（RoutingKey）分到不同邮筒（Queue）"

🐰 架构流程

Producer

→

Exchange

→

Queue

→

Consumer

📍

Direct

精确路由

Fanout

广播全部

🏷️

Topic

通配符匹配

📋

Headers

头部匹配

高级特性

• 死信队列DLX：消息失败转移
• 延迟队列：TTL+DLX实现
• 优先级队列：重要消息优先
• 消息确认：ACK机制保可靠

vs Kafka

✅ 复杂路由：Exchange灵活
✅ 消息确认：可靠性高
❌ 吞吐量：不如Kafka
❌ 大数据：Kafka更合适

最佳实践

✅ 持久化配置：队列和消息都要持久化，防丢失
✅ 预取数量：设置合理prefetch，避免消费者过载
✅ 集群镜像：镜像队列保证高可用，但性能有损
✅ 延迟队列：使用rabbitmq-delayed-message插件

💼 业务异步、事件通知、复杂路由 | 死信队列、延迟队列、优先级队列

23 缓存/KV存储主流

Redis

内存键值数据库，支持丰富数据结构，单机10万+QPS

一句话比喻

"Redis就像超市收银台旁的货架——常用商品放在最顺手的地方，拿起来秒结账"

为什么快？

💾

纯内存

🧵

单线程

⚡

IO多路复用

5种核心数据结构

结构	用途	结构	用途
String	缓存、计数器、锁	Hash	对象存储
List	消息队列、最新列表	Set	去重、共同好友
ZSet	排行榜、延迟队列	Stream	消息流（5.0+）

💾

缓存

🔐

Session

🔒

分布式锁

🏆

排行榜

📊

限流

常见坑

• 大Key导致阻塞
• 缓存穿透/击穿/雪崩
• 内存溢出OOM

💼 单机10万QPS | 集群：哨兵/Cluster | 持久化：RDB+AOF

24 统一入口主流

API Gateway（API 网关）

所有客户端流量进入后端的统一门面，通常为反向代理 + 扩展插件能力

一句话比喻

"API网关就像酒店前台——
所有客人（请求）先到前台登记（鉴权）、分配房间（路由）、控制入住人数（限流）"

🚪 架构位置

Web

App

IoT

→

🚪 Gateway

→

Service A

Service B

🔀

路由

🔐

鉴权

🚦

限流

📝

日志

📊

监控

🎯

灰度

主流网关产品对比

产品	语言	性能	生态	适用场景
Kong	Lua/Nginx	高	丰富插件	通用企业级
APISIX	Lua/Nginx	极高	Apache生态	高性能/国产
Envoy	C++	极高	Service Mesh	云原生/K8s
Spring Gateway	Java	中等	Spring生态	Java微服务

如何选择？

☕ Java生态 → Spring Cloud Gateway
🏎️ 极致性能 → APISIX / Envoy
🔌 丰富插件 → Kong
☁️ Service Mesh → Envoy + Istio

常见问题

❌ 网关成为单点瓶颈 → 集群部署
❌ 配置同步延迟 → 配置热更新
❌ 限流配置不当 → 压测后调整
❌ 日志过多影响性能 → 采样+异步

最佳实践

✅ 限流熔断：配置合理限流，下游异常时熔断
✅ 认证统一：网关统一鉴权，后端服务无需重复
✅ 日志追踪：注入TraceID，全链路追踪
✅ 版本路由：通过Header路由到不同版本服务

💼 统一鉴权、流量控制、协议转换、灰度发布 | Kong、APISIX、Envoy、Spring Gateway

25 认证授权主流

OAuth2 / OpenID Connect / JWT

现代认证授权体系的三大核心概念

一句话比喻

"OAuth2就像酒店房卡——
前台（授权服务器）给你房卡（Token），凭卡能开门（访问资源），但房卡会过期"

🔐 三者关系

OAuth 2.0

授权框架

"允许访问什么"

+

OIDC

身份层

"你是谁"

→

JWT

Token格式

"自包含凭证"

🎫 JWT 三段结构

Header . Payload . Signature

算法声明
alg: HS256

用户数据
sub, exp, iat

签名验证
防篡改

🔄 OAuth2 四种授权模式

授权码模式

最安全/Web应用

客户端凭证

服务间调用

密码模式

信任应用/已弃用

隐式模式

SPA/已弃用

常见坑

🔐

Token泄露

HTTPS必须，短有效期，及时撤销

🔄

刷新策略

Refresh Token安全存储，滑动过期

🌍

跨域问题

正确配置CORS，Cookie SameSite

⏰

时间同步

服务器时钟同步，避免JWT验证失败

🔑

Keycloak

开源/功能全

🚀

Auth0

SaaS/快速集成

🇨🇳

Authing

国产/合规

☁️

AWS Cognito

云原生

💼 第三方登录、SSO单点登录、API鉴权 | Keycloak、Auth0、Authing、AWS Cognito

26-29 微服务构件主流

微服务常见构件

服务注册与发现、配置中心、熔断限流、可观测性平台

一句话比喻

"微服务就像城市服务体系——
各部门独立办公（服务独立），通过政务大厅（Gateway）对外，有统一通讯录（注册中心）"

微服务架构全景

🚪 Gateway

→

Service A

Service B

↔

注册中心

配置中心

→

👁️ 监控

🔍

服务发现

Nacos / Eureka / Consul

⚙️

配置中心

Apollo / Nacos / Consul

熔断限流

Sentinel / Resilience4j

👁️

可观测性

Prometheus / Grafana

何时拆分微服务？

✅ 适合拆分

团队 > 10人
模块独立演进
技术栈异构
独立扩缩容需求

❌ 不适合

团队 < 5人
业务边界模糊
强事务依赖
运维能力不足

微服务常见坑

❌ 过度拆分 → 分布式事务噩梦
❌ 循环依赖 → 服务间调用成环
❌ 数据不一致 → 缺乏最终一致性设计
❌ 运维复杂 → 缺少可观测性基础设施
❌ 调试困难 → 缺少分布式追踪

微服务技术栈对比

技术栈	语言	注册中心	配置中心	熔断	适用场景
Spring Cloud	Java	Eureka	Config	Hystrix	传统Java企业
Spring Cloud Alibaba	Java	Nacos	Nacos	Sentinel	国内企业首选
Istio Service Mesh	多语言	K8s内置	ConfigMap	Envoy	云原生/多语言

最佳实践

✅ 服务拆分：按业务边界拆分，避免过度拆分
✅ 通信选择：内部gRPC，外部REST，事件用MQ
✅ 数据隔离：每个服务独立数据库，禁止跨库查询
✅ 故障隔离：舱壁模式+熔断器，防止雪崩

💼 服务治理、弹性伸缩、灰度发布 | Spring Cloud Alibaba（国内）/ Istio（云原生）

30 分布式系统核心

分布式锁（Distributed Lock）

多个节点访问同一共享资源时，保证同一时刻只有一个在修改

一句话比喻

"分布式锁就像公共厕所的门锁——
多人要用同一个厕所（资源），进去要锁门（加锁），用完开门（释放锁），门锁坏了要有人来修（超时机制）"

分布式锁解决的问题

Node 1

Node 2

Node 3

→→→ 竞争

🔐

Lock

→→→ 互斥

💾

Resource

三种主流实现方案对比

方案	实现方式	一致性	性能	适用场景
🔴 Redis	SET NX + EX	AP（最终）	极高	高性能场景
🦓 Zookeeper	临时顺序节点	CP（强）	中等	强一致场景
🔧 Etcd	租约Lease	CP（强）	中等	K8s生态

Redis分布式锁的5大坑

⏰

过期太短

业务没做完锁没了

🔄

续约问题

看门狗机制

🔀

主从切换

锁丢失风险

🆔

误删他人锁

需要唯一标识

🔁

不可重入

需要计数器

如何选择？

📈 高性能优先 → Redis
🔒 强一致优先 → Zookeeper
☁️ K8s环境 → Etcd
💰 已有基础设施 → 复用现有

最佳实践

✅ 使用Redisson等成熟框架
✅ 设置合理的过期时间
✅ 释放锁时验证持有者
✅ 关键业务用Lua脚本原子操作

💼 秒杀扣库存、定时任务单点执行、分布式幂等控制 | 推荐框架：Redisson、Curator

31 分布式系统核心

分布式 ID（雪花算法 Snowflake 等）

生成全局唯一、趋势递增的 ID，用作订单号、用户ID等

一句话比喻

"分布式ID就像身份证号——
全国唯一（全局唯一），能看出出生地和出生日期（包含信息），按时间顺序编排（趋势递增）"

Snowflake 64位结构（Twitter发明）

0

符号

1bit

时间戳

毫秒级

41bit ≈ 69年

机器ID

1024台

10bit

序列号

4096/ms

12bit

理论QPS：1024机器 × 4096/ms = 400万+/秒

5种主流方案详细对比

方案	唯一性	有序性	性能	长度	依赖
UUID	✅	❌	极高	36字符	无
数据库自增	✅	✅	低	8字节	DB
❄️ 雪花算法	✅	✅	极高	8字节	时钟
号段模式	✅	✅	高	8字节	DB
Redis INCR	✅	✅	高	8字节	Redis

如何选择？

🚀 性能优先 → 雪花算法
🔢 严格递增 → 号段模式
📝 无依赖 → UUID
💾 已有Redis → Redis INCR

雪花算法的坑

🕐 时钟回拨：NTP同步导致
🆔 机器ID分配：需要管理
📅 69年后溢出：规划起始时间

🍃

美团Leaf

号段+雪花双模式

🔵

百度UidGenerator

雪花增强版

🐦

滴滴TinyId

号段模式

💼 订单号、消息ID、链路追踪ID、分库分表主键 | 日均10亿+ID生成

32 分布式系统核心

幂等性（Idempotency）

同一个操作执行多次，结果必须一致（常用在支付、扣款等关键流程）

一句话比喻

"幂等性就像电梯按钮——
按1次和按100次效果一样，电梯只会来一次，不会来100次"

💸 为什么支付必须幂等？真实故事

用户点击支付 → 网络超时 → 用户重试点击 → 如果没有幂等：
扣款2次、发货2次、用户投诉、资损！

某电商真实案例

重复扣款

¥ 200万

一天内的资损

幂等性数学定义

f(x) = f(f(x))

执行1次 = 执行N次

扣款100元

× 调用3次

= 只扣100元 ✅

4种常用实现方案

🆔

唯一请求ID

客户端生成
服务端去重

适合：API调用

📋

幂等表

唯一索引
INSERT失败

适合：订单创建

🔒

分布式锁

串行化执行
只处理一次

适合：库存扣减

🎫

Token机制

一次性令牌
用后删除

适合：表单提交

HTTP方法幂等性

GET	✅ 天然幂等（读取）
PUT	✅ 天然幂等（全量更新）
DELETE	✅ 天然幂等（删除）
POST	❌ 非幂等（需要处理）

最佳实践

✅ 业务唯一键 > 请求ID
✅ 先查后改，检查状态
✅ 乐观锁（version字段）
✅ 幂等设计前置，不要后补

💼 支付、扣款、库存扣减、表单提交、消息消费 | 金融系统必备

33 分布式系统核心

数据一致性模型

一致性越强，性能和可用性通常越弱，需要权衡（CAP定理）

一句话比喻

"CAP就像三角恋——一致性、可用性、分区容错，你最多只能同时拥有两个，
分布式环境下P是必选项，所以要在C和A之间做选择"

🔺 CAP 定理（布鲁尔定理）

C

Consistency

一致性

A

Availability

可用性

P

Partition

分区容错

分布式系统最多同时满足两个，通常保证 P，在 C 和 A 之间取舍

📖 BASE理论（CAP的工程实践）

BA

Basically Available

基本可用
允许响应时间延长

S

Soft State

软状态
允许中间状态存在

E

Eventually Consistent

最终一致
不要求实时一致

BASE是对CAP中AP的延伸，是大多数互联网系统的选择

💪

强一致性

读取=最新写入

性能↓ 可用性↓

银行转账

⏳

最终一致性

一段时间后一致

性能↑ 可用性↑

朋友圈点赞

读己之写

自己写后能读到

他人不一定

发帖后刷新

🔴 CP系统（选一致性）

• Zookeeper：分布式协调
• Etcd：K8s配置存储
• HBase：强一致读写

场景：配置中心、分布式锁

🟢 AP系统（选可用性）

• Cassandra：海量写入
• Eureka：服务注册
• DynamoDB：低延迟读写

场景：日志、监控、社交

💼 CP: 金融/配置 | AP: 社交/日志 | BASE: 电商订单状态同步

34 缓存体系

缓存三大问题

缓存穿透、缓存击穿、缓存雪崩

一句话比喻

"缓存就像前台接待——穿透是问不存在的人，击穿是明星来了前台挤爆，雪崩是前台集体下班！"

问题	场景	危害	解决方案
🕳️ 穿透	查询不存在的数据	每次都打DB	布隆过滤器、空值缓存（设短TTL）
💥 击穿	热点Key瞬间过期	并发打DB	互斥锁、逻辑过期、永不过期+异步更新
❄️ 雪崩	大量Key同时过期	DB压力激增	随机过期时间、多级缓存、熔断降级

常见踩坑

• 空值缓存TTL设太长 → 脏数据
• 布隆过滤器不支持删除
• 互斥锁等待超时未处理
• 预热数据量估算不准

最佳实践

✅ TTL = 基础值 + 随机偏移
✅ 热点数据提前预热
✅ 本地缓存 + Redis 双层
✅ 监控缓存命中率

🔺 三大问题触发场景

💥

缓存穿透

查不存在的key

→ 布隆过滤器

⚡

缓存击穿

热点key过期

→ 互斥锁/永不过期

🌊

缓存雪崩

大量key同时过期

→ 过期时间随机化

💼 高并发场景必须防范的三大缓存问题 | Redis + 本地缓存双保险 | Caffeine + Redisson

35-36 缓存体系

缓存淘汰策略 & 客户端缓存

服务端淘汰策略 + 浏览器端缓存机制

一句话比喻

"Cache-Aside就像先看菜单再点菜——读时查缓存没有再查数据库，写时直接写数据库再删缓存；而Read/Write-Through是全托管餐厅——缓存系统帮你处理一切同步工作！"

策略	工作原理	优点	缺点
Cache-Aside	应用负责读写数据库+缓存	灵活、适用范围广	代码侵入、一致性弱
Read-Through	缓存层自动从DB加载	对应用透明	需要缓存层支持
Write-Through	写缓存时同步写DB	强一致性	写延迟高
Write-Behind	写缓存后异步写DB	写性能极高	可能丢数据

服务端淘汰策略

• LRU：最近最少使用（Redis默认）
• LFU：最不常用（适合热点数据）
• FIFO：先进先出（简单场景）
• TTL：过期时间（定时失效）

客户端缓存

• HTTP缓存：ETag/Cache-Control
• Service Worker：离线缓存/PWA
• IndexedDB：结构化数据
• LocalStorage：简单键值对

如何选择？

📈 读多写少 → LRU（最近最少使用）
🔄 频率重要 → LFU（最不常用）
⚡ 简单场景 → FIFO（先进先出）
🎯 热点数据 → LRU-K / 2Q算法

常见踩坑

• 先删缓存再写DB → 并发脏数据
• LRU适配器选错 → 性能下降
• HTTP缓存未设Vary → CDN错乱
• Service Worker未处理版本 → 永久缓存旧版

最佳实践

✅ 先更新DB，再删缓存（双删策略）
✅ CDN → 本地缓存 → Redis 多级架构
✅ HTTP强缓存 + 协商缓存组合
✅ 静态资源URL带版本号/Hash

💼 Redis默认allkeys-lru | HTTP: max-age/s-maxage/no-cache/no-store/must-revalidate

37 数据库

分库分表（Sharding）

数据量过大时，将数据分散到多个数据库或表，降低单库压力

一句话比喻

"分库分表就像把图书馆分到各楼层——水平分片是同类书放不同楼层（按ID分），垂直分片是不同类书分开放（用户馆/订单馆），分片键是楼层索引卡！"

分片策略与分片键选择

水平分片

按行拆分

user_0, user_1...

垂直分片

按列/业务拆分

用户库、订单库

分片键

Hash/Range/List

user_id % N

分片键类型	原理	优点	缺点
Hash分片	user_id % 1024	数据分布均匀	扩容需rehash
Range分片	0-1000万/1000万-2000万	范围查询高效、扩容简单	热点数据集中
一致性Hash	Hash环 + 虚拟节点	扩容影响最小（仅影响1/N节点）	实现复杂

数据存储选型

📊 结构化+事务 → MySQL/PostgreSQL
⚡ 高速缓存 → Redis（热数据）
🔍 全文搜索 → Elasticsearch
📁 文件/图片 → OSS/S3
📈 实时分析 → ClickHouse/Doris

常见踩坑

• 分片键选错 → 跨库查询多
• 全局ID未规划 → ID冲突
• 扩容时未停写 → 数据不一致
• 事务跨分片 → 分布式事务地狱

最佳实践

✅ 用户维度用user_id分片
✅ 雪花算法生成全局ID
✅ 双写方案平滑扩容
✅ 设计时避免跨分片join

💼 ShardingSphere、Vitess、TiDB | 单表超2000万/单库超500GB考虑 | 阿里Seata支持分布式事务

38-40 分布式系统

分布式事务

跨多个服务/数据库保证数据一致性的解决方案

一句话比喻

"分布式事务就像跨国银行转账——2PC是双方都确认才转（阻塞），TCC是预扣→确认→取消（业务侵入），Saga是转完A再转B失败就退A（最终一致）！"

方案	原理	一致性	优点	缺点
2PC/3PC	两阶段提交	强一致	简单、可靠	阻塞、单点故障
TCC	Try-Confirm-Cancel	最终一致	性能好、灵活	业务侵入高、复杂
Saga	本地事务+补偿	最终一致	适合长事务	需设计补偿逻辑
本地消息表	事务写+消息表	最终一致	简单、可靠	需定时扫表

🔄 TCC三阶段流程

Try

预留资源

→

Confirm

确认提交

OR

Cancel

释放资源

如何选择？

🏦 强一致性 → 2PC（两阶段提交），适合金融
🔄 高性能 → TCC（Try-Confirm-Cancel），适合电商
📨 最终一致 → Saga（事件驱动），适合长流程
🚀 简单场景 → 本地消息表，适合中小系统

常见踩坑

• TCC幂等性未保证 → 重复扣款
• Saga补偿逻辑有bug → 数据不一致
• 2PC协调器单点 → 服务不可用
• 消息表未清理 → 数据膨胀

最佳实践

✅ 优先用最终一致性方案
✅ TCC用唯一流水号保证幂等
✅ Saga用状态机编排补偿
✅ 消息表定时归档历史数据

💼 Seata（AT/TCC/Saga）、DTM、ByteTCC | 金融场景用2PC，电商用TCC/Saga

41-44 任务系统

任务调度 & 异步处理

定时任务、延迟任务、工作流编排

一句话比喻

"任务调度就像智能闹钟系统——Cron是每天固定时间响（定时任务），延迟队列是"N分钟后提醒"（订单超时），工作流是复杂的连锁提醒（DAG任务编排）！"

⏰ Cron表达式速查

0 0 2 * * ?

每天凌晨2点

0 */10 * * * ?

每10分钟

0 0 9-18 * * ?

9点-18点每小时

0 0 12 ? * MON-FRI

工作日中午12点

0 0 0 1 * ?

每月1号零点

0 0 0 L * ?

每月最后一天

格式: 秒分时日月星期 [年]

⏰

定时任务

XXL-JOB / Quartz

报表生成

⏳

延迟任务

Redis ZSet / RabbitMQ

订单超时

🔄

工作流

Airflow / Temporal

ETL流水线

📋

任务队列

Celery / Sidekiq

异步处理

数据存储选型

📊 结构化+事务 → MySQL/PostgreSQL
⚡ 高速缓存 → Redis（热数据）
🔍 全文搜索 → Elasticsearch
📁 文件/图片 → OSS/S3
📈 实时分析 → ClickHouse/Doris

常见踩坑

• Cron表达式写错 → 不执行
• 任务未幂等 → 重复执行出错
• 延迟队列时钟偏移 → 不准确
• 工作流无超时控制 → 死锁

最佳实践

✅ 用在线工具验证Cron表达式
✅ 任务ID去重保证幂等性
✅ Redis ZSet实现精准延迟
✅ 工作流设置超时+重试策略

💼 XXL-JOB（分布式任务）、Airflow（数据流）、Temporal（微服务编排）、RabbitMQ（延迟队列插件）

45-49 可观测性

可观测性三大支柱

Logs（日志）、Metrics（指标）、Traces（链路追踪）

一句话比喻

"可观测性就像医院体检——Logs是病历记录（详细事件），Metrics是体温血压（实时指标），Traces是CT扫描（全链路追踪），三者结合才能精准诊断！"

支柱	用途	工具链	典型场景
📝 Logs	离散事件记录	ELK、Loki、Splunk	错误排查、审计追踪
📊 Metrics	聚合数据统计	Prometheus、Grafana、InfluxDB	性能监控、容量规划、告警
🔗 Traces	调用链追踪	Jaeger、Zipkin、SkyWalking	定位慢查询、服务依赖分析

🚨 告警设计五原则

1️⃣ 可操作

收到告警必须有明确处理动作

2️⃣ 分级

P0紧急/P1重要/P2一般

3️⃣ 降噪

聚合+静默，避免告警风暴

4️⃣ 上下文

附带Trace/Dashboard链接

5️⃣ SLO驱动

基于业务SLO设阈值

数据存储选型

📊 结构化+事务 → MySQL/PostgreSQL
⚡ 高速缓存 → Redis（热数据）
🔍 全文搜索 → Elasticsearch
📁 文件/图片 → OSS/S3
📈 实时分析 → ClickHouse/Doris

常见踩坑

• 日志无TraceID → 无法关联
• 指标无标签 → 无法细分
• 告警阈值固定 → 误报多
• 采样率过低 → 丢失关键Trace

最佳实践

✅ 统一注入TraceID/SpanID
✅ 指标按service/env/region打标签
✅ 动态基线告警（环比/同比）
✅ 慢查询100%采样，正常请求1%

💼 OpenTelemetry统一标准 | Grafana全家桶（Loki+Tempo+Mimir）| 阿里SLS、腾讯CLS

50-54 搜索/AI数据

搜索引擎 & AI数据基础设施

倒排索引、向量数据库、特征服务、模型服务化、数据湖

一句话比喻

"AI数据基础设施就像智能图书馆——倒排索引是书名目录（关键词查询），向量DB是语义索引（找相似内容），特征服务是读者画像（推荐系统），数据湖是海量原始藏书！"

向量DB	索引算法	优势	适用场景	QPS性能
Milvus	HNSW/IVF	开源、支持GPU、分布式	大规模RAG、推荐	10K-50K
Pinecone	专有算法	全托管、开箱即用	快速验证、中小规模	5K-20K
Weaviate	HNSW	GraphQL、模块化	知识图谱+向量	3K-15K
Qdrant	HNSW	Rust实现、高性能	实时推荐	15K-60K

🔍

倒排索引

ES/Solr

全文搜索

📐

向量DB

Milvus/Pinecone

语义检索

🎯

特征服务

Feast/Tecton

特征工程

🤖

模型服务

TF Serving/vLLM

推理加速

🏞️

数据湖

Delta Lake/Iceberg

海量存储

🧠 RAG 架构核心流程

用户Query

→

Embedding

→

向量检索Top-K

→

上下文注入

→

LLM生成

数据存储选型

📊 结构化+事务 → MySQL/PostgreSQL
⚡ 高速缓存 → Redis（热数据）
🔍 全文搜索 → Elasticsearch
📁 文件/图片 → OSS/S3
📈 实时分析 → ClickHouse/Doris

常见踩坑

• Embedding模型不一致 → 召回差
• 向量维度太高 → 检索慢
• 未做Chunk切分 → 上下文过长
• 数据湖未分区 → 查询扫全表

最佳实践

✅ 统一用BGE/E5中文Embedding
✅ 向量压缩（PQ/LSH）降维
✅ 文档按段落Chunk（500字）
✅ 数据湖按日期/业务分区

💼 ElasticSearch（全文）+ Milvus（向量）+ Feast（特征）+ vLLM（推理）+ Delta Lake（存储）组合拳

55 架构模式进阶

CQRS（命令查询责任分离）

将读操作和写操作分离到不同的模型，各自优化

📖 CQRS 读写分离架构

✍️ 命令端

Command Model

验证 → 业务逻辑 → 写入

⬇️

事件/消息

⬇️

👁️ 查询端

Query Model

物化视图 → 快速读取

一句话比喻

"CQRS就像银行的存款窗口和自助查询机分开——
存款要排队验证，查询要快速响应，各司其职"

适用场景

• 读写比例悬殊（读:写 > 10:1）
• 复杂查询需求（报表、搜索）
• 需要独立扩展读/写
• 配合Event Sourcing

不适用场景

• 简单CRUD系统
• 小团队、快速迭代
• 强一致性要求（银行核心）
• 读写频率相近

🔗 CQRS + Event Sourcing 黄金搭档

命令 → 产生事件

→

事件存储

→

投影 → 查询模型

复杂度警告

📊

两套数据模型

维护成本翻倍

⏱️

最终一致性

读写有延迟

🧠

学习曲线陡

团队需培训

💼 典型案例：电商订单系统（写入订单 vs 查询订单列表）| 框架：Axon, EventStore

56 架构模式进阶

DDD（领域驱动设计）

以业务领域为中心的软件设计方法论，解决复杂业务系统的建模问题

DDD 两大核心层面

🗺️ 战略设计

高层次，划定边界

• 限界上下文 (Bounded Context)
• 上下文映射 (Context Map)
• 统一语言 (Ubiquitous Language)

🔧 战术设计

底层次，具体建模

• 实体 (Entity) / 值对象 (Value Object)
• 聚合根 (Aggregate Root)
• 领域服务 / 领域事件

一句话比喻

"DDD就像城市规划——先划分行政区（限界上下文），再规划每个区的道路和建筑（实体、聚合），
不同区有不同的法规（统一语言），跨区协作需要明确接口（上下文映射）"

🆔

实体

有唯一标识
可变状态

💎

值对象

无标识
不可变

🌳

聚合根

一致性边界
事务单元

领域事件

业务发生
跨BC通信

🔲 限界上下文示例：电商系统

订单上下文

Order, OrderItem

库存上下文

Stock, Warehouse

支付上下文

Payment, Refund

用户上下文

User, Address

何时使用DDD？

✅ 业务逻辑复杂（金融、电商）
✅ 需要长期演进维护
✅ 领域专家可参与建模
✅ 团队规模 > 5人

常见误区

❌ 不是所有项目都需要DDD
❌ DDD ≠ 微服务（可单体）
❌ 过度设计简单CRUD
❌ 忽视统一语言的重要性

💼 经典书籍：Eric Evans《领域驱动设计》| 实践：阿里、美团等大厂核心系统

57 架构模式前沿

Event Sourcing（事件溯源）

不存储当前状态，而是存储所有状态变更事件，通过回放事件重建状态

📜 传统存储 vs 事件溯源

📦 传统存储

只存最终状态

Account: { balance: 1000 }

❌ 不知道怎么变成1000的

📜 事件溯源

存储所有变更事件

Deposited +500
Deposited +800
Withdrawn -300

✅ 完整历史可追溯

一句话比喻

"Event Sourcing就像Git版本控制——
不是只保存最新代码，而是保存每一次commit，随时可以回滚到任意版本"

订单事件流示例

t1

OrderCreated

→

t2

PaymentReceived

→

t3

OrderShipped

→

t4

OrderDelivered

回放t1→t4，即可重建订单当前状态

核心优势

📋 完整审计：每次变更有迹可循
⏪ 时间旅行：可回放任意时间点状态
🔄 事件回放：修复Bug后重建数据
📊 分析友好：事件天然是行为日志

实施挑战

📈 事件膨胀：需要快照优化
🔄 版本演进：事件Schema变更难
⏱️ 最终一致：查询有延迟
🧠 思维转换：团队需要适应

EventStoreDB

专用事件数据库

⚙️

Axon Framework

Java生态首选

☁️

Kafka

事件流存储

💼 适用场景：金融交易、审计系统、游戏存档、协作编辑 | 配合CQRS效果更佳

58 架构模式进阶

六边形架构（Hexagonal Architecture）

又称端口与适配器架构，核心逻辑与外部依赖通过端口隔离，适配器可替换

⬡ 六边形架构图解

🌐 REST API

📱 GraphQL

⌨️ CLI

入站适配器

→

入站端口

→

🎯

核心领域

业务逻辑

→

出站端口

→

MySQL

📧 Email

☁️ S3

出站适配器

一句话比喻

"六边形架构就像USB接口——
电脑（核心）定义USB端口标准，鼠标、键盘、U盘（适配器）只要符合标准就能即插即用，
换个外设不需要改电脑内部"

🔌 端口与适配器详解

类型	端口（接口）	适配器（实现）
🔵 入站	UserService接口	REST Controller, gRPC Handler
🔴 出站	UserRepository接口	MySQLAdapter, MongoAdapter
🔴 出站	NotificationPort接口	EmailAdapter, SMSAdapter, PushAdapter

📚 传统分层架构

Controller

↓

Service

↓

Repository

依赖自上而下，底层变化影响上层

⬡ 六边形架构

适配器

↓ 依赖倒置 ↓

核心领域

核心不依赖外围，外围依赖核心

🧪

测试友好

Mock适配器

🔄

可替换

换DB无影响

🎯

业务聚焦

核心纯净

📁

结构清晰

边界明确

💼 相关架构：Clean Architecture、Onion Architecture | 提出者：Alistair Cockburn (2005)

59

SLA / SLO / SLI

一句话比喻

"SLA/SLO/SLI就像体检报告——SLI是实测血压值，SLO是医生建议的标准，SLA是保险公司要求的底线！"

可用性指标金字塔

SLA

对外承诺 (99.9%)

SLO

内部目标 (99.95%)

SLI

实测数据

可用性速查表

可用性	年停机	月停机	适用场景
99.9%	8.76h	43.8min	普通业务
99.99%	52.6min	4.38min	核心系统
99.999%	5.26min	26s	金融/支付

数据存储选型

📊 结构化+事务 → MySQL/PostgreSQL
⚡ 高速缓存 → Redis（热数据）
🔍 全文搜索 → Elasticsearch
📁 文件/图片 → OSS/S3
📈 实时分析 → ClickHouse/Doris

常见误区

• SLA承诺过高 → 赔不起
• SLI统计口径不一致
• 忽略Error Budget管理

最佳实践

✅ SLO比SLA严格10倍
✅ P99而非平均值
✅ Error Budget驱动发布

Google SRE核心理念 | Prometheus + Grafana监控 | Error Budget管理

60-61

Error Budget & APM

一句话比喻

"Error Budget就像每月零花钱——花光了(错误用完)就不能乱买东西(停止上线)，APM是你的账单明细，告诉你钱花哪儿了(哪个服务慢了)！"

💰 Error Budget 错误预算

SLO = 99.9% → Error Budget = 0.1%

剩余70%

本月已消耗30%错误预算

预算充足时

快速迭代 🚀

预算耗尽时

停止上线 🛑

APM 应用性能监控

🐢

慢接口追踪

慢SQL分析

🗺️

调用拓扑图

🐛

异常堆栈

代表产品：SkyWalking · Datadog · New Relic

APM产品对比

产品	优势	适用场景	成本
SkyWalking	开源免费、中文友好	Java微服务	0元
Datadog	功能最全、UI精美	大型企业	$$$
Prometheus	云原生、生态丰富	K8s环境	0元

常见踩坑

• Error Budget设置过严 → 团队压力大,创新停滞
• APM采样率过低 → 1%可能漏掉关键问题
• 只看平均值不看P99 → 长尾延迟被掩盖
• 忽略SQL慢查询 → 200ms的查询高并发下成瓶颈

最佳实践

✅ 分级SLO → 核心99.95%,非核心99.5%
✅ 智能采样 → 正常1%,异常100%,慢请求100%
✅ 链路染色 → 给VIP用户请求打tag优先排查
✅ 告警分级 → P0电话,P1短信,P2邮件

⚖️ 平衡创新速度与系统稳定性 | SRE的核心决策依据 | Error Budget管理

62-65

认证授权 · 资源隔离

一句话比喻

"认证授权就像酒店入住——前台验身份证(认证),给你房卡(授权),房卡决定你能进哪些房间;舱壁隔离像轮船分仓,一个船舱漏水不会淹没整艘船！"

🔑

JWT

JSON Web Token

header.payload.signature

无状态认证

🎫

OAuth2

开放授权

微信登录、GitHub登录

第三方授权

👥

SSO

单点登录

一次登录,全系统通行

企业统一认证

RBAC

基于角色的权限

用户→角色→权限

最常用模型

🚢 舱壁隔离原理（源自船舶设计）

订单

支付

库存

各服务独立线程池/实例组

→

💥故障

✅正常

订单故障不影响支付和库存

安全大坑

• JWT存localStorage → XSS攻击可窃取,应存HttpOnly Cookie
• 密码明文传输 → 必须HTTPS
• Token永不过期 → 泄露后永久有效
• 只校验登录不校验权限 → 越权漏洞

最佳实践

✅ 双Token机制 → AccessToken(15min)+RefreshToken(7天)
✅ 登录限流 → 同IP 5分钟5次失败锁定
✅ 操作审计日志 → 记录谁在何时做了什么
✅ 最小权限原则 → 默认无权限,按需分配

🔐 认证解决"你是谁",授权解决"你能做什么" | Hystrix · Sentinel · Resilience4j

66-71

API管理与安全

一句话比喻

"API安全就像银行安保系统——WAF是门卫拦坏人,Throttling是限制同一人一天只能取5次钱,Webhook签名是验钞机防假钞,KMS是保险柜存放金库密码！"

Webhook签名>
回调请求验证
`HMAC-SHA256(payload, secret)`
防伪造、防篡改

API Throttling>
请求节流
按用户/IP限制QPS
防止滥用、保护后端

API Quota>
调用配额
日/月调用总量限制
计费、资源规划

WAF>
Web应用防火墙
SQL注入XSSCSRF恶意爬虫

IAM>
身份与访问管理
RBACABAC
用户·角色·权限

🔐 KMS

密钥管理服务

加密密钥证书管理密钥轮换

限流策略对比

策略	限制维度	典型值	适用场景
QPS限流	每秒请求数	1000 req/s	防止瞬时流量
日配额	每日调用次数	100万次/天	API计费
并发限流	同时处理数	200个并发	保护后端资源

常见安全漏洞

• Webhook未验签 → 伪造回调数据
• 限流粒度太粗 → 单用户刷爆整个API
• API Key明文传输 → 被抓包窃取
• 密钥硬编码 → 代码泄露=密钥泄露

安全最佳实践

✅ 分层限流 → IP限流+用户限流+API限流
✅ 零信任架构 → 内部调用也需认证
✅ API密钥轮换 → 90天自动rotate
✅ 安全Header → HSTS, CSP, X-Frame-Options

🔒 安全是企业级系统的底线 | 零信任架构、最小权限原则 | AWS WAF · Cloudflare

72-74

数据管道与数据治理

一句话比喻

"数据管道就像自来水厂——采集(取水)→传输(水管)→处理(过滤消毒)→存储(水塔)→服务化(水龙头);数据目录是图书馆卡片柜,记录每本书(数据)在哪,谁写的！"

🔄 Data Pipeline 数据管道全流程

📥 采集

埋点/日志

→

📨 传输

Kafka

→

⚙️ 处理

Flink/Spark

→

存储

数仓/湖

→

📊 服务化

BI/API

📚 Data Catalog

数据目录

数据资产管理
字段含义、来源
责任人、血缘关系
数据发现与搜索

Apache Atlas · DataHub

Data Quality>
数据质量
空值率监控
重复数据检测
异常值告警
数据延迟监控
Great Expectations · dbt tests

数据存储方案对比

方案	特点	典型工具	适用场景
数据仓库	结构化、OLAP	Snowflake, BigQuery	BI分析、报表
数据湖	原始数据、多格式	S3+Iceberg, Delta Lake	大数据存档
湖仓一体	兼顾灵活性与性能	Databricks, Hudi	AI训练+BI

数据治理大坑

• 血缘关系未记录 → 上游改字段,下游全炸
• 数据无责任人 → 出问题找不到人
• 缺少数据质量监控 → 脏数据污染报表
• ETL失败无告警 → 数据延迟几天才发现

治理最佳实践

✅ 数据Owner制 → 每张表有明确责任人
✅ 自动化血缘分析 → SQL解析生成依赖图
✅ SLA监控 → T+1数据必须在早上8点前ready
✅ 数据版本化 → Iceberg支持时间旅行

📈 数据是新时代的石油 | 数据血缘、数据合规、数据安全 | Kafka · Flink · dbt

75-78

策略	原理	优势	典型应用
协同过滤	相似用户喜欢啥	无需内容理解	电商、视频
向量检索	Embedding相似度	效果好、实时	短视频、新闻
热门/新品	统计规则	冷启动友好	新用户兜底

维度	同步调用(REST)	事件驱动(MQ)
耦合度	强耦合	松耦合
实时性	毫秒级	秒级
可靠性	下游挂了上游阻塞	MQ重试+死信
扩展性	新增下游需改上游	新增订阅者即可

🔗 解决"写DB+发消息"的一致性问题 | CDC、Debezium · Kafka · RocketMQ

82-84

云原生构件进阶

一句话比喻

"Sidecar边车就像摩托车边车——主容器开车,Sidecar坐边上帮你看路况(监控)、收费站(流量代理);Operator像自动驾驶系统,把运维经验编码成自动化规则！"

Sidecar 边车模式

Pod

📦

主容器

业务应用

Sidecar

Envoy代理

常见Sidecar职责：

流量代理 (Istio/Envoy)
日志采集 (Fluentd)
配置热加载
健康检查

🎮 Operator

K8s控制器扩展

将运维经验编码为自动化控制器

Kafka OperatorFlink OperatorMySQL Operator

CRD + 自定义控制器

StatefulSet>
有状态服务管理
与Deployment的区别：
稳定网络标识 (pod-0, pod-1)
持久化存储卷
有序部署/扩缩
适用: DB、Zookeeper、Kafka

K8s工作负载对比

类型	特点	网络标识	适用场景
Deployment	无状态、可随意重启	动态IP	Web服务、API
StatefulSet	有状态、稳定标识	固定域名	数据库、MQ
DaemonSet	每节点一个Pod	节点IP	日志采集、监控
Job/CronJob	一次性/定时任务	-	数据迁移、备份

K8s常见踩坑

• 资源limit设置过低 → OOMKilled频繁重启
• 健康检查过于严格 → 启动慢导致Pod被杀
• PV未正确回收 → 磁盘空间泄露
• Sidecar注入失败 → Service Mesh不生效

云原生最佳实践

✅ Request=0.5核,Limit=2核 → 预留buffer
✅ 就绪探针+存活探针 → 启动期和运行期分开
✅ GitOps部署 → ArgoCD自动同步
✅ 多副本+反亲和 → 分散到不同节点

☸️ 云原生的核心是"声明式"与"自动化" | GitOps、IaC · Istio · ArgoCD

85-88

大流量架构策略

一句话比喻

"大流量应对就像双11商场应急预案——降级关闭试衣间(非核心功能),隔离分楼层独立收银(资源隔离),预热提前开门让人慢慢进(流量预热),冷热分离把畅销品放一楼！"

降级

Degrade

关闭非核心功能

返回默认值兜底

🧱

隔离

Isolation

业务分资源池

避免相互影响

预热

Warm-up

新实例逐渐放量

避免冷启动雪崩

冷热分离

Hot/Cold

热数据→快速存储

冷数据→廉价存储

大流量应对策略矩阵

场景	策略	工具/方案
秒杀活动	限流 + 队列 + 预热	Sentinel + Redis + CDN
依赖故障	熔断 + 降级 + 隔离	Hystrix + 舱壁模式
数据增长	分库分表 + 冷热分离	ShardingSphere + TiDB
新版上线	灰度 + 预热 + 回滚	K8s + Istio + Feature Flag

性能优化ROI排序

优化手段	性能提升	实施成本	ROI
CDN加速	10-100倍	低	⭐⭐⭐⭐⭐
Redis缓存	10-100倍	低	⭐⭐⭐⭐⭐
SQL优化	5-50倍	中	⭐⭐⭐⭐
分库分表	3-10倍	高	⭐⭐⭐

高并发大坑

• 缓存雪崩 → 大量key同时过期,DB被打死
• 缓存穿透 → 查询不存在的数据,直击DB
• 热点数据 → 单个key流量过大,Redis单线程瓶颈
• 慢SQL拖垮连接池 → 一个慢查询占满所有连接

高可用实战

✅ 多级缓存 → 本地缓存+Redis+CDN
✅ 布隆过滤器 → 拦截不存在的key
✅ 热点数据预热 → 提前加载到缓存
✅ 熔断器 → 慢接口自动熔断,快速失败

⚡ 大流量系统的核心：分治、异步、缓存、弹性 | 双11/618实战 | Sentinel · Hystrix

MAP

全栈架构七层鸟瞰

用户端

浏览器App小程序桌面客户端

↓

接入&边缘

DNS→CDN→WAF→API网关

↓

应用&服务

BFFREST/gRPCSSE/WebSocket

同步→微服务异步→MQ/Kafka

↓

数据&存储

MySQL/PGRedisESOSS/S3

↓ 日志&埋点 → Kafka ↓

大数据&AI

Kafka→Flink/Spark→数仓/湖→BI/推荐/LLM

↓

DevOps&SRE

Git→CI/CD→Docker→K8s→监控

↓

业务平台

IAM/SSO支付风控运营后台

一句话比喻

"全栈架构就像麦当劳——从点餐（客户端）→排队（网关）→后厨（服务）→仓库（数据）→配送（AI）→管理系统（DevOps），每层各司其职！"

七层职责速览

层级	职责	核心技术	关键指标
L1 客户端	用户交互	Vue/React/Flutter	FCP < 1.5s
L2 接入层	流量管控	Nginx/Kong/CDN	P99 < 50ms
L3 服务层	业务逻辑	Spring/gRPC/MQ	可用性 > 99.9%
L4 数据层	数据存储	MySQL/Redis/ES	QPS > 10K
L5 大数据	数据分析	Spark/Flink/LLM	延迟 < 1min
L6 DevOps	持续交付	K8s/ArgoCD/监控	MTTR < 30min
L7 平台层	业务支撑	IAM/支付/风控	安全合规

架构选型原则

🚀 初创期 → 单体优先，快速验证
📈 成长期 → 模块化拆分，读写分离
🏢 成熟期 → 微服务+中台+数据湖
🌍 全球化 → 多活+边缘计算

全栈思维三板斧

✅ 分层解耦：各层独立演进，接口稳定
✅ 冗余容灾：每层至少2个节点
✅ 可观测性：全链路追踪，指标告警
✅ 渐进演进：小步快跑，持续重构

🗺️ 全栈架构师核心能力：理解每层职责、掌握核心组件、具备端到端问题排查能力

L1-3

技术地图：上三层

Layer 1: 客户端>
用户交互、展示、采集
Vue/ReactAngularFlutter/RN小程序微前端SSR/SSG

Layer 2: 接入&边缘>
流量入口、安全防护、加速
DNSCDNWAFEdge FunctionsKong/APISIXNginx/Envoy

Layer 3: 应用&服务>
业务逻辑、微服务
BFFREST/gRPCSSE/WS注册中心配置中心Service Mesh

一句话比喻

"上三层就像机场安检——L1是旅客（用户端），L2是安检通道（网关过滤），L3是候机大厅（服务处理），缺一不可！"

通信协议选型

协议	适用场景	优势	劣势
REST	对外API、简单CRUD	通用、易调试	性能一般
gRPC	内部微服务通信	高性能、强类型	调试困难
WebSocket	实时双向通信	低延迟、全双工	连接管理复杂
SSE	服务端推送	简单、自动重连	单向、连接数限制

接入层常见坑

🔥 CORS跨域：配置不当导致接口不通
🔥 CDN缓存：静态资源版本未更新
🔥 API版本：破坏性变更导致客户端崩溃
🔥 超时设置：网关超时短于服务超时

最佳实践

✅ 前端：SSR首屏 + CSR交互
✅ 网关：统一鉴权 + 限流熔断
✅ 服务：BFF聚合 + 异步解耦
✅ 全局：TraceID全链路透传

👆 用户可感知的层次 | 性能、体验、安全的第一道防线

L4-5

技术地图：中间层

一句话比喻

"数据层就像图书馆——MySQL是目录柜，Redis是热门书架，ES是搜索机，大数据是数据分析室！"

Layer 4: 数据&存储>
关系型
MySQL · PG
缓存
Redis
搜索
ES
对象存储
S3/OSS

🧠 Layer 5: 大数据&AI

流处理

Kafka · Flink

批处理

Spark

数仓

ClickHouse

AI

LLM · RAG

数据存储选型

📊 结构化+事务 → MySQL/PostgreSQL
⚡ 高速缓存 → Redis（热数据）
🔍 全文搜索 → Elasticsearch
📁 文件/图片 → OSS/S3
📈 实时分析 → ClickHouse/Doris

常见踩坑

• 单表超5000万不分库分表
• Redis当数据库用 → 数据丢失
• ES实时写入 → 性能崩溃

最佳实践

✅ 读写分离 + 缓存 + 分库
✅ 冷热数据分层存储
✅ 数据血缘 + 质量监控

📊 数据是业务的血液，AI是业务的大脑 | MySQL + Redis + ES + ClickHouse

L6-7

技术地图：底层基座

一句话比喻

"DevOps就像工厂流水线——CI/CD是自动化产线，K8s是智能调度系统，监控是品控质检员！"

🔧 Layer 6: DevOps & SRE

Git→CI/CD→Docker→K8s

PrometheusGrafanaELK

Layer 7: 业务平台>
IAM
支付
风控
消息
后台
营销

DevOps工具链对比

环节	开源方案	云厂商方案	推荐场景
代码托管	GitLab	GitHub/云效	GitLab私有化
CI/CD	Jenkins/ArgoCD	GitHub Actions	ArgoCD for K8s
容器编排	K8s	ACK/EKS/GKE	托管K8s省运维
监控	Prometheus+Grafana	Datadog/云监控	开源成本低

常见踩坑

• CI/CD没有回滚机制
• K8s资源限制设置不当
• 平台能力过度设计

最佳实践

✅ GitOps + 蓝绿/灰度发布
✅ Error Budget驱动
✅ 中台能力按需引入

🏗️ 平台化减少重复造轮子 | Jenkins/GitLab CI + ArgoCD + K8s

提示词片段

清洗后的原始内容

架构师全栈技术词典

前端 / 后端 / 大数据 / AI产品方法论核心词典

React

一句话比喻

核心理念

组件化

虚拟DOM

Hooks

React 生态圈（需要自行搭配）

为什么选React？

需要注意

Angular

一句话比喻

Angular 一站式架构

Angular vs React vs Vue 对比

Angular 常见痛点

什么时候选Angular？

最佳实践

Vue.js

一句话比喻

🌱 Vue 渐进式架构

Vue2 vs Vue3 迁移对比

Vue 常见坑

什么时候选Vue？

最佳实践

Svelte

一句话比喻

编译时 vs 运行时

Svelte vs 主流框架对比

Svelte 需要注意

什么时候选Svelte？

最佳实践

Node.js

一句话比喻

🔄 事件循环机制

Node.js vs 传统后端

Node.js 常见坑

什么时候选Node.js？

最佳实践

Bun

一句话比喻

性能对比（相对 Node.js）

Bun vs Node.js vs Deno

Bun 需要注意

什么时候选Bun？

使用建议

Kubernetes（K8s）

一句话比喻

K8s 核心概念层级

容器编排工具对比

什么时候用K8s？

常见问题

Apache Hadoop

一句话比喻

🐘 Hadoop 生态架构

大数据批处理框架对比

常见坑

什么时候用Hadoop？

Hadoop 最佳实践

Apache Spark

一句话比喻

统一 API，五大能力

Spark vs Flink vs Presto 对比

Spark 常见坑

什么时候用Spark？

Spark 最佳实践

Apache Kafka

一句话比喻

📨 Kafka 消息流转架构

分区（Partition）—— Kafka高性能的秘密

Apache Flink

一句话比喻

流处理引擎对比

Flink 常见坑

什么时候用Flink？

Flink 最佳实践

TensorFlow

一句话比喻

前端 / 后端 / 大数据 / AI
产品方法论核心词典