我自己也深度使用了，包括文章撰写和代码输出，说实话，思考的过程确实惊艳了我。它的思考逻辑比我更完善，推导路径也更显性。

但今天我们聊的不是这些「高光时刻」，而是我们在实际使用过程中常常遇到的不可用场景：

“服务器繁忙，请稍后再试。”

是的，DeepSeek 的繁忙（也可以叫故障？）提示几乎成了高频词。无论是免费用户还是付费 API 调用者，都可能在关键时刻遭遇「空文本返回」、「响应超时」、「重试多次仍异常」等问题。

1. DeepSeek 的可用性表现

首先我们看一下官方的记录： https://status.deepseek.com/

总结起来如下：

• 网页/API 性能异常（Web/API Degraded Performance）
  • 持续时间： 2025 年 1 月 27 日至今（2 月 5 日仍在监控中）
  • 影响范围： API 和网页服务同时出现性能下降，部分用户请求超时或失败。从实际使用体验来看，基本属于不可用的状态了，但是官方的状态还是可用，仅性能问题，这里的状态指标和实际还是有一些出入。
• API 持续故障（Major outage/Partial outage）：
  • 持续时间：2025 年 1 月 27 日到 2 月 5 日
  • 影响范围：持续影响 API 调用，故障持续时间较长，作为一个付费的能力，这是不合格的。
• 网页对话服务不间断故障：
  • 持续时间：2025 年 1 月 27 日到 1 月 31 日
  • 影响范围：持续影响网页用户的使用，在用户的反馈中

从结果来看，DeepSeek 还没有做好应对海量用户的情况，不管是从资源部署，还是工程建设方面，都不是一个合格的状态。

在写这篇文章的时候，除了第一次正常返回，后续都是「服务器繁忙，请稍后再试。」 如下图所示：

从用户能看到的表象来看，自 2025 年 1 月底至 2 月初，DeepSeek 多次出现服务中断：

• 深度思考与联网搜索功能失效：用户使用核心功能时频繁提示「技术原因暂不可用」，仅保留基础对话能力。
• API 服务波动：付费用户调用接口时返回空文本或延迟异常，甚至因「服务器资源紧张」暂停充值。
• 注册与登录拥堵：因恶意攻击导致注册功能瘫痪。

DeepSeek 官方将问题归因于突发流量、系统升级适配、底层基础设施波动，并强调「稳定性是首要任务」。但用户更直观的感受是：服务可用性不足，容错机制缺失。

2. AIGC 产品和互联网产品的天然差异

DeepSeek 作为一个 AIGC 的产品，其和传统的互联网产品就存在天然的差异：

2.1 响应时间与计算资源消耗

传统互联网产品

• 主要依赖数据库查询、预定义的业务逻辑和缓存，响应时间通常较短，且可预测。
• 计算资源需求相对稳定，系统可扩展性较强。

AIGC 产品

• 依赖深度学习模型进行推理，计算量大，响应时间较传统产品长，且可能因模型复杂度、输入长度等因素波动。
• 需要强大的 GPU 计算资源，服务器负载高，可能导致响应延迟或服务不可用。
• 可能需要异步处理或流式输出（如 ChatGPT 的逐字生成），以改善用户体验。

2.2 可靠性与稳定性

传统互联网产品

• 由于功能是规则驱动的，系统行为可预测，崩溃或异常情况较少。
• 依赖负载均衡、CDN、数据库复制等机制，保障高可用性（通常可达 99.99% 以上）。

AIGC 产品

• 生成式AI的输出不确定，在不同运行环境、不同模型版本下可能产生不同结果，影响用户体验的一致性。
• 可能受到模型崩溃、推理失败、内存爆炸、API 速率限制等问题的影响，导致服务不可用或部分功能异常。
• 需要额外的故障检测、自动重试、回退机制（如降级到预定义模板或缓存内容）来提升系统可用性。

2.3 可控性与一致性

