移动域全链路可观测架构和关键技术

本文侧重阐述团队对移动领域全链路技术理念的原创性引入，整篇约1.2万字、阅读需要15分钟，读者将收获移动技术域体验优化的思路转变，以及软件定义体验的沉淀和研发实践。

App现有架构挑战

2013年开始All in无线到如今，集团移动技术发展十余年，历经几个关键阶段，

• 第一阶段，解决大规模业务并发研发的痛点，定义了Atlas（容器化框架, 提供组件解耦、动态性等支持）架构；

• 第二阶段，建设ACCS（淘宝无线全双工、低延时、高安全的通道服务）长连双工加密网络能力，补齐端到端互操作移动服务能力追赶行业；

• 第三阶段，面向业务特性建设Weex、小程序等动态化研发框架，移动技术进入动态化跨平台时期。

中后期通过移动小组机制进行各BU拉通和能力共建。自此，移动基础设施基本成型，各个领域各自沉淀若干组做到能力复用，App基本形成上层业务、中间研发框架或容器、基础能力三层的架构。我们团队作为无线端侧基础设施的承建方，过去重点是负责集团移动端的基础能力建设，近年来，团队重点深入淘宝业务场景展开性能优化，通过体验优化项目横向剖析App架构和及相关调用链路，感受到集团App普遍存在如下共性问题： (图1 淘宝App架构挑战)

• 运维排查效率低下：首先是监控阶段，多数问题无监控或者监控上报后的信息无法支撑更有效的分析，需要依赖日志进行问题排查；其次是没有日志的问题，发生异常时并不会主动上传日志，需要手动捞取，用户不在线更是拉取不到日志；拉取到日志后，还会继续遇到日志读不懂的问题问题；跟服务端有关的链路，还会遇到服务端鹰眼日志只保存5分钟的问题，经过这样一轮下来，基本时间已经过去半天...

• 端到端追踪不完整：一个完整的业务链路，流量会穿越端到端多层，以一次下单为例，通过客户端所触发的网络请求到达服务器之后，会经过若干客户端模块处理、触发N次后端应用调用以及历经移动网络的不稳定性，试想一下，这些调用中有哪些出问题会影响这次下单交易，有哪些步骤会拖慢整个处理流程、请求没返回不清楚是服务端问题还是网络问题，假如各调用全链路性能定义不清，意味着各层问题得不到充分暴露，这些因素都是需要考虑的，加上端侧天然异步调用，导致各阶段度量和全链路打通存在重大挑战，目前现状就是客户端各层没有统一调用规范，并且缺乏拓扑结构，无法还原调用链路，导致端到端无法追踪。

• 优化缺少统一口径：过去因为各研发框架性能口径自闭环，不管是客户端原生技术，还是跨平台技术都是面向技术视角统一采集通用的技术口径，这种情况会天然导致各业务实现和表现差异巨大，通俗说就是不接近用户体感，会导致线上的数据难以反应真实情况及优劣趋势，长久以来，淘宝的体验也一直在劣化，每年基本都要靠运动式方式来搞体验优化，无法常态化保持。

• 移动Paas流程赋能成本：大量的SDK组件输出集团各BU后，基础能力嵌入到不同的App宿主环境后，同样会遇到上面提到的几类问题，对各BU同学来说，基础设施更是黑盒，如果问题涉及到基础设施，排查过程更加艰辛，加上没有现有的工具可以自助诊断问题在哪，遇到问题只能过来咨询，各种拉群拉人，导致答疑成本居高不下。

以上是从APP结构的角度对当前客户端在运维排查、度量监控、全链路优化等方面的不足进行的一些思考，也是我们后续的发力方向。

可观测体系

▐ 监控到可观测性的演变

可观测性是一套理念系统，没有对技术实现的具体要求，重点是通过引入该理念，将理念应用到我们的业务迭代和问题洞察中。传统的运维可能只能给我们带来最顶层的告警和异常的概况，当需要更深层次的错误信息定位的时候，往往会通过建群拉人，然后先通过人肉找寻问题的特征，甚至是某个模块的开发承担起分析各个模块的依赖关系等的工作，问题处理基本涉及3个角色以上（业务、测试、开发、架构、平台等）。

