Skip to content

🗺️ 架构模板库

每个模板是一张「架构地图」。我们只讲架构,不讲语言/框架/语法。 目标是:让你看完就能理解「这类系统为什么这么设计」,并能把它当作自己设计的起点。


模板清单

21 个模板:16 个经典 / 通用系统 + 5 个 AI 原生系统(LLM 时代新增)。每个模板都附真实开源项目 / 工程文档链接(见各模板末尾「参考原型与延伸阅读」)。

经典 / 通用系统

模板代表产品一句话定位核心看点
AI 对话产品Claude、ChatGPT把大模型包装成可对话、可流式、可联网的产品推理服务、流式、上下文、RAG、成本
浏览器插件Honey、Grammarly在别人的网页里安全地注入能力并变现脚本分离、注入、隐私边界、变现
普通网站官网、博客、SaaS 后台90% 项目真正需要的「够用就好」架构三层、缓存、读写分离
移动 App大多数 iOS/Android 应用在不稳定网络下提供顺滑体验离线优先、同步、状态、推送
电商平台Amazon、Shopify、淘宝让「钱货两清」在高并发下不出错库存、订单、支付、超卖、洪峰
社交信息流Twitter/X、Instagram把海量内容按关系/兴趣排好送到每个人眼前Feed 推拉、关注图、热点扩散
视频流媒体Netflix、YouTube把大文件以最低延迟、最省带宽送达全球转码、CDN、自适应码率、推荐
实时通讯WhatsApp、Slack、微信让消息又快又不丢又有序地到达长连接、时序、离线投递、群扩散
短链接服务Bitly、TinyURL、t.co把长链接压成可分发可追踪的短码并极速重定向读多写少、缓存、301/302、唯一 ID
支付系统Stripe、支付宝、PayPal在不确定世界里把账算到分毫不差幂等、复式记账、对账、状态机
搜索引擎Google、Elasticsearch用倒排索引让关键词毫秒级命中并排序倒排索引、相关性、召回+精排、分片
网约车 / 出行Uber、滴滴在活地图上秒级撮合海量司机与乘客地理空间索引、实时位置、供需匹配
实时协同文档Google Docs、Figma多人同时编辑、实时合并、互不覆盖OT/CRDT、单 writer 串行、操作日志
云存储 / 网盘Dropbox、iCloud文件不丢、多设备同步、少占空间分块、内容寻址去重、增量同步
通知 / 推送系统Novu、FCM/APNs把「发生了什么」克制可靠地送达对的人多渠道扇出、去重限频、异步重试
在线票务 / 抢票Ticketmaster、大麦、12306海量瞬时争抢有限座位还不超卖虚拟等候室、原子扣减、锁座超时

🤖 AI 原生系统(LLM 时代新增)

模板代表产品 / 原型一句话定位核心看点
AI 中转站 / 网关One API、LiteLLM、Portkey用统一入口接入所有大模型并集中治理统一接口、计费限流、负载均衡、缓存
RAG 知识库RAGFlow、LlamaIndex、Dify让模型「开卷考试」、基于你的资料作答切块、向量检索、混合检索+重排、引用
AI Agent / 工作流Dify、Coze、LangGraph让模型规划→调工具→观察→再决策行动循环、工具沙箱、记忆、可控兜底
模型推理服务vLLM、SGLang、Triton在 GPU 上把模型榨到最高吞吐连续批处理、分页 KV、量化、多副本
向量数据库Milvus、Qdrant、pgvector海量高维向量的毫秒级相似检索ANN、HNSW/IVF、召回-延迟权衡

每个模板都长一样:统一的 14 段结构

我们刻意让所有模板遵循同一套结构(见 _TEMPLATE.md)。这样做有两个好处:

  1. 越读越快:你第一次读要从头看,第十次读就能直接跳到「关键决策」那一节。
  2. 结构本身就是教学:这 14 段,正好就是你设计任何系统时该依次问自己的 14 类问题。
#段落它在回答什么问题
1一句话定位这东西到底是什么?
2业务本质它在解决什么真实问题?谁付钱?
3核心需求与约束功能要做什么?非功能(质量)要满足什么?
4架构全景图整体长什么样?(一张 ASCII 图)
5组件职责每个部件干什么?为什么需要它?
6关键数据流核心场景下,请求/数据怎么流动?
7数据模型与存储存什么?为什么用这种存储?
8关键决策与权衡在哪些岔路口做了选择?放弃了什么?
9规模化与瓶颈用户涨 100 倍,第一个会死的是哪?
10安全与合规哪里是攻击面?哪些数据碰不得?
11常见误区 / 反模式新手最容易在哪里把它做错?
12演进路线MVP→成长期→成熟期,每阶段架构长什么样?
13可复用要点哪些思想能搬到别的系统上?
14参考原型与延伸阅读它的真实原型是哪些开源项目 / 公开文档?

阅读建议

  • 别死记图。记住的应该是「为什么这么连」,而不是「这里有几个框」。同一个系统,换个规模或换个约束,图就完全不同。
  • 重点看第 8、9、11 段。这三段(决策权衡、瓶颈、误区)是浓缩了真实经验的部分,也是面试和实战最值钱的部分。
  • 对照第 12 段(演进)看自己。你现在做的东西,大概率不需要成熟期那套重型架构。看清楚自己在哪个阶段,避免过度设计。

关于「真实性」的说明

这些模板基于这些产品公开披露的架构理念、工程博客、技术演讲和业界通行实践整理而成,目的是教学:抓住这类系统架构上的共性与关键取舍。

它们不是任何公司的内部真实图纸,具体数字、组件命名做了通用化处理。把它们当作「这一类系统的典型架构长这样」来理解,而不是「某公司就是这么实现的」。


想贡献一个新模板?

  1. 复制 _TEMPLATE.md 到一个新目录,比如 templates/your-system/README.md
  2. 把 14 段逐一填满(含给出真实的参考原型链接),坚持只讲架构——一旦你开始写「用 XX 语言的 YY 库」,就停下来问自己:这是架构决策,还是实现细节?
  3. 图用 ASCII 画(纯文本、到处都能看、永不失效)。
  4. 在上面的清单表格里加一行。

标准:一个没接触过这个领域的工程师,读完你的模板,能讲清楚「这类系统为什么这么设计、会死在哪」。