1.本发明涉及it技术领域，特别是涉及一种运维中台的实现方法和系统。
背景技术：2.目前，运维自动化活动在it领域广泛使用，特别是以it技术作为业务支撑的行业尤其重要，例如：银行、证券、汽车、制造、互联网等各类领域。因此，企业都在研发适合自己企业的运维自动化系统，用于满足企业的日常运维和管理需求。同时在市场上也有大量的第三方企业研发了类似的产品，例如：腾讯的蓝鲸智云平台、优维科技的easyops平台、华为的devcloud平台、阿里的云效平台等，从企业客户提升运维活动的效率、运维活动的智能化管控等多维度提供相应的解决方案和对应的落地产品活动。
3.运维自动化活动的场景主要应用于企业客户市场。企业客户的特点就是个性化要求非常突出、业务活动多变以及不同企业的管理思维各有不一，所以企业的运维自动化的活动比较类似，但是呈现的方式却各有不一，所以难以采取某一个标准的产品来适配客户的诉求。大多数运维自动化领域的产品都是需要进行大幅度的定制开发来适应客户的要求，这类个性化就引发了运维自动化活动的一些不足的地方：
4.①
适配的周期长：从客户诉求转化为企业所需要的自动化活动衍变的周期长，难以适配业务的快速变化。
5.②
通用性差：在做个性化设计之后，往往就会放弃通用性的设计思维，从而导致需求的变化而会引发应用的二次修改来适配业务诉求。
6.③
重复投入：很多类似的功能不断在重复建设，不同的企业之间、不同的业务部门之间、同一部门不同的时间段之间都存在的多次建设类似的自动化运维能力。虽然在业务上可能存在管理的模式不同、实现的功能的部分差异，但是核心的功能方面却基本一致，所以很多时候在不同建设重复类似的能力。
7.随着业务快速的发展、对it业务上线的效率要求越来越高的前提下，这种矛盾越发突显出来，针对企业和产品公司来说都在该方向上寻求业务与自动化之间的平衡点，在效率和业务特征的平衡点来满足企业客户最终的业务诉求。
技术实现要素：8.鉴于以上所述现有技术的缺点，本发明的目的在于提供一种运维中台的实现方法和系统，主要针对运维自动化这个领域如何解决快速适配业务诉求，来提升运维自动化活动的转化效率、降低重复建设的成本投入以及解决通用性与个性化之间的平衡点，将运维自动化活动拆分成稳态、通用、共性、个性化多态模式，来组建符合生态链的运维中台。
9.本发明提供一种运维中台的实现方法，所述方法包括以下步骤：
10.步骤1：将运维自动化活动进行解耦，获取相对独立的服务前台、服务中台和服务后台；
11.步骤2：从服务前台、服务中台和服务后台三个维度进行业务行为分解，根据业务
行为自动组装快速适配企业的业务活动。
12.于本发明的一实施例中，所述步骤2的具体流程如下：
13.步骤2.1：从服务前台、服务中台和服务后台三个维度将业务行为组件化，所述业务行为包括脚本、管理操作以及底层设施对接；
14.步骤2.2：将组件化的业务行为流程化，通过流程的模式组建一套特定的业务活动；
15.步骤2.3：基于业务活动实现业务活动自动化、运行执行自动化、数据回收自动化、业务监控自动化和数据流转自动化。
16.本发明提供一种运维中台系统，所述系统包括ui设计器、组件管理器、业务流程组装器、业务流程解析引擎和自动化行为调度器；
17.所述ui设计器用于可视化页面元素设置和展现，便于快速创建业务活动的操作行为；
18.所述组件管理器用于业务行为定义，实现业务行为组件化；
19.所述业务流程组装器用于将业务行为转化为业务活动，实现业务行为流程化；
20.所述业务流程解析引擎用于根据预设规定进行业务行为组装和数据加载组合；
21.所述自动化行为调度器用于与底层设施进行数据交互，实现业务活动自动化、运行执行自动化、数据回收自动化、业务监控自动化和数据流转自动化。
22.于本发明的一实施例中，所述系统还包括业务监控器；所述业务监控器用于监听所有业务链路日志，分解业务链路组件的运行情况信息和并发情况信息。
23.于本发明的一实施例中，所述系统还包括驱动引擎和采集引擎；
24.所述驱动引擎用于获取业务链路组件传递的脚本，并且根据预先设置参数与脚本绑定，连接底层设施后下发执行脚本；
25.所述采集引擎用于与底层设施进行数据交互。
26.于本发明的一实施例中，所述底层设施包括服务器、存储器、数据库以及应用设备。
27.于本发明的一实施例中，所述组件管理器包括组件脚本编辑器、组件调试器以及组件发布管理器。
28.于本发明的一实施例中，所述业务流程组装器用于将业务行为转化为业务活动的过程中，进行了操作行为的设定、流程与页面的绑定、流程与组件的绑定、组件之间数据传输的绑定、组将运转行为的绑定、组装实例和实例衍变。
29.如上所述，本发明的一种运维中台的实现方法和系统，具有以下有益效果：
30.一、本发明提升了运维自动化活动的研发效率，快速适配企业临时、个性化、共用性业务需求。
31.二、本发明降低了运维自动化活动的成本，提供了一整套的运维活动通道以及管控策略，企业只要在平台上定制业务体即可，大幅度的降低了企业时间投入成本和人力投入成本。
32.三、本发明降低了运维平台研发人员的素质要求，降低了运维人员素质的门槛，使得运维人员也能成为运维平台研发人员，快速建设适合自己活动的业务平台。
33.四、本发明降低了重复投入的可能性，因为首先业务被打散成原子，业务是通过组
装出来的，不再像之前重复定制研发的，所以对类似功能的重复研发已不再可能；与此同时，这个过程中能够快速进行能力复用，降低重复投入的代价和人力与时间成本。
34.五、本发明实现了运维活动的标准化，可以确保业务操作能够按照应为活动的标准化模式进行，标准化为降低运维自动化风险一种保障；与此同时，提供了便利的手段提升效率，实际还隐藏了使用和检测的管控，从而降低运维活动的风险。
附图说明
35.图1显示为本发明实施例中公开的运维中台系统的结构框图。
36.图2显示为本发明实施例中公开的业务流程组装器配置虚拟机申请的流程图。
37.图3显示为本发明实施例中公开的业务流程解析引擎的控制流程图。
38.图4显示为本发明实施例中公开的自动化行为调度器的工作流程图。
39.图5显示为本发明实施例中公开的驱动引擎和采集引擎的工作流程图。
具体实施方式
40.以下通过特定的具体实例说明本发明的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。需说明的是，在不冲突的情况下，以下实施例及实施例中的特征可以相互组合。
41.需要说明的是，以下实施例中所提供的图示仅以示意方式说明本发明的基本构想，遂图式中仅显示与本发明中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。
42.本发明提供一种运维中台的实现方法，所述方法用于解决企业客户现在的痛点，快速适配企业的业务活动，通过运维中台系统来构建企业运维自动化活动，提升企业运维自动化活动的效率，提升原子化的通用性，降低业务重复构建的可能性。
43.首先将运维自动化活动进行活动解耦，包括服务前台、服务中台和服务后台：
44.①
通用、稳态性强的服务后台：即自动化运维服务引擎，通过自动化运维服务引擎，能够实现指令的下达、执行以及执行过程回送。
45.②
共性、通用性强的服务中台：即将业务共性作为服务中台来进行活动封装，实现业务活动的解析和数据闭环的中转。
46.③
个性化的服务前台：即能够快速构建页面的逻辑，提供多模式的数据源模型，适配业务的自动化管理需求，同时兼容特殊业务操作的快速集成等。
47.然后从服务后台、服务中台、服务前台三个维度进行行为分解，并且根据行为自动组装快速适配企业的业务行为；与此同时，从数据维度又能构建数据闭环，从而实现符合企业特点的运维中台系统，其中，所述方法主要围绕“三化”模式进行：
48.①
组件化：将业务行为组件化，其中，业务行为涵盖业务行为包括脚本、管理操作以及底层设施对接等。
49.②
流程化：任何一个业务行为需要通过流程的模式来组建一套特定的业务活动，
该业务活动可以是一套纯粹的运维自动化业务，也可以是涵盖管理活动的运维业务或者多平台打通的业务模式。
50.③
自动化：包括业务活动自动化(需要将业务行为进行自动化拼装来完成业务操作行为、运维)、运维执行自动化(需要根据业务指令或者业务场景)、数据回收自动化(回收会涵盖执行过程信息、结果信息、状态信息)、业务监控自动化(自动化活动会涉及到各个环节、大量的服务器、网络信息等如何对业务实现实时监控也是自动化必须涵盖的内容之一)数据流转自动化(对外呈现的是一种业务活动、业务必然存在模块内、模块之间、系统与系统之间的数据流转，如何实现数据流转过程自动化力也是一种必须涵盖的能力)。
51.因此，基于上述运维中台的实现方法的“三化”能力，实现快速适配运维业务、完成通用性向个性化进行转变、降低运维的核心功能重复建设。
52.于本发明实施例中，所述系统基于上述方法构建，所述运维中台系统包括ui设计器、组件管理器、业务监控器、业务流程组装器、业务流程解析引擎、自动化行为调度器、驱动引擎和采集引擎，请参阅图1。
53.(1)ui设计器：由于任何一套业务都会有对应的页面进行操作和维护，因此，所述ui设计器用于协助用户进行可视化页面元素设置和展现；其中，所述ui设计器的功能涵盖业务数据结构的可视化设计、外部数据源的管理、ui组件的管理以及ui布局的管理，便于用户快速创建业务的操作行为。
54.(2)组件管理器：主要通过定义业务组件行为，业务组件可以采用通用模式来完成业务行为的开发，也可以通过一套通用的模式来构建，其中，所述组件管理器包括组件脚本编辑器、组件调试器、组件发布管理器，用于业务组件行为定义。
55.(3)业务流程组装器：一个业务需求实际衍生出一套业务流程，所述业务流程组装器主要是将组件行为转化为业务行为的一个过程，包括所有操作行为的设置、流程与页面的绑定、流程与组件的绑定、组件之间数据传输的绑定、组件运转行为的绑定(暂停、恢复、终止、信息重新填写等等业务操作行为)、组装实例、实例衍变业务行为等。
56.(4)业务流程解析引擎：所述业务流程解析引擎是一套核心的业务解析服务引擎，根据预设的规则进行业务组装和数据加载组合，即完成业务行为的预设定义，转化为一套可执行的自动化服务。
57.(5)自动化行为调度器：运维是一套底层运维的行为场景，用于与底层的设施进行交互(服务器、网络、存储、数据库、应用等)；在自动化行为调度器中需要根据网络的状态(网络区域的隔离分配)、自动化并发的控制、硬件型号的分离、公有云与私有云的区分等，自动化行为调度器负责解析和控制底层的驱动控制，并且可以随时根据指令进行底层交互。
58.(6)驱动引擎和采集引擎：二个引擎负责完成自动化行为调度器的指令传递，其中，驱动引擎负责获取业务传递过来的脚本，根据预先设置、参数与脚本的绑定、连接远端的设备去下发和执行脚本；采集引擎负责进行数据的旁听，然后进行信息采集，进行状态和运行过程数据的实时回转，完成业务底层数据处理。
59.(7)业务监控器：在运维中台系统由大量异构的活动体来实现业务运转的延续性，所以业务监控器作为运维活动的监管器，自动化行为是一套复杂的运维活动体，而且也是一套非常危险操作的活动，以及如何在复杂的工程体内在出错的情况下如何快速定位问
题，业务监控器将负责旁听所有的业务链路，跟踪业务数据走向，收集所有业务链路日志，分解业务链路组件的运行情况、并发情况等信息。一旦在出现链路异常及时告警，协助快速解决问题，以及协助监听业务的饱和过程。
60.请参阅图2，业务流程组装器配置虚拟机申请的流程为：
61.(1.1)配置设计虚拟机申请业务表，通过ui设计器定义表结构、属性等元素，并且持久化到数据库中。
62.(1.2)通过ui设计器配置虚拟机申请表单页面，包含虚拟机名称、操作系统、内存、项目组、虚拟机用途等表单元素。
63.(1.3)持久化虚拟机申请表单页面元素、页面设计，保持到数据库中。
64.(1.4)添加“创建虚拟机”python脚本，配置脚本输入输出参数，提交脚本到组件管理器进行后端初步程序校验；校验通过持久化脚本到本地数据库，不通过则返回对应提示信息。
65.(1.5)组件管理器进行脚本测试工作，并反馈调试结果到ui设计器。
66.(1.6)用户接收到脚本调试结果进行确认，根据结果选择下一步动作，如果调试失败，则重新编辑脚本重复调试工作，直至成功，如果调试成功，则提交发布请求，服务端接受到请求会发送消息通知运维经理。
67.(1.7)运维经理根据调试结果结合脚本审查后正式发布到组件库。
68.(1.8)业务流程组装器开始编排虚拟机创建业务流程：提交申请(虚拟机申请页面组件)
‑‑
项目经理审批
‑‑
部门经理审批
‑‑‑
运维确认
‑‑
运维经理审批
‑‑‑
虚拟机创建组件
‑‑
信息回执组件。
69.(1.9)保存任务编排后系统自动生成发布申请并通知应用市场管理员审核，通过后正式发布，否则回到任务编排模块重新编辑。
70.请参阅图3，业务流程解析引擎的控制流程为：
71.(2.1)在业务流发起启动指令后，业务解析引擎生成一个唯一的执行id号，此id号将作为该业务实例的执行唯一id号，以便实现业务链路的唯一跟踪号码，也是业务记录的关键属性。
72.(2.2)业务流程定义中存在着大量的业务定义和数据定义，加载流程定义，获取流程所有的全局定义信息以及节点连接信息等。
73.(2.3)加载所有的节点详细定义信息、这里涵盖节点对应的脚本、节点参数定义、节点参数获取定义等信息。
74.(2.4)业务流中，比如存在大量的参数信息，为了确保参数数据获取的效率，引擎会首先预分配一个数据缓存池，已被快速加载和处理数据，保证业务在运行过程中，数据处理逻辑的效率。
75.(2.5)此时开始在数据库中首先加载固化的数据信息，并将固化的数据先纳入到数据池中。
76.(2.6)部分涵盖动态数据源数据信息，则根据数据源的定义来建立数据源定义的数据配置信息，实时去数据源获取数据，并且数据关系的定义进行数据的组装后，将对应的数据纳入到缓存库中。
77.(2.7)在根据数据关系的定义和已被加载出来的数据，实现数据的关系的运行，并
组装成一套可以运转的数据池，并建立节点的初始化指针，以便进行数据获取以及传输工作。
78.(2.8)执行实例根据流程执行的逻辑关系，生成运行控制模型，并启动流程运行控制操作。
79.(2.9)根据数据池以及节点加载的组件组合生成组件实例，生成组件实例执行id号，存入到业务库。
80.(2.10)根据流程执行运行控制逻辑来判别可以执行的组件，将组装好的组件进行下发，交付给业务流程解析引擎。
81.(2.11)业务流程解析引擎下发作业，并进行驱动运行，并将运行状态和结果进行回送到业务端。
82.(2.12)业务端获取到组件运行状态后，将再次交付给流程运行控制服务，由流程控制服务根据节点之间的关系来判别交付给哪一个组件进行执行。
83.(2.13)将重复执行10—12步骤信息，直到流程所有节点执行结束、或者达到异常触发条件来结束流程和运行工作。
84.(2.14)流程实例执行结束、更新业务状态、业务数据写入、流程执行实例结束该业务活动，并将运行记录进入数据历史表，以便进行后期的业务信息查询和数据分析工作。
85.(2.15)业务解析引擎释放线程，进行线程休眠，等待下个业务接入。
86.请参阅图4，自动化行为调度器主要能力需要将业务请求根据规则调度到对应服务区域，并收集状态信息进行与业务层交互，确保业务流程的正常运转，它的工作模式：
87.(3.1)自动化行为调度器启动、自动化行为调度器开始预加载相应的配置信息；
88.(3.2)自动化行为调度器启动请求服务监听端口7980主线程，等待业务请求的下发。
89.(3.3)主线程获取到业务的配置信息，缓存配置信息。
90.(3.4)接收到连接现场，接收到对应的业务请求指令。
91.(3.5)主线程根据业务请求创建一个新线程来接收任务，并传递调度配置参数，并将线程纳入到线程池(如果线程池饱和，则进入到线程的等待区(数据库)；如果等待区饱和，则会回送信息到业务层，报业务请求饱和、拒绝业务连接)。
92.(3.6)根据业务请求的类型(本地模式、远程模式)来处理调度的下发区域，如果是远程模式，则根据设备的类型(windows、linux、网络设备等)，再加上对应的ip地址段(不同ip段则会存在网络隔离)，如果涉及到多台设备，则需要进行分组处理，可能拆分多个请求下发不同的区域，(自动化行为调度器还需要生成拆分id、确保下发执行之后，结果仍然在调度层进行合并上传)。
93.(3.7)业务层数据拆分或者原生下发后，业务数据写入调度数据库，以便未来能够进行合并数据和数据跟踪。
94.(3.8)调度下发后，主线程处在等待状态，监听后台的结果回写，判别结果处理的状态，如果成功并请求经过拆分，则会获取结果并进行数据合并，然后进行数据回送；如果处理结果状态为失败(注：如果请求拆分后为多个调度作业，只要一个为失败，则状态则至为失败)，则需要收集失败的原因以及标识不同的设备执行的失败等等失败信息。
95.(3.9)数据回收到业务层，释放对应主线程并清理线程池里面的线程数量等相关
的清理工作。
96.通过自动化行为调度器进行请求的下发到对应可以执行的区域之后，在针对底层将需要将作业传输到指定的设备中，并将作业驱动起来，然后实时传递结果和运行信息，请参阅图5：
97.(4.1)启动驱动引擎(驱动服务根据不同的类型的作业类型、驱动服务各有不同、例如：windows自动驱动引擎、linux自动化驱动引擎、网络设备驱动引擎等)，因为驱动引擎又可能放置在不同的网络区域里面，所以相同的驱动引擎会多实例存放在不同的服务器上，这样确保系统具备高度横向扩展的能力，以及在性能比较吃紧的时候，可以启动多服务模式来减轻性能压力等。
98.(4.2)监听分布式消息队列(每个引擎实例会监听单一队列，或者多个引擎实例监听一个队列(负载均衡))，等待业务请求。
99.(4.3)在接收到业务请求后，判别业务请求的脚本类型，是否要对脚本进行二次组装，如果需要，则根据规则生成可执行的脚本文件以及对应参数文件信息来使得业务请求转化为一个可以运行的业务脚本。(多脚本文件和对应的参数文件)。
100.(4.4)同时启动监听线程，负责采集运行脚本的日志信息和运行的结果信息。
101.(4.5)如果是本地运行，则在本机上直接启动运行命令进行脚本运行工作。
102.(4.6)如果是远程运行，则启动远程连接指令，远程连接对应的设备信息，(服务器、网络、防火墙等)。
103.(4.7)如果是远程运行，则会自动下发脚本，(或者脚本已经存在远程之外)。
104.(4.8)启动运行命令，启动脚本的运行。
105.(4.9)采集引擎线程负责旁听在运行过程中生成的日志信息，以及运行的每个task的状态信息。
106.(4.10)采集引擎线程将数据缓存在本地、直到所有的作业运行结束，汇总作业日志，本地存放一份，然后进行日志回送。(如果日志文件很大，超出了分布队列日志的大小，则需要对日志进行分片处理，然后进行多次回送，调度层会根据分片标志进行日志合并处理)。
107.(4.11)采集引擎线程负责汇总运行状态，因为状态信息需要及时回送，则可以走同步接口，将对应的状态直接回送到调度层，进行结果判别的处理。
108.(4.11)所有信息处理结束后，则将业务线程关闭，等待下一个业务到来。
109.综上所述，本发明将传统自动化运维平台转化为运维中台+业务配置模型来适配企业客户的个性化和多变的诉求，能够快速适配企业个性化诉求以及在需求变化后能够快速适应业务，提升了自动化运维研发效率、降低了研发成本以及降低了类似功能的重复建设；本发明将业务打散为组件，每个原子化的组件，然后通过流程的模式来将原子化组件进行业务组装，来快速适配业务活动，同时提供了大量的组件模型、业务管控模型、数据流转模型、页面设计模型，自动化驱动模型、数据采集模型、业务链路跟踪模型等，将大量运维活动的行为纳入为通用的服务引擎，然后通过接口或者页面模式来实现了业务的二次构造，如果出现需求变更，只需要对原子化的组件进行二次改造，或者增加变化的需求增加原子组件来适配业务活动，无需在进行二次开发、程序发布等过程，针对自动化而言，它本身也是一种非常危险的业务操作，所以本发明在各个业务操作层面提供各类管理策略，确保在
业务定制的时候，降低人为的失误而引发的业务风险。所以，本发明有效克服了现有技术中的种种缺点而具高度产业利用价值。
110.上述实施例仅例示性说明本发明的原理及其功效，而非用于限制本发明。任何熟悉此技术的人士皆可在不违背本发明的精神及范畴下，对上述实施例进行修饰或改变。因此，举凡所属技术领域中具有通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本发明的权利要求所涵盖。
技术特征：1.一种运维中台的实现方法，其特征在于，所述方法包括以下步骤：步骤1：将运维自动化活动进行解耦，获取相对独立的服务前台、服务中台和服务后台；步骤2：从服务前台、服务中台和服务后台三个维度进行业务行为分解，根据业务行为自动组装快速适配企业的业务活动。2.根据权利要求1所述的一种运维中台的实现方法，其特征在于：所述步骤2的具体流程如下：步骤2.1：从服务前台、服务中台和服务后台三个维度将业务行为组件化，所述业务行为包括脚本、管理操作以及底层设施对接；步骤2.2：将组件化的业务行为流程化，通过流程的模式组建一套特定的业务活动；步骤2.3：基于业务活动实现业务活动自动化、运行执行自动化、数据回收自动化、业务监控自动化和数据流转自动化。3.一种运维中台系统，所述系统执行权利要求1-2任一所述的方法，其特征在于，所述系统包括ui设计器、组件管理器、业务流程组装器、业务流程解析引擎和自动化行为调度器；所述ui设计器用于可视化页面元素设置和展现，便于快速创建业务活动的操作行为；所述组件管理器用于业务行为定义，实现业务行为组件化；所述业务流程组装器用于将业务行为转化为业务活动，实现业务行为流程化；所述业务流程解析引擎用于根据预设规定进行业务行为组装和数据加载组合；所述自动化行为调度器用于与底层设施进行数据交互，实现业务活动自动化、运行执行自动化、数据回收自动化、业务监控自动化和数据流转自动化。4.根据权利要求3所述的一种运维中台系统，其特征在于：所述系统还包括业务监控器；所述业务监控器用于监听所有业务链路日志，分解业务链路组件的运行情况信息和并发情况信息。5.根据权利要求4所述的一种运维中台系统，其特征在于：所述系统还包括驱动引擎和采集引擎；所述驱动引擎用于获取业务链路组件传递的脚本，并且根据预先设置参数与脚本绑定，连接底层设施后下发执行脚本；所述采集引擎用于与底层设施进行数据交互。6.根据权利要求5所述的一种运维中台系统，其特征在于：所述底层设施包括服务器、存储器、数据库以及应用设备。7.根据权利要求3所述的一种运维中台系统，其特征在于：所述组件管理器包括组件脚本编辑器、组件调试器以及组件发布管理器。8.根据权利要求3所述的一种运维中台系统，其特征在于：所述业务流程组装器用于将业务行为转化为业务活动的过程中，进行作行为的设定、流程与页面的绑定、流程与组件的绑定、组件之间数据传输的绑定、组将运转行为的绑定、组装实例和实例衍变。
技术总结本发明提供一种运维中台的实现方法和系统，涉及IT技术领域，所述方法包括步骤1：将运维自动化活动进行解耦，获取相对独立的服务前台、服务中台和服务后台；步骤2：从服务前台、服务中台和服务后台三个维度进行业务行为分解，根据业务行为自动组装快速适配企业的业务活动。本发明将传统自动化运维平台转化为运维中台+业务配置模型来适配企业客户的个性化和多变的诉求，能够快速适配企业个性化诉求以及在需求变化后能够快速适应业务，提升了自动化运维研发效率、降低了研发成本以及降低了类似功能的重复建设。能的重复建设。能的重复建设。
技术研发人员：张斌
受保护的技术使用者：上海敏智信息科技有限公司
技术研发日：2021.06.09
技术公布日：2022/12/8
