一种新型的工业APP与标识注册解析集成方法与流程

一种新型的工业app与标识注册解析集成方法
技术领域
1.本发明涉及工业互联网标识解析系统技术领域，具体为一种新型的工业app与标识注册解析集成方法。


背景技术：

2.工业互联网标识解析系统是工业互联网的神经系统，是工业互联网的重要组成部分，也是构建人、机、物全面互联的基础设施。当前，gs1、handle、oid等标识解析体系相互之间不兼容，需要从工业互联网需求角度出发，构建新型的工业互联网标识解析体系，解决编码标识、标识解析寻址、安全解析和管理的问题，实现资源的灵活调度，优化工业资源并提高协作效率。
3.在工业互联网出现之前，标识主要应用在仓储物流管理中，用以提升自动化水平，提高工作效率，降低物流成本。随着信息技术的不断发展以及数字化水平的不断提升，标识不再局限在企业内部管理中，而是被赋予了打通信息壁垒，实现信息共享，挖掘数据价值等更深层次的意义。
4.将标识解析技术与电子元器件智能制造应用模式深度融合，借助标识解析为电子元器件制造产业赋能，打破国外技术封锁，构建立足贵州、辐射西南、服务全国的电子元器件标识应用综合服务能力，并将相关应用经验推广扩展到一、三产业，探索产业发展新业态、新模式的尝试，具有极为重要的战略意义。落地实施标识解析系统建设，在促进企业自身生产经营能力转型升级的同时，带动我国电子行业标识解析应用的发展。
5.工业互联网标识解析的建设，将为电子行业工业上下游生产、防伪、供应链追踪等各环节提供产品、质量、过程等的标识注册、解析、备案等配套服务；面向行业提供标识创新服务、标识解决方案，及加快工业互联网“万物互联”的进程，提高制造企业内部系统与系统、系统与设备、设备与设备以及人与系统/设备的交互即时性及效率，实现异地、异主、跨领域的广泛互联互通；推进我国自主可控的工业互联网标识解析体系建设，培育行业标识解析生态，推动工业互联网更大范围、更高效率、更加精准地优化生产和服务资源配置，促进电子行业转型升级。
6.目前，企业中多采用erp、nc、mes等业务系统，对相应业务进行专项管理。业务系统由不通语言、不同技术架构、不同标准开发，相似系统之间数据无法通用，数据壁垒凸显。完成标识注册解析建设将会面临以下困难：
7.a.系统维护困难；
8.b.二次开发迭代仅原厂商可以进行；
9.c.新承接系统过多的重复工作；
10.d.同一业主不同系统存在数据壁垒。


技术实现要素：

