xiaohack's Blog - 扩展性
type: channel
link: https://blog.xiaohack.org/tag/3a455446-c2aa30/
items: 6 个步骤搞定系统设计面试
items: 不到百万级，看不见 MCP 的真实问题：创始人亲述这疯狂的一年

6 个步骤搞定系统设计面试
type: item
date: 2026-01-20T12:40:38+08:00
description: 本文梳理了一套通过 6 个步骤清晰展示系统设计思维的应对框架，包括澄清需求、定义成功标准、画出高层架构、设计数据层，到扩展性与可靠性，最后考虑权衡取舍。系统设计面试并不是考你会不会背各种技术名词，而是看你能不能在有限时间里，有条理的拆解问题、做出合理的架构决策，并把自己的思路讲清楚。面试的评分标准其实是“思考方式”，而不是“系统有多炫酷”。因此需要一套可重复执行的流程，把几十分钟的面试时间拆分成若干阶段，每一阶段回答一个明确的问题。接下来就介绍这套能够帮助你顺利通过各种系统设计面试的框架。50 分钟作战计划下面是一份 50 分钟时间切片路线图：- 0–5 分钟：澄清需求 - 6–12 分钟：定义成功标准 - 13–22 分钟：画出高层架构 - 23–32 分钟：设计数据层 - 33–42 分钟：讨论扩展性与可靠性 - 43–50 分钟：收尾与权衡总结路线图可以按阶段展开，每个阶段都对应面试过程中呈现在白板或文档上的“可见成果”。阶段 1：先澄清再设计（0–5 分钟）永远不要直接开始画图。第一步应该是：用问题把“题目”变成“需求”。可以围绕以下维度澄清：用户与规模：有多少用户、日活？是 100 万还是 10 亿？核心用例：最重要的 1～2 个场景是什么？例如仅做照片分享，还是要包含完整的社交功能？客户端形态：只考虑移动端，还是移动 + Web？地理分布：是否是全球分布，是否有多区域部署需求？时延要求：例如“Feed 打开时间需要控制在 500ms 以内”。对于面试官抛出的“设计 Instagram”之类的问题，可以先反问：“我们是只关注图片流（Photo Feed），还是要覆盖整个产品？是否支持视频？大致用户量级是多少？”这一阶段的目标：用 2–3 分钟让双方对“要构建的东西”达成共识，让后面的设计有清晰边界。阶段 2：写下什么叫“成功”（6–12 分钟）在澄清了范围之后，第二步是明确定义功能性和非功能性需求，包括：功能性需求：比如“用户可以上传图片、关注他人、看到关注对象的动态流、对内容点赞与评论”等；非功能性需求：比如“高可用性（High Availability）达到 99.9%”、“Feed 加载延迟（Latency）小于 500ms”、“可以扩展到 1 亿日活用户”、“允许最终一致性（Eventual Consistency）”。把这些需求点写在白板上或共享文档中，就相当于和面试官形成了“设计合约”：后续所有架构选择，都要能解释清楚“这是为了满足哪条需求”。这一阶段的目标：让面试官看到你不是在“凭感觉设计”，而是在对齐“什么设计是成功的”。阶段 3：先画大图，再补细节（13–22 分钟）到了真正画架构图的时候，强调一个原则：先画大块（High-Level Components），再深入具体实现，而不是一开始就纠结字段、索引或具体中间件。典型高层架构可以包括：┌─────────┐ │ Users │ └────┬────┘ │ ↓ ┌─────────────┐ │ CDN/Cache │ └─────┬───────┘ │ ↓ ┌──────────────┐ ┌──────────────┐ │ Load Balancer│─────→│ Load Balancer│ └──────┬───────┘ └──────┬───────┘ │ │ ↓ ↓ ┌─────────────┐ ┌─────────────┐ │ API Servers │ │Media Service│ └──────┬──────┘ └──────┬──────┘ │ │ ↓ ↓ ┌─────────────┐ ┌─────────────┐ │ Database │ │Object Storage│ └─────────────┘ └─────────────┘客户端（Mobile / Web）；CDN（Content Delivery Network）和缓存（Cache），用于分发静态资源与热门内容；负载均衡（Load Balancer），把流量分发到后端服务；API 服务（API Servers），承载业务逻辑；媒体服务（Media Service），负责图片/视频的处理与存储；数据库（Database），保存用户、关系、元数据；对象存储（Object Storage），保存实际的图片/视频文件。在讲解数据流时，可以用一句简短的“端到端路径”来串起来，例如：用户上传图片 → API 服务处理请求 → 媒体服务转码与压缩 ↓ 写入对象存储 ↓ 在数据库中记录元数据 ↓ 返回可访问 URL这一阶段的目标：让面试官在脑中形成清晰的“系统鸟瞰图”，知道所有关键组件长什么样、怎么互相连接。此时还不必深入到每个组件内部实现。阶段 4：谈数据，而不…