相比传统的监控，可观测性能够通过结合数据，并且将数据有机联系在一起，产生更好的连接，帮助我们更好的观察系统的运行状况，快速定位和解决问题。「监控告诉我们系统的哪些部分是工作的，而可观测性告诉我们那里为什么不工作了」，下图2说明了两者之间的关系，监控侧重宏观大盘展现，而可观测性包含了传统监控的范畴。

(图2 监控和可观测的关系)

从上图来看，核心还是观察各个模块以及关键调用和依赖等的输出，基于这些输出来判断整体的工作状态，业界通常会把这些关键点总结为Traces、Loggings、Metrics。

▐ 可观测性关键数据

(图3 可观测性关键数据)

结合Traces、Loggings、Metrics的定义和淘宝现有情况，做了一些解读：

• Loggings（日志）：基于现有TLOG（无线端到端日志系统）日志通道，展现的是App运行时产生的事件或者程序在执行的过程中间产生的一些日志，可以详细解释系统的运行状态，如页面跳转、请求日志、全局CPU、内存使用等信息，多数日志是没有实现串联的，现在引入结构化的调用链路日志后，日志在调用链场景结构化后其实可以转变为Trace，支撑单机排查。

• Metrics（指标）：是聚合后的数值，偏宏观大盘使用，对于问题定位缺乏细节展示，一般有各种维度、指标，Metrics数据量一般很大，需要针对场景做一些采样控制。

• Traces（追踪）：是最标准的调用日志，除了定义了调用的父子关系外（一般通过TraceID、SpanID），一般还会定义操作的服务、方法、属性、状态、耗时等详细信息，通过Trace能够代替一部分Logs的功能，长期看通过Trace的聚合也能得到每个模块、方法的Metrics度量指标，但日志存储大，成本高。

▐ 全链路可观测性架构

上述可观测体系理念在后端有一些实践落地，但回归到移动领域的特性和现状，有种种问题如下：

• 调用规范的问题：与云端的差异是端侧完全异步，异步API极其丰富，且没有统一调用规范。

• 多技术域的问题：研发框架数量众多，能力对外黑盒，如何串联存在大量难以感知的成本。

• 端云差异的问题：端侧的海量分布式设备，意味着可观测模式的挑战与服务端也有本质差异，logging与metrics在服务端可以基于一套体系完全上报实现，但单机埋点和日志量差异极大，这也是端侧埋点系统和日志系统分离的原因，端侧则需要实现如何兼顾海量设备的单机问题排查和大数据下的指标趋势定义。

• 端云关联的问题：端到端现实一直是割裂状态，以端侧为视角如何更好感知后端状态，如何做关联，如怎么持续推进serverRT（后端请求调用耗时）从IDC（互联网数据中心）到CDN覆盖，端侧全链路标识如何让后端也感知。

因此，我们需要围绕以上这些问题对移动技术领域全链路进行定义，并建立起相关领域级的分析能力和好的评价标准，才能更深刻的洞察移动端的问题所在，才能在问题排查和性能度量领域持续服务好集团各App以及跨域的问题。

(图4 全链路可观测架构定义设想)

• 数据层：定义指标规范和采集方案，基于Opentracing（分布式跟踪规范）数据上报。

• 领域层：围绕问题发现到问题定位、性能持续优化体系、技术升级沉淀几方面演进。

• 平台层：沉淀集团&竞对视角的比对，结合线上线下指标，引入厂商视角，驱动App性能提升。

• 业务层：全链路视角，打通端到端，除了客户端同学，还可以服务不同技术栈跨域的研发人员。

回顾全链路可观测项目的目标，我们设定为“打造全链路可观测体系，改善性能并驱动业务体验改善，提升问题定位效率”，后续章节会重点讲解每一层的实践。

移动端opentracing可观测架构

▐ 全链路构成

(图5 端到端情况、详情场景分层图)