传统互联网产品

• 业务逻辑是确定性的，相同输入通常会产生相同输出，保证用户体验的一致性。虽然有「千人千面」的算法，但是其本质上是可控的
• 开发人员可以精确控制系统行为，便于调试和优化。

AIGC 产品

• AI 生成内容的不可预测性导致相同输入可能产生不同的输出，影响可控性和一致性。
• 需要温度参数（Temperature）、Top-K 采样等技术来调整生成稳定性，但仍无法完全保证一致性。
• 可能需要缓存机制、提示词优化（Prompt Engineering）或微调模型来提高可控性。

2.4 可扩展性

传统互联网产品

• 主要依赖水平扩展（如增加服务器、数据库分片）来提升性能。
• 由于业务逻辑固定，扩展后的系统可保持较高的一致性。

AIGC 产品

• 由于深度学习推理的计算密集型特性，水平扩展难度较高，需要依赖专用硬件（如 GPU）。
• 高并发场景下，可能需要分布式推理、模型量化、边缘计算等优化策略来提升可扩展性。
• 可能采用多级缓存（如存储常见问题的预生成答案，在产品中是否能使用待确认）来减少推理开销。

2.5 错误处理与恢复机制

传统互联网产品

• 由于逻辑清晰，错误通常可以通过日志分析、异常处理机制快速排查和修复。
• 具备回滚机制，当系统发生故障时，可以回退到稳定版本。

AIGC 产品

• 由于模型的黑箱特性，错误较难追踪。
• 可能需要人机协同（Human-in-the-loop）机制，让人工审核关键任务的生成内容。
• 需要自动调整机制（如 RAG，Retrieval-Augmented Generation），结合外部知识库提高准确性。

2.6 可维护性与升级

传统互联网产品

• 代码和数据库可以模块化升级，通常只影响部分功能。
• 版本管理清晰，可通过灰度发布、A/B 测试等方式进行平滑更新。

AIGC 产品

• 模型升级可能导致行为变化，新模型可能生成完全不同的内容，影响可用性。
• 需要持续微调（Fine-tuning）或增强检索（RAG），以适应新需求。
• 可能需要模型版本管理（如 OpenAI API 的 GPT-4.0 vs. GPT-3.5），让用户可选择不同模型版本，以保证兼容性。

AIGC 产品在系统可用性上面临更大的挑战，主要在于响应时间、可靠性、可控性和错误处理等方面。为了提升可用性，需要结合缓存优化、模型优化、人工审核、错误监测、版本管理等策略，从而确保系统的高效性和稳定性。

3. 借鉴传统互联网产品的可用性策略

在面对 DeepSeek 这样 AIGC 产品的可用性挑战时，我们可以借鉴传统互联网产品的高可用性策略。以下是三种核心策略：隔离、限流和弹性扩展，它们对于提升整体服务的稳定性和可靠性至关重要。

3.1 隔离

隔离 是指将不同类型的流量、服务和资源进行物理或逻辑上的分离，以减少单点故障的影响，提高系统的稳定性。

（1）传统互联网产品的隔离策略

• 数据库读写分离：使用主从数据库架构，将读请求和写请求分离，提高数据库吞吐能力。
• 微服务架构：将不同的业务模块拆分为独立的微服务，避免单个模块的故障影响整个系统。
• 多数据中心部署：在不同地域部署多个数据中心，确保某个数据中心故障时，服务仍然可用。

（2）AIGC 产品中的隔离策略

• 模型推理服务隔离：不同的 AI 任务（如文本生成、代码补全、图像生成）使用独立的推理服务，以避免相互影响。
• 缓存与实时推理分离：对于常见问题或高频请求，使用缓存存储预生成的答案，减少对 AI 推理的依赖。
• 免费用户和付费用户隔离：将高优先级的计算资源分配给付费用户，确保他们在高负载时仍能获得稳定的服务。
• 企业用户和个人用户隔离：针对企业用户的部署资源和个人用户的资源做隔离，甚至对于企业用户做多个隔离泳道。

