一种基于区块链的城市自然灾害监测应急管理调度平台的制作方法

1.本发明属于区块链及城市安全技术领域，特别涉及一种基于区块链的城市自然灾害监测应急管理调度平台。


背景技术：

2.近年来，城市自然灾害频繁发生，造成了大量的人员伤亡和财产损失。对于这些自然灾害的预测和应急是我国社会经济发展中亟待解决的重大问题。城市作为人类与各类经济活动高度聚集地，若要保证人员的安全和社会经济的稳定发展，则需要大力推进城市自然灾害防御工程建设，建立城市自然灾害监测预警系统。
3.目前，现有的自然灾害监测预警系统存在以下问题：
4.1)现今的物联网平台架构技术使得基于物联网的灾害监测预警应用与相关设备仍然保持垂直开发模式，导致设备之间很难进行直接的数据与控制交互，并且不同灾害监测预警系统间也无法直接进行互联互通。因此建立的联动应急系统信息传递不顺畅，信息共享实现不高，信息没有得到充分的处理。
5.2)采用了大量的物联网设备并运用中心化管理。中心化的架构会出现以下几个问题：随着物联网技术的发展，每一类灾害监测预警系统中接入设备类型也呈现爆发式增长，如此一来通信量将显著增长，中心系统的负荷会越来越大，性能降低以及出故障的概率会增大；一旦中心系统因为需要维护，收到攻击或者故障而关闭，可能会造成数据丢失，引发严重后果；物联网设备如果受到攻击，会可能会通过执行拒绝服务(ddos)攻击或者更改收集的数据来破坏整个网络。因此，一旦中心系统或者物联网设备出现问题，整个系统就会遭受威胁。
6.3)在防灾救灾管理中，形成了“重救轻防”的观念，应急管理中采取事后控制，导致长期的规划不协调，分配不合理的问题，通常情况下“治标不治本”，对防灾能力有很大影响，造成的后果更加严重。
7.4)灾害管理模式按照灾害种类分部门管理，很难形成统一有效的系统管理中心。看似分工明确，但在出现各种灾害同时出现或者诱发次生灾害情况下，各部门很难合作救灾，不能及时地采取救灾措施，合理分配救灾资源。灾后缺乏明确的追责机制和追责证据链。
8.综上，目前预警系统的建设中存在着设施中心化，设备之间难以交互，不同预警系统之间难以互联互通，部门之间缺乏统一的组织协调等问题，这些问题在应急救灾中造成了信息不实或者信息阻塞的危害。


技术实现要素：