11.针对现有技术的不足，本发明提供了一种新型的工业app与标识注册解析集成方
法，具备企业对于业务数据的汇聚、清洗加工、数据可视化及数据价值变现的4大核心能力的优点，解决了完成标识注册解析建设将会面临的困难的问题。
12.为实现上述目的，本发明提供如下技术方案：一种新型的工业app与标识注册解析集成方法，包括以下步骤：
13.1)低侵入快速集成标识解析。
14.2)增量数据自动完成标识注册。
15.3)将标识解析技术与电子元器件智能制造应用模式深度融合，借助标识解析为电子元器件制造产业赋能。
16.4)工业app作为数据来源，以中台为核心，通过全要素的资源接入、深层次的数据采集、异构数据的协议解析与边缘智能处理、以及接入资源的安全防护，构建资源接入能力。
17.优选的，所述步骤1)低侵入快速集成标识解析：
18.低侵入性不需要对工业app系统进行二次开发，快速集成标识解析；
19.由工业app消费主体，提供只读数据库账户、文件导入、etl数据迁移、接口调度等方式，接入中台，而实现对企业内海量数据的业务数据进行采集、储存、计算、加工；
20.以中台为核心，采集合适的业务数据，通过标识解析服务平台进行标识注册，实现对工业app的集成建设，注册的标识可在idis节点与标识解析服务平台进行标识解析。
21.优选的，所述步骤2)增量数据自动完成标识注册：
22.工业app正常运行的情况下，时间段内都会产生新的业务数据，中台通过以下三种方式，完成增量业务数据抽取：
23.a.日志分析：通过分析日志增、删、改操作，采集增量业务数据；
24.b.定时抽取：时间戳方式、定时任务调度(接口)完成增量数据的抽取；
25.c.其他方式：触发器采集、全表对比、增量字段、指定条件全量采集等方式采集增量业务数据；
26.通过中台(数据中台)将数据加工处理后，标识解析服务平台获取最新的标识业务数据完成增量标识解析注册。
27.优选的，所述步骤3)将标识解析技术与电子元器件智能制造应用模式深度融合，借助标识解析为电子元器件制造产业赋能：
28.a.工业app使用过程中产生相应的业务数据；
29.b.中台通过多种方式进行业务数据采集，保存数据至ods层作为数据镜像；
30.c.通过中台汇总各个维度的数据，并对数据进行清洗，脱敏处理等，处理后的数据报告储存至dws层；
31.d.通过标识解析服务平台对dws的报告数据进行标识注册，获得数据报告的唯一标识；
32.e.通过数据字典以及业务需求分析，使用中台进行数据集成、建模、开发、共享、治理，组合相关和相似数据，采用明细宽表，复用关联计算，减少数据扫描，统一的数据模型，建立标识与业务数据的关联。并将数据储存到ads层；
33.f.中台提供对外的解析业务api(标识解析、物流解析、订单解析、质量报告等)；
34.g.通过标识解析服务平台或中台对外开放的openapi进行解析，完成标识解析的
建设，同时为标识赋能。
35.优选的，所述步骤4)工业app作为数据来源，以中台为核心，通过全要素的资源接入、深层次的数据采集、异构数据的协议解析与边缘智能处理、以及接入资源的安全防护，构建资源接入能力；
36.中台由数据中台、业务中台以及技术中台等组成；数据中台，提供大量的适配器满足不同数据源的需求，完成(工业app)数据采集适配，数据治理、可视化分析和数据开放等功能；业务中台，承载所有的通用业务，将业务数据化，把数据与业务结合起来，实现业务数据赋能；技术中台，提供网关服务、消息服务、任务调度、缓存机制、负载均衡等资源支持；
37.标识解析公共服务平台，为企业提供租户管理、前缀注册、标识注册、标识解析以及订制应用等功能，实现业务数据的真实赋能，例：物流查询，通过解析物品的标识码，从中台业务api中获取该物品的物流信息。
38.与现有技术相比，本发明提供了一种新型的工业app与标识注册解析集成方法，具备以下有益效果：
39.该新型的工业app与标识注册解析集成方法，中台策略是工业app集成标识注册解析上优之选，是数字化代对企业组织、流程再造与技术升级，它并非一个简单的平台，而是对企业内海量数据的业务数据进行采集、储存、计算、加工与融合的产物，中台让数据与业务分离，旨在消除数据标准不一致的问题，在完成标识注册解析建设的同时，赋予企业对于业务数据的汇聚、清洗加工、数据可视化及数据价值变现的4大核心能力，最终实现企业业务数据的资产化。
附图说明
40.图1为本发明的低侵入快速集成标识解析流程图；
41.图2为本发明的增量数据自动完成标识注册流程图；
42.图3为本发明新的业务数据集，数据赋能流程图；
43.图4为本发明的借助标识解析为电子元器件制造产业赋能的流程图；
44.图5为本发明的总体架构图；
45.图6为本发明的数据中台的总体方案设计图；
46.图7为本发明的业务中台的总体方案设计图；
47.图8为本发明标识解析公共服务平台的总体构架设计图。
具体实施方式
48.下面将结合本发明的实施例，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
49.实施例：
50.一种新型的工业app与标识注册解析集成方法，包括以下步骤：
51.低侵入快速集成标识解析：
52.低侵入性不需要对工业app系统进行二次开发，快速集成标识解析；
53.由工业app消费主体，提供只读数据库账户、文件导入、etl数据迁移、接口调度等方式，接入中台，而实现对企业内海量数据的业务数据进行采集、储存、计算、加工；
54.以中台为核心，采集合适的业务数据，通过标识解析服务平台进行标识注册，实现对工业app的集成建设，注册的标识可在idis节点与标识解析服务平台进行标识解析。
55.增量数据自动完成标识注册：
56.工业app正常运行的情况下，时间段内都会产生新的业务数据，中台通过以下三种方式，完成增量业务数据抽取：
57.a.日志分析：通过分析日志增、删、改操作，采集增量业务数据；
58.b.定时抽取：时间戳方式、定时任务调度(接口)完成增量数据的抽取；
59.c.其他方式：触发器采集、全表对比、增量字段、指定条件全量采集等方式采集增量业务数据；
60.通过中台(数据中台)将数据加工处理后，标识解析服务平台获取最新的标识业务数据完成增量标识解析注册。
61.将标识解析技术与电子元器件智能制造应用模式深度融合，借助标识解析为电子元器件制造产业赋能：
62.a.工业app使用过程中产生相应的业务数据；
63.b.中台通过多种方式进行业务数据采集，保存数据至ods层作为数据镜像；
64.c.通过中台汇总各个维度的数据，并对数据进行清洗，脱敏处理等，处理后的数据报告储存至dws层；
65.d.通过标识解析服务平台对dws的报告数据进行标识注册，获得数据报告的唯一标识；
66.e.通过数据字典以及业务需求分析，使用中台进行数据集成、建模、开发、共享、治理，组合相关和相似数据，采用明细宽表，复用关联计算，减少数据扫描，统一的数据模型，建立标识与业务数据的关联。并将数据储存到ads层；
67.f.中台提供对外的解析业务api(标识解析、物流解析、订单解析、质量报告等)；
68.g.通过标识解析服务平台或中台对外开放的openapi进行解析，完成标识解析的建设，同时为标识赋能。
69.工业app作为数据来源，以中台为核心，通过全要素的资源接入、深层次的数据采集、异构数据的协议解析与边缘智能处理、以及接入资源的安全防护，构建资源接入能力；
70.中台由数据中台、业务中台以及技术中台等组成；数据中台，提供大量的适配器满足不同数据源的需求，完成(工业app)数据采集适配，数据治理、可视化分析和数据开放等功能；业务中台，承载所有的通用业务，将业务数据化，把数据与业务结合起来，实现业务数据赋能；技术中台，提供网关服务、消息服务、任务调度、缓存机制、负载均衡等资源支持；
71.标识解析公共服务平台，为企业提供租户管理、前缀注册、标识注册、标识解析以及订制应用等功能，实现业务数据的真实赋能，例：物流查询，通过解析物品的标识码，从中台业务api中获取该物品的物流信息。
72.1、工业app集成方案
73.工业app集成标识注册解析，作为业务数据来源的角色。以中台为核心通过数据采集适配，进行数据镜像。数据中台对数据进行汇总、脱敏、治理，保存报告数据至dws层，业务
中台调用标识解析平台完成标识注册。工业app提供的数据字典、业务需求分析等通过中台完成数据建模。
74.1.1、文件导入
75.第一种，是基于表头管理来进行解析，通过维护表头管理模块，使得用户可以手动在系统中增加修改对应的表头，也可以扩展定义多级表头。系统会根据用户定义好的表头信息，解析文件中的内容。excel就是解析指定表头行之后的数据，json就是解析对应的key，如果是多级表头就是解析多层嵌套的key，csv同理。解析完毕后再将数据与表头关联，这样就得到了源数据，就可以往数据湖中送了。
76.第二种是基于模板来进行解析，将用户待导入的数据抽象为一份模板，模板定义好数据结构，比如excel模板就定义好这类数据的表头在第几行，数据在第几行。json就定义好结构是怎样的，结构有几层，等等。定义好之后，用户只需要上传这部分模板，之后就能按照模板的格式进行解析。但是这种模板的方式并不能完全hold住所有类型的数据，所以，这里还有插件的机制，也就是一段代码，用户方来编写这段代码，读取数据后通过暴露特定的接口来将数据通过插件进行特殊处理。
77.两种方式各有优缺点，第一种方案对于用户方来说比较方便，不需要有代码的相关经验，也无需开发插件，系统还可以基于导入的历史表头对某一业务领域的表头关键字进行沉淀，开发自动表头识别，也就是不用为每次导入都配置特定的表头，对于一些比较标准的源数据文件，可以一键识别。第二种方案的使用对于一些会有重复导入，但是格式略有变化的场景就会不太方便。因为你需要针对每种业务场景去开发对应的插件和模板。需要用户方具有一定的开发能力。但是这种方案处理数据就更强大，几乎任何数据都能接入。
78.1.2、接口调度
79.接口也是一种非常常见的接入方式。一般由外部系统提供。有时候就会遇到一些尴尬的问题，数据中台中有提供入湖的接口，但是源数据接口是外部系统提供的，不可能单独再针对这个接口在中台里面写一个接口入湖的程序，数据中台需要将入口和出口两个接口串起来。所以数据中台里就需要一套独立的调度系统。
80.调度系统会是一套独立的系统，它不单单是仅限于数据接入，而是横跨整个数据中台的辅助系统。这里我选择了开源的轻量级调度框架xxl
‑
job，当然也可以选择使用其他的方式自己实现，比如spring schedule等等。需要实现基本的时间调度功能，可以自定义的调度器，以及围绕调度过程的日志功能等等。
81.之后就可以利用调度系统来配置一些业务上的接口调度，比如两个接口间的相互调用，从指定位置读数据等等，因为调度器是可以自定义的比如定时执行一段java代码)，所以可以适配的场景也会比较多。
82.1.3、各类etl
83.这里主要采用的是rdb数据采集mysql等)，以及来自其他数仓数据源的采集比如hive，hdfs)。该选择怎样的方案取决于实际的场景。比如湖的架构采用的是hive，那么rdb的数据采集就可以使用sqoop来做。如果是hive到hive的流向，那么则可以利用hive的thrift接口来做数据传输，再使用我们之前完成的调度系统来调度。
84.场景如果实际中还涉及到了一些复杂的逻辑，那么单纯的调度可能并不能满足我们的需求。这个时候就需要etl编程。当然你可以使用现有的模块工具比如sqoop等)加上调
度系统自己写逻辑。从代码层面来做通用逻辑是非常困难的，大部分的etl编程你只能开发出一次性的代码，而且需要有足够的开发能力才能胜任。所以这里就推荐使用一些开源的etl编程组件来做，比如kettle，datax等。推荐使用的就是kettle，因为它所支持的数据集更广，且是图形化界面操作，数据流向更清晰，且基本无需任何的代码开发能力。
85.使用kettle 调度系统来进行etl，使用carte来搭建kettle集群运行环境，再利用kettle的spoon来图形化编写好的etl流程，最后只需要将这个文件提交到carte，集群就会自动执行你的etl逻辑。而通过调度系统可以保证etl调度节点的时间性。而kettle日志收集加上调度系统的日志以及失败报警机制，可以保证etl异常时，错误可追溯，并能及时进行处理。
86.如图是kettle的主页面，支持非常多的输出输入和转换操作。
87.1.4、自动采集
88.自动采集，即日志类数据的采集场景。这类场景需要区分为两种情况，实时和非实时。
89.实时日志采集，比较常见的就是flume(cloudera底层就是采用的这个架构)，flume可以直接定义逻辑之后采集到hdfs，也可以与kafka组合实现实时的日志数据采集。而应用数据采集的架构elk，也是比较常用的。通过logstash采集之后可以到es上做聚合，再通过调度系统来进行非实时的写入，也是可行的。
90.flume是一个分布式、高可靠、高可用的海量日志聚合系统，支持在系统中定制各类数据发送方，用于收集数据，同时，flume提供对数据的简单处理，并写到各种数据接收方的能力。
91.flume提供了从console(控制台)、rpc(thrift
‑
rpc)、text(文件)、tail(unix tail)、syslog(syslog日志系统，支持tcp和udp等2种模式)，exec(命令执行)等数据源上收集数据的能力。
92.flume的数据接受方，可以是console(控制台)、text(文件)、dfs(hdfs文件)、rpc(thrift
‑
rpc)和syslogtcp(tcp syslog日志系统)等。最常用的是kafka。
93.flume的数据流由事件(event)贯穿始终。事件是flume的基本数据单位，它携带日志数据(字节数组形式)并且携带有头信息，这些event由agent外部的source生成，当source捕获事件后会进行特定的格式化，然后source会把事件推入(单个或多个)channel中。可以把channel看作是一个缓冲区，它将保存事件直到sink处理完该事件。sink负责持久化日志或者把事件推向另一个source。
94.flume以agent为最小的独立运行单位。一个agent就是一个jvm。单agent由source、sink和channel三大组件构成。
[0095][0096]
1.5、实时数据
[0097]
对于实时数据，数据湖一般会采用kafka来做存储。那么如果是外部的实时数据接入，例如kafka
‑
>kafka，使用spark streaming做消息的消费，清洗等操作并转发到另一个kafka中。如果是非实时数据的接入，那么可以使用接口调度来实现。在数据中台中提供写入kafka的接口，并通过调度系统的配置来定时往kafka中写入数据，来达到一个“实时数据”的模拟。
[0098]
2、数据中台
[0099]
总体方案设计：
[0100]
数据中台对数据的接入、数据的传输、数据的加载、数据加工处理、数据标准、数据目录、数据质量、数据共享、数据利用、数据挖掘进行全方面管控。如图6所示。
[0101]
①
、数据采集适配：
[0102]
数据采集采用适配器模式进行设计，实现适配器的可拔插、可扩展性，目前提供了大量的适配器满足不同的数据源的需求。支持数据库数据采集；半结构化数据采集；非结构化文件采集；接口服务数据采集；业务数据报送。
[0103]
a)数据库采集适配
[0104]
数据采集模块需要支持国内外主流的关系数据适配采集，并且支持多种数据增量、全量采集方式：实现数据库数据的接入适配，包括数据的全量数据、增量采集、存储入库等；
[0105]
支持国内外主流的数据库：
[0106]
数据库适配采集支持增量和全量数据采集策略采集数据，需要支持国内外主流数据库mysql、oracle、db2、sybase、sql server、informix、derby、postgresql、kingbasees金仓)、达梦等的数据采集。
[0107]
提供多种增量数据采集方式：数据库多种增量采集策略支持：时间戳方式、全表比对、增量字段标示、触发器方式、oracle cdc、mysql binlog、sqlserver cdc、postgresql slony。
[0108]
(1)触发器数据采集
[0109]
触发器数据采集是指在采集表中建立触发器，捕获增、删、改操作并记录到日志表中日志表会自动创建)，每次抽取数据从上次抽取后变化的数据；
[0110]
(2)时间戳数据采集
[0111]
时间戳方式要求被抽取表必须有一个时间戳字段，已记录每行数据的添加时间。此种抽取方式对没有时间戳字段的应用系统数据抽取局限性比较大，需要更改业务表结构，但对于有时间戳字段的表抽取规则是比较理想的抽取方式，能够迅速处理增量数据的情况，且不影响应用系统的运行效率；
[0112]
(3)全量抽取数据采集
[0113]
是指根据指定条件全部抽取数据,配置界面如下图：
[0114]
b)半结构化数据采集
[0115]
半结构化文件归集是指可以将文件数据解析成结构化数据的文件，支持xml、csv、excel、json数据的采集。产品支持从本地文件目录、ftp文件服务器、samba文件共享目录采集文件数据。
[0116]
c)非结构化文件采集
[0117]
文件交换是指将文件从不同的文件服务器中采集文件，并将文件交换到其他区域的文件服务器中。
[0118]
d)接口采集适配
[0119]
接口服务采集是指通过定时去调用第三方接口服务，然后提取返回的结果内容，并对内容进行加工处理、存储等过程。接口服务采集配置过程如下：
[0120]
一)配置采集任务的基本信息；
[0121]
二)配置数据采集接口；
[0122]
三)配置数据提取规则；
[0123]
四)配置数据存储。
[0124]
②
、数据加工处理：
[0125]
数据加工处理模块主要是完成将异构数据转换为同构，将非关系数据源转换为关系数据库数表的形式。数据预处理的方法比较多，如数据压缩、数据离散、标准化处理和概化处理等方法，依据不同的数据类型和不同需要，选择不同的预处理方法。主要包括：数据清洗、数据转换、数据加解密、数据脱敏等加工处理功能。
[0126]
a)数据清洗
[0127]
数据补缺：对空数据、缺失数据进行数据补缺操作，无法处理的做标记。
[0128]
数据替换：对无效数据进行数据的替换。
[0129]
格式规范化：将源数据抽取的数据格式转换成为便于进入仓库处理的目标数据格式。
[0130]
主外键约束：通过建立主外键约束，对非法数据进行数据替换或导出到错误文件重新处理。
[0131]
b)数据转化
[0132]
数据合并：多用表关联实现，大小表关联用lookup，大大表相交用join每个字段家索引，保证关联查询的效率)；
[0133]
数据拆分：按一定规则进行数据拆分；
[0134]
行列互换、排序/修改序号、去除重复记录；
[0135]
数据验证：loolup、sum、count；
[0136]
实现方式：在etl引擎中进行sql无法实现的)，在数据库中进行sql可以实现的)。
[0137]
c)数据加解密
[0138]
base64：“base64”是指采用base64对字段的数据进行编码或解码。
[0139]
digest：“digest”是指采用消息摘要算法对原字段的内容进行摘要提取，摘要算法：md5、sha、sha256、sha384、sha512。
[0140]
hmac：“hmac”是指采用hmac算法对源字段的数据进行摘要提取，支持hmac
‑
md5、hmac
‑
md1、hmac
‑
md256、hmac
‑
md384、hmac
‑
md512。
[0141]
对称加解密：“对称加解密”是指采用对称加解密算法对源字段进行加密处理。
[0142]
d)数据脱敏
[0143]
数据汇聚建设过程中，需要保障数据的安全，因为隐私或敏感数据的泄露，会对数据主体的财产、名誉、人身安全、以及合法利益造成严重损害。因此需要对某些敏感信息通过脱敏规则进行数据的变形，实现敏感隐私数据的可靠保护。
[0144]
数据汇聚平台需要支持多种的数据脱敏处理方法：替换、重排、加密、截断、掩码、日期偏移取整等。
[0145]
③
、可视化服务编排
[0146]
数据汇聚整合系统由于数据采集的方式、标准众多，要求需要提供灵活的集成开发环境，支持数据汇聚过程的建模、开发、集成、部署、运行、监控、维护的完整生命周期过程管理。基于b/s的可视化服务编排：提供众多数据整合、协议转换构件以及可视化的人机操作界面，只通过拖拽及配置即可实现用户信息交互的各种场景，最大限度的降低用户工作量。
[0147]
提供大量的服务模板：针对常见的业务应用场景，内置了大量的服务模板，采用向导式的参数配置即可完成服务定制。
[0148]
支持远程部署、调试：支持对编排好的服务直接进行在线部署和调试。
[0149]
提供统一的数据抽取、转换方案模板。各类业务数据的抽取和转换方案采用统一的设计思路实施，便于共享智慧，优化设计，方便维护。抽取方案采用结构化设计，将共性的功能规范为可复用模块。
[0150]
3、业务中台
[0151]
业务中台将企业的核心能力以数字化形式沉淀为各种服务中心，其目的是“提供企业能够快速，低成本创新的能力”。业务中台的核心是“构建企业共享服务中心”，其过程是通过业务板块之间的链接和协同，持续提升业务创新效率，确保关键业务链路的稳定高效和经济性兼顾的思想体系，并突出组织和业务机制。
[0152]
业务中台对外暴露的就是服务化的产品，与传统产品的不同是它是以共享服务平台的模式对外提供服务。而原来烟囱式系统建设的时候我们的产品基本上是以系统的方式对外提供服务。
[0153]
产品服务化的重点是对服务的编排，服务编排可能会分为几个层次。业务中台重点关注的是最上一层的业务场景服务层。
[0154]
总体方案设计：
[0155]
业务中台作为业务前台的数据支撑，需要保证平台的容错性，可扩展性、完整性以及可维护性。
[0156]
①
、采用微服务架构设计，有以下好处：
[0157]
(1)服务的独立部署：
[0158]
每个服务都是一个独立的项目，可以独立部署，不依赖于其他服务，耦合性低。
[0159]
(2)服务的快速启动:
[0160]
拆分之后服务启动的速度必然要比拆分之前快很多，因为依赖的库少了，代码量也少了。
[0161]
(3)更加适合敏捷开发：
[0162]
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行。服务拆分可以快速发布新版本，修改哪个服务只需要发布对应的服务即可，不用整体重新发布。
[0163]
(4)职责专一，由专门的团队负责专门的服务：
[0164]
业务发展迅速时，研发人员也会越来越多，每个团队可以负责对应的业务线，服务的拆分有利于团队之间的分工。
[0165]
(5)服务可以动态按需扩容：
[0166]
当某个服务的访问量较大时，我们只需要将这个服务扩容即可。
[0167]
(6)代码的复用：
[0168]
每个服务都提供rest api，所有的基础服务都必须抽出来，很多的底层实现都可以以接口方式提供。
[0169]
②
、业务api
[0170]
业务api指对外开放的业务数据请求接口，标识api、用户api、订单api、物流api等，可根据具体的业务场景需求定制开发接口。用于支撑标识注册解析建设的业务数据。
[0171]
③
用户中心
[0172]
把授权的逻辑与用户信息的相关逻辑独立成一个应用，称为用户中心。用户中心不处理业务逻辑，只是处理用户信息的管理以及授权给第三方应用。第三方应用需要登录的时候，则把用户的登录请求转发给用户中心进行处理，用户处理完毕返回凭证，第三方应用验证凭证，通过后就登录用户。
[0173]
④
订单中心
[0174]
搭载整个平台的订单，使用统一、稳定的模型支撑不同的业务。提供稳定、可靠、原子的订单api服务。
[0175]
⑤
、物流中心
[0176]
把物流的信息与物品的相关逻辑独立成为一个应用，称为物流中心。物流中心不处理业务逻辑，只做物流信息的汇总查询，并根据业务场景提供相应的查询入库。
[0177]
⑥
支付中心
[0178]
各业务的公共交易、支付、财务等沉淀到支付中心。快速响应业务的支付、退款以及一些基础需求，支付中心主要负责接入支付通道支付宝、微信、连连等)，由各业务线分别实现收银台，然后调用支付中心进行支付。建立基础订单、支付、财务统一体系，抽象和封装公共处理逻辑，形成统一的基础服务，降低业务的接入成本及重复研发成本。构建安全、稳定、可扩展的系统，为业务的快速发展和创新需求提供基础支撑，解决业务「快」和支付「稳」
之间的矛盾；沉淀核心交易数据，同时为用户、商家、财务提供大数据支撑。
[0179]
⑦
、商品中心
[0180]
商品中心主要分为商品相关基础数据管理模块和商品应用数据管理模块。基础数据包括品牌模块，规格模块，属性模块和分类模块。商品应用数据包括商品基础信息管理，商品销售信息管理模块。
[0181]
4、技术中台
[0182]
技术中台作为资源整合、能力沉淀的平台体系，当前台实现业务功能时，为他们提供底层的技术、数据等资源和能力的支持。
[0183]
api网关：
[0184]
①
、服务网关
[0185]
服务网关模块是单一调解，用于处理对多个服务使用者和提供者的请求。提供zuul、gateway、zookeeper等网关。任何服务网关都有如下四个典型步骤：
[0186]
常用处理
‑
一旦网关接收到消息，就对所有消息执行常用处理，例如添加协议级的头或者记录该消息。
[0187]
服务标识
‑
必须将网关所处理的消息标识为特定服务类型。例如，查询消息以确定它是针对服务提供者a、b还是c。
[0188]
端点路由
‑
当它确定某消息将传递到特定服务提供者时，它将映射到网络可寻址端点，以便可以将该消息转发到服务提供者。
[0189]
特定于服务的处理
‑
执行特定目标服务所需的任何处理。
[0190]
②
、流量控制
[0191]
提供setinel、hystrix等面向分布式服务架构的流量控制组件，主要以流量为切入点，从限流、流量整形、熔断降级、系统负载保护、热点防护等多个维度来帮助开发者保障微服务的稳定性。
[0192]
③
、服务监控
[0193]
从请求量、响应时间、错误率等指标监控微服务调用。监控的对象主要分为四层：
[0194]
基础监控：通常指对服务器本身的健康状况的监控，主要包括cpu利用率、内存使用量、io读写量、网络带宽。
[0195]
资源监控：通常指对接口依赖的外部资源的监控，如redis。
[0196]
接口监控：通常指对业务提供的功能所依赖的具体rpc接口的监控。
[0197]
用户端监控：通常指业务直接对用户提供的功能的监控。
[0198]
开发框架：
[0199]
①
、前端开放框架
[0200]
提供前端开发相关框架，vue、react、angular、qucokui、dojo、layui等。
[0201]
②
、微服务开发框架
[0202]
服务治理：
[0203]
①
、注册发现
[0204]
服务注册，构建一个注册中心，每个服务单元向注册中心登记自己提供服务的详细信息，并在注册中心形成一张注册清单，服务注册中心需要以心跳的方式去检测清单中的服务是否可用，如果不可用，需要在清单中剔除。
[0205]
服务发现,服务调用方向注册中心咨询服务，并获取所有服务的实例清单，实现对具体服务实例的访问。
[0206]
常见的注册中心：erueka、zookeeper、consul、nacos
[0207]
②
、负载均衡
[0208]
提供负载均衡相关组件支撑。服务器端负载均衡：例如nginx，通过nginx进行负载均衡，先发送请求，然后通过负载均衡算法，在多个服务器之间选择一个进行访问；即在服务器端再进行负载均衡算法分配。客户端负载均衡：例如ribbon，客户端会有一个服务器地址列表，在发送请求前通过负载均衡算法选择一个服务器，然后进行访问，这是客户端负载均衡；即在客户端就进行负载均衡算法分配。
[0209]
③
、熔断限流
[0210]
某个服务故障或者异常时，如果该服务触发熔断，可以防止其他调用方一直等待超时或者故障，从而防止雪崩。
[0211]
可以通过下述操作让故障处于可控范围：
[0212]
通过监控或者服务拓扑查看到某个服务延时较大、错误率较多后，进行服务治理。
[0213]
选择异常服务后，进行服务熔断自动设置，可自定义熔断条件，例如：在某个时间段内例如10s)请求数达到某个值，且错误率或者延时达到某个值。
[0214]
满足条件，则可以触发熔断，还可以持续测试该服务，进行自动熔断恢复。
[0215]
④
、配置管理
[0216]
对集群部署的应用配置进行修改时需要一次修改每个节点上的应用配置。
[0217]
能够按需动态加载配置，可以从多个源加载配置：内存，文件，环境变量，分布式配置中心等
[0218]
多个配置源可以合并并覆盖，可以监听配置变更，配置可以版本化管理，并可以使用指定版本。
[0219]
⑤
、链路追踪
[0220]
在分布式系统中能跟踪一个用户请求的过程(包括数据采集，数据传输，数据存储，数据分析，数据可视化)，捕获这些跟踪数据，就能构建微服务的整个调用链的视图，这是调试和监控微服务的关键工具。提供spring cloud sleuth、spring cloud zipkin等组件。
[0221]
数据处理组件：
[0222]
①
、分布式缓存
[0223]
主要提供memcached、redis及alluxio等分布式缓存组件。
[0224]
②
、分布式事务
[0225]
提供由seata、dubbo、zookeeper、redis等组合的分布式事务配置。
[0226]
③
、内存数据库
[0227]
内存dbms是一种新型的、通用型关系数据库，内存dbms服务器启动后在内存中管理整个数据库的数据。内存dbms是在要求提高事务处理速度的背景下出现的。因为内存dbms的整个数据库都在内存中，内存dbms访问磁盘的次数相对于磁盘dbms要少得多。因为整个数据库常住在内存中，数据处理算法非常简单。因为这些原因，内存dbms的性能相对于磁盘dbms要高得多。当然，内存dbms不只是性能高，同样具有磁盘dbms的各种功能。
[0228]
④
、消息中间件
[0229]
提供利用高效可靠的异步消息传递机制集成分布式系统。非底层操作系统软件，非业务应用软件，不是直接给最终用户使用的，不能直接给客户带来价值的软件统称为中间件。
[0230]
activemq：activemq是apache公司出品，最流行的，能力强劲的开源消息总线。activemq是一个完全支持jms1.1和j2ee1.4规范的jms provider实现，尽管jms规范出台已经是很久的事情了，但是jms在当今的j2ee应用中间仍然扮演者特殊的地位。特性：多种语言和协议编写客户端。语言：java,c,c ,c#,rubt,
[0231]
perl,python,php。应用协议：openwire,stomp rest,ws notification,xmpp,amqp完全支持jms1.1和j2ee 1.4规范持久化，xa消息，事务)虚拟主题、组合目的、镜像队列，消息持久化。
[0232]
rabbitmq：rabbitmq是一个开源的amqp实现，服务端采用erlang语言编写。用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。特性：支持多种客户端，如：python、ruby、.net、java、jms、c、php、actionscript等。amqp的完整实现vhost、exchange、binding、routing key等)事务支持/发布确认，消息持久化，主要用于金融行业，对安全性稳定性要求极高！
[0233]
kafka：kafka是一种高吞吐量的分布式发布订阅消息系统，是一个分布式的、分区的、可靠的分布式日志存储服务。它通过一种独一无二的设计提供了一个消息系统的功能。特性，通过o(1)的磁盘数据结构提供消息的持久化，这种结构对于即使数以tb的消息储存也能够保持长时间的稳定性能。高吞吐量：即使是非常普通的硬件，kafka也可以支持每秒数以百万的消息。
[0234]
⑤
、搜索引擎
[0235]
搜索引擎：一套可对大量结构化、半结构化数据、非结构化文本类数据进行实时搜索的专门软件。最早应用于信息检索领域，经谷歌、百度等公司推出网页搜索而为大众广知。后又被各大电商网站采用来做网站的商品搜索。现广泛应用于各行业、互联网应用。搜索引擎专门解决大量结构化、半结构化数据、非结构化文本类数据的实时检索问题。这种实时搜索数据库做不了。使用场景：信息检索(如电子图书馆、电子档案馆)网页搜索内容提供网站的内容搜索(如新闻、论坛、博客网站)电子商务网站的商品搜索如果你负责的系统数据量大，通过数据库检索慢，可以考虑用搜索引擎来专门负责检索。
[0236]
核心部件：数据源、分词器、反向索引(倒排索引)、相关性计算模型
[0237]
工作原理：从数据源加载数据，分词、建立反向索引搜索时，对搜索输入进行分词，查找反向索引计算相关性，排序，输出应用日志。
[0238]
在标识解析集成中，使用elasticsearch来储存标识的相关信息，提升检索效率。
[0239]
lucene：apache顶级开源项目，lucene
‑
core是一个开放源代码的全文检索引擎工具包，但它不是一个完整的全文检索引擎，而是一个全文检索引擎的框架，提供了完整的查询引擎和索引引擎，部分文本分词引擎(英文与德文两种西方语言)。lucene的目的是为软件开发人员提供一个简单易用的工具包，以方便的在目标系统中实现全文检索的功能，或者是以此为基础建立起完整的全文检索引擎。
[0240]
nutch：apache顶级开源项目，包含网络爬虫和搜索引擎(基于lucene)的系统(同
百度、google)。hadoop因它而生。
[0241]
solr：lucene下的子项目，基于lucene构建的独立的企业级开源搜索平台，一个服务。它提供了基于xml/json/http的api供外界访问，还有web管理界面。
[0242]
elasticsearch：基于lucene的企业级分布式搜索平台，它对外提供restful
‑
web接口，让技术人员可以轻松、方便使用搜索平台，而不需要了解lucene。
[0243]
分布式数据：
[0244]
①
、oltp数据库
[0245]
oltp(online transactional processing，联机事务处理)是专注于面向事务的任务的一类数据处理，通常涉及在数据库中插入，更新或删除少量数据，主要是处理大量用户下的大量事务。
[0246]
②
、olap数据库
[0247]
olap，也叫联机分析处理online analytical processing)系统，有的时候也叫dss决策支持系统，即数据仓库。在系统中，语句的执行量不是考核标准，因为一条语句的执行时间可能会非常长，读取的数据也非常多。所以，在这样的系统中，考核的标准往往是磁盘子系统的吞吐量带宽)，如能达到多少mb/s的流量。在olap系统中，常使用分区技术、并行技术。
[0248]
③
、htap数据库
[0249]
数据湖是一种在系统或存储库中以自然格式存储数据的方法，它有助于以各种模式和结构形式配置数据，通常是对象块或文件。数据湖的主要应用是对企业中的所有数据进行统一存储，从原始数据这意味着源系统数据的精确副本)转换为用于报告、可视化、分析和机器学习等各种任务的转换数据。湖中的数据包括结构化数据从关系数据库行和列)，半结构化数据csv、xml、json的日志)，非结构化数据电子邮件，文档，pdf)和二进制数据图像、音频、视频)从而形成一个集中式数据存储容纳所有形式的数据。
[0250]
hive数据库，批量分析处理的最佳选择。
[0251]
hbase数据库，实时并发查询最佳选择。
[0252]
5、标识解析公共服务平台
[0253]
①
、标识解析总体架构
[0254]
标识解析应用分为前置系统和后置系统，主要包含了账户注册、租户管理、标识注册、标识查询、前缀管理、数据模板、统计分析、及其他等功能；采用微服务架构，产品与开发模块使用java语言开发，使用目前主流、先进、通用的技术栈，包含spring boot、spring cloud、devops、vue、mybatis、redis、mogondb等。
[0255]
标识解析应用通过数据中台提供的业务api,获取到正确格式的业务数据。进行标识注册，并通过租户id进行数据隔离。
[0256]
②
、企业注册
[0257]
提供企业注册接口，完成企业相关信息注册。企业基本资质信息新增、修改、发起申请管理，申请结果返回信息管理
[0258]
③
、前缀申请
[0259]
对申请的前缀进行初审、终审、通过与不通过管理；对申请的前缀进行唯一校验，同一企业只能注册一个前缀标识。
[0260]
④
、标识注册
[0261]
通过数据中台提供业务api，进行标识注册；在标识注册模块自定义标识注册。
[0262]
⑤
、标识解析
[0263]
根据国家公共递归查询平台、二维码扫描、接口调用形式解析标识数据及在终端(pc、h5、小程序)展示。
[0264]
通过标识名称，查询出标识本身所代表的标识信息。
[0265]
例：88.103.10/s.g.zjbg.7994393286031228929
[0266]
物流解析：
[0267]
每个产品都有自己独立的标识。通过产品的标识，在中台中获取物流信息，将其物流信息解析出来。
[0268]
本发明的有益效果是：
[0269]
中台策略是工业app集成标识注册解析上优之选，是数字化代对企业组织、流程再造与技术升级，它并非一个简单的平台，而是对企业内海量数据的业务数据进行采集、储存、计算、加工与融合的产物，中台让数据与业务分离，旨在消除数据标准不一致的问题，在完成标识注册解析建设的同时，赋予企业对于业务数据的汇聚、清洗加工、数据可视化及数据价值变现的4大核心能力，最终实现企业业务数据的资产化。
[0270]
服务保障：
[0271]
安全保密原则
[0272]
系统将具备统一完善的多级安全机制设置，符合国家安全及保密部门要求，拒绝非法用户和合法用户越权操作，避免系统数据遭到破坏，防止系统数据被窃取和篡改，对于关键信息使用加密传输，传输的数据文件提供不可抵赖性确认。
[0273]
网络安全
[0274]
为了抵抗恶意或传播的安全隐患，系统将对传输包和传输途径都进行加密和监管。在软件中对下载代码也进行分析和甄别。如果必要，可以结合物理隔离卡。对非法侵入、非法攻击和网络计算机病毒具有很强的防范能力。
[0275]
应用软件将具有相应的容错手段、操作回滚功能，保证系统的健壮性和数据完整性。
[0276]
为确保系统的安全性，系统采取应用系统使用验证操作员验证)、数据库登陆验证相结合的方法验证用户。运用日志，对进入系统的用户的操作进行记录,根据日志进行事后分析，从而找到事故的发生原因、责任者或非法用户。
[0277]
其它安全：
[0278]
1)建立安全的管理制度；
[0279]
2)保证网络安全；
[0280]
3)保证系统安全；
[0281]
4)解决系统异常应急处理；
[0282]
5)确保数据访问安全；
[0283]
6)保障数据存储安全；
[0284]
7)提供安全的维护机制。
[0285]
尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以
理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同物限定。