端到端现有链路长，端侧存在各类研发框架和能力，虽然后端调用链路明确，但从全链路视角看，并没有与端侧打通。以用户浏览详情动线为例，一次首屏打开，会触发奥创、MTOP（无线网关）、DX三个模块不同的调用时序，不同的模块有各自的处理过程，不同阶段有不同的耗时和状态（成功、失败等）；接着继续看滑动，可以看到模块的调用时序组合又不一样，因此不同场景下可以由若干要素随机组合，需要根据用户实际场景，划分若干维度来定义全链路：

• 场景定义：一次用户操作为一个场景，如点击、滑动都是单独的场景，场景也可以是多个单个场景的组合。

• 能力分层：不同场景，有业务类，框架类、容器类、请求类的调用，可以对每个领域进行分层。

• 阶段定义：不同分层有各自的阶段。如框架类有4个本地阶段，而请求类可以包含后端服务端处理阶段。

• 用户动线：一次动线由若干场景组成。

全链路，就是把复杂的大调用分解为有限个结构化的小调用，并且**可以衍生出各种case：**

• 「单场景+单阶段」的组合全链路

• 「单场景+若干分层+若干阶段」组合的全链路

• 「若干场景+若干分层+若干阶段」组合的全链路

• ... ...

▐ Falco-基于OpenTracing模型

全链路为了支持Logs + Metrics + Tracing 行业标准，引入分布式调用规范opentracing协议，在上述的客户端架构上进行二次建模（后续简称为Falco）。OpenTracing 规范是 Falco 的模型基础，以下不再列举，完整可参考OpenTracing设计规范，https://opentracing.io/docs/overview/。Falco定义了端侧领域的调用链追踪模型，主要表结构如下： (图6 Falco数据表模型)

• span公共头：黄色部分，对应OpenTracing规范的Span基础属性。

• scene：对应OpenTracing的baggage部分，会从根span往下透传，存放业务场景，命名规则为「业务标识_行为」。比如详情首屏为ProductDetail_FirstScreen、详情刷新为ProductDetail_Refresh。

• layer: 对应OpenTracing的Tags部分，定义了层的概念，目前划分为业务层、容器层和能力层。处理业务逻辑的模块归属业务层，命名为business；提供视图容器归属容器&框架层，如DX、Weex都是，命名为frameworkContainer；仅提供一个原子能力的模块，归属能力层，命名为ability，如mtop、picture，层可应用于对同层同能力的不同模块进行横向性能对比。

• stages：对应OpenTracing的Tags部分，表示一次模块调用包含的阶段。每一层基于领域模型划分了关键阶段，目的是让同层的不同模块具备一致的对比口径，如DX和TNode对比，可以从预处理耗时、解析耗时、渲染耗时衡量彼此优劣。比如预处理阶段名为preProcessStart，也可以自定义。

• module：对应OpenTracing的Tags部分，更多的是逻辑模块。比如 DX、mtop、图片库、网络库。

• Logs：对应OpenTracing的Logs部分，日志仅记录到TLog，不输出到UT埋点。

▐ Falco-关键要点

(图7 Falco关键实现)

1. 端侧traceID：满足唯一性、生成快、可扩展、可读、长度短等原则生成。

2. 调用&还原抽象：由traceID和span多级序列号一路透传，明确上下游关系。

3. 端到端串联：核心解决云端串联的问题，端侧ID透传到服务端，服务端存放和鹰眼ID的映射关系；接入层返回鹰眼ID，端侧全链路模型存在鹰眼ID，通过这样的双向映射关系，我们能知道一个未返回的请求究竟是因为在网络阶段没有成功、还是没有到达接入层、或者是业务服务没有返回，从而将耳熟能详、粗粒度的网络问题变得可定义和可解释

4. 分层度量：核心目的是让同层的不同模块具备一致的对比口径，支撑框架升级后的性能横向对比，思路为抽象客户端领域模型，如以框架类为例子，虽然框架不同，但一些关键调用和解析是一致的，因此可以抽象成为标准阶段，其它类似。

5. 结构化埋点：首先采用列式存储，利于大数据集的数据聚合操作和数据压缩，减少数据量；其次，业务+场景+阶段沉淀到一张表中，方便关联查询。

