刨根问底“黑科技”EP模块的演进—高可用

首先我们掉个书袋，什么是高可用？“高可用性”（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。

我们的EP(event process)功能主要是实现租户操作记录，定时转储到租户OBS 桶中，类似于一种归档操作。从这个模块的功能要求来看对于实时性要求并不高，但也不意味着可以容忍故障处理需要人工介入，所以这个模块的高可用性设计会从下面几个方面展开：

    避免单点故障

负载均衡

集群部署

故障转移

首先要考虑的就是避免单点故障，EP模块会采用集群部署的方式。负载均衡是一种常见的适用与接口触发工作的模块(负责API处理的模块常用)实现集群部署，我们的EP是自己定时任务触发所以没有采用这种技术。

实现集群，其实核心问题就两点：

1、节点状态管理—可以感知异常

            2、任务分发机制。

对应如下的图，节点状态管理：我们通过DB中的node表保存集群中节点信息。节点定时刷新表内数据，并判断其他节点刷新时间是否在认可的alive 时间区间，否则主动刷新为error，这时候就认为该节点异常。 任务分发机制：EP节点处理数据的粒度是以租户为角度，租户开通时就在shard表中增加租户id，另外这个表的key是从0-127 租户id随机添加到某个id的value中，EP按照node表中的alive顺序平均的取shard表中数据实现任务分发。

通过这两个问题的解决EP节点实现了集群部署，并且当节点异常时有其他的节点能够动态感知并接管异常节点的任务做到故障自动处理。

避免单点故障只是开始，EP运行过程中的保障也同样重要，这里的思考对应下面这几点。

    应用可用性

及时发现故障

监控 基本监控+业务监控

日志分析

告警

数据量上升的应对策略

垂直扩容

水平扩容

任务自动分发

这里需要特别说明几点：对于EP的监控应该是全方位的，不仅仅局限在进程是否存在，所在OS的基本参数，更重要的是我们梳理出了EP在运行中的一些关键业务指标，例如上传OBS耗时等。另外对于业务量上升后的扩容，我们会先采取垂直扩容的方式即 增加CPU/MEM这种，防止盲目增加节点带来的运维成本上升。