现在哪个网站还做白拿,设计摄影作品,莱芜地板街50一次,深圳网站建设服背景
结合《蚂蚁金服面对亿级并发场景的组件体系设计》#xff0c;我们能够通盘了解支付宝移动端基础组件体系的构建之路和背后的思考#xff0c;本文基于服务端组建体系的大背景下#xff0c;着重探讨“自动化日志手机与分析”在支付宝 App 内的演进之路。
支付宝移动端技…背景
结合《蚂蚁金服面对亿级并发场景的组件体系设计》我们能够通盘了解支付宝移动端基础组件体系的构建之路和背后的思考本文基于服务端组建体系的大背景下着重探讨“自动化日志手机与分析”在支付宝 App 内的演进之路。
支付宝移动端技术服务框架 这是整个支付宝移动端无线基础团队的技术架构图同时蚂蚁金服体系内的其他业务 口碑、网商银行、香港支付宝、天弘基金等) 通过移动开发平台 mPaaS进行代码开发、打包、灰度发布、上线、问题修复、运营、分析。因此mPaaS 源自于支付宝移动端的核心技术架构并在 App 全生命周期的每个环节提供特定的能力支持。接下来我们将着重分享“日志诊断”和“移动分析”两个能力背后的架构演进和选型思考。
支付宝移动端技术服务框架数据分析框架 如图所示即数据分析能力的技术架构图其中“数据同步”、“埋点SDK”、“日志网关”是移动端专属的能力其余部分是所有的数据分析平台都必须具备的数据结构。
1. 日志采集 接下来我们重点分析支付宝移动端的日志采集框架首先第一部分是“日志 SDK”日志 SDK 会向业务层提供一个埋点接口使用起来就和 Java 里面的 logger.info 的感觉一样业务层只需要把想记录的信息传递给日志 SDK。日志 SDK 会在拿到业务日志后去系统内部获取相关的系统级别的上下文信息比如机型、操作系统版本、App 版本、手机分辨率、用户ID (如果用户登录了)、设备ID、上一个页面、当前页面等接着把这些信息与业务日志内容整合成一个埋点然后记录到设备的硬盘上。对只是记录到硬盘上并没有上报到服务端。
日志 SDK 会在合适的时机去和日志网关交互判断获取什么样的日志、什么级别的日志可以上报。如果可以上报是以什么频率上报、在什么网络条件下上报。因此通过日志 SDK 与日志网关的交付我们可以来实现日志的策略式降级。日志的策略式降级这点对于支付宝特别重要因为目前支付宝的体量日常的日志上报量为约 30W 条日志/s而在大促的时候日志量会是日常的几十倍 所以如果大促期间不采用任何的日志降级策略的话我们的带宽会被日志打包支付宝的正常业务功能就不可用了。
由此我们可以总结在大促高并发场景下我们需要只保留关键日志的上传其余日志统统降级。即使是日常业务处理我们也只允许日志在 WIFI 条件下上报防止发生流量相关的投诉。
埋点网关除了提供日志上报的策略开关能力之外就是接收客户端的日志。它在接受到客户端日志之后会对日志内容进行校验发现无效的日志会丢弃掉。而对有效合法的埋点会根据客户端上报的公网 IP 地址反解出城市级别的地址位置信息并添加到埋点中然后将埋点存放在它自己的硬盘上。
2. 埋点分类 经过多年的实践支付宝把日志埋点分为了四类。
1行为埋点用于监控业务行为即业务层传递的日志埋点属于行为埋点行为埋点属于“手动埋点”需要业务层开发同学自己开发。不过也不是全部的业务行为都需要业务方手动开发有一些具备非常通用性的业务事件支付宝把它们的埋点记录放到了框架层如报活事件、登录事件。因此行为埋点也可以叫做 半自动埋点。
2自动化埋点属于“全自动化埋点”用于记录一些通用的页面级别、组件级别的行为比如页面打开、页面关闭、页面耗时、组件点击等。
3性能埋点属于“全自动化埋点”用于记录 App 的电量使用情况、流量使用、内存使用、启动速度等。
4异常埋点属于“全自动化埋点”严格上讲也算是性能埋点的一种。但是它记录的是最关键的最直接影响用户的性能指标比如 App 的闪退情况、卡死、卡顿情况等。这类埋点就属于即时大促期间也不能降级的埋点
图中的代码示例即为一条行为埋点样例大家可以看到埋点实际上就是一条 CSV 文本。我们可以看到里面有日志网关添加进行的地址位置信息内容也有日志 SDK 给添加的客户端设备信息。
3. 日志处理模型 下面我们来整体了解支付宝内部日志处理的通用流程
1日志切分
我们已经了解到埋点实际上即为一段 CSV 文本。而所谓日志切分呢即将 CSV 格式的文本转成 KV通俗点说就是内存里面的 HASHMAP。这个切分的过程可以直接根据逗号进行切换当然也还有很多其他的办法。
2日志切换
日志埋点中的内容并不是直接可以拿来进行分析的。比如客户端启动时间相关数据是按照毫秒级别的颗粒度进行上报但实际应用上我们只需要把数据分析到某个特定区间内的个数所以在处理之前一般会做一个具体启动时间到截止时间范围编码的映射。除了这种转换之外还会有一些白名单、黑名单之类的过滤转换。
3维表影射
因为客户端并不能拿到业务方需要分析的所有数据维度如用户的性别、职业等内容因此在真实分析之前我们可以通过维表映射将日志埋点中的用户 ID 映射成业务层面的具体属性来进行后续的分析。
4UID 的滤重
UID 滤重的指标有两种一种是 PV 指标一种是 UV 指标。
UV 指标在做具体的计算之前要做一步 UID 去重。所谓 UID 去重就是指检查这个 ID 在一定时间范围内有没有出现过如果出现过那么这条记录就必须丢弃了。UV 是有时间周期的概念的比如日 UV、小时 UV、分钟 UV、月 UV 等。
5指标聚合
在完成了上述的所有过程后终于要进行指标的计算了。计算的方式包括求和、平均值、最大值、最小值、95 百分位。
6结果写出
就是指把计算的指标的结果输出到各种存储或者通过接口发送给 mPaaS 的客户。目前我们的计算方式有三大类实时计算、即时计算和离线计算。下面我会介绍这三种计算方式。
实时计算实时计算模式接收到日志后模型立即开始进行计算数据结果将在N分钟(N2)内产出延迟非常的低。
推荐用作实时计算的技术选型包括1) Flink 2) Spark 3) Storm (阿里做的 JStorm 4) akka其中 akka 适合用作业务逻辑较轻的实时监控和报警关键的业务大盘、日志翻译回放这些都用 Flink 做比较好。
简单总结如下
实时计算的优势是产出结果速度快、资源消耗少、灵活度中等 实时计算的劣势是学习曲线相对陡峭、维护成本较高、配置复杂度高。
离线计算离线计算模式接收到日志后直接保存下来不做任何处理。待日志量积攒一段时间后模型可进行一次性处理多日或者多月的日志数据。
推荐用作实时计算的技术选型包括: 1) Flink 2) Spark 3) Hive 4) Hadoop大家看到了 FLINKSPARK 也出现在了实时模型的推荐技术选择中。这两个技术呢分别从不同的起点出发达到了相同的终点。
Flink 一开始是只做实时计算的后来他开始提供批量离线计算能力Spark 则正好相反。我们目前呢还是充分利用每个技术栈的最大优势离线还是选择 Spark而不是 Flink。在这里多说两句之前有一个经典架构是 “Lambda”模型是指实时计算的结果要在离线里面再算一遍这是因为之前总会出现实时计算丢数据、计算不准的情况所以实时计算出来的结果只是用来观察一个趋势再等第二天用离线的结果做补充从而确保业务方能够看到准确的数据。但是在谷歌的 data-flow 计算模型的论文出来之后目前市面上的实时计算引擎都具备了 exactly-once 的计算能力换句话说实时计算不会再出现丢数据以及计算不准的问题了。目前虽然还有“Lambda”模型即数据会流向实时计算、离线计算两个引擎但是离线不再是为实时计算做补充而是为了充分利用它的性能计算多日、多月的指标。
简单总结如下
离线计算的优势是 计算性能高、学习难度低 离线计算的劣势是 消耗资源大、延迟高、灵活度偏低。
即时计算即时计算模式接收到日志后只做简单的预处理比如日志切分之后就直接入库。在需要展示界面的时候根据用户配置的过滤和聚合规则即时进行数据处理。
推荐用作即时计算的的技术选型包括: Clickhouse (来自俄罗斯 yandex)、Apache Druid (来自 MetaMarket)、 Pinot (来自 LinkedIn)。支付宝内部将即时计算模型应用到下钻分析、漏斗分析这些场景中有时候也直接把它当做 OLAP 数据库使用。
简单总结如下
即时计算的优势是超高灵活度、任务维度UV聚合、无限下钻能力、交付式的查询延迟(15s内)、学习成本低 即时计算的劣势是资源消耗巨大、延迟中等无法用于做实时监控与报警、维度成本高结构复杂。 这是目前支付宝内部的一个即时计算框架的技术架构图。从图中可以看出来目前即时计算的技术架构包括用来接收数据写入的实时日志节点Read-time Nodes、用于存储历史数据的深度存储HDFS、AFS、OSS 等多种类型、用来对历史数据一天以前的数据提供查询分析能力的历史节点historical。这个计算框架完全的支持 MySQL 协议用户可以直接用 MySQL 客户端对其进行操作。还有一个重要特性是他可以对任意的外部数据联合进行分析。
日志处理模型我们再总结一下三种计算模式
实时计算模型数据摄入后立即按照预定规则执行计算并在N分钟内产出需要的计算结果。 适用场景: 实时监控预警、链路追踪 优势: 消耗资源少、产出速度快 劣势: 配置复杂度高灵活度低 离线计算模型数据摄入后积攒N 小时/天 后按照预定规则进行批量处理。 适用场景: 用户分群、数据集市 优势:性能高、学习成本低 劣势: 延迟高、灵活度低 即时计算模型数据摄入后只做简单的预处理立即入库待查询时根据查询需求实时计算出指标。 适用场景: 下钻分析、漏斗分析 优势: 灵活度高、学习成本低 劣势: 资源消耗巨大、延迟中 希望大家能够根据我们的推荐选择适合的技术栈。
动态埋点
说完了我们目前的埋点类型、埋点计算模型下面来说一下我们目前在内部使用的下一代埋点框架动态埋点。 我们先针对以上四个问题进行思路串联每个问题我也给出了相应的思路和解决办法。那么这些答案是针对以上问题的最优解或者唯一解吗很显然不是因为这些解法都会带来开发量。而对于客户端来说新的开发量就要发布版本同时开发新的埋点也可能会导致 App 内部的埋点臃肿不堪。 什么是动态埋点呢有三个核心概念1) 埋点集、2) 动态埋点上报规则、3) 指标计算动态配置。
有了以上三项能力和配置我们便可以根据现有的埋点集来配置某个链路的监控埋点并依据这个复杂埋点来定义具体的指标的计算规则从而做到不用增加开发量同样可以快速监控新的指标的效果。不仅如此我们还能够让埋点变成一种通用的资源让大家更好地去使用它而不是无谓地增加埋点使得代码变得更臃肿。 让我们一起看一下动态埋点框架的一些 UI 交付图。 相应的我们再对焦看一下支付宝埋点相关的应用服务实时日志拉取。其中它的主要技术框架包括了 mPaaS 里面的 MPS (消息推送)、MSS(数据同步)、以及日志网关。这是因为蚂蚁系 App 会与 MPS (安卓系统)、MSS (苹果系统) 保持长连接在需要实时拉取日志的时候用户可以在 mPaaS 的控制台上面通过这两个渠道下发指令然后客户端就会把加密的明细日志全部上报到日志网关。 这是实时日志拉取的界面操作展示图。 针对于非常重要的性能指标: 闪退、卡顿、卡死 mPaaS 根据多年经验准备了对应的大盘。如图所示上半部分是每分钟的闪退数下面是我们根据闪退分类算法梳理出来的各个闪退分类情况针对每个分类大盘里我们还能看到具体的设备分布情况。 最后让我们从逻辑结构上再梳理一下 mPaaS 的服务端结构。mPaaS 包含五个核心组件:
1) MGS网关服务将客户端的请求转发到业务服务器.
2) MDS发布服务为客户端提供多种资源的多种灰度策略发布能力。
3) MPS MSS消息推送和数据同步服务以长连接为基础来提供数据下发能力。
4) MAS,分析服务也是今天讲解的重点以日志埋点为基础的分析能力。
原文链接 本文为云栖社区原创内容未经允许不得转载。
