系统设计 101

使用可视化图表和通俗语言解析复杂系统

无论你是备战系统设计面试，还是单纯想了解系统底层工作原理，我们希望这个知识库能助你一臂之力

通信协议

Communication protocols

架构风格定义了应用程序接口（API）各组件间的交互方式，通过标准化设计和构建 API 的方法来确保效率、可靠性和系统集成便利性。以下是常用风格：

• SOAP：
成熟全面的 XML 协议
适合企业级应用

• RESTful：
流行易实现的 HTTP 方法
适合 Web 服务

• GraphQL：
查询语言精准获取数据
减少网络开销加速响应

• gRPC：
现代高性能 Protocol Buffers
适合微服务架构

• WebSocket：
实时双向持久连接
低延迟数据交换首选

• Webhook：
事件驱动 HTTP 回调
异步通知系统事件

REST API vs. GraphQL

REST API vs. GraphQL

API 设计中 REST 和 GraphQL 各有所长：

REST 特点： • 使用标准 HTTP 方法（GET/POST/PUT/DELETE）进行 CRUD • 简单统一接口适合服务间通信 • 缓存策略易于实现 • 缺点：关联数据需多次请求

GraphQL 优势： • 单一端点精准查询所需字段 • 嵌套查询优化响应体大小 • 支持数据变更（Mutations）和实时订阅（Subscriptions） • 适合快速迭代的前端需求 • 缺点：客户端复杂度增加，需防范恶意查询

选择依据：
GraphQL 适合复杂多变的前端场景，REST 适合需要简单稳定接口的应用。两者各有适用场景，需根据需求权衡。

gRPC 工作原理

How does gRPC work?

RPC（远程过程调用）的”远程”特性在微服务架构中尤为重要，从用户角度看就像本地函数调用：

工作流程：

1. 客户端发起 REST 调用（JSON 格式）
2. 订单服务（gRPC 客户端）转换请求为二进制格式
3. 通过 HTTP2 传输（比 JSON 快 5 倍）
4. 支付服务（gRPC 服务端）解码执行
5. 结果返回经过相同路径

优势：二进制编码和网络优化带来高性能。

什么是 Webhook？

What is a webhook?

对比轮询与 Webhook：

电商支付场景示例：
短轮询缺点：
• 支付服务持续轮询消耗资源
• 直接通信存在安全隐患

Webhook 优势：

1. 注册回调 URL
2. 支付完成时外部服务主动通知
3. 无需主动查询，节省资源
4. 设置定时任务处理未回调情况

注意事项：

1. 设计合理的回调 API
2. 配置 API 网关安全规则
3. 确保注册正确的 URL

如何提升 API 性能？

How to improve API performance?

五大优化技巧：

1. 分页处理：流式返回大数据集
2. 异步日志：无锁缓冲区提升 I/O 性能
3. 缓存策略：Redis 内存缓存热点数据
4. 负载压缩：gzip 压缩传输数据
5. 连接池：复用数据库连接减少开销

HTTP 版本演进

HTTP 1.0 -> HTTP 1.1 -> HTTP 2.0 -> HTTP 3.0 (QUIC)

各版本解决的问题：

• HTTP/1.0（1996）：每次请求新建 TCP 连接
• HTTP/1.1（1997）：持久连接但存在队头阻塞
• HTTP/2（2015）：多路复用解决应用层阻塞
• HTTP/3（2020）：QUIC 基于 UDP，彻底解决传输层阻塞

QUIC 特性：
• 基于 UDP 的独立流传输
• 0-RTT 快速建立连接
• 单个流故障不影响其他流

SOAP vs REST vs GraphQL vs RPC

SOAP vs REST vs GraphQL vs RPC

API 风格演进对比：

时间线：
• SOAP（1998）：XML 格式，企业级 WS-* 标准
• REST（2000）：HTTP 方法，资源导向
• GraphQL（2015）：精准查询，减少过度获取
• gRPC（2016）：高性能二进制协议

应用场景：
• 企业内部集成 → SOAP
• 公共 API → REST
• 复杂数据需求 → GraphQL
• 微服务通信 → gRPC

代码优先 vs API 优先

Code First vs. API First

微服务架构设计哲学：

为何选择 API 优先？

1. 降低系统复杂性：明确定义服务边界
2. 统一语言：跨团队协作基础
3. 提升质量：早期验证接口设计
4. 测试驱动：接口契约先行

