高可用实践需求及实现方案解析

高可用性设计目标

一个完整的全系统高可用性设计通常会涉及五大层面：基础设施、服务器、数据、应用程序、系统服务。

在基础设施层，FreeWheel更多的是将AWS视为一项服务。虽然AWS会充分保证其基础设施的稳定性，FreeWheel还是会在所有的服务都可能出问题这一假设下指导设计。服务器层也是如此。

数据层，如果该数据存在于FreeWheel自身系统，其通常会借助于像Kafka、HBase的天然多副本能力，即设置多个副本提供数据容灾。

应用程序层，FreeWheel一般会将它做到无状态，从而更容易实现快速恢复和高可用，无论是水平扩展还是垂直扩展都更方便。

服务层，FreeWheel采用的是Failover（故障转移）机制。即应用服务器设置多台，彼此之间通过心跳联系。数据库、缓存、应用服务器等任何位置出现瓶颈就只需增加处理能力。目前，对于服务器的对等可替换性，主要有三种类型：Active-Active（双主）、Active-Standby（主备）以及单Active。

· 在双主模式下，FreeWheel通常会通过先绑定Amazon ELB，再注册到Amazon Route 53的方式，从而实现自动对应用无感知访问。

· 对于主备模式，FreeWheel通常会将信息注册到ZooKeeper，由ZooKeeper实现Failover的分布式协调服务，从而实现Master的选举和对外服务发现。

· 对于单主模式，一般是一些离线任务，FreeWheel会将其绑定在ASG（Auto Scaling Group）中，出现问题时可以自动扩展重试。

高可用的整体实现方案

无论是跨Region（区域）还是跨AZ（可用区），数据交换都将产生一定的成本开销。面对着庞大数据量和跨区域 / 可用区间的数据延迟，在AWS多可用区实践过程中，FreeWheel针对数据平台对于高可用的需求及AWS自身高可用实践经验，采用了多种定制方式——主要对Hadoop-HBase、Kafka、Zookeeper及数据处理部分实现了不同的高可用解决方案。

Hadoop-HBase多可用区

在设计之初，FreeWheel就试图平衡了成本、性能和可用性之间的关系。但是类似数据库系统中的CAP理论，这三者很难同时得到满足。例如，AWS上很多及其类型和存储类型都不尽相同。为了提升HBase性能需要采用Instance Store这类本地SSD存储方式，而相应的弊端也随之产生：一旦挂载这个Instance Store这个实例出现异常，相应的存储就会丢失。尤其是当其真实宿主机发生大面积故障时，可能导致数据的彻底丢失。

因此，FreeWheel也需要对HBase在多个可用区上实现高可用。

对于存储模块，FreeWheel选择两个可用区来部署，通过HDFS Storage Policy接口，实现数据块副本数在主可用区和次可用区的分布。对于无状态的数据应用优先部署在与Hadoop/HBase主可用区同侧，并支持在次可用区快速部署。应用和数据优先同侧的策略，可以有效降低数据应用的因为跨可用区带来的数据延迟，并降低可用区之间网络传输的成本开销。借助AWS提供不同存储介质的IOPS和持久化特点，实现针对不同业务的工作负载灵活选择存储节点配置，并实现业务之间的物理隔离（原理如下图）。

其中，隔离思路主要是基于不同的工作负载选用不用的EC2实例或EBS实例。这样也可根据自身的业务特点，在AWS中选择不同的硬件、实例类型或EBS类型来满足需求。此外，FreeWheel也可以在AWS Hadoop上实现一组机器的上线及下线，而且只把具有某一类标签的机器上、下线，而不影响到其他数据。

Kafka多可用区

Kafka Topic内每个Partition有多个副本，多可用区部署，需保证在不同可用区的副本个数的划分。姜冰提到，在正常情况下每个Partition里可设置多个副本，如果要保证高可用，意味着需要将多个副本同时被部署到同一可用区上，但同时，这样做的弊端是无法保证可用区级别高可用，如果一个可用区宕机将导致整个Partition不可用。

于是，考虑到跨可用区带来的数据延迟以及成本开销，FreeWheel针对数据应用和规模实现了不同的策略。

一种策略是，对于用于数据处理流程的Kafka Topic，在次可用区仅部署Partition副本中的Follower。应用程序和Kafka主可用区同侧，读写数据的流量全部在同一可用区完成，这样在主从可用之间，仅有Leader和Follower之间的网络传输开销。在主可用区发生故障时，从可用区的Follower切换成Leader对外提供服务（原理如下图）。

在这种情况下，Kafka消费者只会在同一可用区消费，从而避免跨可用区间因网络传输带来的成本消耗，同一可用区间的延迟性也大大降低。

而对于以在线服务为主的数据，为了提供更强的高可用和更快速的恢复能力，Kafka采用3可用区对等部署的方案，无差别地对外提供服务：每一个Partition的Leader和Follower以公平的策略随机分配到不同的可用区，在AWS出现可用区级别的故障时，Kafka借助Leader和Follower之间的切换，保证服务的高可用（原理如下图）。

放在FreeWheel的具体业务场景中，为保证广告主预算与广告竞价间反馈回路的可用性高且延时性低，避免出现广告超量投放或投放价格与预算偏差等问题，FreeWheel需采用上述第二类这种解决方案。

Zookeeper多可用区部署方案

Zookeeper集群是由1个Leader和若干个Follower组成，这些节点被部署到3个AWS可用区。应用通过名字注册服务将主工作服务（Active）注册到Zookeeper。在可用区发生故障时，应用Active/Standby角色根据Zookeeper名字服务状态变化进行切换，并注册最新的Active服务到Route53（原理如下图）。

数据处理高可用部署方案

目前FreeWheel DIP（Data Ingestion Pipeline）架构由两部分组成，一是流处理工作类型，二是上下游以小时为级别的批处理工作类型。

流处理消费一次来源于Kafka，同时会和HBase交互，所以就流处理来说，如果能解决数据和状态高可用，其本身是属于一条无状态的数据处理流水线。反观，这也是为什么FreeWheel会花更多功夫在Kafka、Hadoop-Hbase和Zookeeper高可用部署上的原因，从而进一步确保流式数据处理状态和高可用。

流式处理主要通过Hadoop YARN部署，采用ASG做扩展 / 收缩，以及采用ASG绑定同一YARN队列的方式来保证高可用性。

对于批处理工作类型的解决方案，FreeWheel也有比较好的Failover方案应对异常状况下的自我修复。总的来说，利用分布式的天然架构，FreeWheel可以通过监控措施很快地对其进行恢复。