6. 基于Falco的领域问题沉淀：包括复杂问题的关键定义、追踪问题的线索型日志、某些特殊诉求的埋点。所有领域问题的信息被结构化沉淀到Falco，领域技术开发者也可以基于沉淀的领域信息持续开展分析能力的建设，只有实现数据的有效性供给和领域性解释合一，才能定义和解决更深层次的问题。

(图8 Falco领域问题模型)

基于Falco的运维实践

运维的范畴极为广泛，围绕问题发现、问题接手、定位分析、问题修复关键流程，从海量设备的指标观测、告警，到单机排查、日志分析等，大家都知道要这么做，里面每个流程都涉及很多能力的建设，但实际执行起来很难做，各方也不认可，淘宝客户端一直以来存在指标准确性和日志拉取效率低下的问题。如APM性能指标为例，淘宝App过去很多指标不准，业务同学不认可，不能指导实际优化。本章节会从重点分享下淘宝App在指标准确性和日志拉取效率方面的相关优化实践。

(图9 问题扭转用户动线以及运维系统)

▐ 宏观指标体系

以端性能横向战役为契机，基于用户体感的体验，APM开启了相关升级工作，核心涉及启动、外链以及各业务场景下的可视可交互指标，如何做到让指标对应的终点更贴近用户体感，主要有以下一些工作：

• 8060算法的升级：视觉有用的元素提取出来计算（如图片和文字），剔除用户不能感知的元素（空白控件、兜底图），如制定视图可视规范，满足图片库、鱼骨图等自定义控件打标

• H5领域：支持UC 页面元素可视可交互以及前端 JSTracker（事件埋点框架）回溯算法，与H5页面可视算法打通

• 深入复杂的场景：制定自定义框架可视规范，打通 Flutter 、TNode（动态化研发框架）并校准等各类研发框架，8060算法交由各研发框架来实现。

• 外链领域：打通H5页面口径，重新定义外链离开等负向动作。

以启动为例，APM 在 校准后，包含了图片上屏等阶段后，数据虽然上涨了，但更符合业务方诉求

(图10 校准后启动数据趋势)

以外链为例，打通H5后，新口径也出现了上涨，但更符合体感

(图11 校准后外链前后口径数据对比)

基于此战役，已实现打通若干研发框架可视指标和校正工作。

▐ 单机排查体系

对于问题排查，目前核心还是基于TLOG，本次仅围绕用户问题排查动线中日志上报、日志分析、定位诊断关键环节遇到的问题(无日志、日志看不懂、定位难等)，介绍运维排查体系为提升问题定位效率做的努力。 (图12 单机排查问题定位核心功能)

• 提升日志上传成功率，从几个方面保障在排查问题时有日志供应过来，一是内置日志主动上传能力，在核心场景或问题反馈多时机触发，提高日志触达率，如舆情反馈、新功能上线发生异常时；二对TLOG能力进行升级，涉及到分片策略、重试、日志治理等优化，解决以往用户反馈较多日志上传的时效问题；最后是收集各类异常信息，作为快照，通过MTOP链路旁路上报，辅助还原现场。

• 提升日志的定位效率，首先对日志做分类，如区分出页面日志、全链路日志支持快速筛选过滤；接着是打通各个场景的全链路调用拓扑结构，目的是可以快速看出问题发生在哪个节点，以便快速分发处理；最后结构化错误、慢、UI卡等问题，原则是将领域问题的解释权交给领域，比如卡顿日志有几类，如APM冻帧、ANR、主线程卡顿等；业务类有请求失败、请求RT大于xx时间、页面白屏等，通过各领域的能力 对接来提升问题的快速诊断定位能力。

• 全链路追踪能力建设，鹰眼（分布式跟踪系统在阿里后端的实现）接入业务众多，日志量大，不可避免要做日志的采样，对于没有命中采样的调用，缓存只有5分钟，需要想办法在5分钟内通知鹰眼保持更久的时间。第一阶段，后端解析服务会解析出调用链的鹰眼ID，通知鹰眼服务存储对应的trace日志，成功通知后可以存3天；第二阶段感知网关发生异常，取出鹰眼ID，通知鹰眼存储将存储前置；第三阶段，类似场景追踪，获取核心场景的鹰眼trace日志，尝试放在摩天轮平台上存储。第一阶段已经上线，可以做到关联跳转鹰眼平台，一般从问题发生到排查都过了5分钟，因此成功率不高，还需要结合2、3阶段进一步提升成功率，正在规划开发中。