优势：
• 减少后期变更风险
• 支持并行开发
• 自动化测试更易实施

HTTP 状态码

HTTP status codes

状态码分类：

五类状态码：
• 1xx：信息性状态
• 2xx：成功（200 OK，201 Created）
• 3xx：重定向（301 永久，302 临时）
• 4xx：客户端错误（400 错误请求，404 未找到）
• 5xx：服务端错误（500 内部错误，503 服务不可用）

API 网关作用

What does API gateway do?

网关核心功能图解：

处理流程：

1. 接收 HTTP 请求
2. 解析验证请求属性
3. 白名单/黑名单检查
4. 身份认证鉴权
5. 限流规则应用
6. 路由匹配服务
7. 协议转换（如 REST 转 gRPC）
8. 错误处理与熔断
9. 日志监控（ELK 集成）

附加功能：
• 请求响应转换
• 数据缓存
• 服务聚合

如何设计安全高效的 API？

How do we design effective and safe APIs?

购物车 API 设计示例：

关键设计要素：

1. 资源命名规范（/cart/{id}/items）
2. 版本控制（/v1/carts）
3. 安全头部（X-Request-ID，RateLimit）
4. 限流策略（1000 次/小时）
5. 错误代码标准化
6. 文档自动化（OpenAPI）

TCP/IP 封装

TCP/IP encapsulation

网络数据传输过程：

封装流程：

1. 应用层添加 HTTP 头
2. 传输层加 TCP/UDP 头（端口号）
3. 网络层加 IP 头（IP 地址）
4. 数据链路层加 MAC 头
5. 物理层二进制传输

解封装流程：
逆向逐层去除头部，各层专注自身职责（如网络层处理路由，传输层保证可靠传输）。

反向代理原理

Why is Nginx called a “reverse” proxy?

正向 vs 反向代理对比：

正向代理：
• 客户端保护者
• 突破访问限制
• 企业网络管控

反向代理：
• 服务端守护者
• 负载均衡
• 静态内容缓存
• SSL 终端加速

Nginx 核心功能：
• 请求分发
• 安全过滤
• 压缩优化
• 访问控制

负载均衡算法

What are the common load-balancing algorithms?

六种常用算法：

静态算法：

1. 轮询（Round Robin）
2. 粘性轮询（Session 保持）
3. 加权轮询（根据服务器性能）
4. 哈希（IP/URL 哈希）

动态算法：

1. 最少连接（优先空闲服务器）
2. 最快响应（基于响应时间）

应用场景：
• 短连接 → 轮询
• 长连接 → 最少连接
• 会话保持 → 粘性策略
• 资源异构 → 加权算法

URL、URI、URN 区别

URL, URI, URN - Do you know the differences?

概念关系图解：

