这是一个酷热的下午，太阳焦炙地烤着大地，回想童年的美好时光，这个时候应该是欢快的在田间奔跑着，赤着脚丫，那是我逝去的青春......，想到这儿，我眼眶湿润了，提起桌边的枸杞杯，嘎了一大口，准备再摸鱼5分钟。
此时，老大也端着枸杞杯走了过来：
老大：xw，还记得前几天运维的邮件不，用户日志上报超时了，导致数据部门报表没有准时出来，这个事情看看有什么方案解决没有？
我：嗯，记得，我们的日志是凌晨本来4点前要清洗好是吧，但是那天6点了都没处理好。
老大：你了解这个具体的流程吗？
我：有了解，可以再整体说一下哇？记得日志之前是另外一个团队做的噶。
老大：是的，目前日志这块的处理逻辑是：客户端通过SDK的接口上报日志，然后日志服务器收集并存储以Log日志定制方式存储起来，凌晨12点，有定时任务启东日志清洗脚本，处理完后，存放到指定文件服务器上，然后他们来拉取。
我：明白，那他这个是工具是单线程的吧，我们使用多线程来优化处理，应该就可以了吧。
老大：目前来看，池化处理可以hold住，但是可能需要多考虑一些业务问题，比如我们现在的业务在各渠道都在大力度推广，总体用户已经达到6000+W，日活用户近500W，还有就是运营会经常策划一些活动，这时用户流量就可能会出现突增情况，还记得xxx那次吗，活动刚开始，NG连接数瞬间被打满了。
我：是啊，那你的意思是除了日志清洗问题，还有就是需要处理需要处理日志实时上报问题是吧。
老大：嗯，你这面研究一下，看能不能用Kafka来处理这种情况呢？
我：咿，Kafka木用过。
老大：相信你，你行的，搞定加鸡腿。
我：好的，我研究研究。
然后，花了半小时了解Kafka，再花了半小时梳理了业务流程，确认好整改方案，找老大确认对接流程咯。主要的流程差不多就下面这样的噶
框架图：
其实主要流程还是比较简单的：
- 用户通过APK操作，通过内置的SDK生成启动、事件、页面日志，通过HTTPS调用日志服务接口上报；
- NG将用户请求负载到各日志接收服务器，服务器接收到请求，封装成日志消息，推入Kafka队列；
- Kafka日志消费端负责异步对日志条目进行清洗，并将清洗格式化的日志append到本地的Log日志文件；
- 在统一文件存储服务器通过日志脚本凌晨负责收集第3步生成的Log日志文件，汇总，并生成校验文件信息；
- 数据中心根据约定好的事件来拉取文件。
验证：
在本地模拟日志请求没得啥问题了，数据能够正常上报和消费清洗，并最终以文件方式存储好，那么这个怎么验证在现网环境下没得问题呢，既能验证程序处理逻辑的准确性，又能准确反映现网服务的用户请求。
网上搜索了一波，了解到Nignx据有流量复制能力，能够将生产环境的流量拷贝测试环境，需要了解的可以看网Nginx官网或者(Nginx流量复制)，本来以为找到方法了，但打击来得太快，线上环境的Ng环境版本较低，不支持流量复制功能，额，那只能找其它方法了。终于黄天不负有心人，找到一款同样优秀的工具GoReplay，GoReplay主要是监听网络接口上的流量，不需要对生产基础设施进行任何更改，而是在与服务相同的机器上运行GoReplay守护进程。
上线部署
我们线上有7台日志服务器，虽然上面验证通过了，但是为了保险起见，还是采取了逐步替换策略，分布验证：
| 升级 | 升级Kafka新版 | 之前清洗方式 |
|---|---|---|
| 第1次升级 | 1台 | 6台 |
| 第2次升级 | 2台 | 5台 |
| 第3次升级 | 4台 | 3台 |
| 第4次升级 | 7台 | 0台 |
说明： 每次升级，验证需要运维做好Kafka集群健康状态监控，运营同学核查各运营指标是否正常。这个过程其实战线十分漫长，也涉及到三方技术团队的切换和验证，整个也算是一次基于Kafka的简单实践吧，虽然实施过程可能比文章里面描述的复杂，哈哈。
（这么一看，好像是简单得一批，大家有兴趣了解的，留言，搞个Demo给大家看看）来吧，赶紧吐槽，嘎嘎。
