互联网+推动越来越多的企业把核心业务迁移到互联网上，通过云计算、移动互联网等新技术的应用，用户不必通过专业的服务人员就能直接获得企业的服务，而这些服务已经渗透到了我们衣食住行的方方面面，最近就有CNN记者在北京体验了一下24小时无现金生存。

　　这就是移动互联网带来的变革，随着用户体验的前置，当用户感受服务质量不好时，就会对业务产生巨大影响。那么企业该如何将用户体验和后端IT平台的服务质量关联起来，及时发现影响业务的系统性能问题呢?这就是大数据分析要做的工作了。

　　云智慧面向业务的端到端性能管理平台透视宝以业务的视角，对整个用户体验交付链条的每一个环节进行数据采集和分析，准确发现和定位影响用户体验的任何性能问题。上一篇文章中我们介绍了云智慧透视宝前端架构的功能和实现，今天我们就来看看透视宝后端是如何把前端采集到的数据进行处理，并与企业的业务数据加以整合，从而为企业业务发展提供决策参考的。

　　后端在云智慧透视宝的作用

　　我们把云智慧透视宝的APM产品简单分为三块：数据采集，数据处理，数据展示。对于云智慧的用户来说，能够直接感知到的是数据采集端和数据展示端。

　　后端的数据处理对用户是透明的，但是后端的性能和稳定直接影响到数据的采集和展示。这三块是相辅相成，缺一不可的，他们构成了透视宝的业务基础。后端在其中起着承上启下的作用，他是透视宝的数据中心。

　　透视宝后端主要做什么

　　上面我们说了，后端起着承上启下的作用，那么他是如何承上的呢?

　　后端的“上”是数据采集端，也就是我们的SmartAgent。SmartAgent负责采集包括：主机，Code，服务，Browser，Mobile等环节的性能数据。数据采集到以后，通过Sendproxy(Mobile和Browser是自主发送)发送到后端对外的通讯接口。至此，SmartAgent的采集工作就完成了，下面的工作就交给后端来处理了。

　　后端的“下”是透视宝的数据展示端(也就是我们的portal.toushibao.com)，后端为透视宝提供数据存储、分析、查询等服务。我们在展示端看到不同维度、不同指标的图表，都是通过后端提供各种数据的分析查询服务，才得以展示出来。

　　这就是后端的启下。

　　那么，从采集端的元数据到前端展示的图表，透视宝是如何处理呢?

　　要解答这个问题，首先要知道后端的工作，分为：数据接收，数据传输，数据分析，数据存储，数据查询等。

　　数据接收：我们采用通用的http协议，以restapi方式对外提供接口。

　　数据传输：我们采用数据管道加消息队列的方式，保证数据传输的高并发和低延迟。

　　数据分析：我们利用自主分析以及借助相关的数据分析工具，满足我们不同的图表展示需求。

　　数据存储：我们采用多种数据存储方式，包括mysql，hbase，hadoop，elasticsearch等，分布式存储数据。

　　数据查询：我们采用通用的http协议，以restapi方式提供数据查询服务。

　　透视宝后端架构是如何处理数据的

　　解释完透视宝后端的作用，接下来我们详细介绍下后端架构的实现原理。

　　透视宝架构中，最开始是SmartAgent(上面提到的 “上”)发起数据采集，最终就是透视宝网站平台(portal，上面提到的“下”)，中间就是透视宝后端的各个组件。下面按照数据接收，数据传输，数据分析，数据存储和数据查询的逻辑顺序看一下各个组件是如何工作的：

　　一、 数据接收

　　最前面是nginx和communication部分，透视宝以restful的方式对外提供API，API类型分为四种：

　　(1) 接收浏览器端数据的API

　　(2) 接收移动端数据的API

　　(3) 接收sendproxy发送过来的数据API

　　(4) SmartAgent与透视宝主站进行信息交互的队列接口API