• URI（统一资源标识符）：
资源唯一标识，包含 URL 和 URN
格式：scheme:[//authority]path[?query][#fragment]

• URL（统一资源定位符）：
包含访问协议和路径，如 https://example.com/page

• URN（统一资源名称）：
持久资源命名，如 urn:isbn:0451450523

关键区别：
URL 定位资源，URN 命名资源，URI 是两者的超集。

持续集成/持续交付

CI/CD

用简单术语解释 CI/CD 流水线

第 1 部分 - 包含 CI/CD 的软件开发生命周期 (SDLC)

软件开发生命周期 (SDLC) 包含几个关键阶段：开发、测试、部署和维护。CI/CD 通过自动化与整合这些阶段，实现更快速可靠的版本发布。

当代码被推送到 git 仓库时，会自动触发构建和测试流程。端到端 (e2e) 测试用例会验证代码质量。若测试通过，代码就能自动部署到预发布/生产环境；若发现问题，代码会被打回开发阶段修复。这种自动化机制能快速给开发者反馈，并降低生产环境出现 bug 的风险。

第 2 部分 - CI 与 CD 的区别

持续集成 (CI) 自动化了构建、测试和合并流程。每当代码提交时就会运行测试，及早发现集成问题。这种方式鼓励频繁提交代码并及时获得反馈。

持续交付 (CD) 自动化了基础设施变更、部署等发布流程。通过自动化工作流确保软件随时可发布。CD 还可能自动化生产部署前所需的手动测试与审批步骤。

第 3 部分 - CI/CD 流水线

典型 CI/CD 流水线的串联阶段： • 开发者提交代码变更到版本控制系统 • CI 服务器检测变更并触发构建 • 代码编译与测试（单元测试、集成测试） • 测试结果反馈给开发者 • 成功时，制品部署到预发布环境 • 发布前可能在预发布环境进行更多测试 • CD 系统将核准的变更部署到生产环境

Netflix 技术栈 (CI/CD 流水线)

规划：Netflix 工程团队使用 JIRA 进行任务规划，Confluence 管理文档。

编码：后端服务主要使用 Java，其他语言用于特定场景。

构建：主要使用 Gradle 构建，并开发 Gradle 插件支持多样化需求。

打包：将软件包与依赖打包进 Amazon Machine Image (AMI) 进行发布。

测试：注重生产环境的混沌测试工具开发。

部署：使用自研的 Spinnaker 进行金丝雀发布。

监控：监控指标集中到 Atlas，使用 Kayenta 检测异常。

事件报告：按优先级分派事件，使用 PagerDuty 处理事件。

架构模式

MVC、MVP、MVVM、MVVM-C 与 VIPER

这些架构模式是 iOS 和 Android 应用开发中最常用的解决方案。它们的诞生都是为了克服前代模式的局限性，那么差异在哪里？

• MVC 最古老，历史可追溯 50 年 • 所有模式都包含负责显示内容和接收用户输入的 “视图” (V) • 多数模式包含管理业务数据的 “模型” (M) • “控制器”、”Presenter”、”视图模型” 是视图与模型间的协调者（VIPER 中的 “实体” 属于模型范畴）

开发者必知的 18 种关键设计模式

设计模式是解决常见问题的可复用方案，能提升开发效率。它们就像构建优质软件结构的蓝图。以下是经典模式：

• 抽象工厂（Abstract Factory）：家族创造者 —— 创建相关联的物件群组。 • 生成器（Builder）：乐高大师 —— 分步骤构建对象，保持创建过程与表现形式分离。 • 原型（Prototype）：克隆专家 —— 基于现有实例创建副本。 • 单例（Singleton）：唯一存在 —— 确保类只有一个实例。 • 适配器（Adapter）：万能插头 —— 连接接口不兼容的组件。 • 桥接（Bridge）：功能连接器 —— 分离对象抽象与实现。 • 组合（Composite）：树形建造师 —— 构造简单与复杂元素的树状结构。 • 装饰器（Decorator）：定制专家 —— 动态添加功能而不修改核心。 • 外观（Facade）：一站式服务 —— 提供复杂子系统的简化接口。 • 享元（Flyweight）：空间优化师 —— 高效共享细粒度对象。 • 代理（Proxy）：替身演员 —— 控制对目标对象的访问。 • 责任链（Chain of Responsibility）：请求接力赛 —— 沿处理链传递请求直至被处理。 • 命令（Command）：任务包装器 —— 将请求封装为独立对象。 • 迭代器（Iterator）：集合探险家 —— 顺序访问集合元素。 • 中介者（Mediator）：通信枢纽 —— 简化类间交互。 • 备忘录（Memento）：时光胶囊 —— 保存与恢复对象状态。 • 观察者（Observer）：新闻播报员 —— 状态变更时通知依赖对象。 • 访问者（Visitor）：技能访客 —— 在不修改类的前提下扩展功能。

数据库

云服务数据库速查表

选择合适的数据库是复杂任务。面对众多针对不同场景优化的数据库，决策疲劳很容易出现。

这张速查表提供高层指引，帮助你根据项目需求锁定合适服务，规避潜在陷阱。

注：Google 对其数据库用例文档有限。尽管我们尽力调研，部分条目可能仍有偏差。

支撑数据库的 8 种核心数据结构

最佳选择取决于具体场景。数据可能存储在内存或磁盘，格式包括数字、字符串、地理坐标等。系统可能偏重读写，这些因素都会影响索引结构的选择。

常用索引数据结构： • 跳表（Skiplist）：Redis 使用的内存索引 • 哈希索引：实现 Map/Collection 的常见方式 • SSTable：不可变的磁盘 Map 实现 • LSM 树：跳表 + SSTable，高写入吞吐 • B 树：磁盘方案，读写性能均衡 • 倒排索引：文档索引，用于 Lucene • 后缀树：字符串模式匹配 • R 树：多维搜索如最近邻查询

SQL 语句在数据库中的执行过程

下图展示通用流程（不同数据库架构可能不同）：

步骤 1 - SQL 语句通过 TCP 等传输层协议发送到数据库。

步骤 2 - 命令解析器进行语法语义分析，生成查询树。

步骤 3 - 查询树发送给优化器生成执行计划。

步骤 4 - 执行器根据计划获取数据。

步骤 5 - 访问方法从存储引擎获取数据。

步骤 6 - 若为 SELECT 等只读操作，缓冲管理器从缓存或数据文件读取。

步骤 7 - 若为 UPDATE/INSERT，转交事务管理器处理。

步骤 8 - 事务期间数据加锁，由锁管理器保障 ACID 特性。

CAP 定理

CAP 定理是计算机科学经典理论，但开发者常有不同理解。让我们解析其本质与常见误区。

CAP 定理指出分布式系统无法同时满足以下三个保证：

一致性（Consistency）：所有客户端无论连接哪个节点，都能看到相同数据。

可用性（Availability）：即使部分节点故障，请求仍能获得响应。

分区容忍（Partition Tolerance）：网络分区发生时系统仍可运行。

“三选二” 的简化表述容易引起误解：

1. 选型不能仅凭 CAP。例如选择 Cassandra 存储聊天消息不仅因为它是 AP 系统，还需考虑其他特性。
2. CAP 仅禁止极少数情况 —— 分区发生时同时要求完美可用性与一致性，这种情况罕见。
3. 定理讨论的是 100% 的可用性与一致性。实际更多是在无分区时权衡延迟与一致性（参见 PACELC 定理）。

CAP 定理的价值在于开启取舍讨论，但只是选型考量的一部分。

SQL 查询的可视化解析

SQL 执行步骤： • 解析 SQL 并验证合法性 • 转换为关系代数等内部表示 • 优化执行计划（利用索引等信息） • 执行计划并返回结果

执行过程涉及： • 索引与缓存使用 • 表连接顺序 • 并发控制 • 事务管理

SQL 语言演进

1986 年 SQL 成为标准，40 年后仍是关系型数据库主导语言。学习最新标准（ANSI SQL 2016）耗时，如何高效掌握？

SQL 五大组件： • DDL：数据定义语言（CREATE/ALTER/DROP） • DQL：数据查询语言（SELECT） • DML：数据操作语言（INSERT/UPDATE/DELETE） • DCL：数据控制语言（GRANT/REVOKE） • TCL：事务控制语言（COMMIT/ROLLBACK）

后端工程师需掌握大部分，数据分析师重点掌握 DQL。

缓存

数据缓存的层级网络

多层缓存机制：

1. 客户端：浏览器缓存 HTTP 响应
2. CDN：缓存静态资源
3. 负载均衡器：缓存资源
4. 消息中间件：Kafka 按保留策略暂存消息
5. 服务：CPU 缓存 -> 内存 -> 二级磁盘缓存
6. 分布式缓存：Redis 提供优于数据库的读写性能
7. 全文搜索：Elasticsearch 索引数据副本
8. 数据库多级缓存： • WAL（预写日志） • 缓冲池 • 物化视图 • 事务日志 • 复制日志

Redis 为何如此高效？

三大原因：

1. 基于内存存储（比随机磁盘访问快千倍）
2. I/O 多路复用 + 单线程执行循环
3. 高效底层数据结构

思考题：Redis 与 Memcached 有何区别？

Redis 的多样化应用场景

不止于缓存： • 会话共享 • 热点数据缓存 • 分布式锁 • 计数器（点赞/阅读量） • 速率限制器 • 全局 ID 生成器 • 购物车（Hash 结构） • 用户留存计算（Bitmap） • 消息队列（List） • 排行榜（ZSet）

主流缓存策略

设计大型系统需重点考量缓存，常用五大策略： • 旁路缓存（Cache-Aside） • 读写穿透（Read/Write Through） • 写入回写（Write Behind） • 刷新提前（Refresh Ahead）

微服务架构

典型微服务架构

组件解析： • 负载均衡器：流量分发 • CDN：静态资源就近分发 • API 网关：身份验证 + 服务发现路由 • 身份提供者：鉴权认证 • 服务注册发现：微服务注册与查找 • 管理模块：服务监控 • 微服务：按领域划分，各自维护数据库，通过 REST/RPC 通信

优势： • 快速部署与水平扩展 • 领域专属团队维护 • 灵活支持业务需求

微服务九大最佳实践

开发准则：

1. 独立数据存储
2. 代码成熟度保持一致
3. 独立构建
4. 单一职责
5. 容器化部署
6. 无状态设计
7. 领域驱动设计
8. 微前端架构
9. 服务编排

微服务技术栈

开发阶段： • API 定义（Postman/OpenAPI） • 开发（Node.js/React 前端，Java/Python/Go 后端） • CI（Jenkins + Docker 镜像）

生产环境： • 负载均衡（Nginx） + CDN（Cloudflare） • API 网关（Spring Boot） + 服务发现（Eureka/Zookeeper） • 云部署（AWS/Azure/GCP） • 缓存（Redis） + 搜索（Elasticsearch） • 通信（Kafka/RPC） • 存储（MySQL/PostgreSQL + S3/Cassandra） • 监控（Prometheus/Elastic Stack/Kubernetes）

Kafka 的高性能秘诀

两大设计：

1. 顺序 I/O：充分利用磁盘顺序写入特性
2. 零拷贝技术： • 传统方式：磁盘 -> OS 缓存 -> 应用内存 -> Socket 缓冲 -> 网卡 • 零拷贝：通过 sendfile() 系统调用，OS 缓存直送网卡

支付系统

信用卡如何为银行创造利润？VISA/Mastercard 盈利模式

流程解析：

1. 持卡人支付 $100
2. 收单行收取商户折扣费（含交换费）
3. 发卡行获得交换费
4. 卡组织（VISA）收取网络服务费
5. 持卡人支付服务费

发卡行成本包括风险承担、运营成本等。

VISA 支付流程

两大流程： 授权流程：

1. POS 终端发送交易
2. 收单行转交卡组织
3. 发卡行批准并冻结资金

结算流程：

1. 商户发起批量请款
2. 卡组织清算
3. 资金划转

印度统一支付接口 (UPI)

特点： • 实时支付系统 • 占印度数字交易 60% • = 支付标记语言 + 互操作标准

DevOps

DevOps vs. SRE vs. 平台工程

演进历程： • DevOps（2009）：弥合开发与运维鸿沟 • SRE（Google 2000s）：大规模系统可靠性工程 • 平台工程：延伸 DevOps/SRE，提供全方位支持

Kubernetes 架构解析

核心组件： 控制平面：

1. API Server：集群通信枢纽
2. Scheduler：Pod 调度
3. Controller Manager：运行各类控制器
4. Etcd：集群状态存储

节点：

1. Pod：最小调度单元（多容器共享 IP）
2. Kubelet：容器生命周期管理
3. Kube Proxy：网络流量路由

Docker 与 Kubernetes 如何选择？

Docker： • 单机容器化 • 手动管理网络/存储

Kubernetes： • 集群级容器编排 • 自动化扩缩容与负载均衡

简言之：Docker 专注容器化，K8s 专注大规模编排。

GIT

Git 命令工作流

四区域模型： • 工作区：编辑文件 • 暂存区：准备提交 • 本地仓库：已提交代码 • 远程仓库：服务器存储

Git Merge vs. Rebase

Merge： • 创建新提交保留分支历史 • 非破坏性操作

Rebase： • 将特性分支变基到主分支头部 • 生成线性提交历史 • 黄金准则：永远不要在公共分支使用！

云服务

2023 云服务对比速查

云原生演进史

四大维度演进：

1. 开发流程：瀑布式 -> 敏捷 -> DevOps
2. 架构：单体 -> 微服务
3. 部署：物理机 -> 虚拟机 -> 容器
4. 基础设施：自建 -> 云端

开发效率工具

JSON 可视化神器 JsonCrack

功能亮点： • 将嵌套 JSON 转为关系图 • 支持导出为图片 • 提升可读性

代码转架构图工具

特性： • Python 代码生成云架构图 • 直接渲染在 Jupyter Notebook • 支持 AWS/Azure/GCP/K8s 等 • GitHub 仓库

Linux

Linux 文件系统解析

关键点： • 1994 年 FHS 标准统一布局 • 主要目录功能： • /bin：基础命令 • /etc：配置文件 • /home：用户目录 • /var：可变数据 • 通过 cd/ls 命令探索

18 个常用 Linux 命令

常用命令： • ls：列出目录内容 • cd：切换目录 • mkdir：创建目录 • rm：删除文件或目录 • cp：复制文件或目录 • mv：移动或重命名文件或目录 • chmod：修改文件权限 • grep：在文件中搜索模式 • find：查找文件或目录 • tar：操作 tar 归档文件 • vi：文本编辑器 • cat：显示文件内容 • top：显示进程与资源使用 • ps：显示进程信息 • kill：终止进程 • du：估算文件空间占用 • ifconfig：配置网络接口 • ping：测试网络连通性

安全

HTTPS 工作原理

流程解析：

1. 建立 TCP 连接
2. 客户端发送 “client hello”，协商加密算法与 TLS 版本
3. 服务器返回证书，客户端验证
4. 客户端生成会话密钥，用服务器公钥加密
5. 服务器用私钥解密，双方持有相同会话密钥
6. 对称加密传输数据

为何切换到对称加密？

1. 非对称加密单向，服务器无法安全返回数据
2. 非对称加密计算开销大，不适合长会话

OAuth 2.0 简易解析

核心概念： • 用户、服务器、身份提供者（IDP） • OAuth 令牌功能： • 单点登录（SSO） • 跨系统授权 • 访问用户信息

四大认证机制

常用方式：

1. SSH 密钥：安全访问远程系统
2. OAuth 令牌：第三方应用有限访问
3. SSL 证书：加密通信
4. 凭证：用户认证信息

会话、Cookie、JWT、令牌、SSO 与 OAuth 2.0

演进历程： • WWW-Authenticate：基本认证 • Session-Cookie：服务器维护会话 • Token：客户端传递令牌 • JWT：标准令牌格式，自包含签名 • SSO：单点登录，跨站点认证 • OAuth 2.0：授权第三方访问

密码安全存储与验证

最佳实践： • 切勿明文存储 • 直接哈希仍不安全 • 加盐哈希：哈希（密码 + 唯一随机盐值） • 验证流程：

1. 获取盐值
2. 计算哈希
3. 比对存储哈希

JSON Web Token (JWT) 解析

结构解析： • 头部：算法与类型 • 载荷：用户信息 • 签名：防篡改

Google 身份验证器原理

两阶段流程：

1. 启用两步验证：生成密钥，存储于数据库与客户端
2. 登录验证：基于时间的一次性密码（TOTP）算法

安全性： • 密钥加密传输 • 6 位密码百万组合，30 秒失效

真实案例研究

Netflix 技术栈

关键组件： • 移动与 Web：Swift/Kotlin + React • 前后端通信：GraphQL • 后端服务：ZUUL + Eureka + Spring Boot • 数据库：EV Cache + Cassandra + CockroachDB • 消息与流：Kafka + Flink • 视频存储：S3 + Open Connect • 数据处理：Flink + Spark + Tableau + Redshift • CI/CD：JIRA + Confluence + Jenkins + Spinnaker

Twitter 2022 架构

关键组件： • 前端：React + GraphQL • 后端：Finagle + Thrift • 存储：Manhattan + Gizzard • 缓存：Twemcache + Memcached • 消息：Kestrel + Kafka • 数据处理：Heron + Scalding

Airbnb 微服务架构演进

三个阶段：

1. 单体架构（2008-2017）：Ruby on Rails
2. 微服务架构（2017-2020）：服务拆分，独立团队
3. 微服务 + 宏服务（2020-至今）：API 统一化

Monorepo 与 Microrepo 对比

核心差异： • Monorepo：全代码库共享依赖，统一标准 • Microrepo：独立仓库，按需升级

工具支持： • Monorepo：Bazel（Google）、Buck（Meta） • Microrepo：Maven、NPM、CMake

Stack Overflow 架构真相

现实 vs 预期： • 预期：微服务 + 分布式缓存 + 消息队列 • 现实：9 台物理服务器 + 单体架构

Amazon Prime Video 监控架构转型

背景： • 实时监控数千直播流质量 • 旧架构：Lambda + Step Functions + S3 • 新架构：单体部署，组件合并

成本优化： • 减少状态转换与数据传输开销 • 节省 90% 成本

启示： • 架构演进是策略而非教条 • Serverless First 不等于 Serverless Only

Disney Hotstar 赛事表情符号处理

架构亮点： • HTTP 请求接收 • Kafka 缓冲 • Spark 流处理（2 秒聚合） • MQTT 实时分发

Discord 消息存储演进

技术选型： • MongoDB -> Cassandra -> ScyllaDB • 性能提升：读写延迟显著降低

视频直播技术解析

流程解析：

1. 音视频采集
2. 编码压缩（H.264/H.265）
3. 分段传输
4. 自适应码率（ABR）
5. CDN 分发
6. 客户端解码播放
7. 存储回放

协议支持： • RTMP：实时消息传输 • HLS：苹果设备支持 • DASH：动态自适应流