不到百万级，看不见 MCP 的真实问题：创始人亲述这疯狂的一年
type: item
date: 2026-01-14T17:03:43+08:00
description: 一年前，MCP 还只是一个“把模型连到工具”的开源协议；一年后，它已经冲进了一个很少有协议能抵达的位置：事实标准。 在这场一年狂飙的亲历者之一——MCP 联合创作者、核心维护者 David Soria Parrra 看来，最戏剧性的分水岭发生在四月前后：当 Sam Altman、Satya Nadella、Sundar Pichai 先后公开表态，Microsoft、Google、OpenAI 都将采用 MCP，“大客户”突然从 Cursor、VS Code 扩散到整个行业。 这一年，MCP 从本地 “桌面玩具”，一路演进到远程 server、认证机制、面向企业可用的 OAuth 重构，再到 11 月引入 long-running tasks，把深度研究、甚至 agent-to-agent 交互变成协议的一等公民。David 的总结很直接：“这一年真的非常疯狂。” 这段对谈里，David 也很坦率地复盘了 MCP 这一年的取舍：做对的，是死磕标准 HTTP；踩坑的，是把关键能力做成了‘可选项’，结果客户端大多不实现，双向能力被削掉。 更现实的问题是扩展性：规模一上来，多实例、多 Pod 下同一段交互可能打到不同机器，不得不用 Redis 之类的共享存储来“拼状态”，请求量到百万级就开始吃力：“当规模一上来，这件事一点都不好玩。”“一些公司——比如 Google、Microsoft——他们在用 MCP 的时候，规模已经大到我不能公开具体数字，但可以说是百万级请求。到了这个量级，这就真的成了一个问题。” 以下是播客内容整理，略有删节：MCP 的一年：从发布到行业事实标准 主持人：要不你先简单讲讲 MCP 的发展情况，以及之前为什么决定把它捐赠给基金会？接下来我们再系统回顾 MCP 这一年的演进，然后再请基金会的其他负责人加入，聊一些更宏观的内容。 David Soria Parrra（MCP Co-creator）：如果回到一年前，MCP 刚发布的时候，其实谁都没想到它会在这一年里迎来如此疯狂的增长。 老实说，这一年感觉像过了一个世纪。一开始是在感恩节和圣诞节前后，很多开发者开始自发地用 MCP 搭东西。随后，像 Cursor、VS Code 这样的“大客户”开始出现。 真正的拐点出现在四月左右——当时 Sam Altman、Satya Nadella、Sundar Pichai 等人陆续公开表示，Microsoft、Google、OpenAI 都会采用 MCP。那是一个非常明显的“分水岭”。与此同时，我们也一直在推进协议本身的演进。 最初，MCP 几乎只支持本地使用：你在桌面上跑一个 MCP server，通过本地 stdio 和客户端通信。但到了今年三月，我们开始推进“远程 MCP server”——也就是如何通过网络连接 MCP，并且第一次引入了认证机制。到了六月，我们又对这套认证方案进行了比较大的修订，尤其是为了让它真正适用于企业场景。 我们非常幸运，在三月到六月这段时间里，有真正做 OAuth 标准的行业专家，直接参与进来，帮我们把一些关键细节“拉正”。我们也在这段时间里大量投入在安全最佳实践上。 到了 11 月底，我们发布了新一轮重要版本，引入了长时间运行任务（long-running tasks）这一关键原语，用来支持深度研究类任务，甚至是 agent-to-agent 的交互。 现在的感觉是：MCP 的基础已经非常扎实了。接下来还有一两个关键原语和可扩展性问题需要解决，然后协议整体会进入一个相对稳定的阶段。 说实话，这一年真的非常疯狂。 主持人：你刚刚提到 agent-to-agent，那是不是也涉及 A2A 协议？在 Agentic AI Foundation 成立时，有没有讨论过把其他协议也纳入进来？ David：老实说，这几乎是必然会发生的讨论。我们当然讨论过市场上其他协议，比如一些支付协议之类的东西。但在决定成立基金会时，我们有两个非常明确的原则： 第一，我们想从小开始。这是 Anthropic 第一次参与开放源代码基金会，一切都是新的。我们希望先在一个相对可控的范围内学习如何把这件事做好，并且和 OpenAI、Block 一起，把基金会的节奏掌控住。 第二，在协议层面，我们非常在意“事实标准（de facto standard）”。目前来看，真正已经具备广泛采用度的协议，只有 MCP。其他协议还没有“走到那一步”。当然，如果未来某个协议发展到那个阶段，并且在功能上是互补的，我们是完全开放的。 在应用层，我们会更灵活；但在协议层，我们不希望一个基金会里同时维护五个做同一件事的通信协议。 主持人：你现在在基金会和 MCP 之间，是不是有点“戴两顶帽子”？ David：确实如此，但我主要精力仍然在 MCP 上。…