一种运用于轨道交通分布式调度系统的通信架构的制作方法

1.本发明涉及轨道交通技术领域，尤其涉及一种运用于轨道交通分布式调度系统的通信架构。


背景技术：

2.传统的调度系统基本都是单线的调度管理系统，是专有接口的单一供应商解决方案，每个供应商系统采用的技术、架构、接口各异，多供应商系统难于融合。大部分系统使用传统技术栈c 、c#开发的c/s软件，系统架构基本是单体系统架构，这些技术已经不是当前的主流开发技术。
3.传统的调度系统的通信协议一般是采用tcp、udp等常规协议，通信逻辑相对简单；数据格式采用自定义的二进制为主，数据多源异构标准不统一。
4.当前的轨道交通调度系统面向的是多条线、线网级别的调度管理系统，在设计、技术实现与传统的调度系统存在巨大差异，故采用传统的调度系统的数据通信明显是不适用的，因此需要结合分布式系统的特点进行设计、技术选型。


技术实现要素：

5.本发明提供一种运用于轨道交通分布式调度系统的通信架构，用以解决现有技术中传统的数据通信不适用于分布式调度系统的不足，能有效地满足复杂的分布式调度系统的数据通信需求。
6.第一方面，本发明提供一种运用于轨道交通分布式调度系统的通信架构，包括：在所述轨道交通分布式调度系统内部包括平台层和应用层的情况下，所述应用层的数据服务平台与所述轨道交通分布式调度系统的前端应用展示层之间通信连接；所述平台层的能力开放平台与其它三方系统之间通信连接；
7.在所述平台层和所述应用层的所有微服务之间，通过restful接口以及消息队列通信的方式进行通信；
8.所述数据服务平台通过应用程序接口api网关以及推送服务协议，实现与所述前端应用展示层之间的通信；
9.所述能力开放平台通过消息队列通信以及微服务扩展的方式，实现与其它三方系统之间的通信。
10.根据本发明提供的一种运用于轨道交通分布式调度系统的通信架构，所述数据服务平台具体通过应用程序接口api网关的restful接口以及推送服务的全双工通信协议websocket，实现与所述前端应用展示层之间的通信。
11.根据本发明提供的一种运用于轨道交通分布式调度系统的通信架构，所述能力开放平台与所述其它三方系统之间的通信采用的消息队列通信的方式采用以下消息中间件中的至少一种：rabbitmq和kafka。
12.根据本发明提供的一种运用于轨道交通分布式调度系统的通信架构，所述能力开
放平台与所述其它三方系统之间的通信采用的微服务扩展的方式，包括采用以下通信协议中的至少一种：超文本传输协议http、传输控制协议tcp、用户数据报协议udp、全双工通信协议websocket以及文件传输协议ftp。
13.根据本发明提供的一种运用于轨道交通分布式调度系统的通信架构，所述其它三方系统包括以下系统中的至少一种：行车综合自动化系统tias、列车自动监控系统ats、视频监控系统cctv、设备监控系统bas和乘客信息系统pis。
14.根据本发明提供的一种运用于轨道交通分布式调度系统的通信架构，所述restful接口，用于实现非实时数据信息的传输；所述消息队列通信，用于实现实时数据信息的传输。
15.根据本发明提供的一种运用于轨道交通分布式调度系统的通信架构，所述实时数据信息采用统一的数据规范；所述统一的数据规范包括以下内容中的至少一种：消息模型、通信指令、超时机制、通信流程；
16.所述消息模型包括以下内容中的至少一种：消息内容、消息类型、消息组成结构和消息字段定义；
17.所述通信指令包括以下内容中的至少一种：命令、信息、告警、心跳、回执和应答；
18.所述超时机制包括以下内容中的至少一种：超时认定时长、超时重发次数；
19.所述通信流程包括以下内容中的至少一种：命令流程、信息交互流程、告警流程、心跳流程和通知流程。
20.本发明提供的一种运用于轨道交通分布式调度系统的通信架构，采用系统分层设计，从系统内部、前端应用和其它三方系统三个层面的集成，制定统一数据通信规范，将系统内部各层的通信协议标准化，使用互联网先进技术并结合传统技术，降低分布式调度系统的设计、实现的复杂度，解决了大型分布式调度系统的数据通信。
附图说明
21.为了更清楚地说明本发明或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
22.图1是本发明提供的轨道交通分布式调度系统的通信架构示意图；
23.图2是本发明提供的数据服务平台与前端应用展示层进行数据通信的架构图；
24.图3是本发明提供的能力开放平台与其它三方系统进行数据通信的架构图；
25.图4是本发明提供的消息组成结构的示意图；
26.图5是本发明提供的命令通信流程的信令示意图；
27.图6是本发明提供的消息通信流程的信令示意图之一；
28.图7是本发明提供的消息通信流程的信令示意图之二；
29.图8是本发明提供的告警通信流程的信令示意图；
30.图9是本发明提供的心跳通信流程的信令示意图；
31.图10是本发明提供的通知通信流程的信令示意图。
具体实施方式
32.为使本发明的目的、技术方案和优点更加清楚，下面将结合本发明中的附图，对本发明中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
33.需要说明的是，在本发明实施例的描述中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、物品或者设备中还存在另外的相同要素。术语“上”、“下”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。除非另有明确的规定和限定，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。
34.本技术的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象，而不用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便本技术的实施例能够以除了在这里图示或描述的那些以外的顺序实施，且“第一”、“第二”等所区分的对象通常为一类，并不限定对象的个数，例如第一对象可以是一个，也可以是多个。此外，说明书以及权利要求中“和/或”表示所连接对象的至少其中之一，字符“/”，一般表示前后关联对象是一种“或”的关系。
35.轨道交通分布式调度系统面向的是多条线、线网级别的调度管理系统，是采用微服务、互联网主流开源技术实现的分布式系统。分布式调度系统的通信架构在设计、技术实现与传统的调度系统存在巨大差异，因此需要结合分布式系统的特点进行设计以及技术选型。
36.由于分布式调度系统是基于微服务实现的全球广域网(world wide web，web)技术架构，其数据通信比传统的调度系统复杂的多，微服务之间的调用成网状结构。由于整个分布式调度系统的通信架构涉及综合监控的业务需求，需要与多个三方系统通信，要兼容不同通信协议和多源异构的数据格式。加之，整个分布式调度系统与系统前端的应用展示层的交互要采用轻量级的通信协议。因此，当前的运用于轨道交通分布式调度系统的通信架构的通信数据，应从技术、业务、架构、应用多个层面考虑，要兼顾整个系统的通信实现。设计最佳的数据通信方案，结合新技术降低系统的设计、实现复杂度，解决复杂的分布式系统数据通信，是本发明所要重点解决的问题。
37.在此之前，先对本发明所出现的一些技术术语作出如下解释：
38.restful(representational state transfer)，是一种网络应用程序的设计风格和开发方式，基于超文本传输协议(hyper text transfer protocol，http)，可以使用xml格式定义或json格式定义。restful适用于移动互联网厂商作为业务接口的场景，实现第三
方应用服务(over the top，ott)调用移动网络资源的功能，动作类型为新增、变更、删除所调用资源。运用于轨道交通分布式调度系统的通信架构中的各微服务之间可以通过http协议的restful接口开放服务。
39.rabbitmq(rabbit message queue)一种程序对程序的通信方法，是实现了高级消息队列协议(advanced message queuing protocol，amqp)的开源消息代理软件(亦称面向消息的中间件)。rabbitmq是用erlang语言编写的，而集群和故障转移是构建在开放电信平台框架上的，所有主要的编程语言均有与代理接口通讯的客户端库。
40.kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。
41.消息队列，在本发明中主要是指实时消息队列(real time messages，rtm)，消息(message)是指在应用之间传送的数据，消息可以非常简单，比如只包含文本字符串，也可以更复杂，可能包含嵌入对象。
42.消息队列(message queue,mq)是一种应用间异步协作机制的通信方式，消息发送后可以立即返回，有消息系统来确保信息的可靠专递，消息发布者只管把消息发布到mq中而不管谁来取，消息使用者只管从mq中取消息而不管谁发布的，这样发布者和使用者都不用知道对方的存在。
43.api网关(application programming interface gataway，api gataway)，是指将所有api的调用统一接入api网关层，由网关层负责接入和输出。两个相互独立的局域网之间通过路由器进行通信，中间的路由被称之为网关。任何一个应用系统如果需要被其他系统调用，就需要暴露api，这些api代表着一个一个的功能点。如果两个系统中间通信，在系统之间加上一个中介者协助api的调用，这个中介者就是api网关
44.全双工通信协议websocket是一种在单个tcp连接上进行全双工通信的协议，使得轨道交通分布式调度系统与应用展示层之间的数据交换变得更加简单，允许分布式调度系统主动向应用展示层推送数据。在websocket api中，分布式调度系统与应用展示层只需要完成一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。
45.传输控制协议(transmission control protocol，tcp)，提供了完善的错误控制和流控制能够确保数据正确传输，它是一个面向连接的协议，是一种面向连接的、可靠的、基于字节流的传输层通信协议，由ietf的rfc793定义。在简化的计算机网络的开放式系统互联通信(open system interconnection，osi)参考模型中，其主要完成第四层传输层所指定的功能，是位于网际互连协议(internet protocol，ip)层之上，应用层之下的中间层。
46.用户数据报协议(user datagram protocol，udp)，是osi参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务，udp协议的正式规范是ietf rfc 768。udp协议能够为应用程序提供了一种无需建立连接就可以发送封装的ip数据包的方法。
47.internet的传输层有两个主要协议，互为补充。无连接的是udp协议，它除了给应用程序发送数据包功能并允许它们在所需的层次上架构自己的协议，面向连接的是tcp协议。
48.udp协议与tcp协议一样用于处理数据包，在osi参考模型中，两者都位于传输层，处于ip协议的上一层。udp协议用来支持那些需要在计算机之间传输数据的网络应用。许多
应用只支持udp协议，如：音频和多媒体应用等。
49.文件传输协议(file transfer protocol，ftp)，是用于在网络上进行文件传输的一套标准协议，允许轨道交通分布式调度系统与其它三方系统之间以文件操作的方式(如文件的增、删、改、查、传送等)相互通信。
50.列车自动监控系统(automatic train supervision，ats)，是一套集现代化数据通信、计算机、网络和信号技术为一体的、分布式的实时监督、控制系统，ats通过与列车自动控制系统(automatic train control，atc)中的其他子系统的协调配合，共同完成对地铁运营列车和信号设备的管理和控制。其核心设备位于信号系统的中央层，用于实现对高密度、大流量的城市轨道交通运输进行自动化管理和调度，是一个综合的行车指挥调度控制系统。
51.行车综合自动化系统tias(train internet automatic system)，是以行车指挥为核心的兼容电调、环调功能的行车系统，能实现电力监控系统、环境与设备监控系统、自动列车见监控系统等不同的业务应用功能，完成行车信息和机电设备信息之间的联动。
52.视频监控系统(closed circuit television，cctv)是一项综合性的保安系统，具有接入层的终端设备数量众多(高清摄像机数量多)、带宽需求巨大(每个高清摄像机的平均带宽不低于8mbps，峰值带宽可以达到16mbps)、接入距离长短不一、网络管理复杂(有很高的实时管理监控及维护的管理要求)等数据通信特点。
53.设备监控系统(building automation system，bas)，采用计算机网络、自动控制、通讯及分布智能等技术，实现地铁环境与设备系统的三级控制管理模式，对地铁车站及区间隧道内的空调通风、给排水、照明、电、扶梯、安全门等机电设备进行全面的运行管理与控制。同时，bas系统还能够对在地下车站发生火灾事故的情况下，执行相应防灾和阻塞模式，使有关救灾设施按照设计工况及时有效地运行，充分发挥各种设备应有的作用，保证乘客的安全和设备的正常运行。
54.乘客信息系统(passenger information system，pis)是列车系统的一个重要组成部分，是列车为乘客提供信息和服务的关键平台，是依托多媒体网络技术，以计算机系统为核心，通过列车的显示终端，让乘客及时准确地了解列车运营信息和公共媒体信息的多媒体综合信息系统。乘客信息系统采用冗余环网连接方式，以多媒体播放的形式向乘客提供当前线路的车站信息和换乘信息；遇到紧急情况，乘客可以通过报警装置通知地铁工作人员进行处理；实时监控列车车厢，保存监控录像；支持灵活的时间周期广告业务，如按周、月、年等。
55.下面结合图1-图10描述本发明所提供的运用于轨道交通分布式调度系统的通信架构。
56.图1是本发明提供的轨道交通分布式调度系统的通信架构示意图，如图1所示，在所述运用于轨道交通分布式调度系统的通信架构内部包括平台层和应用层的情况下，所述应用层的数据服务平台与所述轨道交通分布式调度系统的前端应用展示层之间通信连接；所述平台层的能力开放平台与其它三方系统之间通信连接。
57.本发明提供的运用于轨道交通分布式调度系统的通信架构，是采用微服务实现的基于web技术的系统平台，涉及综合监控业务需求，与多个三方系统实现双向通信，支撑各种前端应用运行。
58.在本发明中主要是通过从数据通信的角度，展示所提供的运用于轨道交通分布式调度系统的通信架构，这个数据通信方案从技术选型、业务需求、系统架构、前端应用多个维度考虑，通过选择合理的通信协议、消息模型，结合新技术以降低分布式调度系统的设计和实现的复杂度，解决复杂的分布式系统的数据通信。
59.本发明提供的运用于轨道交通分布式调度系统的通信架构，采用了系统分层的方法，通过将整个分布式调度系统分成平台层和应用层等多个服务层，每个服务层由若干微服务组成，微服务之间成网状相互调用。同时在平台层中划分出能力开放平台，在应用层中划分出数据服务平台，以在每个层内和层间，使用互联网先进技术(微服务、容器、消息队列、restful、websocket等)，兼容传统技术(c 、c#、tcp、udp等)，相互融合，以选择合理的通信技术，降低实现复杂度。
60.一方面，数据服务平台作为分布式调度系统与其它三方系统集成的边界，主要功能包括：适配不同三方系统的通信协议，如：http协议、tcp协议、udp协议、websocket协议、ftp协议等；实现其它三方系统的多源异构通信数据与分布式调度系统的标准消息模型的转换。
61.数据服务平台集成有多供应商专业系统(即其它三方系统)，通过与多个三方系统的双向通信，进行系统联动，研发新的智能功能。通过能力开放平台的通信协议适配能力、数据模型转换能力可以实现分布式调度系统与三方系统双向通信，实现跨平台通信。
62.另一方面，分布式调度系统采用分层设计，且前端与后端分离的分布式架构。后端也即是系统内部包括平台层和应用层，前端主要是指前端应用层，前端应用层主要包括pc(web、c/s)、大屏、手机、pad以及其他设备，对此本发明不作具体的限定。通过处于后端应用层的数据服务平台开放相应的服务接口，支撑前端应用层的各种前端应用的运行。
63.本发明提供的运用于轨道交通分布式调度系统的通信架构，采用系统分层设计，从系统内部、前端应用和其它三方系统三个层面的集成，制定统一数据通信规范，将系统内部各层的通信协议标准化，使用互联网先进技术并结合传统技术，降低分布式调度系统的设计、实现的复杂度，解决了大型分布式调度系统的数据通信。
64.基于上述实施例的内容，作为一种可选实施例，本发明所提供的运用于轨道交通分布式调度系统的通信架构，涉及了如何建立系统内部微服之间通信机制，包括：在所述平台层和所述应用层的所有微服务之间，通过restful接口以及消息队列通信的方式进行通信。
65.数据服务平台与应用层中的部分微服务，如调度服务之间的非实时数据通信可以采用restful接口开放微服务数据服务；数据服务平台与应用层中的部分微服务如辅助决策服务之间的实时数据通信，可以采用rtm通信的方式进行实时消息通信。
66.同时平台层中的能力开放平台也可以通过rtm通信的方式与平台层中的其它微服务进行数据通信。
67.另外，应用层与平台层中的各个微服务也可以通过restful接口或者rtm通信的方式建立数据通信。
68.分布式调度系统内部，采用分层设计实现，在业务方面涉及综合监控的数据采集、告警、指令控制等需求，综合监控的实时消息需要实时传输。
69.综合监控的实时消息通常在多个微服务之间、跨不同的服务层进行实时传输。采
用传统的长连接方式(tcp或websocket)实现太复杂，难于维护。通过消息队列(rabbitmq或kafka)通信，降低了系统的设计复杂度，易于实现、维护。
70.消息队列通信是一种应用间的通信方式，消息发送后可以立即返回，由消息系统来确保消息的可靠传递。根据业务需求选择成熟的消息中间件rabbitmq或kafka，消息队列对应用屏蔽通信的复杂性，提升系统异步通信、扩展解耦能力。
71.消息队列通信常用的消息通道方式，包括：
72.1)点对点式，消息发送者发送消息，消息代理将其放入一个队列中，消息接收者从队列中获取消息内容，消息读取后被移出队列，消息只有唯一的发送者和接受者。
73.2)发布订阅式，发送者(发布者)发送消息到主题，多个接收者(订阅者)监听(订阅)这个主题，那么就会在消息到达时同时收到消息。
74.需要说明的是微服务框架，提供了对消息队列(采用rabbitmq/kafka)开发工具包，支持开箱即用，以便于分布式调度系统实现与rabbitmq/kafka的通信。
75.本发明提供的运用于轨道交通分布式调度系统的通信架构，采用系统分层的方法，在层间根据数据通信的需要，选择使用互联网先进技术以及传统技术，有效地降低了分布式调度系统的设计、实现复杂度。
76.基于上述实施例的内容，作为一种可选实施例，所述数据服务平台通过应用程序接口api网关以及推送服务协议，实现与所述前端应用展示层之间的通信。
77.图2是本发明提供的数据服务平台与前端应用展示层进行数据通信架构图，如图2所示，本发明提供的分布式调度系统，其后端的数据服务平台与前端应用层之间的通信方式可以采取：
78.1)api网关，即通过http协议的restful接口开放后端平台服务；
79.2)推送服务，即通过websocket协议实现实时消息的通信。
80.一方面，分布式调度系统后端的数据服务平台，通过api网关http协议的restful接口开放服务，支撑各种前端应用功能。基于http的restful接口，不仅能支持web应用、手机、pad移动应用，同时也支持传统开发语言c 、c#开发的c/s应用程序。api网关支撑所有前端应用非实时消息需求。
81.另一方面，分布式调度系统后端的数据服务平台，通过推送服务解决综合监控的数据监测、告警、指令控制等业务需求。
82.其中，推送服务是基于长连接的websocket服务端：前端展示层的相关应用作为客户端，通过websocket协议连接到推送服务，通过握手机制建立连接，定期发送心跳消息机制保持连接状态。
83.websocket协议不仅能支持web应用、手机、pad移动应用，同时也支持传统的c/s应用程序。推送服务支撑所有前端应用实时消息需求。
84.另外，分布式调度系统可以采用oauth2(开放授权)基于令牌(token)的认证授权。oauth2是一个开放标准，oauth2令牌可以采用jwt(json web token)，结合rbac授权模型，根据用户、角色、应用端类型实现restful接口、websocket协议接口的原子权限控制。
85.本发明提供的交通分布式调度系统，通过api网关的restful接口、推送服务的websocket协议，建立后端数据服务平台与前端应用层之间的数据通信，为前端应用提供了轻量级的通用先进方案。
86.基于上述实施例的内容，作为一种可选实施例，所述能力开放平台通过消息队列通信以及微服务扩展的方式，实现与其它三方系统之间的通信。
87.可选地，所述能力开放平台与所述其它三方系统之间的通信采用的消息队列通信的方式采用以下消息中间件中的至少一种：rabbitmq和kafka。
88.由于其它三方系统的开放接口的通信协议不统一，大部分采用传统的tcp、udp等，且其通信数据的格式大部分采用自定义二进制格式，故形成多源异构的数据。
89.图3是本发明提供的能力开放平台与其它三方系统进行数据通信架构图，如图3所示，分布式调度系统与其它三方系统的通信方式，主要可以采取以下几种：
90.1)发布-订阅，是能力开放平台的标准通信方式，通过消息队列(如rabbitmq/kafka)提供标准的数据访问接口、规范的消息模型与三方系统实现双向通信。
91.2)泛链接，本发明将发布-订阅以外的所有其它通信方式统称未泛链接。泛链接是指以微服务扩展的方式解决特殊通信方式、特殊数据格式(二进制、文件、日志等)的通信，完成多源异构数据与规范的消息模型相互转换，实现与三方系统的双向通信。
92.可选地，所述能力开放平台与所述其它三方系统之间的通信采用的微服务扩展的方式，包括采用以下通信协议中的至少一种：超文本传输协议http、传输控制协议tcp、用户数据报协议udp、全双工通信协议websocket以及文件传输协议ftp。
93.本发明提供的运用于轨道交通分布式调度系统的通信架构，从技术选型、业务需求、系统架构、前端应用多个维度考虑，设计实现的先进、通用数据通信方案，尤其是提供其他三方系统通过能力开放平台的消息队列发布-订阅机制、微服务扩展的通信方式实现通信，能够有效地支撑各种前端应用运行。
94.基于上述实施例的内容，作为一种可选实施例，本发明提供了一种运用于轨道交通的分布式调度系统，所述其它三方系统包括以下系统中的至少一种：行车综合自动化系统tias、列车自动监控系统ats、视频监控系统cctv、设备监控系统bas和乘客信息系统pis。
95.接下来以其中的行车综合自动化系统tias、列车自动监控系统ats与本发明所提供的运用于轨道交通分布式调度系统的通信架构进行数据通信为例进行说明，其实现方式可以是：
96.关于列车自动监控系统ats，由于ats开放的接口采用二进制数据格式、udp通信协议，故ats接入分布式调度系统可以采用两种方式：
97.方式1：ats按照分布式调度系统的通信数据，规范定义通信数据，通过消息队列(rabbitmq/kafka)提供标准的数据访问接口进行通信。
98.方式2：分布式调度系统开发相应的微服务，通过udp协议的方式与ats进行二进制通信，该微服务把二进制数据转化为标准消息模型，以实现两者的数据通信。
99.关于行车综合自动化系统tias，由于tias开放的接口是采用二进制数据格式、udp通信协议，故其接入分布式调度系统的方式与ats相同。
100.本发明构建的运用于轨道交通分布式调度系统的通信架构，采用系统分层设计，从系统内部、前端应用和其它三方系统三个层面的集成，制定统一数据通信规范，将系统内部各层的通信协议标准化，使用互联网先进技术并结合传统技术，降低分布式调度系统的设计、实现的复杂度，解决了大型分布式调度系统的数据通信。
101.基于上述实施例的内容，作为一种可选实施例，所述restful接口，用于实现非实
时数据信息的传输；所述消息队列通信，用于实现实时数据信息的传输。
102.本发明提供的分布式调度系统的通信数据，可以分为实时数据和非实时数据，实时数据主要是综合监控的监测、告警、指令控制等业务数据，其他都是非实时数据。
103.非实时数据主要通过http协议的restful接口通信，通信流程、超时机制采用基本的http标准，消息模型采用简洁的json格式，根据实际业务需求定义。非实时数据的数据通信规范比较简单，本专利不再进一步设计。
104.实时数据的通信比较复杂，本发明中提到的数据通信规范就是针对实时数据通信的设计，如果没有特别说明数据通信规范就是指实时数据通信。
105.作为一种可选实施例，在本发明提供的分布式调度系统中，实时数据信息采用统一的数据规范；
106.所述统一的数据规范包括以下内容中的至少一种：消息模型、通信指令、超时机制、通信流程；
107.所述消息模型包括以下内容中的至少一种：消息内容、消息类型、消息组成结构和消息字段定义；
108.所述通信指令包括以下内容中的至少一种：命令、信息、告警、心跳、回执和应答；
109.所述超时机制包括以下内容中的至少一种：超时认定时长、超时重发次数；
110.所述通信流程包括以下内容中的至少一种：命令流程、信息交互流程、告警流程、心跳流程和通知流程。
111.具体来说，本发明综合技术架构和业务需求，所提供的分布式调度系统的数据通信要实现以下功能：
112.1)数据通信规范，包括：消息模型、通信指令、超时机制、通信流程；
113.2)系统内部通信：调度系统内部微服务之间数据通信；
114.3)与其它三方系统的数据通信：调度系统与集成的三方系统之间数据通信；
115.4)与前端应用的数据通信：调度系统前后端分离，后端平台与前端应用的数据通信。
116.其中功能2)-4)已经在前面的实施例中给予了说明，在此不作赘述。先就本发明所实施的数据通信规范进行详细说明：
117.本发明分布式调度系统的数据通信规范采用统一的消息模型、通信指令、通信流程、超时机制。通用的规范为系统内部数据传输提供标准，为三方系统集成提供数据转换标准，为前端应用提供实时消息数据标准。
118.一、关于消息模型
119.1)消息内容是指分布式调度系统数据传输的通信数据包，数据包采用json格式。
120.2)分布式调度系统的消息类型，主要包括：命令、信息、告警、通知、应答、回执、心跳等。
121.3)图4是本发明提供的消息组成结构的示意图，表1是本发明提供的消息字段定义列表，结合图4和表1所示，一个消息字段主要包括以下部分：消息id、消息类型、服务id、微服务id、消息体、调用链id、调用链序号、签名、时间戳和路由链等。其中，消息体中包含有相应消息字段的通信指令。
122.表1消息字段定义列表
[0123][0124]
二、关于通信指令，主要包括以下几种：
[0125]
1)命令指令：控制命令，请求执行操作，执行方收到命令消息发送回执消息，命令执行完成发送应答消息；
[0126]
信息：数据信息、报送数据，回执消息根据需求可选；
[0127]
告警：系统发生故障、应急时，系统发出的告警信息；
[0128]
通知：控制过程执行的进度反馈；
[0129]
心跳：定时发送心跳包，保持存活状态，确保连接有效的机制；
[0130]
回执：对收到通信指令的反馈；
[0131]
应答：命令的执行结果。
[0132]
三、关于超时机制的规范化，主要包括以下几点：
[0133]
1)一个通信指令发出后在规定的时间内未收到回执，认为超时；
[0134]
2)对于超时时间，可以根据具体的通讯方式和任务性质定义(默认3秒)；
[0135]
3)对于超时重发次数，可以根据具体的通讯方式和任务性质定义(默认重发1次)。
[0136]
4)对于超时后重发，可以规定重发规定次数后仍未收到回执认为通讯失败，通讯结束。
[0137]
四、关于通信流程的规范化，本发明提供的分布式调度系统数据通信指令主要包括：命令、信息、告警、心跳、通知等，现结合相关的附图对各种通信指令的具体通信流程进行简要说明。
[0138]
图5是本发明提供的命令通信流程的信令示意图，如图5所示，其中服务service-a和服务service-b分别为分布式调度系统中的两个不同微服务，或者其中一个是其它三方系统的服务器。其整个通信流程主要包括以下步骤：
[0139]
1)服务service-a向服务service-b发送命令消息；
[0140]
2)服务service-b收到命令消息，向服务service-a发送回执消息；
[0141]
3)服务service-b执行命令；
[0142]
4)服务service-b执行完命令，把执行结果通过应答消息发送给服务service-a；
[0143]
5)通信流程结束。
[0144]
图6是本发明提供的消息通信流程的信令示意图之一，如图6所示，其整个通信流程主要包括以下步骤：
[0145]
1)服务service-a向服务service-b发送信息消息；
[0146]
2)服务service-b收到信息消息，向服务service-a发送回执消息；
[0147]
3)通信流程结束。
[0148]
图7是本发明提供的消息通信流程的信令示意图之二，如图7所示，其整个通信流程也可以仅包括以下步骤：
[0149]
1)服务service-a向服务service-b发送信息消息；
[0150]
2)通信流程结束。
[0151]
图8是本发明提供的告警通信流程的信令示意图，如图8所示，其整个通信流程可以包括以下步骤：
[0152]
1)服务service-a向服务service-b发送告警消息；
[0153]
2)服务service-b收到告警消息，向服务service-a发送回执消息；
[0154]
3)通信流程结束。
[0155]
图9是本发明提供的心跳通信流程的信令示意图，如图9所示，其整个通信流程可以包括以下步骤：
[0156]
1)服务service-a向服务service-b发送心跳消息；
[0157]
2)服务service-b收到心跳消息，向服务service-a发送回执消息；
[0158]
3)通信流程结束。
[0159]
图10是本发明提供的通知通信流程的信令示意图，如图10所示，其整个通信流程可以包括以下步骤：
[0160]
1)服务service-a向服务service-b发送通知消息；
[0161]
2)服务service-b收到通知消息，向服务service-a发送回执消息；
[0162]
3)通信流程结束。
[0163]
以上所描述的实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。
[0164]
最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。