本文作者---于闲
背景简介
背景
- 从业务划分上看，在非渲染团队眼中“渲染”是工具线上的一个独立工具，如下图1。实际上的"渲染"是关联整个工具线的渲染出口业务，如下图2。而这种理解导致了只要是渲染出现了问题，全都先抛给渲染中台，终究是渲染一个人承受了所有。
- 微服务架构下拆分的服务多链路长，造成服务间关系复杂，业务边界不清晰。整条渲染链路涉及的服务达数十个。下图是一个渲染任务的hunter调用链，不完整显示就有500+次调用
- 渲染链路上的代码逻辑复杂，数据结构复杂、专业性强（3D计算机图形/3D渲染相关），数据量大（一个普通的渲染任务数据量达到1M）。
在很长一段时间里，渲染中台测试或技术支持都无法快速定位问题，中台的研发一直处于辅助其他业务方去定位问题的困境中。由于没有合适的定位工具，研发在定位问题的时候需要反复繁琐的debug。
为了打破这种低效的境况，提高团队的战斗力。渲染中台团队一直在持续的进行渲染全链路定位平台的落地和定位流程的推进。
面临的挑战
要解决基于以上渲染业务特性的问题定位的痛点，我们面临的挑战是：
- 除了负责具体模块的研发，其他人不了解内部逻辑，怎么把细节逻辑透出给外部人员？
- 大部分人不具备专业知识数据，看不懂复杂的数据结构怎么解决？
- 现有架构对定位平台的支持比较松散，无法系统化
- 如何让业务方、技术支持快速自助定位问题，避免开发被击穿？
平台化过程
整个渲染定位系统的定位模块划分主要根据渲染领域模型和故障反馈归类确定，主要为渲染任务、图册查询、渲染效果、渲染权益四个模块。
以其中最复杂的渲染全链路数据查询功能为例，具体展开介绍一下搭建过程。渲染中台最核心的能力就是渲染能力，而这块能力也是业务逻辑上最为复杂的，在和业务方对接过程中需要协同定位耗时最多，线上线下问题故障反馈也是最多的。
首先我们对渲染能力领域的故障进行收集分析，基本可归结为三类：
- 渲染物品丢失（模型/硬装/定制等）
- 渲染任务失败/卡住
- 渲染效果与预期不一致
经过对这些故障原因和定位过程的分析，我们先尝试去确定定位工具的大致形态，理论上一个好的定位工具肯定是一键就能做到发现问题原因。虽然渲染全过程中有TaskId这种唯一的Id串联了整条链路，但是要做到TaskId一键定位问题所在还是面临了不可跨越的高山：
- 与不同业务方约定的规则不统一 在定位物品丢失的问题原因时，最关键的是需要找到物品Id在哪个位置缺失，但是物品的Id在整条链路上不同节点的命名不一样（比如模型id在前端被命名为brandgoodid，在后端则为furnitureid，到渲染后台后变成meshid），展示的规则也不是唯一确定的。
- 不同业务方的TaskId转换规则不一致 链路上会涉及到TaskId的转换，关系可能是一对一，一对多。并且不同的接入方转换的规则也不一样。
- 效果类问题没有固定的数据错误表现 造成渲染效果不对的原因不是统一的，影响效果可能是参数问题，业务逻辑问题
- 日志丢失/不规范/不完整 借助日志定位的部分不稳定，推进日志完善的成本过高
对此，我们暂时放弃了一键定位的想法，决定去做一个链路级别的定位工具，追踪每一个节点的关键信息从而可以人工的灵活的判断问题所在。
链路拆解
根据先前的问题定位过程对渲染链路进行详细的梳理，拆解出每一个关键节点和数据流转形式。下图可见，一个渲染任务从发起到结束经过了前端入口、渲染中台、业务方（硬装/定制/DIY等）、Mesh中台、渲染后台这几个最关键的节点，理论上只要根据这些节点的输入输出信息就能判断在渲染链路上的问题产生方和原因。
定位模型
为了便于可视化，我们将拆解后的全链路流程模型化，发起渲染后的请求任务会在渲染中台被转换成不同的子任务，每个子任务会处理不同的业务逻辑，例如中台的子任务处理为三个步骤：1、渲染场景预处理；2、向业务方请求modelpackage；3、合并&剔除场景数据。
至此可以将一个渲染任务的定位链路抽象出来转化为一颗流转树，链路上的子任务定义成节点（包含请求数据、输出数据、任务描述、任务状态等信息），节点上复杂的处理过程映射为一个Pipeline（由不同的stage组成，每个stage包含各种过程中间信息）。
可视化
当渲染全链路过程具象后，我们就需要考虑如何将链路树的形态用前端元素可视化出来。为支持pipeline和链路节点嵌套的展示形式我们最终找到Antv-G6下Combo这种新的节点分组模式去完成交互需要。
为了让非产研人员及不了解渲染内部逻辑的使用人员能容易上手，实现自助定位。整个定位平台的可视化实现主要围绕以下三个标准：
- 打通整个渲染链路，将割裂的流程串联起来，细节信息全透出
- 交互设计上考虑到非专业人员，入口尽量放在浅层，专业的数据语义化
- 复杂的数据进行图形化、三维化展示
全链路数据查询模块的主界面输入taskid就会展示一颗链路树，基于每个节点的颜色可以判断任务的状态，节点上的语义化描述可以判断任务做了什么事情。点击不同的节点会展示不同的处理逻辑的交互：1、普通的处理（包含请求数据、日志、队列等基本定位信息）；2、渲染中台的复杂处理过程（主要包含三个stage中产生的数据）；3、渲染后台任务调用链（包含渲染状态、集群信息、引擎的参数配置等信息）。
由于渲染链路上的数据十分复杂专业，3d场景的建筑、模型、造型转化成代码语言后，人工从一份庞大的渲染数据（Infonode/ModelPackage）中去识别数据上的错误和偏差成本太高。为了用户可以通过图形化肉眼简单判别问题，我们使用三维的方式还原了渲染任务所在的户型方案的3d场景，场景中展示出位置、灯光、相机等重要的三维立体信息。同样的为了解决三维展示功能无法判断问题的案例，我们也搭建了一套任务重新渲染的工具，并接入渲染的回归平台。用户可以根据不同的接入方类型（硬装\定制\Diy\水电等）自选需要的数据对原始任务再次发起渲染。
成效
渲染定位平台上线后，每月使用人次最高达170+，月pv访问量最高已经达到11500+；10+业务方从原来的无从查起到现在可以快速判断问题所在方；在技术支持侧80%的渲染问题需要经过定位平台判断原因或者获得进一步的定位信息；渲染团队内部人员的debug时间大大减少，企信处理排查问题的时间至少下降30%。
总结规划
经验总结
- 即使在可视化方面下了很多功夫，定位平台的上手还是具有一定的难度和成本。因此我们也详细编写了定位平台的使用指南，对相关产研人员、技术支持等多次进行工具使用上的培训。
- 除了已有能力的建设，在新业务devdesign时期考虑定位能力的支持，后期可以对接定位平台。
- 用于定位的数据一般会上传OSS，考虑到节约成本，我们设置了合理的有效期；通过添加开关，根据对线上现有服务的影响，可以做到随时去切换是否存储。
- 研发实现定位能力时对现有业务代码有侵入的情况下一定要走迭代流程，需要经过测试回归。
- 借力已有的能力，避免重复造轮子，在实现新能力时去考虑可复用、中台化。
未来规划
接下来我们会持续的建设定位体系，完善业务方定位模块以及难啃的渲染效果问题定位能力；去推进中台架构的优化改进，尝试将一键定位工具落地。在未来可能与工单系统、客服系统打通，可以用于线上反馈问题的分类，将问题的定位前置。