• 平台能力的建设，基于端侧全链路日志做解析，在可视化方面，通过结构化展示全链路日志内容，方便快速部分节点的异常；还有就是基于结构化日志，对全链路日志中的耗时异常、接口报错、数据大小异常等问题进行快速诊断。

以上是今年在运维做的一些尝试，目的是希望可以通过技术升级，在排查领域用技术赋能代替流程赋能。 下面接着继续给大家展示下淘宝的实践和集团其它app接入的效果。

▐ 全链路运维实践

• 淘宝卡顿问题排查

内部同事反馈在海外用淘宝App，出现卡、部分页面打不开等现象，经过上诉排查过程，提取到TLOG日志后。

• 通过“全链路可视化”功能(图10)，可以看到H5页面spanID为0.1的network状态为“失败”，导致页面打不开。
• 通过“全链路诊断”耗时异常功能（图11），可以看到大量network耗时分布在2s、3s+，有的甚至8s+，network阶段发生在请求调用阶段(传输)，与海外用户访问到阿里的CDN节点慢相关。

(图13 全链路可视化功能)

(图14 全链路卡顿诊断功能)

• 饿了么主链路接入

冷启全链路

(图15 饿了么全链路视图-冷启全链路)

店铺全链路

(图16 饿了么全链路视图-店铺全链路)

基于Falco的优化实践

▐ 新指标体系

现在重点介绍下我们怎么围绕Falco可观测模型，从端到端全链路视角构建线上性能基线，用数据驱动淘宝App体验持续改善，首先就是数据指标体系的构建，主要有如下几点：

• 指标定义和规范：贴近用户的感受，围绕用户点击到内容呈现到滑动页面的操作动线来定义相关指标，重点采集页面打开、内容上屏、点击响应、滑动等技术场景，如内容展现有页面可视可交互、图片上屏指标，滑动有滑动帧率(手指)、冻帧等指标来衡量。

• 指标度量方案：原则是不同领域的指标交由对应领域负责，以卡顿指标为例，可以是厂商的口径(苹果MetricKit)、也可以是自建的口径(APM的主线程卡顿/ANR等)、还可以是不同业务域的自定义指标（场景全链路），如MTOP请求失败、详情头图上屏等。

• 指标组成：由线上集合指标和线下集合指标组成，基于线上和线下数据和相关规范，立足用户视角和竞对情况牵引APP体验优化。

（图17 App性能指标体系）

• APM为例

定义了滑动相关的指标如下：

(图18 APM相关指标定义方案)

• 场景全链路为例

某个具体业务下，对于用户的一次交互行为，从发起响应到结束响应，从前端到服务端到客户端的完整调用链路，详情基于场景全链路下的详情首屏指标：

(图19 场景全链路-详情首屏定义)

还有其他等等... ...

可以看到，整个数据体系是多元化的，后续整个性能体验数据会有一个标准的输出，敬请期待。

▐ 新指标体系下的优化

FY22 平台技术围绕全链路视角，以体验为出口，深入业务开展摸排优化，围绕指标定义并拆解问题域，面向用户真实体感开展各大专项优化。我们自底向上一一介绍，通用的网络层策略优化，如何围绕请求周期，从连通性->传输层->超时策略提升；面向用户体感的有技术策略升级，如网关和图片的优化；面向业务场景的技术改造，会场框架的预处理预加载、安全保镖的轻量化实践，甚至是业务上的体验分级，如首页信息流低端机下不启用端智能，下面会重点介绍相关实践。

（图20 淘宝App全链路优化技术方案）

• 请求精简提速-极简调用实践

以MTOP请求作为一个场景，链路主要涉及「MTOP到网络库」的交互，通过对全链路线程模型现状分析，从MTOP发起到网络层接收到会几点会导致请求慢：、

• 数据拷贝多：现有网络层机制，网络库存在hook拦截处理，基于NSURLConnection + "URL Loading System" 转发到网络库进行网络传输，涉及多次数据拷贝，中转拦截处理非常耗时。

