线上物流快速响应机制

[toc]

这里的高可用并不是指HBase本身的高可用机制。而是HBase主备双服务的高可用，线上业务依赖于主备HBase集群来提供数据支持，主集群首要的任务时负责数据的读写，备集群只是为了容灾。

对于HBase主备服务高可用方案的调研，团队内部从未停止过探索的步伐。从最初手动切换Nginx的域名映射，到统计异常日志占比，然后进行自动的域名切换。那时候我们面临的状况是，主集群大量读写超时、甚至服务不可用，造成业务方接口无法为用户提供正常的线上业务时，HBase运维小伙伴们才能感知到HBase集群的异常状态，手动切换流量至备集群，从而在服务恢复的时间内，造成了无法容忍的损失。

针对旧方案的种种痛点，以及受微服务中熔断概念的启发，最终选择集成了饿了么提供的一个熔断框架—— doctor ，实现了HBase主集群服务查询异常时，查询流量能够及时、自动、无感知地进行切换到备集群。

一般在微服架构中，有一个组件角色叫熔断器。顾名思义，熔断器起的作用就是在特定的场景下关掉当前的通路，从而起到保护整个系统的效果。

在微服务架构中，一般我们的独立服务是比较多的，每个独立服务之间划分责任边界，并通过约定协议接口来进行通信。当我们的调用链路复杂依赖多时，很可能会发生雪崩效应。

假设有这么一个场景，有A, B, C, D四个独立服务，A会依赖B，C，D；当D发生负载过高或网络异常等导致响应过慢或超时时，很可能A会因此堆积过多的等待链接，从而导致A的状态也转为异常，后面依赖到A的其他服务跟着发生链式反应，这将会导致大面积的服务不可用，即使本来是一些没有依赖到B，C，D的服务。如下图所示：

这不是我们希望看到的结果，所以这个时候熔断器可以派上用场。最简单的做法，我们为每个依赖服务配置一个熔断器开关，正常情况下是关闭的，也就是可以正常发起请求；当请求失败(超时或者其他异常)次数超过预设值时，熔断器自动打开，这时所有经过这个熔断器的请求都会直接返回失败，并没有真正到达所依赖的服务上。这时服务A本身仍然是能正常服务的。当然，我们针对失败请求的策略，并没有这么简单粗暴。

HBase 虽然提供了 HBase Replication 机制，用来实现集群间单方向的异步数据复制，线上虽然部署了双集群，备集群 SSD 分组和主集群 SSD 分组有相同的配置。当主集群因为磁盘，网络，或者其他业务突发流量影响导致某些 RegionServer 甚至集群不可用的时候，就需要提供备集群继续提供服务，备集群的数据可能会因为 HBase Replication 机制的延迟，相比主集群的数据是滞后的，按照我们集群目前的规模统计，平均延迟在 100ms 以内。所以为了达到高可用，业务方只能接受复制延迟，放弃强一致性，选择最终一致性和高可用性。

有赞技术团队对于HBase高可用服务接口的设计，同样使用了熔断的概念，只是其底层的熔断技术依赖于java微服务中的Hystrix框架。其简单的客户端高可用方案原理图如下所示：

业务方是不想感知到后端服务的状态，也就是说在客户端层面，他们只希望一个 Put 或者 Get 请求正常送达且返回预期的数据即可，那么就需要高可用客户端封装一层降级，熔断处理的逻辑，这里有赞采用 Hystrix 做为底层熔断处理引擎，在引擎之上封装了 HBase 的基本 API，用户只需要配置主备机房的 ZK 地址即可，所有的降级熔断逻辑最终封装到 ha-hbase-client 中。

以上文字描述摘选自有赞的技术博客，详情可以参考链接， 有赞 HBase 技术实践：读流程解析与优化

与微服务中的熔断概念类比，我们也可以把我们的主备HBase集群看做是两个独立的服务，而我们的业务方则需要依赖这一个HBase服务，对外提供自己的服务。这里稍微有一点不一样的地方是，我们HBase服务的角色是由两个集群来担任，正常情况下，只有一个集群来承担起HBase服务的功能。HBase熔断切换的简单示例如下：

如果想要更深入地理解主备熔断切换的设计理念，那么，需要优先理解一下滚动窗口计数，以及阈值判断相关的一些内容。 doctor 熔断框架的设计中，依赖于滑动窗口时间内的滚动计数，来进行阈值计算，从而判断当前服务的健康状况。

滚动计数的行为类似于一个拥有固定长度的先进先出队列，或者时间戳序列上的滑动窗口。一个滚动计数的值是队列元素的和，时钟结束时，最后一个元素的值将滚动到先前的位置，传递了一个时间粒度，这个时间粒度，默认1s。下面将借助一个小例子，具体来说明这种机制。

上述便是对HBase熔断思想所做的一个由浅入深的解释，用于实现业务方访问HBase时，对于主备HBase集群的状态切换无感知。即使主集群处于异常状态，我们依旧可以为业务方提供正常的HBase服务。

拒绝大型单体应用，把一个独立的应用程序开发为一套小服务，每个小服务运行在自己独立的进程中，并使用轻量级机制通信，通常>