简单的说APM即应用性能管理，主要指对关键业务应用进行监测、优化，提高应用的可靠性和质量，保证用户得到良好的服务。同时通过监控不断优化应用，达到提高用户体验的同时节省成本的目的。下面是维基百科上的介绍：
Application performance management is the monitoring and management of performance and availability of software applications. APM strives to detect and diagnose complex application performance problems to maintain an expected level of service. APM is “the translation of IT metrics into business meaning.”
饿了么作为一家全球领先的O2O移动互联网公司，目前日订单量超过650万，超过98%的订单量来自于App端。
O2O业务具有即时性和集中性等特点，订单主要集中在午高峰和晚高峰两个时段，系统高峰期面临高并发、高负载等多重压力。
早期也业务爆发高峰期，为了抗住系统压力基本属于不断堆人堆机器。随着技术不断提高和业务变化，部分机器利用率不高。
国内移动网络环境极为复杂，WIFI、4G、3G、2.5G(Edge)、2G等多种移动网络并存。
Android系统碎片化过于严重。
多语言并存，目前饿了么后端有Java、Python、PHP、Go等；
H5端VUE JS、Angular JS、React JS等多框架并存；
多终端并存，Backend、Frontend、iOS、Android、Hybird、Semi-Hybird等，且交叉混合较多。
高并发，海量数据。目前仅后端每天收集到APM相关数据40TB+。
Mobile Native端APM不能影响宿主App运行，且不能明显增加用户流量、电量等消耗。
如何做到无侵入APM至关重要。
移动端架构
Why protobuf？
使用Protobuf可以达到约60%的数据压缩比，达到节省流量的目的同时增加数据decode的复杂度，初步防止抓包轻易阅读报文行为。
Why 7Z?
由于APM收集到的数据量比较大，并且APM数据对于系统是有益，但是对于用户并无溢出，且用户流量消耗较多。经过Gzip，7Z，Snappy等多种压缩算法对比后，综合多种因素考虑后选择7Z压缩算法。7Z+Protobuf可以在多条数据的时候最高达到97.4%的压缩比，单条数据也可以达到88.6%的压缩比。
后端架构1.0
通过Nginx+lua模块来完成Un-7Z, Protobuf等工作，将数据写入access.log；
通过Flume读取access.log，将数据写入Kafka；
Kafka只有一个Topic，ETL Service直接消费Kafka。根据消息类型不同做不同业务逻辑处理，然后将数据写入ES或者LinDB（饿了么框架工具部自研）；
Webport展示数据结果；
缺点
Nginx+lua模块处理能力有限；
反复读写access.log让系统变成了一个IO密集型系统；
Kafka只有一个Topic，一旦一种类型数据出现问题，将会影响其它类型数据处理；
所有数据都依赖ETL Service来处理，但是每种消息的处理逻辑完全不同。部分处理比较复杂的消息严重影响了ETL的消费能力，导致Kafka数据大量堵塞，数据延迟极高；
后端架构2.0
使用Gateway来代替Nginx，智能降级熔断；
放弃flume，使用Collector Service代替lua模块，简单处理之后直接将Protobuf数据插入Kafka；
使用Dispatch Service对每种类型消息做简单处理之后，分Topic插入Kafka中，确保每个Topic中消息格式统一；
增加Transport Service将Metadata存储ES中；
增加Alerting Service，异常指标及时通知；
在ES之上增加一层API Service，提供各种DIY数据指标；
胡彪，饿了么移动技术负责人，移动技术总监。负责饿了么移动架构，新技术预研与实践；移动安全，移动应用开发等等。09年投身移动互联网研发，曾先后就职于新蛋、盛大、百度、腾讯等国内外知名企业。
