移动域全链路可观测架构和关键技术
作者：执水
出品：大淘宝技术
本文侧重阐述团队对移动领域全链路技术理念的原创性引入，整篇约1.2万字、阅读需要15分钟，读者将收获移动技术域体验优化的思路转变，以及软件定义体验的沉淀和研发实践。
App现有架构挑战
2013年开始All in无线到如今，集团移动技术发展十余年，历经几个关键阶段，
第一阶段，解决大规模业务并发研发的痛点，定义了Atlas（容器化框架, 提供组件解耦、动态性等支持）架构； 第二阶段，建设ACCS（淘宝无线全双工、低延时、高安全的通道服务）长连双工加密网络能力，补齐端到端互 操作移动服务能力追赶行业；
第三阶段，面向业务特性建设Weex、小程序等动态化研发框架，移动技术进入动态化跨平台时期。
中后期通过移动小组机制进行各BU拉通和能力共建。自此，移动基础设施基本成型，各个领域各自沉淀若干组做到能力复用，App基本形成上层业务、中间研发框架或容器、基础能力三层的架构。我们团队作为无线端侧基础设施的承建方，过去重点是负责集团移动端的基础能力建设，近年来，团队重点深入淘宝业务场景展开性能优化，通过体验优化项目横向剖析App架构和及相关调用链路，感受到集团App普遍存在如下共性问题：
(图1 淘宝App架构挑战)
运维排查效率低下：首先是监控阶段，多数问题无监控或者监控上报后的信息无法支撑更有效的分析，需要依赖日志进行问题排查；其次是没有日志的问题，发生异常时并不会主动上传日志，需要手动捞取，用户不在线更是拉取不到日志；拉取到日志后，还会继续遇到日志读不懂的问题问题；跟服务端有关的链路，还会遇到服务端鹰眼日志只保存5分钟的问题，经过这样一轮下来，基本时间已经过去半天...
端到端追踪不完整：一个完整的业务链路，流量会穿越端到端多层，以一次下单为例，通过客户端所触发的网络请求到达服务器之后，会经过若干客户端模块处理、触发N次后端应用调用以及历经移动网络的不稳定性，试想一下，这些调用中有哪些出问题会影响这次下单交易，有哪些步骤会拖慢整个处理流程、请求没返回不清楚是服务端问题还是网络问题，假如各调用全链路性能定义不清，意味着各层问题得不到充分暴露，这些因素都是需要考虑的，加上端侧天然异步调用，导致各阶段度量和全链路打通存在重大挑战，目前现状就是客户端各层没有统一调用规范，并且缺乏拓扑结构，无法还原调用链路，导致端到端无法追踪。
优化缺少统一口径：过去因为各研发框架性能口径自闭环，不管是客户端原生技术，还是跨平台技术都是面向技术视角统一采集通用的技术口径，这种情况会天然导致各业务实现和表现差异巨大，通俗说就是不接近用户体感，会导致线上的数据难以反应真实情况及优劣趋势，长久以来，淘宝的体验也一直在劣化，每年基本都要靠运动式方式来搞体验优化，无法常态化保持。
移动Paas流程赋能成本：大量的SDK组件输出集团各BU后，基础能力嵌入到不同的App宿主环境后，同样会遇 到上面提到的几类问题，对各BU同学来说，基础设施更是黑盒，如果问题涉及到基础设施，排查过程更加艰辛， 加上没有现有的工具可以自助诊断问题在哪，遇到问题只能过来咨询，各种拉群拉人，导致答疑成本居高不下。
以上是从APP结构的角度对当前客户端在运维排查、度量监控、全链路优化等方面的不足进行的一些思考，也是我们后续的发力方向。
带你读《2022技术人的百宝黑皮书》——移动域全链路可观测架构和关键技术（2）https://developer.aliyun.com/article/1340967?groupCode=taobaotech
