推荐阅读：
微服务是⼀种分布式架构，系统内各部分（服务）被部署为单独的应用程序，并通过某种远程访问协议进⾏通讯。分布式应⽤的挑战之⼀就是如何管理远程服务的可用性和它们的响应。本⽂主要探讨服务的响应时间对系统的影响和应对。
上图是简化的微服务调用链路过程，为清晰阐述三个相关方，图中的客户端被限定为用户端（如移动端应用、浏览器页面等），服务端被区分为服务消费方（网络调用中客户端）和服务提供方（网络调用中服务端）。⼤部分服务既为服务消费方，⼜为服务提供方，如处于调⽤链路中间的业务服务，大概率需要去整合数据，所以通常会同时作为服务消费方和服务提供方，两种资源消耗并存。小部分服务是纯粹的服务提供方，如数据库、缓存、ZooKeeper 等。下⽂先来分析服务响应时间过⻓对资源消耗问题。
1、资源消耗分析 静态分析
微服务都有⾃身的硬件资源上限，直观来看，响应时间会对资源消耗产⽣直接影响。
服务消费方
协议消耗，每次发起 TCP 连接请求时，通常会让系统选取⼀个空闲的本地端⼝（local port），该端⼝是独占的，不能和其他 TCP 连接共享。TCP 端⼝的数据类型是 unsigned short，因此可⽤端⼝最多只有 65535，所以在全部作为 client 端的情况下，最⼤TCP 连接数 65535。
除端⼝消耗外，发起调⽤的业务进程、线程、协程等待过程中，⽆法释放其所消耗的内存、CPU 等，是服务消费⽅发起调⽤的主要消耗。
服务提供方
协议消耗，主要是建⽴连接的消耗，每接收每⼀个 tcp 连接都要占⼀个⽂件描述符，理论上是 server 端单机最⼤tcp 连接数约为 2 的 48 次⽅。
业务逻辑消耗。在复杂的业务逻辑、机器资源和⽹络带宽条件下，最⼤并发 tcp 连接数远不能达到理论上限，有时候会发现，单机 1w 并发往往也是⽐较困难。因此，服务提供⽅主要是业务逻辑的⼤量资源消耗，如 CPU、⽹络带宽、磁盘 IO 等。
动态分析
在调⽤持续发⽣且服务提供⽅不及时返回的情况下，未触发性能拐点前，可以简化认为资源的消耗是线性增⻓。微服务发起⼀个请求，会占⽤⼀个空闲的本地端⼝，当然，每个连接所对应的业务处理过程，也会对应消耗内存、IO、CPU 消耗等资源，
简化为如下公式：
RR = RT - QPS * RCPR * Duration- Release * Tinny_T
其中，资源容量（rt, Resource Total ）受单机性能影响，可以简化为固定值；单请求消耗资源数（rcpr , ResourceCostPerRequest）受业务影响，也可以简化为固定值。
那么，资源剩余数（RR, Resource Remaining），将受这三个变量影响：每秒请求数（QPS）、请求持续时间 （Duration ）和资源释放的速度（ Release *Tinny_T）。
在连接不释放的情境下，Release 简化为 0，则上⾯公式简化为：
RR = RT - QPS * RCPR * Duration
可以看到，系统所剩余资源，随 Duration 线性减少，最终被耗尽。
这⾥额外讨论下池化技术，池化技术是⼀个⾮常重要的技术，如连接池可以避免 重新创建连接，在提⾼效率的同时也限制资源不受控的消耗。Redis、数据库 （Mysql、Mongo）等中间件连接驱动⼤都采⽤连接池。如 Golang Mysql 连接池设置 如下：
db.SetConnMaxLifetime(time.Minute * 3)
虽然有池化技术，但是如果连接未得到及时释放，且连接池未设置最⼤连接数的情况 下，⽤户不断的请求仍会导致不断创建新连接，急剧消耗资源。限定最⼤连接数最⼤连接数的情况下，造成连接池拒绝连接，或进⾏排队等待，虽然会避免系统宕机风险，但也造成业务⽆法使⽤。对于对外提供实时服务的系统来讲，池化的队列上限， 也可以看作是资源对外提供服务的上限。
设置超时
在设定超时时间后。由于资源释放速度较快，可以假设为⼀旦主动关闭连接，资源⽴即释放。那么，系统内所保留的资源可以简化为设置超时时间（TV，Timeout Value）时间段内连接所保持的资源：
RR = RT - QPS * RCPR * TV
对参数进⾏归⼀简化：
rr = 1 - k * qps * tv
示意图如下：
从图中可以看到，在资源总量、QPS 固定、且发⽣超时的情况下，超时时间和资源消耗的速度和成近似线性正⽐。所以从尽快释放消耗资源的⻆度来看，超时时间的设置 应当和 QPS 成反⽐，QPS 越⾼，超时时间应当越短。
2、超时时间设置治理
从资源静态和动态分析看，我们应当规范设置调⽤超时时间。设置超时时间的意义， 是在极端情况下，采⽤主动的快速失败策略，使得资源消耗与释放资源之间达到平衡，避免调⽤双⽅因资源耗尽⽽宕机。超时时间设置不当引发，容易引发⽣产故障， 线上已经有诸多血的教训。
设置过长
超时时间过⻓容易引起降级失效、系统崩溃、连接池爆满等问题。如下图，内容服务是⾯向⽤户直接提供知识内容的核⼼服务。收藏服务返回⽤户对内容的是否收藏，属于低优先级服务。如果内容服务请求收藏服务设置超时时间过⻓，如图中，虽然设置 1S 超时，但是重试累计 3S，则⼀旦收藏服务发⽣宕机（通常是由于上游 QPS 异常导致），则内容服务会失效，⽆法返回给⽤户数据，甚⾄发⽣串联雪崩。
设置过短
超时时间设置过短，实际⽣产中容易因⽹络抖动⽽告警频繁，造成服务不稳定等⽤户体验问题。如内容服务调⽤资源服务超时时间设置 200ms，资源服务调⽤ID 发号器服务超时时间设置为 300ms，⼀旦⽹络抖动后，资源服务 200ms 即超时返回，资源服务对下游的调⽤ 300ms 超时也⽆实际意义。
合理设定
合理设置超时时间，对系统的稳定来⾔，非常重要，我们可以从以下⻆度来考虑设置值：
用户角度。微服务最终为服务对象是⽤户，从⽤户交互数据来讲，服务响应时间在 300ms 内最佳， 2000ms 内仍可接受。通常情况下，建议超时的上限值为 2000ms，超过 2000ms 的非重要请求，则有必要被降级处理。
技术角度。同时考虑到 TCP 算法中 Delayed ACK + Nagle 算法开启的场景，最小 delay 值 40 ms，建议下限值设定为 50ms；在 RTT 较⼩的正常网络环境中，TCP 数据包丢包，超时重传的最⼩值，200 ms，因此我们建议 300ms 可以视为超时设置的最佳选择，为重传保留⼀定的余量。
资源消耗角度。依据资源消耗的分析，超时时间⻓短应当和 QPS 成反⽐例。我们设定基础值超时设定为 300ms、100QPS，并根据实际 QPS 做调整。
综合⽽⾔，我们简单的给出以下参考值，也可以根据自己的情况设定基准值后进⾏调整：
⾃动化设置
前⽂给出了合理设置超时时间的参考值，接下来，我们要考虑如何将超时时间的设置与业务解耦。超时时间的设置，和熔断、限流⼀样，是异常状况下系统的⼀种⾃我保护机制，熔断、限流都已经从业务解耦⾄框架层，如利⽤API ⽹关可以统⼀处理微服务之间调⽤的熔断、限流。超时时间的设置，也可以借助运维体系内其他框架，实现解耦并⾃动设定，如下图。
这⾥我们构建了超时治理系统，它⾃身包含三个模块：推荐设置模块，分析治理模块、UI 界⾯。并对外部依赖监控系统（Prometheus 等）、告警系统、配置中⼼（Consul、etcd）、及统⼀的⽹络调⽤框架（Http）。该系统还可以嵌⼊监控系统内 作为其内部功能来实现，或在响应时间监控的基础性进⾏改造。
下⽂对每个模块及依赖进⾏简述：
推荐设置模块
该模块，以响应监控系统的数据为输⼊，产出每⽇/ 周等固定周期内 P99.9（根据实际 情况来要求）的响应时间，除去异常偏离点，并添加⼀定的 Buffer，⾃动产出 API 调⽤超时时间的设置参考值。
⽇常中，线上正常的响应时间 P99.9 代表该系统稳定状态下的值，超出该值意味着系统出现异常。但必须明确指出，该推荐值可能并⾮理想状态下的超时设置值。
分析治理模块
由于服务响应时间可以粗略认为是对资源的消耗量成正⽐，分析治理模块依赖监控系 统产出的服务响应时间、流量峰值、以及对应的系统资源⽔位，对响应时间及超时时 间设置进⾏分析，输出最终的设置值后，通过配置中⼼下发⾄调⽤框架。
从简处理的话，可以基于上⽂推荐的 QPS 和 超时时间设定值，来进⾏预警提示偏离点。
更加精细化的处理，可以按接⼝的响应时间 * QPS 来均摊服务资源，对于明显超出均摊值的点，进⾏异常提示。
反馈上下游调⽤链路中，下游超时时间设置⾼于上游超时时间的异常点。
收集线上真实告警数据，并依据策略对持续发⽣的超时问题进⾏汇总反 馈。如产⽣超时异常周报等。
UI 界面
通过管理 UI 界⾯，以微服务为单位，对其调⽤情况，展示分析治理模块异常点，以及告警问题汇总。赋予使⽤者进⾏⼈⼯调整超时时间⼊⼝，并以⼈⼯设置为⾼优先级。
配置中心
超时时间设置的下发通常有配置中⼼来实现，配置中⼼有⾃身的⾼可⽤和⼀致性保障，同时有 Watch 机制来确保及时下发配置⾄调⽤框架使⽤。
调用框架
⽹络调⽤框架，接受从配置中⼼下发的配置并实现指定的⾏为，与超时设置⾏为相关的配置有三类，降级、阻塞、设置超时时间。
降级，即降级开关，开关下发后，对依赖服务直接进⾏降级，不再进⾏调⽤，该状态在紧急状态或重⼤活动时候使⽤。
阻塞开关，服务调⽤内部框架会按照设定超时时间进⾏阻塞，该能⼒⽤于寻找在当前超时时间设置下，系统性能瓶颈。通过压测，为重要服务线上超时时间设置提供最真实的数据。
超时配置，由超时治理系统所最终输出的超时配置，会由配置中⼼⾃动下发⾄各个服务，并在调⽤过程中使⽤。
另外，调⽤框架还应当实现，超时时间⾃动递减机制，如上游每次发起请求，到下游开始发起请求前，如果剩余可⽤时间已经为 0 ，则应当主动失败，参考下图。
3、告警和优化
超时时间设置是系统的第⼀重保护，超时时间设置后，需要配合超时告警和响应时间优化，才能形成构成的完整的系统⾃我修复的闭环。
告警
超时告警，会直接反馈超时设置的效果，⽽且也是⻓耗时请求被超时设置拦截后，系 统⾃我保护的下⼀个重要环节。系统调⽤发⽣超时告警，可以通过运维体系监控告警 让⼈⼒及时介⼊排查问题，以避免更⼤损失。
超时告警通常只是告警监控系统⾥⼀个⼦监控项，从实际⽣产中来看，超时告警 往往也是最频繁发⽣的告警，超时告警如何在保障灵敏度的同时，避免过渡告警，需 要专⻔考虑。对此，我们建议从范围和时间两个维度来区分超时告警：
从范围来看，可以将局部性超时和⼤⾯积超时告警区分对待：
大面积告警，紧急⼈⼒介⼊，通常是运维⽹络故障等原因，可以结合⽹络 监控来具体定位。
局部小范围告警，作为⾮紧急重要事情处理。
从时间来看，将波动性和持续性超时告警区分对待：
持续性问题，⼤概率是业务问题，紧急人力介入从而避免业务发⽣重⼤损失。
波动性问题，根据出现频率，排查隐藏线上问题并解决，作为⾮紧急重要事情处理。
对于如何定义短暂性的波动，可以由运维评估出⽇常⽹络抖动平均抖动时⻓ ，超过⽹ 络波动的时⻓⼀定阈值后，则触发紧急告警。如果运维体系资源充⾜，建议将超时告 警波动性监控细化到具体接⼝。
优化
响应时间优化是超时治理的治本措施。理想情况下，服务的响应时间当然是越快越 好，但也要和当前业务发展相匹配，要保障系统稳定，也要避免为优化响应时间耗费过多成本。
原则上，应当依据超时设置时间来优化响应时间，⽽⾮以响应时间来决定超时时 间。服务超时，可能是应⽤层代码错误、⽹络丢包，服务器⾃身硬件异常、或⼤量数 据库操作慢查询等问题导致。可以采⽤的措施有：
排查异常问题，如排查业务超时重试次数、排查错误⽇志、排查库表操作是否有慢查询等。
调整软件设计架构，提⾼业务响应速度，如使⽤缓存、拆分调整架构减少调⽤层级等。
调整运维⽅式，如发版引发的告警，则可以从调⽤框架的重试中进⾏解决，也可以依赖滚动发布进⾏解决。
纵向或横向扩充资源，提⾼单机性能，如 CPU、内存，以期望在性能拐点达到前获得消耗与释放平衡。横向在降低单机 QPS 的同时，适当增加超时时间。
4、总结
单体服务内部只有对库、Redis 等网络调用，相比之下，微服务系统内部发⽣的⽹络调用频度呈几何倍数增加。所以网络超时参数的设置治理，在微服务体系治理体系内也非常重要。
本⽂从动态和静态资源⻆度分析了超时设置对系统的影响，让我们从原理的⻆度 看到超时合理设置的必要性，它是避免系统在极端情况下发⽣串联性雪崩的有效措施。在以往开发过程中，对于这⼀重要的参数，通常是由各位开发⼈员凭自身经验来设置，由于开发者水平经验参差不齐，设置的超时时间也不⼀定合理。这会导致在系统在异常情况下容易处于串联雪崩的危险境地（如⼤型活动⾼流量⾼并发，个别⾮核 ⼼服务宕机，导致整个活动失败）。而通过自动化设置，将超时的设置解耦到框架层来解决，可以由开发经验差异导致的不合理设置，还可以实现⼀些特殊功能，如探究 服务在超时状态下极限性能。
超时时间设置完成后，超时的治理，核心还在于对系统或者架构的优化。我们再 次阐述下设置超时的原则，应当优化服务响应时间，来满⾜合理的超时设置时间，⽽非以响应时间来决定超时时间。
有疑问加站长微信联系（非本文作者）