9.鉴于上述情况，在区块链技术的支撑下，本发明提出一种基于区块链的城市自然灾害监测应急管理调度平台，可解决目前预警系统设施中心化、设备之间难以交互、不同预警系统之间难以互联互通、部门之间缺乏统一的组织协调等问题。
10.为实现上述目的，本发明采取的技术方案为：
11.本发明实施例提供一种基于区块链的城市自然灾害监测应急管理调度平台，包括：
12.通过网络连接的城市自然灾害监测预警可信应急调度系统与城市自然灾害监测预警区块链管理平台；
13.所述城市自然灾害监测预警可信应急调度系统，包含多个独立的服务系统，用于完成iot设备的采集、数据监测预警、应急预案制定及模拟、应急调度指挥、应急监测指挥数据分析的业务操作；
14.所述城市自然灾害监测预警区块链管理平台，包含区块链网络及对应的区块链管理平台；所区块链管理平台通过通讯网关与各应急系统各终端采集设备相连；
15.多个独立的服务系统和区块链网络的节点分散部署通过网络连接，进行分布式任务分发和调度。
16.进一步地，所述城市自然灾害监测预警可信应急调度系统,包括：
17.前端设备采集模块，利用各种iot设备和移动终端，进行实时监测，根据采集的数据做出灾害预警分析、预判及提醒；
18.应急监测管理模块，将所述前端设备采集模块采集的数据以及各应急业务系统中录入的相关数据存储到区块链底层，以图形化方式展现；并用于设置各类数据预警的阈值和预警提示范围，写入区块链智能合约中；
19.应急预案管理模块，用于预案类型、预案模板、预案流程、预案模拟及发布、预案评价的管理；
20.应急指挥管理模块，用于响应启动、任务分发、任务执行、指挥协调、任务监控和执行评价的管理；
21.基础数据模块，用于救灾资源、专家库、预案库和iot设备的维护和管理；
22.系统管理模块，用于组织管理、用户管理、终端权限、设备权限、功能或数据权限的维护和管理；
23.数据分析模块，用于监测预警分析、执行响应分析、救灾情况分析、预案效果分析、指挥效率分析和网络效率分析。
24.进一步地，所述应急预案管理模块中对预案流程的管理包括：
25.每个预案均有设置好的救灾执行任务流程，每一步流程需要参与的主体，预案启动时，区块链网络底层的流程引擎及智能合约，会按照预定步骤进行任务的派发。
26.进一步地，所述应急预案管理模块中对预案评价的管理包括：
27.每一个预案的执行流程会被赋予一个执行评分，每一次执行完毕会根据执行结果和救灾参与者的反馈，通过智能合约自动评分；预案执行过多次，则会加权平均后给出预案的最终分数。
28.进一步地，所述应急指挥管理模块中对指挥协调的管理包括：
29.当在执行任务的过程中遇到突发情况，指挥官可及时对预案中的流程做出调整，上传至区块链，调整后的流程引擎将按照新的预案派发任务。
30.进一步地，所述应急指挥管理模块中对执行评价的管理包括：
31.根据预案中设置好的评价模型，每一项任务完成后，智能合约会自动按照评价模
型给予该任务一个评分。
32.进一步地，所述区块链管理平台包含网关服务模块、共识服务模块、数据账本模块以及其他管理模块；
33.所述网关服务模块为应用的接入层，提供终端接入、私钥托管、安全隐私和协议转换功能；
34.所述共识服务模块包括共识网络、身份管理、安全权限、交易处理、智能合约和数据检索功能，来保证各节点间账本信息的一致性；
35.所述数据账本模块为各参与方提供区块链底层服务功能，包括区块、账户、配置和存储
36.所述其他管理模块，包括：数据管理、权限管理、终端采集、任务分发、iot数据采集和事件监控的功能。
37.进一步地，所述区块链网络的共识算法为pbft共识算法；
38.所述区块链网络的账本结构为账户模型，包括：表示交易、账户和账本状态。
39.进一步地，所述区块链网络中共识节点的功能组件，包括共识接口、查询接口、数据账本、智能合约虚拟机和数据存储
40.与现有技术相比，本发明具有如下有益效果：
41.本发明提出一种基于区块链的城市自然灾害监测应急管理调度平台，在这个平台下，将地方的公共危机管理的指挥中心与其他灾害监测预警系统连接进区块链网络中，去中心化的特点使不仅让每一个部门都可以共享数据，而且让系统出问题的可能性大大降低，性能也得到保障；不可篡改性以及平台中用到的智能合约以及共识机制可以让数据得到可信证明，从而做到权责到人。同时该平台具有辅助性，不是对现有系统进行替代性或入侵性地改造，具有可行性。
42.本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。
43.下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。
附图说明
44.附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：
45.图1为本发明实施例提供的基于区块链的城市自然灾害监测应急管理调度平台整体运行机制图；
46.图2为本发明实施例提供的基于区块链的城市自然灾害监测应急管理调度平台结构图；
47.图3为本发明实施例提供的城市自然灾害监测预警可信应急调度系统结构图；
48.图4为本发明实施例提供的城市自然灾害监测预警区块链管理平台功能结构图；
49.图5为pbft共识算法的执行过程示意图；
50.图6为本发明实施例提供的共识节点功能结构图；
51.图7为本发明实施例提供的多链组网图；
52.图8为本发明实施例提供的任务分发与调度示意图。
具体实施方式
53.下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
54.针对城市灾害指挥预警系统预防和应急准备工作存在中心化管理易受威胁，信息发布滞后、应急预案制定不够详尽、缺乏应急演练应急管理体制复杂，没有清晰的监管体系，指挥控制系统协调性差等问题。本发明利用区块链全网实时记账、智能合约等模型与技术特点，对城市灾害指挥预警应急调度组织和运行机制进行了调整，整体运行机制如图1所示。
55.平时，公安部门、城管部门、地质部门，气象部门等相关组织机构构建成一个救灾监测区块链网络，各部门通过iot设备等设施采集监测城市灾害发生的关键点，收集监测数据。
56.收集到监测数据后，由以下的方法将数据上传至区块链网络中：1.数据上传到系统中后，将这部分数据从各自现有的业务系统同步到区块链网络中；2.设置跟踪器。在物联网设备的附近设置智能跟踪器，跟踪器上带有区块链客户端，ble无线电，gsm或lte无线电以便于连接到internet，当物联网设备上传数据时，智能跟踪器截获到数据并上传至区块链网络。类似的还有filament为传感器提供称为“taps”的远程无线电，通过telehash协议交互后上链以及利用边缘节点技术或者雾计算技术进行处理后上传至区块链等。通过以上的方法，把数据上传到区块链中，确保与其他部门实时、可信共享监测数据。基于区块链网络的监测数据，全面涵盖了多个部门、各个领域，从而提升了整体城市灾害情况的监控效果。
57.从救灾监测区块链网络收集的各种监测数据，为灾害的分析、防护和模拟都提供了全面的支撑。同时，对于救灾预案的制定可以让更多的部门给予专业的建议及救灾支持参与，使得预案的制定更加科学、有效、实用。同时每一个预案都会配备一个预案执行评分模型，在预案启动之后，根据救灾任务的执行情况智能合约可以自动进行评分，救灾任务执行结束后根据加权平均后得出预案的效果评分。预案制定者可以及时、客观的了解、评估预案救灾效果，从而做到及时修订。
58.由救灾指挥中心、110指挥中心、119指挥中心、120指挥中心、122指挥中心、红十字会、社区应急委员会等机构组成救灾指挥区块链网络。当救灾预案启动时，根据预案设置好的执行任务，底层流程引擎会将救灾任务有序的发放到各救灾主体，救灾主体在救灾现场通过移动终端、iot设备等实时采集分享救灾任务执行情况，该任务执行完毕后，流程引擎将会自动分发下一任务给其他救灾主体。与此同时，智能合约根据评价体系，自动为该救灾任务执行情况打分，并通知到各方。
59.本发明提供了一种基于区块链的城市自然灾害监测应急管理调度平台，分为两部分，如图2所示。一部分是城市自然灾害监测预警可信应急调度系统，主要完成iot设备的采集、数据监测预警、应急预案制定及模拟、应急调度指挥、应急监测指挥数据分析等业务操
作。
60.另一部分，是城市自然灾害监测预警可信应急调度平台的底层基础设施即城市自然灾害监测预警区块链管理平台，包含了区块链网络及对应的区块链网络管理平台。
61.下面对上述两部分进行详细说明：
62.1、城市自然灾害监测预警可信应急调度系统：
63.城市自然灾害监测预警可信应急调度系统是城市自然灾害监测预警可信应急调度平台的业务应用系统，包含了前端设备采集、应急监测管理、应急预案管理、应急指挥管理、基础数据、系统管理和数据分析七大功能模块。主要设计目标是提供灾害检测预警数据采集、数据监测、预案设置、预案执行、预警下发、数据上报/采集终端管理等通用的功能服务，向上提供面向各个相关管理机构和其它参与方的接入接口，向下封装屏蔽区块链底层技术的复杂性。系统功能架构如图3所示。
64.1)前端采集
65.利用各种iot设备和移动终端，进行实时监测，根据采集的数据做出灾害预警分析、预判及提醒。同时，在指挥现场实时客观地反映救灾执行情况。
66.2)应急监测管理
67.数据监测：将iot设备或者app采集到的数据以及各应急业务系统中录入的相关数据存储并展现出出来，并实时存储到区块链底层，确保区块链网络中被授权的参与方可以实时查看到此数据。
68.数据展现：将多种途径获取的数据，根据不同检测业务需要进行梳理、融合，以图形化的方式进行展现。
69.预警设置以及提示：设置各类数据预警的阈值和预警提示范围，写入区块链智能合约中。当采集到的数据超过对应数据的阈值，智能合约则自动触发，根据设置好的提示范围进行预警。
70.3)应急预案管理
71.预案类型：城市自然灾害分很多种类型，每一种预案都截然不同，因此需要将预案进行分类，便于后续的查找与管理。
72.预案模板：每一预案都可以设置基础的预案模板，包含预案涉及的救灾主体、救灾人员角色、使用的救灾物资、预案关键环节等等。
73.预案流程：为确保救灾行动可以有序的开展，每个预案都可以设置好救灾执行任务的流程，每一步流程需要参与的主体，预案启动时，区块链网络底层的流程引擎及智能合约，就会按照预定步骤进行任务的派发。
74.预案模拟及发布：用于预案制定后，存储进行救灾行动模拟演练测试的数据，如预案尚有欠缺则可及时调整，调整完毕后即可发布。
75.预案评价：每一个预案的执行流程都会赋予一个执行评分，每一次执行完毕都会根据执行结果和救灾参与者的反馈，通过智能合约自动评分。预案执行过多次，则会加权平均后给出预案的最终分数。
76.4)应急指挥管理
77.响应启动：当指挥官启动救灾响应时，选取对应的应急预案，通过智能合约将救灾指令推送到预案中涉及的全部救灾主体，做好救灾准备，等待救灾任务分配。
78.任务分发：根据预案中的救灾流程，分布式流程引擎将串行或并行分发具体的救灾任务给预案中对应的主体。
79.任务执行：救灾主体收到救灾任务后，根据预案中的救灾指示开展救灾工作，工作现场中通过iot设备或终端app采集现场情况，任务执行完毕后，流程引擎自动将任务流转至下一任务执行主体。
80.指挥协调：当在执行任务的过程中遇到突发情况，指挥官可及时对预案中的流程做出调整，上传至区块链，调整后的流程引擎将按照新的预案派发任务。
81.任务监控：通过iot或者app设备来实时监测数据以及执行者上传执行数据的方法来监控任务执行情况，预案流程执行进度等信息。
82.执行评价：根据预案中设置好的评价模型，每一项任务完成后，智能合约都会自动按照评价模型给予该任务一个评分。
83.5)基础数据
84.救灾资源：维护和管理包括救灾设备，救灾物资，救灾机构等数据。
85.专家库：维护、管理不同救灾领域的专家信息，便于救灾过程中任务分配及指导求助。
86.预案库：维护、管理不同救灾领域的应急预案模板库。
87.iot设备：维护、管理各个机构使用的iot设备信息。
88.6)系统管理
89.组织管理：维护、管理业务系统中每一个组织机构、部门等。
90.用户管理：维护、管理业务系统中每一个用户。
91.终端权限：维护、管理业务系统中终端app的使用功能权限。
92.设备权限：维护、管理业务系统中的设备信息、采集范围、采集内容等。
93.功能或数据权限：维护、管理业务系统中组织、用户的功能权限。
94.2、城市自然灾害监测预警区块链管理平台
95.城市自然灾害监测预警区块链管理平台是城市自然灾害监测预警可信应急调度平台的底层区块链基础设施，包含了区块链网路、区块链管理平台，通过通讯网关与各应急系统各终端采集设备相连，功能架构图如图4所示。
96.其中，区块链管理平台包含网关服务、共识服务，数据账本以及其他管理四个功能模块。
97.1)网关服务
98.网关服务是应用的接入层，提供终端接入、私钥托管、安全隐私和协议转换等功能。
99.终端接入：在确认终端身份的同时提供连接节点、转发消息和隔离共识节点与客户端等服务。网关确认客户端的合法身份，接收并验证交易；网关根据初始配置文件与对应的共识节点建立连接，并转发交易数据。
100.私钥托管：使共识节点可以将私钥等秘密信息以密文的形式托管在网关内，为有权限的共识节点提供私钥恢复、签名生成等服务。
101.安全隐私：网关借助具有隐私保护功能的密码算法和协议，来进行隐藏端到端身份信息，脱敏处理数据信息，防止无权限客户端访问数据信息等操作。
102.协议转换：提供轻量化的httprestfulservice，能够适配区块链节点的api，实现各节点在不同协议之间的互操作。
103.数据浏览：提供对链上数据可视化展示的能力。
104.2)共识服务
105.共识服务包括共识网络、身份管理、安全权限、交易处理、智能合约和数据检索等功能，来保证各节点间账本信息的一致性。
106.共识网络：采用拜占庭共识协议，并加以优化，来提供确定性交易执行、容错和动态调整节点等功能。
107.身份管理：使区块链网络能够通过公钥信息来辨识并认证节点，为访问控制、权限管理提供基础身份服务。
108.安全权限：根据具体应用和业务场景，为节点设置多种权限形式，实现指定的安全管理，契合应用和业务场景。
109.交易处理：共识节点根据具体的协议来对交易信息进行排序、验证、共识和结块等处理操作，使全局共享相同的账本信息的功能。
110.智能合约：一种能够自动执行的链上编码逻辑，来更改账本和账户的信息，包括业务逻辑、节点的准入退出和系统配置的变更等。
111.数据检索：协助节点检索接口，来查询区块、交易、合约、账本等相关信息。
112.3)数据账本
113.为各参与方提供区块链底层服务功能，包括区块、账户、配置和存储等。
114.区块：账本主要组成部分，包含交易信息和交易执行状态的数据快照哈希值。
115.账户：细化账户分类、分级分类授权的方式，对区块链系统中的账户进行管理，达到逻辑清晰化、隔离业务和保护相关数据内容的目的。
116.配置文件：包括密钥信息，存储信息以及共享的参与者身份信息等内容，使区块链网络中各节点能够执行诸如连接其他节点、验证信息、存储并更新账本等操作。
117.存储：由于数据类型不统一，而且存在大量的哈希计算，所以本发明采用简洁的kv数据库来实现账本的持久化存储，使区块链系统能够支持海量交易。对于无用的或者参考价值已经很少的数据，因为处于联盟链，在共识通过的情况下，可以考虑删除或者存到如ipfs等内容寻址的p2p文件系统中而在链中保存其哈希值即可。
118.4)其他管理
119.数据管理：对区块链网络中的数据操作进行管理，包括备份、转移、导出、校验、回溯，及多链情况下的数据合并、拆分等操作。
120.权限管理：对于区块链网络中各节点准入、对于不同账本的读写、智能合约的调用等权限进行管理。
121.终端采集：管理应急系统中终端设备与底层区块链网络的数据交互，终端设备的准入等。
122.任务分发：内置分布式网络流程引擎，负责任务区块链网络各节点间的任务分发、接受、流转等操作。
123.iot数据采集：管理应急系统中iot设备与底层区块链网络的数据交互，终端设备的准入等。
124.事件监控：帮组使用者获取即时吞吐量、节点状态、数据内容等系统运行信息，实现运维管理和实时监控。
125.2.1共识算法
126.典型的共识算法有bft类算法，比如pbft算法，zyzzyva算法，区块链背景下诞生的pow算法，pos算法以及dpos算法等。非bft类算法有paxos算法，raft算法等。从本系统应用的场景出发，本发明实施例选择兼顾安全性以及速度良好的pbft共识算法，通过系统性工程架构优化来弥补该算法在网络规模上的不足，从整体上获得最优的效率表现。
127.图5为pbft共识算法的执行过程示意图。
128.其中cl1发送请求端，n1、n2、n3、n4为服务端，n4为宕机的服务端，具体步骤如下：
129.1)request：请求端cl1发送请求到任意一节点，这里是n1。
130.2)pre
‑
prepare：服务端n1收到cl1的请求后进行广播，扩散至n2、n3、n4。
131.3)prepare：n2、n3、n4，收到后记录并再次广播，n2
‑
>n1n3n4，n2
‑
>124，n4因为宕机无法广播。
132.4)commit：n1、n2、n3、n4节点在prepare阶段，若收到超一定数量的相同请求，则进入commit阶段，广播commit请求。
133.5)reply：n1、n2、n3、n4节点在commit阶段，若收到超过一定数量的相同请求，则对cl1进行反馈。
134.根据上述流程，在n≥3f+1的情況下一致性是可能解決，n为总计算机数，f为有问题的计算机总数。
135.因为本项目使用联盟链，节点的行为可以得到有效的监督，不需要全部节点参与共识，所以只选用部分核心节点参与共识，全部节点存储区块即可。这样在情况比较紧急或者节点规模比较大的情况下，共识的效率能得以提高。
136.2.2账本结构
137.在账本结构方面有3种典型的设计思路：1)采用“utxo模型”表示交易、账户和金额；2)采用“账户模型”表示交易、账户和账本状态；3)“dag模型”表示交易、账户和金额。其中，“utxo模型”为比特币采用，更适合公链数字资产类场景，不适合政府或企业应用的场景；“dag模型”是一种探索中的账户模型，如今有少数项目采用，比如大红大紫的物联网平台iota.但是如今该设计并不成熟，更适合公链数字资产场景；“账户模型”最早在以太坊中被应用和证明，后来更多的联盟链项目都采用这一设计方案，并通过选择更高效的共识算法来获得整体更优良的效率。本系统选择采用“账户模型”作为账本结构的设计方案，结合pbft共识算法来建立区块链的账本系统。
138.2.3共识节点
139.本系统中共识节点的功能组件包括共识接口、查询接口、数据账本、智能合约虚拟机、数据存储这几个部分。如图6所示。
140.1)共识接口
141.共识接口是建立在tcp通讯协议之上的bft共识协议，复用了tcp协议的可靠性实现节点之前的点对点消息可靠传输。客户端通过共识接口提交交易，在达成共识后交易交由各个节点按照一致的方式执行，并写入数据存储。
142.2)查询接口
143.为了保持系统的易用性，因此查询接口提供了对链上数据的检索能力。在实现上采用http协议提供restful风格的服务接口，能够兼容上层各类异构系统的对接，屏蔽掉一些复杂的细节，让客户根据标准即可调用。
144.3)智能合约虚拟机
145.智能合约是一段预定义的可执行代码。可以通过智能合约来设计各种业务校验规则和执行逻辑。智能合约虚拟机是智能合约代码的执行器，内置在共识节点中，用于执行由交易触发的合约调用指令，例如以太坊采用evm虚拟机来执行智能合约。本发明实施例中基于jvm虚拟机设计实现智能合约引擎。通过智能合约技术实现预案设置和执行，确保预案能够按预定义的规则得到准确客观地执行。
146.4)数据账本
147.数据账本维护了由区块和默克尔树构成的密码学证明、状态数据、交易记录等信息。本发明实施例中监控采集到的所有数据、参与者的身份公钥、预定义灾害预案、预案执行记录等数据都是由数据账本组件进行管理和提供查验证明。
148.5)数据存储
149.数据存储提供了数据记录的持久化能力。在本发明实施例中将采用k
‑
v类数据库作为数据存储，利用成熟的nosql数据库集群技术或者存储在ipfs节点当中来实现对海量数据的支持，支撑千万级人口城市的应用场景。
150.本发明实施例提供的基于区块链的城市自然灾害监测应急管理调度平台，如图7所示：采用多链的组网方法，抛弃了“一链治所有”的传统方案，采用“多链分而治之”的新方案，可以满足不同区域或不同体系的对数据平行切分的需求，又可以使各有关参与者成为一个有机的整体，在面对突发灾害时，实现“统一接警，统一指挥，协同作战”，使应急管理的各个环节能够衔接顺畅便捷。同时这一措施极大程度上简化架构，降低数据处理压力，确保一条链上流量激增不会影响到另一条链的效率，在链上进行的任何业务都不会受到其他业务干扰，有效实现了资源隔离。
151.如图7所示，以区域为划分，各个区域内不同的主体搭建自己的应急工作链，当某些灾害发生时，也可以根据实际需要选取不同链上的多个节点(如圈所示)通过跨链操作，组成一个临时应急网络进行救灾指挥。实现跨部门、跨地区以及不同警种、救援力量之间的快速反应、有效协作。本发明的跨链操作不涉及货币资产的转移，只涉及验证以及存储数据，所以可以参考cosmos，plasma,mulitchain等架构设计。
152.分布式任务分发和调度：
153.本发明的分布式任务分发与调度模型整体设计目标需支持动态负载均衡、零停机更新、具备高可用，以满足在应急指挥过程中系统所要求的性能。整体模型设计如图8所示。
154.slack：一个与各种通信服务，实现集成和统一的消息收发平台。
155.influxdb：一个开源分布式时序、时间和指标数据库，实现分布式和水平伸缩扩展。主要用于性能监控，应用程序指标，物联网传感器数据和实时分析等的后端存储。
156.grafana：一款网络架构和应用分析中时序数据展示工具，用于大规模指标数据的可视化展现。
157.calico：一个三层的数据中心网络方案，而且方便集成openstack这种iaas云架构，能够提供高效可控的vm、容器、裸机之间的通信。
158.在应急指挥中心部署一个领导者，负责集中调度统一管理。而agent则部署在各个区块链网络节点上，每个节点的每台机器上都会有一个agent，负责采集数据，管理docker。在边缘运行长期服务，支持故障恢复。agent会负责创建各个docker的任务，容器服务的用户直接会去边缘节点访问容器服务。
159.agent启动后会上报消息到领导者，而领导者会根据用户的请求和上报的消息下发指定给agent。两者的数据交互、消息处理都是异步进行的。防止在处理数据的时候出现超时、延迟等问题，且同步操作可能会导致用户的请求一直得不到响应，最终导致信息丢失等问题。
160.模型中引入calico网络方案，用于隔离不同所有者的容器网络，实现访问控制，以达到不同用户之间网络隔离的作用。集群中的分布式的kv数据库，负责保存网络元数据。
161.本模型中使用raft分布式一致性协议实现高可用，首先用心跳机制触发选举，选举出领导者，领导者把一条指令(能被复制状态机执行)附加到日志中，发起附加条目rpc(远程过程调用协议)请求给其他任务执行者。
162.本发明基于区块链技术，提出一种基于区块链的城市自然灾害监测应急管理调度平台。该平台在物理部署形态上是一种分布式数字网络，由各个管理部门和其它参与方各自独立的服务系统和区块链节点分散部署通过网络连接共同组成，每一方的业务系统都以规定好的的方式接入到由区块链节点组成的区块链网络，区块链网络充当了各方之间信息交换的通讯通道。在该平台中，不同灾害监测预警系统间可以快速进行互联互通，保证信息得到充分地共享，传递顺畅，提高了效率；提前建立好预案放置在区块链中，发生紧急情况可快速根据预案进行任务的布置和分发，快速反应，一定程度上避免被动响应，事后诸葛等行为；不可篡改等特点保证数据真实可信，可以建立起完备的证据链和追责链，确保处置权责到人；该平台是平行于现有的系统，作为预警监测系统的数据资源和执行预案支撑系统，而不是对其入侵性地替代或改造，具有良好的经济性。
163.显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。