flume容器化之路

今天主要讲下 qbus 落地到hdfs的组件–flume,的容器化过程，希望能给在座的有把服务迁移到容器的各位，提供一个解决方案，可能不是最好，但是它很真实。

---

flume 在qbus 服务中作用：

消费各个业务的topic数据，持久化到hdfs。

hulk流程

• user 通过 hulk 开通落地到hdfs服务，hulk脚本把相关配置存在zookeeper中。

• 本地脚本cron遍历读取zk配置（每个机器消费集群维护一个cluster_list）

• 机器本地起flume进程消费，写hdfs。

服务痛点:

可用性

• hdfs集群割接断网
• flume机器down机
• 某些topic量过于大

配额/负载均衡

• 业务短时间内开启多个进程

运维成本

• 多处配置文件维护（cluster.conf,burrow.list）

• 手动进程增添，跨机器之后配置不统一

• 进程存在哪台机器，未知

最初运维改善

1. 可用性监控

2. 运维工具编写

   • 配置批量增删改查工具

   • 机器整体迁移工具

思考-容器能为我们带来什么？

• 可用性更强
  hulk容器有保活功能。挂掉自动拉起

• 资源配比均衡
  不用考虑机器上进程超载状况

• 增添副本更加方便
  有接口，可以直接操作

• 运维成本更低
  迁移，更改配置更加方便

而且各进程之间没有什么数据同步，基本无状态，非常适合容器场景。

容器化面对的问题

如何实现以下问题

1. hdfs授权

2. 配置

3. 监控

4. 动态调整

5. 无痛迁移

最终实现

• 自动授权

  • [x]系统部配合出授权接口
  • 我们自己用golang包成工具，嵌入到容器中，每次容器启动的时候自动授权

• 配置存取

  • 从zookeeper迁移到qcm, 制定新的配置模板，由hulk写入到qcm配置中心
    

* [x] 容器读取qcm http接口

• 监控

  • 容器主进程自动check服务进程

  • 根据topic流量和lag情况进行副本动态调整
    

  • 每次调整之后的结果，包括pod_num,lag情况,partition数量都记录在数据库中，做到有据可查，也能及时发现异常情况
    

* [x] 设置黑名单功能，对异常业务进行隔离

• hulk用户无缝迁移
  • 使用相同consumer group
  • hulk 开发配合特征识别新老版本进程（新建走新流程）

总结

其实在这个过程当中工作量具体分配如下：

content	工作量/时间 占比
发现问题	10%
提出方案	10%
沟通/跨部门沟通	30%
优化/确定方案	10%
上线	30%
后续问题处理	10%

所以沟通尤其跨部门沟通也是技术活儿，

ToDo:

• 授权优化
• 不同特征topic配置优化