• 线程切换多：线程模型过于复杂，完成一次请求频繁切换线程。

• 异步转同步：原有请求使用一个队列 NSOperationQueue 来处理任务，底层维护的这个队列把请求和响应绑在一起，使得发送之后要等待响应结果回来才会释放，"HTTP Operation" 占住完整的一个HTTP收发过程的全部IO，违背了网络请求的并行性，operation queue容易打满阻塞。

以上几点问题，在大批量请求、系统资源竞争激烈场景下下(冷启动，几十个请求一拥而上)，更为明显。 （图21 线程模型优化前后-极简调用）

改造方案，通过MTOP直接调用网络库接口来获得较大性能体验提升

• 简化线程模型: 跳过系统URL Loading System hook机制，完成收发数据线程切换，减少线程切换。

• 避免弱网阻塞：数据包Sending 与 Receiving 拆分处理，空口长RT不影响 I/O 并发容量；

• 汰换废弃API：升级老旧NSURLConnection 到直接调用 网络库API。

数据效果：可以看到，在系统资源更为紧张环境下，如低端机上优化幅度更为明显。

（图22 极简调用AB优化幅度）

• 弱网策略优化-Android网络多通道实践

在WIFI信号差、弱网环境下，有时候多次重试对成功率提升效果并不明显。系统提供了一种能力，允许设备在WIFI环境下将请求切换蜂窝网卡的能力。网络应用层可以利用该技术，减少请求的超时等一类错误，提升请求的成功率。

在Android 21之后，系统提供了新的获取网络对象的方式，即使设备当前具有通过以太网的数据连接，应用程序也可以使用此方法来获取连接的蜂窝网络。所以，当用户设备同时存在WIFI和蜂窝网络的情况下，可以在特定策略下将不同请求同时调度到以太网和蜂窝网两个网卡通道上，实现网络加速。

核心改动点：

• 方案前提：当前Wi-Fi网络环境是否支持蜂窝网络。

• 触发时机：当请求发出超过一定时间未返回数据后，触发切换蜂窝网络重试的请求，原先流程的请求不中断，使用优先返回的通道的请求响应，晚返回的会取消。

• 时间控制：根据特定场景Orange配置，后续还需要灵活根据网络强弱来动态调整。

• 产品形态&合规上：使用时给用户透出文案 “正在同时使用WIFI和移动网络改善浏览体验，可在设置-通用里关闭”，弹出策略为 每次启动首次功能触发。

（图23 Android多通道网络能力优化+用户合规授权）

数据效果：在网络资源竞争剧烈的情况下，WiFi+蜂窝双通道网络场景下，长尾和超时率优化较为明显，AB数据，首页API， P99/P999分位性能分别提升23%/63%，错误率减少1.19‰，首页图片， P99/P999分位性能分别提升12%/58%，错误率减少0.41‰。

• 技术策略分级-图片分级实践

不同设备性能千差万别，业务的复杂度也越来越高，很多业务无法在低端设备上让用户体验到应有的效果，反而会带来卡顿等不良的体验。以往会通过“延迟、并发、预加载”等手段来优化性能，但只是规避了问题，核心链路仍然要要直面关键的调用耗时。所以，我们需要对业务做体验分级，基于对业务流程的分级处理，让高端设备体验最完美复杂的流程，低端设备也能顺滑的使用核心功能，理想是期望实现 用户体验 & 业务核心指标 的双高，退一步来说，让部分功能有损(不影响核心业务指标)的情况下，让性能体验更佳，初步的设想是希望分2步走来实现：

• 第一阶段，业务分级需要丰富的策略库和判断条件来实现分级，我们将在核心组件上沉淀这部分通用能力，帮助业务快速的实现业务分级能力。
• 第二阶段，随着大量的业务都接入了分级能力，积累了大量的业务分级策略以及AB数据，那么可以去做单点业务分级策略的推荐&最优化，实现大量相似的业务可以快速复用，提升效率。

