System Design on Chen Kai Blog

系统设计（八）：案例分析 —— 网址缩短服务、实时聊天系统、新闻信息流

Sun, 27 Jul 2025 09:00:00 +0000

学习系统设计的最佳方式是动手实践。阅读关于单个组件（如缓存、消息队列、负载均衡器）的资料能帮你建立术语库，但只有亲手设计一个完整系统，才能学会如何将这些组件有机组合，构建出真正可用的系统。

系统设计（七）：数据管道——批处理、流处理与 Lambda 架构

Thu, 24 Jul 2025 09:00:00 +0000

每秒，一家大型电商平台都会生成数千个数据点：页面浏览、搜索查询、加入购物车事件、下单、库存变更、价格更新、配送状态变化。这些原始数据未经处理时毫无价值——散落在数十个服务中，以不同格式存储，且到达速率不可预测。而将这类原始数据转化为可操作洞察的系统——实时仪表盘、个性化推荐、欺诈检测告警、业务报表——正是数据管道（Data Pipeline）。

系统设计（六）：微服务 vs 单体架构——坦诚的权衡分析

Tue, 22 Jul 2025 09:00:00 +0000

2020 年，客户数据平台 Segment 的工程团队发布了一篇题为《告别微服务》（Goodbye Microservices）的博客文章。当时，他们已将原有单体应用拆分为 140 多个微服务，但结果并非预期中的工程乌托邦。相反，团队大部分时间都在对抗分布式系统自身带来的复杂性：服务发现失败、级联超时、不一致的部署流水线，以及爆炸式增长的服务间通信缺陷。最终，他们选择回归单体架构，并报告称开发者生产力与系统可靠性均获得显著提升。

系统设计（五）：消息队列与事件驱动架构

Sat, 19 Jul 2025 09:00:00 +0000

2011 年，LinkedIn 工程团队正面临许多快速成长公司共有的难题：其单体应用已演变为一张由强耦合服务构成的复杂网络，每个服务都需同步调用另外约六个服务。一旦其中任一服务宕机，级联故障便会迅速蔓延至整个系统；而对某个服务做一次变更发布，则必须协调所有被它调用的服务所属团队。

系统设计（四）：缓存——在哪里缓存、淘汰什么，以及缓存何时反而有害

Thu, 17 Jul 2025 09:00:00 +0000

计算机科学中有个老笑话：最难的两个问题，是缓存失效（cache invalidation）、命名（naming things），以及 off-by-one 错误。这个笑话之所以成立，正是因为缓存失效确实极难处理。但与此同时，缓存又是提升系统性能最有效的单一技术——一个部署得当的缓存，可将延迟降低 100 倍，减少 90% 的数据库负载，并每月节省数千美元的基础设施成本。

系统设计（三）：API 设计——REST、gRPC、GraphQL 及如何明智选型

Tue, 15 Jul 2025 09:00:00 +0000

2015 年，Facebook 发布了一篇博客文章，正式介绍 GraphQL，并描述了其移动应用正被海量 REST API 调用所“淹没”。单个新闻信息流页面就需要从帖子、用户、评论、点赞和媒体等多个资源获取数据——每个资源对应一个独立端点，且每个端点返回的数据远超客户端实际所需。这种过度获取（over-fetching）在弱网环境下严重拖垮了移动端性能。GraphQL 是他们的解决方案，但它绝非万能解药。

系统设计（二）：DNS、CDN 与负载均衡——请求旅程的前三跳

Sat, 12 Jul 2025 09:00:00 +0000

2017 年，一家主流云服务商因一条配置错误的 DNS 记录，导致互联网大面积中断数小时——成千上万个网站无法访问，并非因为服务器宕机，而是负责将域名翻译为 IP 地址的系统出了问题。这次事故尖锐地提醒我们：那些被视作理所当然的基础设施——DNS、CDN 和负载均衡器——正是整个系统赖以运转的地基。

系统设计（一）：以系统思维思考——负载、延迟与估算的艺术

Thu, 10 Jul 2025 09:00:00 +0000

一位朋友曾请我帮忙排查一个性能问题。他们的照片分享应用在开发环境运行良好，但一到生产环境就彻底崩溃：数据库过载、API 网关频繁超时，用户大量看到 504 错误。当我问系统每秒处理多少请求时，对方回答“我不知道”；再问预期负载是多少，他说“根本没想过这个问题”。