关于balancer的建议

[1887656]

1、学习了源码，目前负载均衡的策略是random和leastping，leastping是使用http的get方法，考虑到一些服务器不允许提供http服务的场景，建议能支持类似tcping的方法，增强适用范围。
2、此外对检查各服务器delay的时机，是否可以使用单独的线程轮询更新，这样可以不影响每次实际通过代理的访问请求。

[wy580477]

没看过源码，但你说的都不对啊。

1. 不是向代理服务器发起http请求的，是向指定的URL发起http请求。适用范围比tcpping更广，因为tcping有应答不代表代理服务正常。
2. 目前探测服务器连接性是由观测组件的probeInterval设置项指定探测间隔的，定时顺序探测。因为不能并发探测，有更新缓慢的问题，隔壁v5有burstObservatory，可以并发探测。

[1887656]

假定场景：(client c) -> (proxy a) -> ( b1-b3) -> (website w)，a有多个outbound b1,b2,b3，在a上配balancer，选择响应最快的b，leastping计算的delay是指a到b的时延，还是指a通过b访问w的时延呢？我理解是a到b，不知道是否正确。

[wy580477]

假定场景：(client c) -> (proxy a) -> ( b1-b3) -> (website w)，a有多个outbound b1,b2,b3，在a上配balancer，选择响应最快的b，leastping计算的delay是指a到b的时延，还是指a通过b访问w的时延呢？我理解是a到b，不知道是否正确。

观测组件里面有probeURL项指定探测连接，探测的是client经过观测组件subjectSelector项选择的客户端outbounds访问probeURL的用时。至于服务端outbounds，是无法从客户端选择的。

[1887656]

那么探测的是c->w的用时，还是a->w的用时？

[wy580477]

那么探测的是c->w的用时，还是a->w的用时？

都说了是从client发起http请求，你在c上配置负载均衡，测的就是从c到probeURL的用时。在a上配置负载均衡，测的就是从a到probeURL的用时。

[1887656]

嗯，谢谢解惑。如果这样的话，probeurl设置为http://www.google.com/generate_204就没问题了，能够真实的反映各个outbound的访问时延。定时并发探测只能等fly v5出来以后再修改了吧。