　　各个接口分布式部署，前端通过nginx代理，实现负载均衡。这些接口接收到数据以后，将数据进行简单处理，然后将数据转发到数据管道。

　　二、 数据传输

　　数据传输的功能由data pipeline和message queue部分承担。数据管道可以收集不同应用上的事件数据，将数据根据不同的主题(topic)发送到不同的数据平台上。我们可以把数据管道想象成一个非常大的水道，在这个大的管道里又有不同小管道，每个小管道对应一种数据类型。数据管道将这些数据sink到不同的数据平台上去，比如， 比较有名的消息队列kafka，等待后续的数据处理。

　　补充知识：

　　Kafka是一种高吞吐量的分布式发布订阅消息系统，具有以下特性：

　　(1) 以磁盘数据结构提供消息的持久化，即使数以TB的消息存储也能保持长时间的稳定性能。

　　(2) 高吞吐量，即使是非常普通的硬件Kafka也可以支持每秒数百万的消息。

　　(3) 多消费者模式，消息分topic传输，可以被不同group的消费者消费。

　　透视宝数据量巨大，需要有高并发、高吞吐的消息队列支持，同时多消费模式也满足我们对数据进行订阅消费的需求。

　　下图是多消费模式的示例图：

　　现在数据传到了消息队列了，我们如何处理在队列里的消息呢?

　　三、 数据分析

　　采集到数据只是万里长征的第一步，如何分析数据并得出有意义的结论才是大数据的价值所在。透视宝数据有这样几个去向： elasticsearch、alert platform、raw data share、hadoop……

　　Elasticsearch是透视宝数据分析查询的核心，也是前端图表的数据来源。所以，数据都会流向Elasticsearch。我们可以把Elasticsearch看成是一个海洋，是数据的来源，在数据注入这个海洋之前，需要经过河流的沉淀。这里所说的River就是我们的分析引擎，在数据进入elasticsearch之前从采集到的元数据中提取出有用且方便查询的数据，供前端展示分析。比如，应用发现、应用拓扑发现、uri发现等。元数据经过分析引擎分析过滤后，最终汇入到elasticsearch。

　　Alert platform是告警平台，透视宝发现问题后通过告警平台根据分级告警设定，以多样化的告警方式及时告知用户，确保用户第一时间得到系统故障告警。

　　Raw data share是元数据分享平台，用户如果需要对SmartAgent采集到的原始数据进行独立分析，通过数据分享平台就可以满足这样的需求。目前百视通就在使用此平台。

　　Hadoop：数据管道在处理数据时会将堆栈数据存储到hadoop中，以restapi方式对外提供查询服务。

　　四、数据存储

　　数据分析过后，需要存储起来才能够提供稳定持久化的服务，接下来说说透视宝的数据存储，方式有：elasitcsearch，hadoop、mysql等。

　　Elasticsearch是一个数据分析引擎，同时他也提供数据存储。我们可以把Elasticsearch看成是一个nosql数据库，以restapi方式对外提供服务，查询方式是标准的json查询，这样可以满足复杂的聚合查询。

　　Hadoop的hdfs存储是分布式的，可以满足透视宝堆栈大文本数据的存储需求。

　　MySQL主要存储企业的应用拓扑和应用数据。后端是通过前端提供的restapi来存储这些数据的。

　　五、数据查询

　　透视宝的数据查询都是以restapi方式提供服务的，查询包括：elasticsearch分析查询，堆栈数据查询等。

　　Elasticsearch提供数据分析功能，前端图表展示调用elasticsearch提供的rest接口，得到聚合后数据，在图表中展示。

　　堆栈数据查询：在透视宝网站上的追踪详情页，查看追踪详情，需要调用后端提供的rest接口，查询出某一次的堆栈详情，查找原因，定位问题。

　　透视宝从开发阶段就本着可运维、可恢复的原则，帮助用户在问题出现之前发现问题并解决问题，以保证7*24提供服务为标准，而这正依赖于透视宝后端稳定的数据分析能力。