1、工单业务简介及核心链路
1.1 业务简介
得物客服工单系统主要承载着得物与用户关联需要客服处理的事件，其主要功能可以认为有如下两项：
·承载事件的基本信息及关联信息
· 允许客服处理事件，并可以流转相关信息至关联方或用户
简单来说就是客服根据工单信息进行流转处理，围绕着这个核心链路，工单域在处理中心、信息分类的管理配置、客服人员的管理及分配，以及信息处理过程的质检抽检等做了很多建设。
1.2 核心链路
要完成这个核心链路作业那就需要有一个承载平台，那就是工单工作台，包括工单的来源，展现，处理流转及最终处理方案的完结，如下图所示：
工单工作台作为核心链路承载平台，是二线客服对工单作业的“生产流水线”，是整个工单作业的核心，因此在这篇文章后续所有的优化都是围绕着这一点来进行的。
工单作业的流程是相当复杂的，我们需要另外一张图将核心部分的流程表达出来，如下图所示：
工单中心每天会收集来自各个来源的工单，在线客服进线产生的工单是主要部分，占比一半左右。
二线客服根据工单的信息还有与用户沟通的情况，需要其他客服或其他域提供协助或其他信息，此时工单会流转至关联方。
当关联方提供相关信息或协助后，大部分工单会返回到当前客服继续下一步处理。
当客服本身与客户，其他关联方全部协商一致后，会根据工单情形进行对应的完结处理，而完结的处理流程目前有数十种。
在这个核心的作业流水线上，平均每天有很多很多的客服处理更多更多的工单，这些客服每天工作至少非常多的时间是在章鱼工单工作台上持续的作业。
这是我们在二线客服职场调研时的场景，在工位上的客服基本都在使用工单工作台（10个打开屏幕的，至少有九个屏幕内容是工单工作台），说实话，作为一个前端，当上百号客服同时在你面前使用你开发的应用时，还是相当震撼的，同时也深感责任的重大。
这在前端方面对工作台从性能，稳定性，易用性等各个角度的体验问题上提出了很大的要求！
2、工单域前端问题
在参与工单业务开发时，工单在前端这方面存在很多的问题，这些问题集中在两个方面：
· 面向客服同学的使用体验问题，集中在性能，稳定性和易用性等方面；
· 面向研发同学的研发体验或效能问题，集中在代码维护困难，花费大量精力处理线上问题等。
而需要解决这些问题，需要多种手段多种维度介入。
3、多维度重构优化现有系统
在架构设计中, 架构形态往往是跟随业务形态变化而变化。在客服域内，面向一二线客服作业的章鱼工作台已使用微前端来区分IM，电话，工单及工具箱；而对工单域来说，除了要开发作为章鱼工作台的子应用外，还有各个方面的架构调整或性能提升优化需要做：
3.1 聚合接口，加速工单渲染
工单详情每次渲染初始接口数有21个，在服务端同学梳理整合这些接口成本过高的情况下，与服务端同学一起推动使用网关聚合的模式，将前端请求接口数降低至5个，整体渲染完成时间降低至600ms以内。
3.2 区分快慢，缩短订单FMP
订单详情接口字段有190多个，但是其中首屏接口100多个，其中有部分字段还依赖外域，导致整个接口RT过长，前端与后端协商后，推动了快慢接口的方案的落地，其原理如下：
· 快接口：将首屏较慢的依赖外域的字段去除，经过分析, 去除最慢5个字段后，接口rt能降低到300ms以内；
· 慢接口：即全量接口，作为补充快接口未返回字段之用；
· 接口批次处理：其他接口，在以往是返回即更新，会导致页面过于频繁的更新，甚至抖动，因此将页面更新机会集中在三次，以降低渲染偏移量(CLS, Cumulative Layout Shift)。
其中首屏渲染能将首屏中95%的字段优先展示，方案运行后，首屏FMP渲染时间从873ms降至376ms，下降了57%，95分位567ms，下降了62%。另外我们也在推动优化外域接口，后续将进一步降低渲染时间。
3.3 引入Module Federation， 使应用互联
引入MF（Module Federation，远程组件）是一个十分创新和实用的新技术转化的举措，其解决了子应用间互相渲染业务组件的困局：
· 使用iframe，性能差，渲染慢，内存占用高，经常导致崩溃；
· 使用npm包，严重推高研发维护成本，提升线上风险。
而MF远程组件能十分完美的解决上述问题。
使用后将渲染时间降低了6倍，内存占用减少到了之前的1/10以内：
除了提升性能，在业务模块间高效率复用也是该技术的亮点，所以这也是接下来几个重要业务技术重构的基础技术。
3.4 推行单实例，提升性能
在开发工单工作台工单详情时，由于客服作业时经常保留多个工单详情tab，如果详情使用多实例，那势必会造成页面dom节点数多，内存占用高的情况，因此开发时就是设计成单实例的。
而工单工作台与工单系统两个应用隔离后，工单系统使用工作台的详情页面时，由于两个系统的技术栈是不一样的，因此不能通过远程组件联通，只能使用iframe，由于工单系统打开详情页也有较高的频次，每次渲染iframe也依旧很慢，因此利用iframe的postMessage通信，及工单详情的单实例特性，工单系统切换tab时将工单号通过postMessage通知工单工作台，再通过工单详情的单实例切换，在非首屏场景也能取得与MF相当的响应速度。
这个方案是在两个互相关联的应用不是同一技术栈情况的下的过渡方案，随着所有应用都向React迁移，未来MF仍旧是主力方案。
3.5 动态渲染，降开发维护成本
简单来说思路就是：过简单的数据内容的增减和修改，根据约定动态渲染，快速达成业务目标。以替代工单创单，关单流程，订单渲染等关键环节的各自问题。
3.5.1 创建工单的重构
创建工单以往存在着这样的问题：
· 不同工单类型对应创单表单不一样，模板渲染又十分复杂
· 多个应用维护同样业务代码，代码技术栈又不一致的情况，维护起来十分头疼
· 在IM创单场景，由于客服切换IM会话频次较快，又没有涉及按会话ID维度的单独表单内存存储空间，时常会发生表单信息丢失或错乱的情况, 线上很多问题多是由于这样的原因导致的。
因此在设计新的架构时，设计了两个维度的数据隔离：第一维度是会话维度，第二维度是会话内数据内容和模板数据的隔离，以便提交表单时能立即将当前表单数据内容提交。
· 一份不同会话维度的数据表，该表会随着客服与不同用户的会话的新增结束而动态变化
· 客服切换会话时，根据对应会话的数据，立即渲染出对应的表单内容
· 客服会高频的切换不同的会话
· 将客服在当前创建工单表单的修改内容反应至对应的数据，这里的难点是：
有时修改数据的交互是异步的，例如修改订单号会异步查询订单信息并自动填充
假设这个过程中发生了客服切换会话，那有可能导致信息错乱
解决手段是充分利用闭包缓存的特性，当异步返回时设置对应闭包下会话id的数据内容
通过以上重构的手段，再结合Module Federation统一不同应用中的业务代码，彻底解决了之前的问题。
相关流程图：
3.5.2 关单流程的重构
关单流程目前存在着数十个不同的流程类型，每种流程类型客服关单时的表单内容和流程都是不一样的，在以往都是按简单的判断逻辑堆砌流程，导致代码十分冗长和复杂，在充分梳理不同流程类型的业务逻辑后，新的架构设计方案如下：
· 将不同流程类型渲染逻辑通过schema表达，由于该表达较为复杂并且与交互关联较大，因此维护在前端
· 通过schema组件渲染器逻辑，渲染对应流程表单，也可将通用信息或特殊业务信息透传给该流程下的对应组件
· 不同流程类型通过schema配置，可快速插拔组件和复用组件
该方案有点类似低代码的渲染逻辑，能很好的梳理出不同流程各自的逻辑，也便于后期的开发维护，该重构上线后，前后端在关单业务上的开发比例从1:1下降至1:3，节省了很多前端开发维护成本。
3.5.3 订单详情的重构
订单详情平常需求中，约60%的需求都是配合外域或者内部的简单的字段增改，虽然前端开发内容不多，但每个也要花费前端的开发成本。在最新的重构中，设计是这样的：
· 将变化较大的订单基本信息及关联信息通过统一schema维护
· 前后端约定schema的格式，后端将对应数据通过该schema格式的数据返回
· 前端根据该格式渲染至页面，简单增减字段时前端无需开发，只需后端配置对应字段值即可。
该方案是前后端共同推进的，目前已上线，正在灰度中（2023年3月底），统计以往数据，订单需求预计可节省66%的前端人力投入，在最近515的需求中已有部分需求无需在新的重构版本中投入人力。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
