饿了么的移动APM架构实践

2019独角兽企业重金招聘Python工程师标准>>>

作者简介：胡彪，饿了么移动技术负责人，移动技术总监。负责饿了么移动架构，新技术预研与实践；移动安全，移动应用开发等等。09年投身移动互联网研发，曾先后就职于新蛋、盛大、百度、腾讯等国内外知名企业。

发布日期：2016-12-06

本文针对表达不清晰的地方进行了调整，并针对关键信息进行了标注，可以参考原文进行对比；

---

简单的说 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.”

为什么饿了么需要研发 APM 系统？

饿了么作为一家全球领先的 O2O 移动互联网公司，目前日订单量超过 650 万，超过 98% 的订单量来自于 App 端。

• O2O 业务具有即时性和集中性等特点，订单主要集中在午高峰和晚高峰两个时段，系统高峰期面临高并发、高负载等多重压力。
• 早期再业务爆发高峰期，为了抗住系统压力基本靠不断堆人堆机器。随着技术不断提高和业务变化，存在部分机器利用率不高的问题。
• 国内移动网络环境极为复杂，WIFI、4G、3G、2.5G(Edge)、2G 等多种移动网络并存。
• Android系统碎片化过于严重。

APM系统的挑战

• 多语言并存，目前饿了么后端有 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 至关重要。

饿了么APM架构

移动端架构

Why protobuf？

使用 Protobuf 可以达到约 60% 的数据压缩比，达到节省流量目的的同时增加了数据 decode 复杂度，初步防止抓包轻易阅读报文行为。

自定义格式的协议均有此特点；说实话，我并不确定 protobuf 在移动端使用是否真的具有绝对优势；

Why 7Z?

鉴于 APM 收集到的数据量较大，对于系统分析有益，而对于用户来说用处不大，且会占用较多用户流量的情况；经过对比 Gzip，7Z，Snappy 等多种压缩算法，并综合多种因素考虑后，我们选择了 7Z 压缩算法。7Z+Protobuf 在多条数据的使用场景中最高可达 97.4% 的压缩比，单条数据使用场景也可达到 88.6% 的压缩比。

后端架构1.0

• 通过 Nginx+lua 模块来完成 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 数据指标；

一堆轮子被造出来了，然后这篇文章却不说清楚细节，哎～

---

原文地址：这里

转载于:https://my.oschina.net/moooofly/blog/804696