传统CDN适配规则会根据网络、view大小、系统等因素动态拼装获取「最佳」的图片尺寸来减少网络带宽、位图内存占用，提升设备图片加载体验，本次设备分级视角，并且会基于UED给出的规范，实现压缩参数可配置，扩展原有CDN适配规则，实现不同机型的图片分级策略，通过该能力，可以让图片的尺寸进一步缩小，加快图片上屏。 （图24 图片设备分级规则）

• 轻量化链路架构-安全免签实践

外链拉端链路从启动到海关请求再到落地页加载（主请求仍是MTOP），涉及多次安全加签，加签属于CPU密集型任务，低端机长尾明显，拉端耗时过长会导致流量跳失，FY22 S1 在巨浪业务上，拉端链路做了很多性能优化，优化性能可以带来跳失率的降低，目前性能大头海关请求，海关请求安全加签耗时占比高，因此希望跳过安全加签，业务可以根据情况使用，提升进端的流量价值，链路涉及到MTOP、Aserver（统一接入层）、安全多方改造： （图25 安全免签架构变化）

• 网关协议升级：协议升级支持免签，对外提供设置免签接口，若业务API设置免签，携带头到网络库。

• AMDC调度服务：稳定性考虑，目前短期会先通过AMDC（无线网络策略调度服务）调度到线上安全生产环境，因此AMDC调度模块会根据描述标识判断是否返回客户端免签vip，功能稳定性后，会灵活调度到线上主站环境。

• 验签模块迁移：安全延签能力前置在AServer接入层，基于运维成本考虑，能力会从Aserver统一迁移到安全，后续Aserver不会有延签模块，安全会根据API/header特征 决定启用验签等功能。

• MTOP免签错误重试：免签情况下，MTOP层遇到非法签名请求失败会触发降级老链路，保障用户体验。

总结&展望

▐ 总结

本文主要阐述了面对移动端现有挑战，如何通过实现调用链路Tracing、标准Logging及场景化追踪完成可观测能力的建设，并基于全链路视角和新可观测能力，打造全链路运维体系和性能持续优化体系，补齐移动端长久缺失的调用链追踪能力、解决复杂调用场景下问题的快速定位、改变过去拉群人肉排查的低效过程，开始了流程赋能到技术赋能的转变，并围绕该能力构建全链路Metrics指标，打造全链路性能指标体系，深入业务场景展开治理，升级平台技术能力，用数据驱动业务体验改善和体验的长效追踪。

▐ 不足

虽然淘宝App陆续在接入各类场景，但离15分钟内定位出问题还有不小的差距，相关的卡点还较多，如日志上报成功率、服务端日志获取的有效性、问题定位效率的提升、接入源头的数据质量检验产品化&技术化、领域技术方对问题的认识和持续沉淀结构化信息，最后就是整个产品的用户体验，需要持续优化。

▐ 展望

延续阿里巴巴移动技术小组的移动原生技术理念，我们要做好技术做好体验，需深入移动域腹地，直面东西向多研发框架、南北向端到端全链路等领域挑战。18年体验优化一期，我们在请求领域就引入类似理念并开展尝试，直到如今寻求到合适的结构化理论基础，并通过立足移动端特性开展深入实践，持续做厚领域问题的定义和解决模型。希望打造出移动域可观测技术体系、形成架构沉淀。

参考资料

1. 可观测性技术大会 https://ppt.infoq.cn/list/qconsh2021
2. OpenTracing设计规范 https://opentracing.io/docs/overview/
3. 万字破解云原生可观测性 https://xie.infoq.cn/article/598fd893709f01ae751dbd7b8?utm_medium=article
4. Apache APISIX https://www.apiseven.com/zh/blog/why-we-need-Apache-APISIX
5. Mesh: SideCar 是什么 https://cloud.tencent.com/developer/article/1706553
6. gatner APM 分析报告 https://www.gartner.com/doc/reprints?id=1-25SQ95K7&ct=210414&st=sb
7. New Relic APM https://blog.csdn.net/yiyihuazi/article/details/107974539
8. dynatrace https://www.dynatrace.cn/platform/application-performance-management/
9. OpenTelemetry 简析 https://zhuanlan.zhihu.com/p/361652744
10. AppDynamics https://www.appdynamics.com/
11. SkyWalking 分布式追踪系统 https://www.jianshu.com/p/2fd56627a3cf