1. 从一个真实的线上故障说起去年我们团队负责的一个核心服务在某个深夜突然出现大面积调用失败。监控告警瞬间刷屏但诡异的是后端依赖的数据库和缓存集群各项指标都显示正常。紧急排查后发现问题出在服务与一个第三方计费API的交互上。这个API的某个服务节点因为区域网络波动响应变得极其缓慢且不稳定导致我们服务的大量线程被阻塞在等待响应上最终线程池耗尽服务雪崩。我们紧急切走了流量但损失已经造成。事后复盘我们意识到一个致命问题我们的HTTP客户端虽然配置了超时和简单的重试但缺乏一套智能的、可编排的故障转移与重试策略。所有的请求都傻傻地撞向同一个可能已经“半死不活”的服务端点直到超时。这个惨痛教训直接催生了我们对run.ts这个核心执行单元的升级思考。上篇我们构建了基础的执行器、上下文和生命周期钩子解决了“如何规范地执行一个任务”。但一个健壮的生产级系统不仅要能“执行”更要能“优雅地失败并成功恢复”。这就是本篇要深入探讨的故障转移、重试策略与结果封装。我们将不再把run函数看作一个简单的调用而是将其视为一个具备韧性、可观测性的分布式事务单元。通过本篇你将学会如何为你的异步任务注入“不死”的特性以及如何将纷乱的执行结果标准化让调用方处理起来得心应手。2. 故障转移从单点依赖到韧性架构故障转移的核心思想是“不要把所有鸡蛋放在一个篮子里”。在分布式调用中这意味着当首选方案如特定的API端点、数据库主节点、算法策略A失败时系统应能自动、无缝地切换到备用方案而不是直接宣告失败。2.1 故障转移的策略模式设计在run.ts的上下文中故障转移不再局限于网络层面它可以应用于任何可能失败的“执行策略”。我们抽象出一个FallbackStrategy接口。// 定义策略接口 interface ExecutionStrategyT, R { name: string; execute(ctx: RunContext, input: T): PromiseR; } // 故障转移策略实现 class FallbackStrategyT, R implements ExecutionStrategyT, R { constructor( private readonly primary: ExecutionStrategyT, R, private readonly fallback: ExecutionStrategyT, R, private readonly shouldFallback: (error: any, ctx: RunContext) boolean () true ) {} async execute(ctx: RunContext, input: T): PromiseR { ctx.logger.info([${this.primary.name}] 开始执行主策略); try { const result await this.primary.execute(ctx, input); ctx.logger.info([${this.primary.name}] 主策略执行成功); return result; } catch (error) { // 判断是否应该触发故障转移 if (this.shouldFallback(error, ctx)) { ctx.logger.warn([${this.primary.name}] 执行失败触发故障转移至 [${this.fallback.name}], { error }); ctx.metrics.counter(strategy_fallback_total, { from: this.primary.name, to: this.fallback.name }).inc(); // 这里可以加入一些延迟避免立即重试可能存在的瞬时故障 // await new Promise(resolve setTimeout(resolve, 100)); return await this.fallback.execute(ctx, input); } // 如果不应该转移则直接抛出原错误 throw error; } } }设计要点解析策略抽象将每一种执行路径如调用API-A、查询数据库从库、使用降级算法都封装成独立的ExecutionStrategy。这符合开闭原则新增策略无需修改核心逻辑。条件转移shouldFallback函数是关键。并非所有错误都值得转移。例如业务逻辑错误如参数校验失败转移多少次都没用。通常我们只对网络超时、连接拒绝、5xx服务器错误等“基础设施类”错误进行转移。可观测性在转移点打点日志和指标ctx.metrics这对于后期分析故障转移频率、评估备用策略健康度至关重要。2.2 多级故障转移与优先级队列简单的“主-备”模式有时不够用。我们可以设计一个优先级队列按顺序尝试多个策略。class PriorityFallbackStrategyT, R implements ExecutionStrategyT, R { private strategies: ExecutionStrategyT, R[]; constructor(strategies: ArrayExecutionStrategyT, R) { if (strategies.length 2) { throw new Error(PriorityFallbackStrategy 需要至少两个策略); } this.strategies strategies; } async execute(ctx: RunContext, input: T): PromiseR { let lastError: any; for (let i 0; i this.strategies.length; i) { const strategy this.strategies[i]; ctx.logger.info(尝试第 ${i 1} 优先级策略: [${strategy.name}]); try { const result await strategy.execute(ctx, input); if (i 0) { ctx.logger.info(故障转移成功最终由 [${strategy.name}] 完成); ctx.metrics.counter(fallback_success, { level: i }).inc(); } return result; } catch (error) { lastError error; ctx.logger.warn(策略 [${strategy.name}] 执行失败, { error }); // 判断是否继续尝试下一个策略 if (!this.shouldContinue(error, ctx, i)) { break; } // 可选在尝试下一个策略前等待片刻 if (i this.strategies.length - 1) { await this.delayBeforeNextAttempt(ctx, i); } } } ctx.logger.error(所有 ${this.strategies.length} 个策略均执行失败); throw lastError; // 抛出最后一个错误 } private shouldContinue(error: any, ctx: RunContext, attemptIndex: number): boolean { // 示例4xx错误不继续5xx或网络错误继续 if (error.statusCode error.statusCode 400 error.statusCode 500) { return false; } return true; } private async delayBeforeNextAttempt(ctx: RunContext, attemptIndex: number): Promisevoid { // 简单的指数退避但注意这里不是重试是切换策略延迟可以较短或为0 const delayMs Math.min(100 * Math.pow(1.5, attemptIndex), 1000); await new Promise(resolve setTimeout(resolve, delayMs)); } }实战场景一个用户信息查询优先级可以是1. 查询本地缓存 - 2. 查询主数据库 - 3. 查询从数据库 - 4. 返回静态兜底数据。每一级失败后自动降级到下一级。注意故障转移不是银弹。它增加了系统的复杂性并可能带来数据一致性问题如写操作转移到只读备库。务必明确区分只读操作和写操作。对于写操作故障转移需极度谨慎通常需要配合分布式事务或最终一致性方案。3. 重试策略赋予任务“自我愈合”的能力如果说故障转移是“空间”上的冗余换一个地方执行那么重试就是“时间”上的冗余过一会儿再试。合理的重试能有效应对瞬时故障如网络抖动、服务瞬间高负载。3.1 重试策略的核心要素一个完整的重试策略需要定义以下几个要素重试条件什么错误需要重试什么错误不该重试重试间隔每次重试等待多久固定间隔指数退避停止条件最多重试几次总耗时不超过多少结果判定重试成功后如何返回结果需要处理幂等性吗我们首先定义一个RetryPolicy接口interface RetryPolicy { // 最大重试次数不包含首次尝试 maxAttempts: number; // 判断此次错误是否应该重试 shouldRetry(error: any, attemptNumber: number): boolean; // 计算下一次重试的延迟毫秒 getDelayMs(attemptNumber: number): number; // 重试前的回调可用于记录日志、发送通知等 onRetry?(error: any, attemptNumber: number, delayMs: number): void; }3.2 实现指数退避与抖动Jitter策略指数退避是避免重试风暴、减轻服务压力的标准做法。但单纯的指数退避可能导致多个客户端同时重试产生“同步波”。加入随机抖动可以打散这个同步。class ExponentialBackoffWithJitter implements RetryPolicy { constructor( public maxAttempts: number, private initialDelayMs: number 100, private maxDelayMs: number 10000, private factor: number 2, private jitterFactor: number 0.1 // 抖动因子0-1之间 ) {} shouldRetry(error: any): boolean { // 只对可重试错误进行重试 const retriableErrors [ETIMEDOUT, ECONNRESET, ESOCKETTIMEDOUT, ECONNREFUSED, 502, 503, 504]; const isNetworkError retriableErrors.some(e error.code e || error.statusCode e); return isNetworkError; } getDelayMs(attemptNumber: number): number { // 计算指数延迟 const exponentialDelay Math.min( this.initialDelayMs * Math.pow(this.factor, attemptNumber - 1), this.maxDelayMs ); // 计算抖动范围 const jitterRange exponentialDelay * this.jitterFactor; // 在 [exponentialDelay - jitterRange, exponentialDelay jitterRange] 范围内随机 const jitter (Math.random() * 2 - 1) * jitterRange; const delayWithJitter exponentialDelay jitter; // 确保延迟不为负数且不超过最大延迟 return Math.max(0, Math.min(delayWithJitter, this.maxDelayMs)); } onRetry(error: any, attemptNumber: number, delayMs: number): void { console.log(第 ${attemptNumber} 次重试将在 ${delayMs}ms 后执行原因: ${error.message}); } }参数选择经验initialDelayMs首次重试延迟。对于与用户交互的后端服务建议从100-500ms开始避免给下游服务造成即时压力。maxDelayMs最大延迟。设置一个上限如10秒防止因长时间故障导致的重试间隔无限增长。jitterFactor抖动因子。0.110%是一个不错的起点能在打散同步和保持退避效果间取得平衡。3.3 将重试策略集成到 run 函数现在我们将重试能力编织到run函数的执行逻辑中。async function runWithRetryT, R( task: (ctx: RunContext) PromiseR, context: RunContext, retryPolicy: RetryPolicy ): PromiseR { let lastError: any; for (let attempt 1; attempt retryPolicy.maxAttempts 1; attempt) { const isRetry attempt 1; if (isRetry) { const delayMs retryPolicy.getDelayMs(attempt - 1); context.logger.warn(任务开始第 ${attempt - 1} 次重试等待 ${delayMs}ms, { attempt }); retryPolicy.onRetry?.(lastError, attempt - 1, delayMs); await new Promise(resolve setTimeout(resolve, delayMs)); } try { const result await task(context); if (isRetry) { context.logger.info(任务在第 ${attempt} 次尝试第 ${attempt - 1} 次重试后成功); context.metrics.counter(task_retry_success_total).inc(); } return result; } catch (error) { lastError error; // 检查是否达到最大尝试次数 const isLastAttempt attempt retryPolicy.maxAttempts 1; // 检查错误是否可重试 const shouldRetry retryPolicy.shouldRetry(error, attempt - 1) !isLastAttempt; if (!shouldRetry) { context.logger.error(任务失败且不可重试或已达最大重试次数, { attempt, error }); throw error; // 抛出最终错误 } context.logger.warn(任务执行失败准备重试, { attempt, error }); context.metrics.counter(task_retry_attempt_total).inc(); } } // 理论上不会走到这里因为循环内会抛出错误 throw lastError!; }集成到主run函数你可以在创建RunContext时传入RetryPolicy然后在执行核心任务task时使用runWithRetry来包裹它。这样生命周期钩子如onStart,onComplete仍然只在首次执行和最终成功/失败时触发而重试过程对它们来说是透明的内部细节。避坑指南重试的幂等性。这是重试策略设计中最大的坑。如果你的任务不是幂等的例如创建订单、扣减库存盲目重试会导致重复操作。解决方案有1. 服务端设计幂等接口通过唯一业务ID2. 客户端在重试前检查上一次操作的状态3. 将重试策略仅用于安全的只读操作。在run.ts中可以通过上下文ctx传递一个唯一的idempotencyKey并在任务逻辑中利用它。4. 结果封装从混乱的异常到结构化的输出经过故障转移和重试的“洗礼”一个任务最终会有一个明确的结果成功或失败。但直接返回原始结果或抛出原始错误对调用方并不友好。我们需要一个标准化的、富含元数据的输出结构。4.1 定义统一的 Result 类型目标是让每次run的调用都返回一个ResultT对象包含成功的数据或失败的详细信息以及执行过程的元数据。// 定义结果状态枚举 enum ResultStatus { Success SUCCESS, Failure FAILURE, // 可选部分成功、已取消等 } // 统一的错误类型 interface AppError { code: string; // 业务错误码如 NETWORK_TIMEOUT, VALIDATION_ERROR message: string; details?: any; // 原始错误对象或额外信息 isRetriable: boolean; // 是否可重试 } // 核心结果封装 interface ResultT any { status: ResultStatus; // 成功时有数据 data?: T; // 失败时有错误 error?: AppError; // 执行元数据 metadata: { durationMs: number; // 执行总耗时 attemptCount: number; // 总尝试次数1 重试次数 strategyUsed?: string; // 最终使用的策略名称故障转移场景 timestamp: number; // 完成时间戳 contextId: string; // 关联的上下文ID便于追踪 }; // 工具方法 isSuccess(): boolean; isFailure(): boolean; getOrThrow(): T; getOrElse(defaultValue: T): T; }4.2 实现 Result 类及其构建器为了让使用更流畅我们实现一个类并提供静态工厂方法。class ResultImplT implements ResultT { public metadata: Result[metadata]; private constructor( public readonly status: ResultStatus, public readonly data?: T, public readonly error?: AppError, metadata?: PartialResult[metadata] ) { this.metadata { durationMs: 0, attemptCount: 1, timestamp: Date.now(), contextId: , ...metadata, }; } static successT(data: T, metadata?: PartialResult[metadata]): ResultT { return new ResultImpl(ResultStatus.Success, data, undefined, metadata); } static failureT(error: AppError, metadata?: PartialResult[metadata]): ResultT { return new ResultImpl(ResultStatus.Failure, undefined, error, metadata); } static fromPromiseT(promise: PromiseT, context: RunContext): PromiseResultT { const startTime Date.now(); return promise .then(data { const durationMs Date.now() - startTime; return ResultImpl.success(data, { durationMs, contextId: context.id }); }) .catch(err { const durationMs Date.now() - startTime; const appError this.normalizeError(err); return ResultImpl.failure(appError, { durationMs, contextId: context.id }); }); } private static normalizeError(rawError: any): AppError { // 将各种类型的错误标准化为 AppError let code UNKNOWN_ERROR; let message An unknown error occurred; let isRetriable false; if (rawError instanceof Error) { message rawError.message; // 根据错误类型或属性判断错误码和是否可重试 if (code in rawError) { const errCode (rawError as any).code; if ([ETIMEDOUT, ECONNREFUSED, ECONNRESET].includes(errCode)) { code NETWORK_ERROR; isRetriable true; } } if (rawError.name TimeoutError) { code TIMEOUT; isRetriable true; } } else if (typeof rawError object rawError ! null) { // 处理HTTP错误响应等 if (rawError.statusCode) { code HTTP_${rawError.statusCode}; message rawError.message || HTTP Error ${rawError.statusCode}; isRetriable rawError.statusCode 500; // 5xx错误通常可重试 } } // 可以在此处接入更复杂的错误分类逻辑 return { code, message, details: rawError, isRetriable }; } isSuccess(): boolean { return this.status ResultStatus.Success; } isFailure(): boolean { return this.status ResultStatus.Failure; } getOrThrow(): T { if (this.isFailure()) { throw new Error(Result is failure: ${this.error?.code} - ${this.error?.message}); } return this.data!; } getOrElse(defaultValue: T): T { return this.isSuccess() ? this.data! : defaultValue; } }4.3 在 run 函数中整合并输出 Result现在改造我们的run函数使其始终返回ResultT类型。async function runT( task: (ctx: RunContext) PromiseT, options: RunOptions {} ): PromiseResultT { const ctx createRunContext(options); const startTime Date.now(); let finalAttemptCount 1; let finalStrategyName: string | undefined; let finalError: AppError | undefined; let finalData: T | undefined; try { await ctx.hooks.onStart.trigger(ctx); // 组合策略先定义基础执行策略 const baseStrategy: ExecutionStrategyRunContext, T { name: base_task, execute: async (c) await task(c) }; // 应用故障转移策略如果配置了的话 let executionStrategy: ExecutionStrategyRunContext, T baseStrategy; if (options.fallbackStrategy) { executionStrategy new FallbackStrategy(baseStrategy, options.fallbackStrategy); } // 应用重试策略如果配置了的话 const taskWithPolicies async (c: RunContext) { if (options.retryPolicy) { return await runWithRetry(() executionStrategy.execute(c, c), c, options.retryPolicy); } else { return await executionStrategy.execute(c, c); } }; // 执行最终任务 finalData await taskWithPolicies(ctx); finalAttemptCount ctx.attemptCount || 1; // 假设我们在上下文中记录了尝试次数 finalStrategyName executionStrategy.name; await ctx.hooks.onComplete.trigger(ctx, finalData); const durationMs Date.now() - startTime; return ResultImpl.success(finalData, { durationMs, attemptCount: finalAttemptCount, strategyUsed: finalStrategyName, contextId: ctx.id, }); } catch (rawError) { finalError ResultImpl.normalizeError(rawError); const durationMs Date.now() - startTime; await ctx.hooks.onError.trigger(ctx, rawError); return ResultImpl.failure(finalError, { durationMs, attemptCount: finalAttemptCount, strategyUsed: finalStrategyName, contextId: ctx.id, }); } finally { await ctx.hooks.onFinally.trigger(ctx); } }调用方体验的提升现在调用run函数后你得到的是一个结构化的Result对象而不是一个可能在任何地方抛出的Promise。const result await run(async (ctx) { // 你的业务逻辑 return await fetchUserData(userId); }, { retryPolicy: new ExponentialBackoffWithJitter(3), fallbackStrategy: fallbackToCacheStrategy }); if (result.isSuccess()) { const userData result.data; console.log(请求成功耗时 ${result.metadata.durationMs}ms尝试了 ${result.metadata.attemptCount} 次); // 处理业务逻辑 } else { console.error(请求失败: ${result.error.code} - ${result.error.message}); if (result.error.isRetriable) { // 可以记录日志并可能触发更高级别的重试或告警 } // 优雅降级 const fallbackData result.getOrElse(defaultUserData); }这种模式将错误处理从try-catch的“控制流”中解放出来变成了对结果对象的“数据流”检查使代码更清晰更易于维护和组合。5. 高级模式熔断器与策略组合当我们将故障转移、重试和结果封装组合在一起时我们已经构建了一个相当健壮的执行引擎。但在高并发和依赖服务不稳定时还需要最后一块拼图熔断器。5.1 熔断器模式简介熔断器模式模仿电路保险丝。当对一个服务的失败调用达到一定阈值时熔断器“跳闸”后续调用会立即失败而不是继续尝试。经过一段时间后熔断器进入“半开”状态允许少量试探请求通过。如果试探成功熔断器“闭合”恢复正常如果失败则继续保持“打开”状态。5.2 实现一个简单的熔断器我们可以实现一个CircuitBreaker策略将其作为最外层的执行策略包裹其他策略。class CircuitBreakerStrategyT, R implements ExecutionStrategyT, R { private state: CLOSED | OPEN | HALF_OPEN CLOSED; private failureCount 0; private lastFailureTime: number | null null; private nextAttemptTime: number | null null; constructor( private readonly strategy: ExecutionStrategyT, R, private readonly failureThreshold: number 5, private readonly resetTimeoutMs: number 30000, private readonly halfOpenMaxAttempts: number 2 ) {} async execute(ctx: RunContext, input: T): PromiseR { // 检查熔断器状态 if (this.state OPEN) { if (Date.now() this.nextAttemptTime!) { ctx.logger.warn(熔断器处于 OPEN 状态请求被快速失败); throw new Error(CIRCUIT_BREAKER_OPEN); } else { // 超时进入半开状态 this.state HALF_OPEN; ctx.logger.info(熔断器超时进入 HALF_OPEN 状态); } } try { const result await this.strategy.execute(ctx, input); // 请求成功处理状态转移 if (this.state HALF_OPEN) { // 半开状态下成功重置熔断器 this.reset(); ctx.logger.info(半开状态试探成功熔断器重置为 CLOSED); } else if (this.state CLOSED) { // 闭合状态下成功重置失败计数可选也可以滑动窗口 this.failureCount 0; } return result; } catch (error) { // 请求失败 if (this.state CLOSED) { this.failureCount; if (this.failureCount this.failureThreshold) { // 达到阈值跳闸 this.trip(ctx); } } else if (this.state HALF_OPEN) { // 半开状态下失败再次跳闸 this.trip(ctx); } throw error; // 重新抛出错误 } } private trip(ctx: RunContext): void { this.state OPEN; this.lastFailureTime Date.now(); this.nextAttemptTime Date.now() this.resetTimeoutMs; ctx.logger.error(熔断器跳闸进入 OPEN 状态将在 ${new Date(this.nextAttemptTime).toISOString()} 后尝试恢复); ctx.metrics.counter(circuit_breaker_tripped_total).inc(); } private reset(): void { this.state CLOSED; this.failureCount 0; this.lastFailureTime null; this.nextAttemptTime null; } }5.3 策略的链式组合现在我们可以像搭积木一样组合这些策略形成一个强大的执行管道。执行的优先级通常是熔断器 - 重试 - 故障转移。// 构建一个完整的执行管道 function createResilientTaskT, R( primaryTask: (ctx: RunContext) PromiseR, fallbackTask?: (ctx: RunContext) PromiseR ): (ctx: RunContext) PromiseR { // 1. 定义基础策略 const baseStrategy: ExecutionStrategyRunContext, R { name: primary, execute: primaryTask }; let strategy: ExecutionStrategyRunContext, R baseStrategy; // 2. 包裹故障转移策略如果有 if (fallbackTask) { const fallbackStrategy: ExecutionStrategyRunContext, R { name: fallback, execute: fallbackTask }; strategy new FallbackStrategy(baseStrategy, fallbackStrategy); } // 3. 包裹重试策略这里重试策略需要以函数形式适配略过细节 // 4. 包裹熔断器策略 strategy new CircuitBreakerStrategy(strategy, 5, 30000); // 5. 返回最终的执行函数 return async (ctx: RunContext) { return await strategy.execute(ctx, ctx); }; } // 在 run 函数中使用 const resilientTask createResilientTask( async (ctx) { /* 主逻辑 */ }, async (ctx) { /* 降级逻辑 */ } ); const result await run(resilientTask, { /* 其他配置 */ });通过这种组合你的任务将具备1. 快速失败保护下游熔断器2. 自动恢复瞬时故障重试3. 主路失败自动切换故障转移4. 统一清晰的结果反馈结果封装。这构成了一个现代云原生应用处理外部依赖的韧性基础。6. 监控、测试与调试如此复杂的策略交织在一起没有良好的可观测性将是灾难。我们需要知道策略何时被触发、效果如何。6.1 关键指标埋点在RunContext的metrics对象中至少应记录以下指标strategy_fallback_total故障转移触发次数。task_retry_attempt_total重试总次数。task_retry_success_total通过重试最终成功的次数。circuit_breaker_tripped_total熔断器跳闸次数。task_duration_seconds任务执行耗时直方图。task_status_total任务最终状态成功/失败计数器。这些指标应打上丰富的标签如strategy_name、error_code、retry_attempt等以便在 Grafana 等看板上进行多维分析。6.2 策略的单元测试测试这些策略的重点是模拟各种失败场景。使用Jest或Sinon等工具可以方便地模拟超时、抛出特定错误。import sinon from sinon; describe(FallbackStrategy, () { it(应在主策略失败时执行备用策略, async () { const ctx createMockContext(); const primary sinon.stub().rejects(new Error(Primary failed)); const fallback sinon.stub().resolves(Fallback result); const strategy new FallbackStrategy( { name: primary, execute: primary }, { name: fallback, execute: fallback } ); const result await strategy.execute(ctx, {}); expect(primary.calledOnce).toBe(true); expect(fallback.calledOnce).toBe(true); expect(result).toBe(Fallback result); }); }); describe(ExponentialBackoffWithJitter, () { it(应对网络超时错误返回可重试, () { const policy new ExponentialBackoffWithJitter(3); const error new Error(Timeout); error.code ETIMEDOUT; expect(policy.shouldRetry(error)).toBe(true); }); it(应计算包含抖动的延迟, () { const policy new ExponentialBackoffWithJitter(3, 100, 10000, 2, 0.1); const delay policy.getDelayMs(2); // 第二次重试 // 期望值: 100 * 2^(1) 200ms, 抖动范围 ±20ms expect(delay).toBeGreaterThanOrEqual(180); expect(delay).toBeLessThanOrEqual(220); }); });6.3 集成测试与混沌工程在集成测试或 staging 环境中可以注入故障来验证整个韧性策略是否按预期工作。使用混沌工程工具如 Chaos Mesh或简单的代理来模拟网络延迟、丢包、服务不可用等观察系统的行为是否符合设计。例如你可以模拟依赖的API在连续5次请求后开始返回503错误然后验证前几次请求是否成功故障发生后重试策略是否生效重试多次失败后故障转移是否触发如果主备都失败熔断器是否会在一定次数后跳闸熔断器跳闸后新的请求是否被快速失败经过重置超时后半开状态的试探请求是否成功熔断器是否恢复闭合通过这样的测试你才能对系统的韧性有真正的信心。run.ts下篇所构建的正是让系统在复杂、不可靠的环境中依然能够保持核心功能可用的关键基础设施。它将“出错的可能性”从需要处处防范的负担转变为可以通过策略集中管理和优化的资源。当你将这些模式应用到你的异步任务、API调用、数据库操作中时你会发现系统的稳定性得到了质的提升而你也能在深夜睡得更加安稳一些。 
长河君 · 2026/8/16 22:14:18 · 阅读 1.2k 构建韧性系统：故障转移、重试策略与结果封装实践
1. 从一个真实的线上故障说起去年我们团队负责的一个核心服务在某个深夜突然出现大面积调用失败。监控告警瞬间刷屏但诡异的是后端依赖的数据库和缓存集群各项指标都显示正常。紧急排查后发现问题出在服务与一个第三方计费API的交互上。这个API的某个服务节点因为区域网络波动响应变得极其缓慢且不稳定导致我们服务的大量线程被阻塞在等待响应上最终线程池耗尽服务雪崩。我们紧急切走了流量但损失已经造成。事后复盘我们意识到一个致命问题我们的HTTP客户端虽然配置了超时和简单的重试但缺乏一套智能的、可编排的故障转移与重试策略。所有的请求都傻傻地撞向同一个可能已经“半死不活”的服务端点直到超时。这个惨痛教训直接催生了我们对run.ts这个核心执行单元的升级思考。上篇我们构建了基础的执行器、上下文和生命周期钩子解决了“如何规范地执行一个任务”。但一个健壮的生产级系统不仅要能“执行”更要能“优雅地失败并成功恢复”。这就是本篇要深入探讨的故障转移、重试策略与结果封装。我们将不再把run函数看作一个简单的调用而是将其视为一个具备韧性、可观测性的分布式事务单元。通过本篇你将学会如何为你的异步任务注入“不死”的特性以及如何将纷乱的执行结果标准化让调用方处理起来得心应手。2. 故障转移从单点依赖到韧性架构故障转移的核心思想是“不要把所有鸡蛋放在一个篮子里”。在分布式调用中这意味着当首选方案如特定的API端点、数据库主节点、算法策略A失败时系统应能自动、无缝地切换到备用方案而不是直接宣告失败。2.1 故障转移的策略模式设计在run.ts的上下文中故障转移不再局限于网络层面它可以应用于任何可能失败的“执行策略”。我们抽象出一个FallbackStrategy接口。// 定义策略接口 interface ExecutionStrategyT, R { name: string; execute(ctx: RunContext, input: T): PromiseR; } // 故障转移策略实现 class FallbackStrategyT, R implements ExecutionStrategyT, R { constructor( private readonly primary: ExecutionStrategyT, R, private readonly fallback: ExecutionStrategyT, R, private readonly shouldFallback: (error: any, ctx: RunContext) boolean () true ) {} async execute(ctx: RunContext, input: T): PromiseR { ctx.logger.info([${this.primary.name}] 开始执行主策略); try { const result await this.primary.execute(ctx, input); ctx.logger.info([${this.primary.name}] 主策略执行成功); return result; } catch (error) { // 判断是否应该触发故障转移 if (this.shouldFallback(error, ctx)) { ctx.logger.warn([${this.primary.name}] 执行失败触发故障转移至 [${this.fallback.name}], { error }); ctx.metrics.counter(strategy_fallback_total, { from: this.primary.name, to: this.fallback.name }).inc(); // 这里可以加入一些延迟避免立即重试可能存在的瞬时故障 // await new Promise(resolve setTimeout(resolve, 100)); return await this.fallback.execute(ctx, input); } // 如果不应该转移则直接抛出原错误 throw error; } } }设计要点解析策略抽象将每一种执行路径如调用API-A、查询数据库从库、使用降级算法都封装成独立的ExecutionStrategy。这符合开闭原则新增策略无需修改核心逻辑。条件转移shouldFallback函数是关键。并非所有错误都值得转移。例如业务逻辑错误如参数校验失败转移多少次都没用。通常我们只对网络超时、连接拒绝、5xx服务器错误等“基础设施类”错误进行转移。可观测性在转移点打点日志和指标ctx.metrics这对于后期分析故障转移频率、评估备用策略健康度至关重要。2.2 多级故障转移与优先级队列简单的“主-备”模式有时不够用。我们可以设计一个优先级队列按顺序尝试多个策略。class PriorityFallbackStrategyT, R implements ExecutionStrategyT, R { private strategies: ExecutionStrategyT, R[]; constructor(strategies: ArrayExecutionStrategyT, R) { if (strategies.length 2) { throw new Error(PriorityFallbackStrategy 需要至少两个策略); } this.strategies strategies; } async execute(ctx: RunContext, input: T): PromiseR { let lastError: any; for (let i 0; i this.strategies.length; i) { const strategy this.strategies[i]; ctx.logger.info(尝试第 ${i 1} 优先级策略: [${strategy.name}]); try { const result await strategy.execute(ctx, input); if (i 0) { ctx.logger.info(故障转移成功最终由 [${strategy.name}] 完成); ctx.metrics.counter(fallback_success, { level: i }).inc(); } return result; } catch (error) { lastError error; ctx.logger.warn(策略 [${strategy.name}] 执行失败, { error }); // 判断是否继续尝试下一个策略 if (!this.shouldContinue(error, ctx, i)) { break; } // 可选在尝试下一个策略前等待片刻 if (i this.strategies.length - 1) { await this.delayBeforeNextAttempt(ctx, i); } } } ctx.logger.error(所有 ${this.strategies.length} 个策略均执行失败); throw lastError; // 抛出最后一个错误 } private shouldContinue(error: any, ctx: RunContext, attemptIndex: number): boolean { // 示例4xx错误不继续5xx或网络错误继续 if (error.statusCode error.statusCode 400 error.statusCode 500) { return false; } return true; } private async delayBeforeNextAttempt(ctx: RunContext, attemptIndex: number): Promisevoid { // 简单的指数退避但注意这里不是重试是切换策略延迟可以较短或为0 const delayMs Math.min(100 * Math.pow(1.5, attemptIndex), 1000); await new Promise(resolve setTimeout(resolve, delayMs)); } }实战场景一个用户信息查询优先级可以是1. 查询本地缓存 - 2. 查询主数据库 - 3. 查询从数据库 - 4. 返回静态兜底数据。每一级失败后自动降级到下一级。注意故障转移不是银弹。它增加了系统的复杂性并可能带来数据一致性问题如写操作转移到只读备库。务必明确区分只读操作和写操作。对于写操作故障转移需极度谨慎通常需要配合分布式事务或最终一致性方案。3. 重试策略赋予任务“自我愈合”的能力如果说故障转移是“空间”上的冗余换一个地方执行那么重试就是“时间”上的冗余过一会儿再试。合理的重试能有效应对瞬时故障如网络抖动、服务瞬间高负载。3.1 重试策略的核心要素一个完整的重试策略需要定义以下几个要素重试条件什么错误需要重试什么错误不该重试重试间隔每次重试等待多久固定间隔指数退避停止条件最多重试几次总耗时不超过多少结果判定重试成功后如何返回结果需要处理幂等性吗我们首先定义一个RetryPolicy接口interface RetryPolicy { // 最大重试次数不包含首次尝试 maxAttempts: number; // 判断此次错误是否应该重试 shouldRetry(error: any, attemptNumber: number): boolean; // 计算下一次重试的延迟毫秒 getDelayMs(attemptNumber: number): number; // 重试前的回调可用于记录日志、发送通知等 onRetry?(error: any, attemptNumber: number, delayMs: number): void; }3.2 实现指数退避与抖动Jitter策略指数退避是避免重试风暴、减轻服务压力的标准做法。但单纯的指数退避可能导致多个客户端同时重试产生“同步波”。加入随机抖动可以打散这个同步。class ExponentialBackoffWithJitter implements RetryPolicy { constructor( public maxAttempts: number, private initialDelayMs: number 100, private maxDelayMs: number 10000, private factor: number 2, private jitterFactor: number 0.1 // 抖动因子0-1之间 ) {} shouldRetry(error: any): boolean { // 只对可重试错误进行重试 const retriableErrors [ETIMEDOUT, ECONNRESET, ESOCKETTIMEDOUT, ECONNREFUSED, 502, 503, 504]; const isNetworkError retriableErrors.some(e error.code e || error.statusCode e); return isNetworkError; } getDelayMs(attemptNumber: number): number { // 计算指数延迟 const exponentialDelay Math.min( this.initialDelayMs * Math.pow(this.factor, attemptNumber - 1), this.maxDelayMs ); // 计算抖动范围 const jitterRange exponentialDelay * this.jitterFactor; // 在 [exponentialDelay - jitterRange, exponentialDelay jitterRange] 范围内随机 const jitter (Math.random() * 2 - 1) * jitterRange; const delayWithJitter exponentialDelay jitter; // 确保延迟不为负数且不超过最大延迟 return Math.max(0, Math.min(delayWithJitter, this.maxDelayMs)); } onRetry(error: any, attemptNumber: number, delayMs: number): void { console.log(第 ${attemptNumber} 次重试将在 ${delayMs}ms 后执行原因: ${error.message}); } }参数选择经验initialDelayMs首次重试延迟。对于与用户交互的后端服务建议从100-500ms开始避免给下游服务造成即时压力。maxDelayMs最大延迟。设置一个上限如10秒防止因长时间故障导致的重试间隔无限增长。jitterFactor抖动因子。0.110%是一个不错的起点能在打散同步和保持退避效果间取得平衡。3.3 将重试策略集成到 run 函数现在我们将重试能力编织到run函数的执行逻辑中。async function runWithRetryT, R( task: (ctx: RunContext) PromiseR, context: RunContext, retryPolicy: RetryPolicy ): PromiseR { let lastError: any; for (let attempt 1; attempt retryPolicy.maxAttempts 1; attempt) { const isRetry attempt 1; if (isRetry) { const delayMs retryPolicy.getDelayMs(attempt - 1); context.logger.warn(任务开始第 ${attempt - 1} 次重试等待 ${delayMs}ms, { attempt }); retryPolicy.onRetry?.(lastError, attempt - 1, delayMs); await new Promise(resolve setTimeout(resolve, delayMs)); } try { const result await task(context); if (isRetry) { context.logger.info(任务在第 ${attempt} 次尝试第 ${attempt - 1} 次重试后成功); context.metrics.counter(task_retry_success_total).inc(); } return result; } catch (error) { lastError error; // 检查是否达到最大尝试次数 const isLastAttempt attempt retryPolicy.maxAttempts 1; // 检查错误是否可重试 const shouldRetry retryPolicy.shouldRetry(error, attempt - 1) !isLastAttempt; if (!shouldRetry) { context.logger.error(任务失败且不可重试或已达最大重试次数, { attempt, error }); throw error; // 抛出最终错误 } context.logger.warn(任务执行失败准备重试, { attempt, error }); context.metrics.counter(task_retry_attempt_total).inc(); } } // 理论上不会走到这里因为循环内会抛出错误 throw lastError!; }集成到主run函数你可以在创建RunContext时传入RetryPolicy然后在执行核心任务task时使用runWithRetry来包裹它。这样生命周期钩子如onStart,onComplete仍然只在首次执行和最终成功/失败时触发而重试过程对它们来说是透明的内部细节。避坑指南重试的幂等性。这是重试策略设计中最大的坑。如果你的任务不是幂等的例如创建订单、扣减库存盲目重试会导致重复操作。解决方案有1. 服务端设计幂等接口通过唯一业务ID2. 客户端在重试前检查上一次操作的状态3. 将重试策略仅用于安全的只读操作。在run.ts中可以通过上下文ctx传递一个唯一的idempotencyKey并在任务逻辑中利用它。4. 结果封装从混乱的异常到结构化的输出经过故障转移和重试的“洗礼”一个任务最终会有一个明确的结果成功或失败。但直接返回原始结果或抛出原始错误对调用方并不友好。我们需要一个标准化的、富含元数据的输出结构。4.1 定义统一的 Result 类型目标是让每次run的调用都返回一个ResultT对象包含成功的数据或失败的详细信息以及执行过程的元数据。// 定义结果状态枚举 enum ResultStatus { Success SUCCESS, Failure FAILURE, // 可选部分成功、已取消等 } // 统一的错误类型 interface AppError { code: string; // 业务错误码如 NETWORK_TIMEOUT, VALIDATION_ERROR message: string; details?: any; // 原始错误对象或额外信息 isRetriable: boolean; // 是否可重试 } // 核心结果封装 interface ResultT any { status: ResultStatus; // 成功时有数据 data?: T; // 失败时有错误 error?: AppError; // 执行元数据 metadata: { durationMs: number; // 执行总耗时 attemptCount: number; // 总尝试次数1 重试次数 strategyUsed?: string; // 最终使用的策略名称故障转移场景 timestamp: number; // 完成时间戳 contextId: string; // 关联的上下文ID便于追踪 }; // 工具方法 isSuccess(): boolean; isFailure(): boolean; getOrThrow(): T; getOrElse(defaultValue: T): T; }4.2 实现 Result 类及其构建器为了让使用更流畅我们实现一个类并提供静态工厂方法。class ResultImplT implements ResultT { public metadata: Result[metadata]; private constructor( public readonly status: ResultStatus, public readonly data?: T, public readonly error?: AppError, metadata?: PartialResult[metadata] ) { this.metadata { durationMs: 0, attemptCount: 1, timestamp: Date.now(), contextId: , ...metadata, }; } static successT(data: T, metadata?: PartialResult[metadata]): ResultT { return new ResultImpl(ResultStatus.Success, data, undefined, metadata); } static failureT(error: AppError, metadata?: PartialResult[metadata]): ResultT { return new ResultImpl(ResultStatus.Failure, undefined, error, metadata); } static fromPromiseT(promise: PromiseT, context: RunContext): PromiseResultT { const startTime Date.now(); return promise .then(data { const durationMs Date.now() - startTime; return ResultImpl.success(data, { durationMs, contextId: context.id }); }) .catch(err { const durationMs Date.now() - startTime; const appError this.normalizeError(err); return ResultImpl.failure(appError, { durationMs, contextId: context.id }); }); } private static normalizeError(rawError: any): AppError { // 将各种类型的错误标准化为 AppError let code UNKNOWN_ERROR; let message An unknown error occurred; let isRetriable false; if (rawError instanceof Error) { message rawError.message; // 根据错误类型或属性判断错误码和是否可重试 if (code in rawError) { const errCode (rawError as any).code; if ([ETIMEDOUT, ECONNREFUSED, ECONNRESET].includes(errCode)) { code NETWORK_ERROR; isRetriable true; } } if (rawError.name TimeoutError) { code TIMEOUT; isRetriable true; } } else if (typeof rawError object rawError ! null) { // 处理HTTP错误响应等 if (rawError.statusCode) { code HTTP_${rawError.statusCode}; message rawError.message || HTTP Error ${rawError.statusCode}; isRetriable rawError.statusCode 500; // 5xx错误通常可重试 } } // 可以在此处接入更复杂的错误分类逻辑 return { code, message, details: rawError, isRetriable }; } isSuccess(): boolean { return this.status ResultStatus.Success; } isFailure(): boolean { return this.status ResultStatus.Failure; } getOrThrow(): T { if (this.isFailure()) { throw new Error(Result is failure: ${this.error?.code} - ${this.error?.message}); } return this.data!; } getOrElse(defaultValue: T): T { return this.isSuccess() ? this.data! : defaultValue; } }4.3 在 run 函数中整合并输出 Result现在改造我们的run函数使其始终返回ResultT类型。async function runT( task: (ctx: RunContext) PromiseT, options: RunOptions {} ): PromiseResultT { const ctx createRunContext(options); const startTime Date.now(); let finalAttemptCount 1; let finalStrategyName: string | undefined; let finalError: AppError | undefined; let finalData: T | undefined; try { await ctx.hooks.onStart.trigger(ctx); // 组合策略先定义基础执行策略 const baseStrategy: ExecutionStrategyRunContext, T { name: base_task, execute: async (c) await task(c) }; // 应用故障转移策略如果配置了的话 let executionStrategy: ExecutionStrategyRunContext, T baseStrategy; if (options.fallbackStrategy) { executionStrategy new FallbackStrategy(baseStrategy, options.fallbackStrategy); } // 应用重试策略如果配置了的话 const taskWithPolicies async (c: RunContext) { if (options.retryPolicy) { return await runWithRetry(() executionStrategy.execute(c, c), c, options.retryPolicy); } else { return await executionStrategy.execute(c, c); } }; // 执行最终任务 finalData await taskWithPolicies(ctx); finalAttemptCount ctx.attemptCount || 1; // 假设我们在上下文中记录了尝试次数 finalStrategyName executionStrategy.name; await ctx.hooks.onComplete.trigger(ctx, finalData); const durationMs Date.now() - startTime; return ResultImpl.success(finalData, { durationMs, attemptCount: finalAttemptCount, strategyUsed: finalStrategyName, contextId: ctx.id, }); } catch (rawError) { finalError ResultImpl.normalizeError(rawError); const durationMs Date.now() - startTime; await ctx.hooks.onError.trigger(ctx, rawError); return ResultImpl.failure(finalError, { durationMs, attemptCount: finalAttemptCount, strategyUsed: finalStrategyName, contextId: ctx.id, }); } finally { await ctx.hooks.onFinally.trigger(ctx); } }调用方体验的提升现在调用run函数后你得到的是一个结构化的Result对象而不是一个可能在任何地方抛出的Promise。const result await run(async (ctx) { // 你的业务逻辑 return await fetchUserData(userId); }, { retryPolicy: new ExponentialBackoffWithJitter(3), fallbackStrategy: fallbackToCacheStrategy }); if (result.isSuccess()) { const userData result.data; console.log(请求成功耗时 ${result.metadata.durationMs}ms尝试了 ${result.metadata.attemptCount} 次); // 处理业务逻辑 } else { console.error(请求失败: ${result.error.code} - ${result.error.message}); if (result.error.isRetriable) { // 可以记录日志并可能触发更高级别的重试或告警 } // 优雅降级 const fallbackData result.getOrElse(defaultUserData); }这种模式将错误处理从try-catch的“控制流”中解放出来变成了对结果对象的“数据流”检查使代码更清晰更易于维护和组合。5. 高级模式熔断器与策略组合当我们将故障转移、重试和结果封装组合在一起时我们已经构建了一个相当健壮的执行引擎。但在高并发和依赖服务不稳定时还需要最后一块拼图熔断器。5.1 熔断器模式简介熔断器模式模仿电路保险丝。当对一个服务的失败调用达到一定阈值时熔断器“跳闸”后续调用会立即失败而不是继续尝试。经过一段时间后熔断器进入“半开”状态允许少量试探请求通过。如果试探成功熔断器“闭合”恢复正常如果失败则继续保持“打开”状态。5.2 实现一个简单的熔断器我们可以实现一个CircuitBreaker策略将其作为最外层的执行策略包裹其他策略。class CircuitBreakerStrategyT, R implements ExecutionStrategyT, R { private state: CLOSED | OPEN | HALF_OPEN CLOSED; private failureCount 0; private lastFailureTime: number | null null; private nextAttemptTime: number | null null; constructor( private readonly strategy: ExecutionStrategyT, R, private readonly failureThreshold: number 5, private readonly resetTimeoutMs: number 30000, private readonly halfOpenMaxAttempts: number 2 ) {} async execute(ctx: RunContext, input: T): PromiseR { // 检查熔断器状态 if (this.state OPEN) { if (Date.now() this.nextAttemptTime!) { ctx.logger.warn(熔断器处于 OPEN 状态请求被快速失败); throw new Error(CIRCUIT_BREAKER_OPEN); } else { // 超时进入半开状态 this.state HALF_OPEN; ctx.logger.info(熔断器超时进入 HALF_OPEN 状态); } } try { const result await this.strategy.execute(ctx, input); // 请求成功处理状态转移 if (this.state HALF_OPEN) { // 半开状态下成功重置熔断器 this.reset(); ctx.logger.info(半开状态试探成功熔断器重置为 CLOSED); } else if (this.state CLOSED) { // 闭合状态下成功重置失败计数可选也可以滑动窗口 this.failureCount 0; } return result; } catch (error) { // 请求失败 if (this.state CLOSED) { this.failureCount; if (this.failureCount this.failureThreshold) { // 达到阈值跳闸 this.trip(ctx); } } else if (this.state HALF_OPEN) { // 半开状态下失败再次跳闸 this.trip(ctx); } throw error; // 重新抛出错误 } } private trip(ctx: RunContext): void { this.state OPEN; this.lastFailureTime Date.now(); this.nextAttemptTime Date.now() this.resetTimeoutMs; ctx.logger.error(熔断器跳闸进入 OPEN 状态将在 ${new Date(this.nextAttemptTime).toISOString()} 后尝试恢复); ctx.metrics.counter(circuit_breaker_tripped_total).inc(); } private reset(): void { this.state CLOSED; this.failureCount 0; this.lastFailureTime null; this.nextAttemptTime null; } }5.3 策略的链式组合现在我们可以像搭积木一样组合这些策略形成一个强大的执行管道。执行的优先级通常是熔断器 - 重试 - 故障转移。// 构建一个完整的执行管道 function createResilientTaskT, R( primaryTask: (ctx: RunContext) PromiseR, fallbackTask?: (ctx: RunContext) PromiseR ): (ctx: RunContext) PromiseR { // 1. 定义基础策略 const baseStrategy: ExecutionStrategyRunContext, R { name: primary, execute: primaryTask }; let strategy: ExecutionStrategyRunContext, R baseStrategy; // 2. 包裹故障转移策略如果有 if (fallbackTask) { const fallbackStrategy: ExecutionStrategyRunContext, R { name: fallback, execute: fallbackTask }; strategy new FallbackStrategy(baseStrategy, fallbackStrategy); } // 3. 包裹重试策略这里重试策略需要以函数形式适配略过细节 // 4. 包裹熔断器策略 strategy new CircuitBreakerStrategy(strategy, 5, 30000); // 5. 返回最终的执行函数 return async (ctx: RunContext) { return await strategy.execute(ctx, ctx); }; } // 在 run 函数中使用 const resilientTask createResilientTask( async (ctx) { /* 主逻辑 */ }, async (ctx) { /* 降级逻辑 */ } ); const result await run(resilientTask, { /* 其他配置 */ });通过这种组合你的任务将具备1. 快速失败保护下游熔断器2. 自动恢复瞬时故障重试3. 主路失败自动切换故障转移4. 统一清晰的结果反馈结果封装。这构成了一个现代云原生应用处理外部依赖的韧性基础。6. 监控、测试与调试如此复杂的策略交织在一起没有良好的可观测性将是灾难。我们需要知道策略何时被触发、效果如何。6.1 关键指标埋点在RunContext的metrics对象中至少应记录以下指标strategy_fallback_total故障转移触发次数。task_retry_attempt_total重试总次数。task_retry_success_total通过重试最终成功的次数。circuit_breaker_tripped_total熔断器跳闸次数。task_duration_seconds任务执行耗时直方图。task_status_total任务最终状态成功/失败计数器。这些指标应打上丰富的标签如strategy_name、error_code、retry_attempt等以便在 Grafana 等看板上进行多维分析。6.2 策略的单元测试测试这些策略的重点是模拟各种失败场景。使用Jest或Sinon等工具可以方便地模拟超时、抛出特定错误。import sinon from sinon; describe(FallbackStrategy, () { it(应在主策略失败时执行备用策略, async () { const ctx createMockContext(); const primary sinon.stub().rejects(new Error(Primary failed)); const fallback sinon.stub().resolves(Fallback result); const strategy new FallbackStrategy( { name: primary, execute: primary }, { name: fallback, execute: fallback } ); const result await strategy.execute(ctx, {}); expect(primary.calledOnce).toBe(true); expect(fallback.calledOnce).toBe(true); expect(result).toBe(Fallback result); }); }); describe(ExponentialBackoffWithJitter, () { it(应对网络超时错误返回可重试, () { const policy new ExponentialBackoffWithJitter(3); const error new Error(Timeout); error.code ETIMEDOUT; expect(policy.shouldRetry(error)).toBe(true); }); it(应计算包含抖动的延迟, () { const policy new ExponentialBackoffWithJitter(3, 100, 10000, 2, 0.1); const delay policy.getDelayMs(2); // 第二次重试 // 期望值: 100 * 2^(1) 200ms, 抖动范围 ±20ms expect(delay).toBeGreaterThanOrEqual(180); expect(delay).toBeLessThanOrEqual(220); }); });6.3 集成测试与混沌工程在集成测试或 staging 环境中可以注入故障来验证整个韧性策略是否按预期工作。使用混沌工程工具如 Chaos Mesh或简单的代理来模拟网络延迟、丢包、服务不可用等观察系统的行为是否符合设计。例如你可以模拟依赖的API在连续5次请求后开始返回503错误然后验证前几次请求是否成功故障发生后重试策略是否生效重试多次失败后故障转移是否触发如果主备都失败熔断器是否会在一定次数后跳闸熔断器跳闸后新的请求是否被快速失败经过重置超时后半开状态的试探请求是否成功熔断器是否恢复闭合通过这样的测试你才能对系统的韧性有真正的信心。run.ts下篇所构建的正是让系统在复杂、不可靠的环境中依然能够保持核心功能可用的关键基础设施。它将“出错的可能性”从需要处处防范的负担转变为可以通过策略集中管理和优化的资源。当你将这些模式应用到你的异步任务、API调用、数据库操作中时你会发现系统的稳定性得到了质的提升而你也能在深夜睡得更加安稳一些。