关于系统超时设置，简单聊一聊

1.一种系统协作的契约精神

▪避免无限期等待：某个本地操作或某个外部访问需要等待一段时间，若超过约定时间，还没有完成，程序就需要停止等待并采取其他措施。合理的超时处理，可以提高程序自身的健壮性、可靠性和核心服务能力的响应速度。

▪契约无法外之地：模块间的调用不管是同步还是异步的，不管是C端还是B端请求，亦或是独立线程池周期性请求，都需要有契约，设置合理超时。法外之地即是隐患之处，“慢性病”放任蔓延，晚期就是急性重症。（例：A模块里有一个独立线程池每1分钟请求B获取必要数据，对B不设置超时，若B不可用，虽然一时半会不会影响A处理实时请求，但随着时间积累，阻塞越来越多，那问题就会蔓延到实时请求处理的主流程上，最终可能酿成事故）

▪零信任双重保证：安全责任重于泰山，科学生产不信“鬼话”。不管对方怎么承诺，自己都要设置合理超时，超时后设计好异常处理流程，有备才能无患。基于主观信任的设计，友谊的小船说翻就翻。

2.一种高效生产的利己保护

▪减少不必要的资源消耗：A调用已经超时失败返回了，若B调用C、D、E还在等待处理，那就是一种资源浪费，合理控制超时，及时失败，节省资源。

▪谨防被弱依赖拖入绝境：B调用C，若不设置超时，C出现故障5分钟，那5分钟的请求都会堵在B的程序里而无法自动释放，链接池和线程池耗尽，无法接受新请求，且会造成预案无法生效，这种情况只有重启B才能恢复服务，而一旦涉及到重启，那就是陷入绝境，故障恢复速度容易不可控。

3.一种事故处理的自动预案

▪高内聚，秒级全自动化：发生事故时，首要任务是止损，止损的第一手段是预案。而一个有效的预案常取决于及时性和自动化，在面对外部依赖性能异常时，设置合理超时，并做好超时后的异常处理或兜底设计，这样在事故发生的第一时间，程序就相当于自身启动了一个秒级生效且全自动化的预案进行快速止损，而无需外围低效的人工干预。

▪面向失败，零信任设计：失败无处不在，要面向失败设计程序架构，相信合作方的“鬼话”是高可用架构的大忌，向死而生或置之死地而后生，才能生得健壮，生得可用。

4.一种核心服务的体验保障：面向C端的系统，用户对访问体验要求很高，响应超过1秒，用户就可感受到系统卡顿，容易造成用户流失或影响转化，而一个请求在C端系统里一般会经过成十上百的模块，全链路上科学合理分配这1秒的耗时，是保障用户顺畅体验的关键所在。

5.一种性能优化的资源配额：严控配额，可促进性能优化。A调用B的超时是m，B调用C、D和E的单体超时底线不能>=m，同时要控制单体超时总和不能>=m*n，那给到C、D、E的超时大小就是对m*n的配额分配。给得太多，其性能优化动力则不足，超时不设置或设置过大，或滋生“巨婴”。

6.一种强弱依赖的正确理解：中枢模块一般会依赖几个十几个甚至上百个外部依赖，针对外部依赖的可用性，我们不能眉毛胡子一把抓，需要正确理解业务业务核心所需，区分强弱依赖，重保核心，针对弱依赖要设置更低的超时，避免其故障影响全局可用性，防止因小失大，掉入完美主义陷阱。

7.一种系统架构的设计约束：调用不同类型的基础中间件有不同的超时标准范围，如访问Redis等缓存类中间件，超时一般不超过100ms，如果超过100ms，则不适合使用Redis类的中间件做存储服务，或需要选择MYSQL类数据库，或者优化系统架构，确保Redis里数据可在100ms内返回。

8.一种尽力服务的现实主义

▪自由主义：不管不顾，我行我素，不知超时控制是何物。

▪理想主义：把世界想象得都很美好，没有灾难，认为超时控制多此一举。

▪浪漫主义：想到了可能发生的灾难，但没意识到会很痛苦，缺乏敬畏，超时随便设（未经现实毒打）。

▪完美主义：不切实际地追求100%服务，超时设置过大，想以一己之力拯救世界（也称英雄主义），拿不到100分，就拿0分。

▪现实主义：客观理性，善于学习理解，权衡利弊，设定合理契约并严格遵守，精益求精，尽可能服务，精致但不完美（先温饱，后小康，再富裕）。