服务治理

服务治理分为三块：

1、节点管理，即服务提供者在注册中心及客户端创建的服务节点。

节点注册于注册中心，缓存于客户端，目的为若注册中心与服务端出现网络连通故障，但客户端与服务端网络连通正常，此时注册中心已将节点移除，但客户端在下一次同步注册中心节点之前仍可通过自身缓存的服务节点发送请求。

a、注册中心管理：服务提供者定时向注册中心发送心跳通知来证明其是存活状态，每次收到心跳通知均与上一次收到通知的时间进行比较，如果时差超出注册中心允许的最大值，则认为该服务提供者发生故障，将其从注册中心移除，随即通知监听客户端。

b、客户端管理：若注册中心与服务端网络连通出现问题，但客户端与服务端网络连接正常，直至下一次与注册中心同步之前仍可继续使用该节点。若客户端与服务端网络连通故障，但注册中心与服务端网络连通正常，则客户端会将该节点从缓存中移除直至下一次与注册中心进行同步，周而复始。

 

2、负载均衡，顾名思义：平衡所有服务端处理请求的负载，防止某个服务端因接受过多请求导致服务故障。

a、随机算法：字面意思，简洁明了，就是采用随机数的方式选择本次请求所要转发的服务端，此法非常公平，不会因为服务端配置的优劣而对其另眼相看，绝对的公平！

b、加权法：又叫轮询算法。本法则事在人为，完全按照主人的喜好行事，又称拍马屁，就好比食堂打饭，所有人围绕一个圈，如果打饭阿姨看到每个人的长相都一样，那么他对所有人都没有私心，从第一个开始每人给一勺，如此循环下去，谁都不会多谁也不会少，大家都均等，这就是大家的对注册中心来说权重都一样；如果打饭阿姨喜欢帅哥，看到长得帅的（比如我）每次都会多给一勺，其他人仍是一勺，此种情况对于注册中心而言，我的权重大于其他服务提供者，所以每一批请求中都会多分发给权重大的服务端。（此例不太恰当，换为吃饭：胖子和瘦子，胖子多吃，瘦子少吃，好像更好）。

c、最少活跃算法：这个拿吃饭来说吧，吃得多的碗落不下了，然后就少盛点，吃的少趁机多吃点均衡一下。上面也说了，打饭阿姨因为我长得帅，每次给别人打着饭呢都会不定时的拐到我这边给我加上一碗，递过来一碗饭，我桌子上的碗的数量就+1，等我吃完一碗饭将空碗回收后，桌子上的碗的数量就-1，但是打饭阿姨给的次数太过频繁，导致我面前很多碗，其他人面前的碗则很少，有人就向领导投诉，领导痛斥一顿后，阿姨则给面前碗最少的人开始打饭，这时此人碗的数量+1，然后阿姨重新统计，下一碗给统计后面前碗最少的人，这样大家都不至于被冷落，一旦落后，立刻照顾到。

d、一致性Hash算法：对每次请求的参数均计算hash，hash值相同的转发到同一个节点。上体育课1234报数排队，报到相同数字的站在一队，若某一队解散，由4队变成3队，则解散的这一队的人重新123报数，归并相关各队。（为什么不用吃饭举例了？因为再吃就撑死了！）

 

3、服务路由

a、灰度访问：类似于单双号限行和不限行。一条马路刚修好，实行为期一个礼拜的单双号限行，一个礼拜之内无故障，则取消限行，大家都可以走。

b、就近原则：每次请求到达，客户端先关门在自己的局域网内查找可用的服务提供者，若有则直接调用，若未查到则出门浪。

配置分为静态配置和动态配置，这里不做解释了，字面意思！

 

4、服务容错：有容奶大！要有一颗包容的心！没错，是不是没发现奶非乃！?

a、failover：拆开来就是fail over，也就是请求服务端a，然后a故障了，那就直接将请求转发给服务端b，结果b也故障了，那就再转发给c，直到成功！当然也可以设置最大转发次数，比如设置最大转发次数是两次，那么（划重点）在服务端2也故障时就不会转发给c了，直接返回给客户端告知失败！此方式为幂等的，也就是每一个服务提供方返回的数据均相等。

b、failback：遇到请求故障，那么就告知客户端请求失败，不再重试，然后根据返回的指令进行下一步操作。

c、failcache：遇到故障，就把请求缓存起来，间隔一段时间再发起请求，防止频繁请求影响服务端恢复。

d、failfast：遇到故障就返回，管他誓言有多真！绝不重试。