讲师简介
图 1
图 1 是一个常见的情况，在每一台服务器日志上去部署一些数据分析，简单分析后会上报到RDB Redis上，之后会进行二次运算，紧接着到达展示层；在这个过程中，查询日志可以在ELK上进行。这算是比较简单的一个方案，基本可以满足大家的需求。但是这样做也会产生一些问题：
新增不易；
一开始的条件都是写好的话，每一个新增都需要写一个模板，所以新增很麻烦。
直接统计出结果数据集过于庞大，二次运算的复杂度取决于空间的维度；
如果每次都直接统计出一个结果的话，最后就会导致整个数据集越来越大。例如查询来自安卓，渠道为小米(版本号：6443)，时间粒度为5min的订单；遇到这样的情况，假如直接统计出结果，因为需要维护的版本号大约有两百多个，渠道号约有六七十个，平台约四五个，那么5min需要维护的数据就会累积，结果集就会很庞大。
可接受的时间复杂度
时间复杂度就是后台进行查询的时间，二次结果如果数据量大了，查询复杂结果数据就会耗费很长的时间。
集群维护复杂度
每一台机器上都需要写脚本去统计数据，所以每次新增都要重新rsync等，这样集群的维护就会很复杂。
图 2
鉴于这几个问题，我们将需求重新整理，如图 2 所示，最开始（从左至右）是数据源，数据源包含很多，比如日志；第二步是数据处理清洗，主要的目的是将一些不需要的数据清除掉；第三步是落存储，有很多方法，比如HBase；最后一步就是数据应用，比如做一些统计报表、进行报警之类的应用。
图 3
再细化下的话，底层是数据源，服务器日志代表的是半结构化的数据，数据库代表的是结构化数据，图片代表的是非结构化的数据；向上一层是数据收集传输层，包含 Kafka 和 Flume（日志收集系统）两种组件；第三层是数据存储层，这一块主要是使用 HDFS 与 HBase。第四层是数据计算层，包括 Spark、MR、Storm；顶层是数据应用层，进行一些数据开发和展示功能。图 4 便是我们第一代的结构图。
图 4
图 5
图 5 是一代的流程图。从数据源，也就是服务器上日志开始，数据流经 Flume，到达 Kafka后，分成两路流（实时流与非实时流），一路推入HDFS、一路经过 Storm 进行处理；非实时流主要是用 MR 和 Spark，进行清洗加工后将数据存储到 HBase；实时流则经过 Spark Streaming 、Storm处理，最终也是存储到 HBase。这些是早期比较常见的结构。
这种结构下，组件之间兼容问题很多；人力成本消耗大；batchjob、streaming资源、核心非核心资源的竞争难以隔离；由于作业之间依赖关系会导致作业管理复杂；
图 6
因为成本问题，我们规划了第二代的结构图，如图 6 所示。
图 7
图 7 是二代的流程图。我们使用了阿里的 EMR、MAXComputer 等产品，此时，服务器则使用的是 LogStash，日志服务则使用 LogHub，存储则采用OSS。这里也产生一些新的问题。首先，日志服务相对自己搭建ELK要简易很多，但是索引按照字段大小收费，价格较高；其次，不同组件间集成异常繁琐；第三虽然扩容方便，但是人力并未得到释放；第四内存型计算服务可以实现准实时分析出数据，但是价格偏高；第五是资源竞争问题难以隔离的问题依然存在；第六就是产品变更太快，有时候产品会突然下线或者功能迁移到新的产品中。
图 8
图 8 是我们最新的结构图。在第三代中我们采用了七牛云的大数据产品，他们会把一些不属于我们应该做的操作直接放在他们自己的平台上，由他们进行维护，这个产品就是他们的大数据产品Pandora。
图 9
图 9 也是我们最新的一个流程图。最开始还是服务器，然后是Logkit，当搜集到数据源之后，将非实时数据打到对象存储上，利用离线计算去处理这些工作流，经过离线计算的工作流，如果需要做二次计算或存储就再次返回到对象存储，如果需要直接计算出结果的话，就直接写入到J16组件上，J16是我们自己写的接收http结果的组件，实心箭头代表现在这块还未完善，我们是通过额外的脚本进行结果收集到J16的操作；实时数据也采用类似于离线处理的方式，后面步骤与离线计算一致，处理之后的数据，可以用于展示报表和数据挖掘。
这三张结构图一张比一张简单，而且我们自己承担的东西越来越少，其中也包括人力资源的消耗。同时，迁移是很麻烦的一件事情，在一开始最好就选定一种结构，尽量不再修改；
类似于saas的最后一种流程，可以让我们的人力接近完全解放。同时组件不存在集成与兼容的问题。因为上面设计的离线工作流和在线工作流是完全分离的，所以资源可以完全隔离。
实战分享 少走弯路
讲到实战，首先对我们目前的情况做一下简介。
【数据方面】
日均500GB数据增量；
日均产生几十亿条日志数据；
客户端SLA、数据库审计数据等未迁移；
【业务】
商城、社区、直播、运维等
【数据处理】
分析、统计、监控、告警等
图 10
如图 10 所示，我们的业务和数据处理之间其实是相互交叉的。
为了减少大家在实际过程中碰到的弯路，所以我会分享一些实践上的经验，供大家参考。
从数据源开始，数据源常见的是nginx、tomcat、fpm、网关、业务、数据库日志、上报异常、Sla日志等客户端统计数据。
图 11
日志统计是一个比较麻烦的事情，最开始接入，如果不统一日志格式，那么之后再进行日志分析就很困难，因为后期如果修改日志格式则所有的建模都要进行修改，非常麻烦，所以在一开始就要选择并且确定一种日志格式。
图 11 是 nginx 的日志，涵盖的内容很多，比如设备号、跟踪IP、UA头；微服务存在一个很大的问题，就是如何处理用户日志追踪；处理方式就是当客户端进行访问时，带一个唯一的ID号，最终通过这个ID号可以直接抓出这次所有落在不同服务的请求数据。
图 12
图 12 是业务层的一个日志。
图 13
图 13 是日志查询界面，为服务端人员提供查询功能。可以通过设备号，唯一请求ID等，得到客户端的请求日志，也可以支持高级的自定义查询功能。
图 14
图 14 是时序图，通过这张图，可以判断到底是自己调用其他系统服务时耗费时间长还是自己进行查询时耗费时间长，以及慢查询发生在何处，是因为查询数据库慢了还是其它的原因。
图 15
图 16
图 16 是业务在服务器上运行的时间，这边可以反映出代码的质量问题。比如两秒以上的接口几乎都是比较复杂的接口，例如下单操作或者调用第三方接口。
通过慢查询数据，我们可以有针对性地去做优化，例如每天出一个报表，通过数量去做一个排序比如第一个接口发生了五十多万次慢查询，这一定是新迭代修改过的接口，因为我们每两周三次迭代，每次上线之后可能会导致一些修改过的接口变慢。通过这个报表的话我们就可以实时知道说这次迭代是否有性能问题会影响到用户的体验。
图 17
图 17 是微服务带来的问题，微服务有一个版本控制，比如微博接口也从V1、V2、V3一路升上来，就很难确定说什么时候可以下掉这些旧版本，比如我已经升级到V4版本，但是我的V2版本由于旧版本客户端的原因，需要还能够使用。这样子的话一旦出现bug，就必须V2、V3、V4都打一个补丁过去，对开发人员来说是一个很大的负担。
有分析的话，就可以统计处哪些版本访问量对高，哪些版本访问量最低，这样我们就可以不断地根据访问情况下掉旧版本的系统，少维护一些系统。然后也可以知道使用这些API的客户端到底是哪些版本，有没有包括当前最新的版本，有的话就不能下架，需要安排逐步修改。例如今年我们就下掉了六七个版本。
也可以通过历史数据来做一些运维方面的自动化，例如通过前一七天带宽等的分析来做到带宽的自动增减，以及类似推送高峰期前自动扩容等的各种操作。
图 18
我们每天都要应对不同的攻击，例如CC攻击这一块，我们有做一些WAF的防御，还有网关的限流，但是因为阈值的关系，也很难说完全限制住。这个时候我们可以实时的统计当前有哪些客户端访问的数目是异常偏高的，例如图18，我们看最高都是在上面那五条线，每秒钟可能都有几十万人访问，这五个设备访问频率在里面出现次数最高，就说明有异常。这种就可以做一些特殊处理，针对异常设备进行限流。因为你很难说对所有的设备进行限流，有时候客户端的访问确实会很高，比如抢红包之类的。
推荐阅读
未来大数据平台：使用Zeppelin和Spark一键搭建数据分析及可视化平台案例
高可用架构
改变互联网的构建方式
长按二维码 关注「高可用架构」公众号
287
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
