彻底搞懂Ribbon——IPing机制源码解析

IPing机制

我们废话不多说，直接看源码：

这里只有一个isAlive，它会传入一个Ribbon选出来的Server，看看是不是挂了。
我们看一下它的实现类：

可以看到它的实现类还是蛮多，我们就先看一下这个DummyPing：

这个直接返回true。。。那算了，就不要看它了，再看看其他的，我们就看一下PingUrl这个类吧：

这个类还是有点东西的。
这里小编就不debug走了，很多时候我们就是一个肉眼编译器，在很多互联网公司，代码提交链错综复杂，所以说很多时候项目比较忙的时候，代码交叉在一块，你都不知道是哪个分支提交的，这个时候我们就需要肉眼编译器，其实锻炼这种能力还是挺不错了，还能提升自己的工作效率，当然了这个是要建立在自信的基础上的哦。如果没有把握，建议还是debug。

那么今天小编就教大家一招，这种肉眼Debug的方式，来读一下代码。

先看第一行，定义了一个urlStr，如果isSecure为true，就是https否则为http：

然后我们来看，它用urlStr加上了server的Id，然后又拼上了一个pingAppendString，其实就是一串url，来ping一下这个机器是否是UP的状态。
再往下看：

这里它先构造了一个HttpClient，然后发送一个getRequest，如果返回的状态码是200则isAlive置为true，然后再往下看：

首先判断getExpectedContent()是否为空，而expectedContent是通过这个方法设置的：

所以这个expectedContent是一个期望值，当它不为空的时候，就会走下面的逻辑：

如果返回的content是空，那么即使status是200也会认为是挂掉的，如果不为空就会判断返回的content是否和期望值相等，如果相等就会认为服务器是UP状态，最后：

在finally里强制关闭了这个Request，最后返回了isAlive。
这样Ribbon就会知道你的这个服务器是可达的还是不可达的。

我们再来看一下IPing接口的下一个实现类 NIWSDiscoveryPing：

可以看到，这个类也是非常简单，我们一起读一下：
首先它会判断传入的server是否为空，接着再判断server的类型是不是DiscoveryEnabledServer
然后调用了getInstanceInfo获取当前实例的信息，如果instanceInfo不为空，它就会获取Status，最后再获取它的状态，看看是不是UP状态。

通过这段代码，我们可以看到它并没有对服务器发起一个真实的healthCheack，而是通过Eureka的服务发现机制，把这个Instance的Status获取到，最后通过这个Status判断是否为存活状态。

我们不难看出，其实这种方式相比于上一种，它有一定的延迟，服务的状态并不是最新的。那么就有可能造成你当前Instance是应DOWN的状态了，而Ribbon仍然获取的是UP状态。
不过也是没有关系的，即使你访问失败，我们还是有重试的功能，重试不行我们还有Timeout，Timeout还是不行，我们还有降级功能，降级完了还有熔断，一环套一环，直到你服服帖帖。这些内容我们后续探讨，这里就先点到为止。