（3）隔离策略解决的问题

• 减少单点故障，避免某个服务异常影响整个系统。
• 优化资源利用，确保高优先级任务不会被低优先级任务拖累。
• 提高系统韧性，即使部分服务故障，核心功能仍可正常运行。

（4）隔离策略的注意事项

• 隔离的粒度需要合理设计，过度拆分可能导致管理复杂度上升，系统之间的通信成本增加。
• 监控与调度，确保不同隔离层的资源调度合理，避免出现某些区域资源过载，而其他区域资源空闲的情况。

3.2 限流

限流 是指在高并发情况下，对请求进行限制，以防止系统过载，保障关键用户和服务的稳定性。

（1）传统互联网产品的限流策略

• 令牌桶/漏桶算法：限制请求速率，确保系统不会被短时间内的流量高峰压垮。
• IP 级限流：对单个 IP 地址的请求频率进行限制，防止恶意爬虫或 DDoS 攻击。
• 用户级限流：根据用户级别（普通用户、VIP 用户）设置不同的 QPS 上限。

（2）AIGC 产品中的限流策略

• API 访问限流：对于 DeepSeek 这样的 AI API，限制每个用户的最大请求频率，防止个别用户占用过多计算资源。以及对于 IP 的访问限流。
• 任务队列管理：对于高计算消耗的任务（如长文本生成、复杂代码推理），采用任务排队机制，避免瞬时请求超载。排队机制在文生图的场景下属于通用方案，以 MJ 为例，其商业模式就在于任务数，任务能力的不同，底层还是资源的不同。
• 用户限流：以某种代币的方式发放给免费用户，使其有一定的使用次数限制，增加浏览器指纹等用户级的限制，减少用户的并发使用情况，以及增加对话数的限制等。
• 动态限流：根据服务器的当前负载自动调整限流策略，在资源紧张时降低 QPS，在资源充足时放宽限制。

（3）限流策略解决的问题

• 防止系统崩溃，确保 AI 服务在高并发情况下仍能稳定运行。
• 优化资源分配，优先保证高价值用户的服务体验。
• 抵御恶意攻击，防止 DDoS 攻击或恶意爬取 API 造成的资源滥用。

（4）限流策略的注意事项

• 限流策略需要动态调整，不能一刀切，否则可能导致正常用户体验下降。
• 需要提供合理的错误反馈，例如「当前请求过多，请稍后重试」而不是简单的「服务器错误」。
• 与缓存结合使用，对于常见请求，优先返回缓存结果，减少对 AI 推理的调用次数。这个点在产品层面需要考虑，确实，和传统互联网产品相比，缓存在 AIGC 产品中的使用需要更谨慎一些。

3.3. 弹性扩展

弹性扩展 是指根据实际流量动态调整计算资源，以提高系统的可用性和响应速度。

（1）传统互联网产品的弹性扩展策略

• 自动扩容：使用云计算（如 AWS Auto Scaling、Kubernetes HPA）自动增加或减少服务器实例。
• 负载均衡：使用 Nginx、CDN、反向代理等技术，将流量均匀分配到不同的服务器节点上。
• 冷/热数据分离：将访问频率高的数据放入高速缓存，减少数据库查询压力。

（2）AIGC 产品中的弹性扩展策略

• GPU 资源动态调度：由于 AI 推理高度依赖 GPU，可以采用动态 GPU 分配策略，根据请求量调整 GPU 负载。
• 多模型并行推理：对于高负载场景，可以部署多个副本的 AI 模型，采用负载均衡策略分配请求。
• 推理任务分批处理：对于大规模生成任务，采用批处理方式，提高计算效率，减少单次推理的成本。

（3）弹性扩展策略解决的问题

