Ribbon架构剖析
在学习ribbon之前，先看一下这张图，这张图完美的把ribbon的基础架构给描述出来了
这张图的核心是负载均衡管理器，围绕着它的是外面的这5大功能点，咱们就从核心开始看然后再带出来其他的功能
首先看一下负载均衡器的核心接口iloadbalancer
public interface iloadbalancer {
public void addservers(list<server> newservers);
public server chooseserver(object key);
public void markserverdown(server server);
public list<server> getreachableservers();
public list<server> getallservers();
}
这个接口中保护了一个基本的负载均衡器所必须的所有功能：
-
addservers(list)向负载均衡器中添加服务实例 -
chooseserver(object)根据负载均衡策略，从负载均衡器中挑选出一个服务实例 -
markserverdown(server)下线负载均衡器中的某个具体实例 -
getreachableservers()返回当前可正常服务的实例列表 -
getallservers()返回所有的服务实例列表
接着来看一下这个接口的uml图
首先看abstractloadbalancer这个类，这个类是iloadbalancer接口的抽象类实现。
在这个抽象类中定义了一个表示服务实例状态的枚举的同时还新增了两个抽象方法：
public enum servergroup{
all,
status_up,
status_not_up
}
public abstract list<server> getserverlist(servergroup servergroup);
public abstract loadbalancerstats getloadbalancerstats();
-
getserverlist(servergroup):根据分组类型来返回不同的服务实例列表。 -
getloadbalancerstats():返回loadbalancerstatus对象，这个loadbalancerstats对象是用来存储负载均衡器中各个服务实例当前的属性和统计信息的
abstractloadbalancer共有两个实现类，右侧的nooploadbalancer是一个空的实现类，这里可以忽略不计。这里接着继续看baseloadbalancer
baseloadbalancer是负载均衡器的基础实现类，这个类对于接口iloadbalancer的所有方法都给予了基础的实现，除此之外还保护了很多重要的对象
两个存储当前服务实例对象的列表，一个是包含所有服务、一个是包含正常服务
@monitor(name = prefix + "allserverlist", type = datasourcetype.informational)
protected volatile list<server> allserverlist = collections
.synchronizedlist(new arraylist<server>());
@monitor(name = prefix + "upserverlist", type = datasourcetype.informational)
protected volatile list<server> upserverlist = collections
.synchronizedlist(new arraylist<server>());
存储负载系统器各服务实例属性和统计信息的对象
protected loadbalancerstats lbstats;
心跳检测对象
protected iping ping = null;
iping是用来向服务发起心跳检测的，通过心跳检测来判断该服务是否可用。iping的实现类有以下几种：
-
pingurl：使用httpclient去get请求某个url，判断其是否alive -
pingconstant：固定返回某服务是否可用，默认返回true -
noopping：没有任何操作，直接返回true -
dummyping：同样是直接返回true -
niwsdiscoveryping：根据服务的实例对象instanceinfo的instancestatus去判断，如果为instancestatus.up，则为可用
心跳检测策略对象ipingstrategy
private final static serialpingstrategy default_ping_strategy = new serialpingstrategy();
protected ipingstrategy pingstrategy = default_ping_strategy;
默认实现是线型轮询
负载均衡策略对象
private final static irule default_rule = new roundrobinrule();
protected irule rule = default_rule;
irule是在选择实例的时候的负载均衡策略对象，默认使用的是roundrobinrule线性轮询
除此之外的实现为：
-
bestavailablerule：选择最小请求数 -
randomrule：随机选择 -
retryrule：轮询重试 -
weightedresponsetimerule：根据响应时间分配权重 -
zoneavoidancerule：根据服务的分区可用性轮询
现在继续看baseloadbalancer的子类dynamicserverlistloadbalancer
这个类对基础负载均衡器做了扩展。扩展的功能如下：
- 服务实例运行期间的动态更新
- 服务实例的过滤
服务列表
public interface serverlist<t extends server> {
/**
* 获取初始化的服务列表
*/
public list<t> getinitiallistofservers();
/**
* 获取更新后的服务列表
*/
public list<t> getupdatedlistofservers();
}
在dynamicserverlistloadbalancer中默认使用的服务列表实现类是domainextractingserverlist，只不过该服务列表内部还定义了一个服务列表，这个服务列表的实现类则是discoveryenabledniwsserverlist
这个最终的服务列表的数据来源则主要依靠eurekaclient从注册中心获取
服务列表更新
这个接口定义了一系列的对服务列表的更新操作
public interface serverlistupdater {
//内部接口
public interface updateaction {
//实现对服务列表的更新操作
void doupdate();
}
//启动服务更新器
void start(updateaction updateaction);
//停止服务更新器
void stop();
//返回最近的更新时间戳
string getlastupdate();
//返回上一次更新到现在的时间间隔（ms）
long getdurationsincelastupdatems();
//返回错过的更新周期数
int getnumbermissedcycles();
//返回核心线程数
int getcorethreads();
}
它的实现类有两个：
-
pollingserverlistupdater：通过定时任务进行更新 -
eurekanotificationserverlistupdater：利用eureka的事件监听器来更新
服务列表过滤器
public interface serverlistfilter<t extends server> {
public list<t> getfilteredlistofservers(list<t> servers);
}
该接口主要用于根据一些规则过滤传入的服务实例列表，该接口的实现类如下：
-
zoneaffinityserverlistfilter：基于eureka的分区规则对服务实例的过滤 -
defaultniwsserverlistfilter：zoneaffinityserverlistfilter的子类且没有做特殊的更新 -
serverlistsubsetfilter：通过比较服务实例的通信失败数和并发连接数来剔除那些相对不够健康的实例 -
zonepreferenceserverlistfilter：使用springcloud整合eureka和ribbon时默认使用的该过滤器。它实现了通过配置或eureka实例无数据的所属区域(zone)来过滤出同区域的服务实例
zoneawareloadbalancer则是对dynamicserverlistloadbalancer的扩展，它主要增加了区域过滤的功能