通信场景下的网络拓扑组件库实践原创

各位同事，大家下午好。先介绍下本次将要分享的主题内容。面向通信领域下的网络拓扑使用场景，针对网络线拓编辑及拓扑可视功能需求。基于现有前端图可视及图编辑技术底座，本前端团队实现了通用化的网络拓扑组件。本次分享主要分为三趴，第一趴会对本组件库构建的背景进行一个介绍，包括业务介绍及需求分析。第二趴主要是对本次组件库实践的细节进行相关的描述，将通过架构设计、技术选型、工程构建以及源码浅析四大部分进行展开。最后会对本次组件库方案做一个归纳总结，以及后续的一些发展规划。下面将分享第一趴的内容。先介绍下本组件库实践的一个业务背景。

本组件库是基于5G专网管家和大客户网络管家中的网络拓扑模块进行的技术抽象构建。5G专网管家是一个面向客户，实现客户自运营、客户自运维能力开放的5G智能运营平台，满足客户的实时网络感知、数据调用、业务支撑需求，实现专网能力与服务定制化、网格能力显性化。大客户网络自助服务系统以提升客户感知为目标，提升政企客户对业务交付、故障处理流程、客户网络的可视化服务能力，实现网络服务智能化、可视化。为满足客户根据业务场景对网络拓扑进行自主定义的需求，5G专网管家及大客户网络自助服务应用系统提供自定义拓扑功能。

基于业务需求，UI及产品同事绘制了高保真原型图及设计稿。前端团队面对功能需求进行了对应技术方案的拆解。接下来让我们进入第二趴的分享。通过上述原型图及设计稿的输入物料，为了既满足业务生产的场景需求，又满足组件复用的技术需求，提炼抽象的组建力度便成为实现组建架构设计的首要任务。面对5G专网及大客户场景下的定制化功能需求，最终将组件力度锚定在了模块级别。为了满足实现高可用结耦，内部功能模块依赖整体网络。拓扑组件架构设计采用基础加高级的分层架构设计，其中高级组件主要包括拓扑编辑组件及拓扑可视组件。其为面向业务方官方的最佳实践方案，提供基于业务流的输入输出位置，实现高级组件的定制化与复用化。

基础组件则主要是基于高级组件的功能模块拆分，包括属性模块组件、画布模块组件、数据模块组件、拓扑数模块组件、资源数模块组件、图形库模块组件以及工具模块组件等。其为高级组件的器力度拆分，可用于单独整合组件、定制化的拓扑可视及拓扑编辑私有化组件。整个架构采用事件驱动的独立构建架构风格。构件不直接调用一个过程，而是触发或广播一个或多个事件系统中的其他构件中的过程在一个或多个事件中注册。当一个事件被触发，系统自动调用在这个事件注册的所有过程。

一个事件的触发就导致了另一个模块中的过程调用。这种风格中的构建是非命名的过程，它们之间的交互连接往往是以过程之间的隐式调用来实现的。在确定了整个组件库的架构方案后，对现有成熟技术进行了一个选型。最初进行技术选型定位时，网络拓扑组件库是立足于面向通用化的javascript库这样一个目标进行设定的。但是随着业务及资源的KPI压力，结合当前业务方团队本身的技术生态，网络拓扑组件库最终决定基于前端框架生态进行分离建设维护。目前官方团队仅支持VIVO和两种前端框架生态。对于诸如及Swift等其他的前端框架生态，不提供官方技术解决方案，需要与业界、社区各位开发者一起努力，共建共享。

在前端可视化领域，可将业界常见图形库从底层技术到高层应用进行如下划分。包括绘图技术、渲染引擎、原子模块、可视化语法、可视化类库以及高阶封装。对于图可视及图编辑的技术选择，在对比分析了基于通用型和领域型的成本收益后，最终决定采用领域型的技术方案。其中，通用型技术方案的优势在于社区活跃且问题讨论丰富，缺点在于不能完全适用通信场景，二次改造量大，包括MTV机、6TV叉六一叉S。Skype等。领域型技术方案的优势是完全契合业务需求，但社区封闭且有采购成本，如TV hi等。