• 避免资源浪费，在低流量时减少计算资源，降低运营成本。
• 提升系统吞吐能力，在高流量时快速扩展计算能力，确保服务稳定。
• 提升响应速度，减少高并发情况下的请求排队时间，提高用户体验。

（4）弹性扩展策略的注意事项

• 扩容速度需要优化，如果扩容响应过慢，可能导致短时间内大量请求失败。
• 成本控制，GPU 计算资源昂贵，需要权衡服务质量与成本。
• 监控与预警，需要实时监控系统负载，提前预测流量高峰，避免突发情况导致系统崩溃。

AIGC 更多的问题还是算力资源的问题，从 DeepSeek 的服务器 IP 来看，其使用的是华为云，后端推理算力不确定是哪家的。基于多云的弹性调度是一个可以考虑的方案，当然，前提是成本能够扛得住。

4. 从故障看 AIGC 可用性策略的四大核心矛盾

1. 算力需求与资源调度的失衡
   AIGC 模型的推理成本极高。当用户量激增或遭遇攻击时，弹性伸缩能力不足可能直接导致服务崩溃。

2. 功能复杂度与稳定性的博弈
   DeepSeek 的「深度思考」依赖多模态数据处理和强化学习技术，但功能越复杂，系统耦合性越高，单点故障风险越大。

3. 用户预期与容灾能力的落差
   用户对 AIGC 的期待是「类人级响应」，但实际服务常因网络抖动、模型加载延迟等问题降级为「机械式回复」。

4. 商业化压力与技术投入的冲突
   尽管 DeepSeek 登顶多国应用商店榜单，但其快速扩张可能透支了技术团队的运维能力，导致故障频发后被迫暂停 API 充值。

DeepSeek 的故障并非个例，而是 AIGC 行业集体面临的挑战。从技术角度看，模型能力与系统稳定性需同步进化；从用户角度看，容忍度与预期管理同样关键。

未来，AIGC 服务的竞争不仅是「谁更聪明」，更是「谁更可靠」，特别是在企业应用的场景。毕竟，再惊艳的思考过程，若总以「服务器繁忙」收场，终将消磨用户的耐心与信任。

以上。

以下内容来源于QCon某高可用架构群聊天记录整理

如果携程网想把旅游信息展示到另一平台上 平台和他们的系统数据对接，pull好一些还是post好一些？或者说一个系统只是把好多其他商家的数据集合展示到统一的系统上，这样的系统一般如何架构？

先回答第一个问题：数据对接是pull好一些还是post好一些，这里需要根据实际业务做权衡，如果平台系统很大部分是通过聚合第三方数据再展示，那么比较推荐让第三方post数据，自己设计统一数据规则接口。这种情况，需要考虑自身服务的稳定性了，预防第三方误调用，击垮自身系统。如果只有小部分内容聚合第三方，那就pull，比较好保证自己系统稳定性，不过最终还得把所有的数据转换成自己格式，需要自己开发团队做这块工作。

相比较而言，post时效性高，数据交互少，如果系统会需要各个源的信息，最终也不会只是展示那么简单。如果使用post方案，则需要在接入，数据，读取等方面做隔离，在接入使用mq可以提高吞吐，在读的时候用Cache抗。并且在前期需要考虑好数据存储和数据的量级，因为是第三方的数据，在存储的扩展性方面要有比较好的方案。

最终落地的方案可能是：

按业务隔离，不同的业务相互不影响，拆分子系统；
使用redis和kafka保障高性能，kafka主要一方面用到日志上 一方面用到缓解数据库并发上；
使用nginx和lvs保障高可用；
在后期所有数据进hbase然后用storm做数据流处理和分析

以上这些并不需要一次性做到位，不要过早优化，只需要有一些大的原则，比如隔离，扩展等。小系统会随着业务慢慢演变，最终会变成大系统。在演变的过程中，可能会需要读写分离、业务分布式，分服务，架构就是在这样演变的路上成长起来的。