gig：自带负载均衡和降级功能的高可用RPC解决方案

在线查询系统中，业务逻辑将服务划分为树状结构，每个节点通过水平扩展增加自身服务能力，最终形成下图所示拓扑结构：

当一次查询从某一入口进入系统后，自上而下查询各个服务，每个服务又有多个节点可供选择，最简单的负载均衡策略是轮询或者一致性hash，各个节点接相同流量，但是这种策略下如果集群中出现了坏节点，则会导致部分用户查询无结果或者超时，严重时导致故障。

我有几张阿里云幸运券分享给你，用券购买或者升级阿里云相应产品会有特惠惊喜哦！把想要买的产品的幸运券都领走吧！快下手，马上就要抢光了。

复杂一些的系统通过服务发现做坏节点检测，例如阿里的cm2和vipserver。以cm2为例，cm2会通过http心跳探测检查下挂节点的健康度，如果一个节点能够响应cm2的心跳探测，则认为是健康节点，cm2会将该节点发布给在线系统查询；节点异常时，心跳探测失败，cm2通知在线系统该节点需要删除，该节点流量跌0，从而避免坏节点干扰流量，如下图所示：

通过心跳检测发现坏节点主要有一下两个问题：

1. 心跳检测与实际查询的网络通路是不同的，心跳检测成功说明名字服务与目标服务之间的网络正常，但线上系统经常出现某条网络通路延迟高或者不通的情况，外部心跳检测解决不了这类问题。
2. 外部心跳检测无法发现服务自身的业务问题，或者说外部探测只能屏蔽部分进程、系统层面的问题（进程core掉、系统crash等）。例如搜索场景中，某个上层服务本身是健康的，但是他的下挂服务无结果率升高，这时候外部探测发现上层服务是健康的，流量还是会导向这个有问题的子系统，这常见于灰度发布、按机房发布等场景中。

以上问题的原因实际上是一致的：在线系统决策能力弱，完全依靠外部系统辅助决策查询路径。为了解决这些问题，我们开发了gig。

gig（Graph IrriGator）的核心思想是在线实时决策流量流向，不再局限于外部系统探测这种隔靴搔痒的方式，而是作为一个高可用的RPC lib嵌入到在线应用中，代理应用对底层服务的访问，实时统计每个节点的延迟和错误率，屏蔽高延迟节点、高错误率节点，在下游节点延迟上升到无法接受之前主动限流，让流量流向此刻此节点看到的健康路径上去。

从上图的角度来看，外部探测的方式是面向节点的，即每一个节点有一个健康度，而gig是面向边的，每一条边都有一个健康度。显然，边的个数要远大于节点个数，对系统状态的刻画也更加全面，同时，嵌入到在线系统有一个天然的优势：gig可以感知业务层面的错误，并能够据此屏蔽服务异常集群。

原文链接