对于组件库的选择，由于之前确定了本网络组件库是需要基于框架的，因而在组件库选择方面就不再需要单独进行独立的封装，毕竟业界面向框架的通用组件库方案真的是太太太太多了。在整个中心层面，斌总要求前端的组件库方案是以an design作为基础组件进行二次的业务建设，因此组件控方案最终选择了an design的体系生态，其不仅支持了react的实现，也有对应的view实现。对于通用型组件库的构建，除了本身的功能实现之外，也需要对工程构件进行相应的选择。在view组件库实现中，本案例选用的是基于roll的前端打包工具。分别构建基于esmcgsi fe的前端模块输出方案，支持多种使用方式的引入。此外，对于网络拓扑组件而言，其本身不会对所需要依赖进行打包，只会构建出最小体积的可用压缩产物。对于的版本实现中心提供了研发资产平台来供开发者、设计师及产品经理进行组件库的相关建设。因此，本案例将基于蚂蚁金服脚手架方案下的5I进行打包，配合doi进行文档构建。

5I的底层是基于插件化的机制进行实现的，方便广大开发者进行自定义的功能定制。同样的，中心的组件库构建发布流程中也实现了乌密插件的定制。具体的接入方案可以联系相关同事进行了解。由于前期的技术规范要求，React的版本实现会对各个模块进行分包，上传到中心的Nexus私仓。

接下来将会对之前介绍的每个模块中的亮点设计进行一个介绍。首先让我们来看一下属性模块，属性模块是用于对节点组连线以及子网进行对应属性类型定制的模块，包括名称、字号、位置、背景色、粗细、形状等功能。对于整个组件的实现，在接入组件时通常都需要按对应框架的组件接入规则进行编码。这里我以network-top为例进行介绍。对view而言，对组件的编写通常需要为每个组件提供一个install方法，在业务侧使用过程中则需要使用use方法进行应用。其他框架以及非框架的接入，大家可参考对应平台的接入方案，进行对应组件的开发。

对于data模块，其实用于对连线及节点进行相应数据绑定的模块。根据不同的业务需求，可通过输入输出模式实现组件与业务的交互。在数据接入过程中，通常会涉及到大数据量的问题，在前端开发过程中，面对大数据量，通常要提供懒加载的方式提升用户体验。在实现过程中要注意对threshold阈值的设计。对于对应框架，也可按照框架的特点进行包装后为业务侧提供，比如view中可以提供自定义指令等。对于组件库中的组件交互，需要定制开发时，一般也会涉及到原生的实现，比如上图中所需要实现的blur和focus的交互，则与RTD中的默认方式不同。这时就需要我们去对聚焦和失焦的触发机制进行自定义，这里用到了click outside的这样的自定义的实现。

层级模块是用于对画布上所有的元素进行层级逻辑显示的模块，类似于或者sketch中的图层。其为用户提供可视化图层显示功能，帮助用户更好地理解画谱上元素的逻辑排布与分布规律，提升用户体验。对于图层的实现，由于其需要对术中节点进行动态展示，这里使用了GSX的特定领域语言模型。可能会有同学有疑问，View中也可以使用GSX吗？答案是可以的，只是和在react中使用GSX有所不同。具体的细节可以参考VIVO官方文档中对于GSS的使用方式，使用GSS的好处是可以在纯运行时对组件节点进行处理，灵活进行动态展示。资源模块是用于接入业务侧节点进行拓扑、编排和拖拽的模块，针对不同业务资源拖拽需要提供规则集进行个性化定制，采用函数式编程的compose组合函数等思想抽离业务逻辑。和层级模块类似，对于资源模块同样也使用了NTD中的数组件。

所不同的是，资源模块需要根据不同业务的需求进行个性化的功能实现。以专网管家中的资源模块为例，其需要对拖入画布中的网源节点进行父子关系判断，这里使用了规则模式进行处理，提供road JS进行规则级的选择，通过match和transformer对符合需求的节点进行匹配和数据转化。图形库模块是节点组以及子网的图形展示，根据不同的风格样式可通过切换进行风格的变化，也支持自定义入参改变图形样式。目前提供的风格变化方式可提供业务开发侧去自定义图形样式，但是对于用户侧尚未提供上传图形的功能。

