链家网技术总监陈尔冬：链家网的第三种运维

我觉得这里面有两个问题：

• 第一个问题,如果你的超时时间设计得很短,首先这个延迟增大总是可能出现的,不可能认为自己的服务或者网络永远那么正常,异常可能会突然出现.这个我们先放在我的假定范围之内,一定会有可能出现异常.
• 另一个问题,出现异常的时候,如果你的超时时间设计的特别长,调用方就会被堵死.如果你的超时时间设计得特别短,后面就会把服务方压死.那怎么办?

4.3 解决问题的思路

在这个点我们团队从系统层面角度给了一个方案,我们现在的方式是这样：当我慢了之后,M 个服务器,N 个进程,你就是 M+N 全部调到服务方了.我有 M 台机器,有 N 个进程,最后还是M个服务器去调这个服务,我肯定还是有调用,可以让它去尝试,如果慢就不要再调了.

我们给的方案是这样,针对问题一,如果说我调用超时时间设得比较慢,在系统层检测到后端的延迟,在慢的时候快速失败,防止堵塞.

针对问题二,超时时间设得比较短,后面会被压死,实际上是给了后面资源一个负向的正反馈.我们把这个反馈隔离,不要让这个调用到后面去,后面是不是就不会压死了.

那么解决方案就出来了：我们把这个系统叫做 RASH.我们把 Rash 运行在每一个应用服务器上.

4.4 RASH分析

首先我们先写了一个动态链接库,把这个动态连接库配到了 LD_PRELOAD.这么做的目的是为了劫持所有调用.所有的网络调用会被劫持到 Socks4 代理上.

Socks4 使用协程模型,每个协程处理一个连接.它会监测后面资源端给我们响应的第一个应用包,第一个应用协议的响应包的延时是多大,如果很慢,我们就快速的反馈失败,如果很快就让它正常运作.

很快或者很慢,现在说起来很简单,到底怎么做呢?这里有个算法来处理这个问题.

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!