对于主题风格的定制程度，需要根据不同产品形态去对应提供，比如是约定只能改变样式，还是也可以提供图形的自定义上传等。工具模块是用于进行操作相关的集成模块，包括选择创建子网连接线，对齐上一步，下一步放大缩小。填充、恢复、默认保存、另存为、预览以及删除等功能，也支持自定义的功能扩展。工具模块是与画布交互最为频繁的一个模块，对于功能的提供需要与对应图形库进行相应匹配。最后让我们对整个网络拓扑组件的实践过程做一个复盘总结，对于文档的构建，其实也是组件库体系中一个十分重要的组成部分。

在view中通常会使用oil press或者wait press来进行文档的构建。在本案例中，由于有较多的自定义语法实现，本项目采用基于VIK脚手架，通过实现自定义的loader的方式完成markdown与HTML的转化。实现方式如上图所示，其中对于markdown语法的解析使用的是ma克down-it这个库在展示源码的方式中需要自定义实现一个demo.view的组件。整个loader是配置在对点markdown文档的模块匹配中的。基于wepa loader处理机制会先进行自定义的loader，然后走V-loader来满足对SFC的处理。在中，由于公共资产平台使用的是do米进行的文档构建，而do米又是基于五米的脚手架管理，所以对domi而言，其对markdown的处理方式是通过对S的处理进行的。也就是说，在domi中处理markdown相关的模块本质是处理一个process的过程。

而乌米对于pres和plugin的处理则是通过其自定义的生命周期钩子，在相应的时间节点通过注册以及apply后最后run起来相应的命令进行实现的。和view方案所不同的是，Do米对ma克to语法解析则是通过unified.js这样一个内容转化工具及自定义，实现了包括rehab和remark等内容。具体实现方案可参考多米的源码。最后对于本次组件库构建进行如下复盘。对于组件库体系而言，如何很好地对组件进行分类设计是组件库中最为重要的核心，Designing其实是比更重要的。在面向对象编程中，常常会用到设计模式的解决方案。同样的，在组件库设计中，设计模式也被广泛应用到组件库体系设计的方方面面，其可以显著增加研发团队的确定性及系统一致性，节省不必要的开销，提升设计与开发的协作效率。

以网络拓组件库为例，其可以通过功能层、页面层、模块层、组件层对业务形态进行拆解。可规划为六大类组件，分别是属性类组件、画布类组件、数据类组件、逻辑类组件、图形类组件以及工具类组件。在工程领域中，组件库方案是前端工程化领域的一种提升工程效能的最佳实践。对于业务场景的高可用及高可维护具有重要的意义。通常而言，颗粒度与开辟性是组件库方案能否形成内具的关键所在，同时也是考量组件库的核心评价指标。

在日常开发过程中，对于SPA据实应用产生的臃肿问题，合理的使用组件库分包也是优化开发流程及工程管理的重要方式。到这里，本次分享已接近尾声。后续对本组件库的一些发展规划大致如下。在六月中下旬会进行回归测试，将核心的进行分包处理。六月底左右，Well杠、network杠、top1.0及technology1.0将在内部时常发布。在七月初将更加通用型的network社区版进行Alpha版本开源发布。在八月份会对本次网络拓扑组件库的相关方案进行一个专利及软著的编写，同时预计版本的组件库会在九月底进行完成。

十到11月会对社区开源版本中的主题、国际化以及设计资源等方面进行完善，因此后续会对整个图形库进行重构，大概会以G6或X6作为图可视化库的实现蓝本。大致11月底会发布社区版的VI network-1.0。二四年的重点工作应该会主要对图形库进行相关的字眼。目前大致的规划方案是和蚂蚁金服那边的G6或叉六团队进行沟通交流。后续的发展需要看社区的一些反馈进行改进。以上就是今天的分享。最后再做一个广告，如果大家有gity或者github账号的话，欢迎给我们的开源项目点点star，你们的点赞是我们最大的动力。我们的联系方式也放在了右边。大家有关于网络拓扑组件的问题，欢迎和我们沟通。

感谢大家的聆听。