基于微服務(wù)的有毒化學(xué)品運(yùn)輸泄露信息系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)

王 信， 劉曉燕， 張開琦， 王 星， 嚴(yán) 馨

(昆明理工大學(xué) 信息工程與自動(dòng)化學(xué)院，云南 昆明 650500)

有毒化學(xué)品的毒性和易燃易爆性，往往會(huì)影響人的健康并造成嚴(yán)重的經(jīng)濟(jì)損失，在有毒化學(xué)品運(yùn)輸過程中可能會(huì)發(fā)生爆炸或碰撞，因此有毒化學(xué)品的運(yùn)輸是極為危險(xiǎn)的活動(dòng)。一旦發(fā)生泄露事故，可能造成人員傷亡和環(huán)境污染，造成的損害是不可估量的。因此，盡可能預(yù)測(cè)、最小化有毒化學(xué)品運(yùn)輸事故的風(fēng)險(xiǎn)和潛在后果變得極為重要。已有一些研究人員對(duì)有毒化學(xué)品泄露擴(kuò)散進(jìn)行建模，預(yù)估出泄露事故的威脅區(qū)域范圍。Zhang Jian-jun等[1]使用高斯煙羽模型和ArcGIS預(yù)估了有毒化學(xué)品泄露事故的威脅區(qū)域。Jakala D S[2]提出了一種基于GIS的有害化學(xué)品泄露建模工具，具有預(yù)測(cè)分析受有害化學(xué)品影響區(qū)域的功能，且可導(dǎo)出化學(xué)品泄露的相關(guān)數(shù)據(jù)分析報(bào)告。Cherradi G等[3]提出了一種基于微服務(wù)的實(shí)時(shí)危險(xiǎn)材料環(huán)境信息系統(tǒng)。

本文通過應(yīng)用基于微服務(wù)和Spring Cloud框架的針對(duì)有毒化學(xué)品運(yùn)輸泄漏的信息系統(tǒng)，可預(yù)測(cè)有毒化學(xué)品釋放的有毒煙羽在意外泄露發(fā)生后的威脅范圍，從而方便管理人員采取應(yīng)急措施，減少有毒化學(xué)品泄漏造成的損失。上述傳統(tǒng)的單體架構(gòu)等技術(shù)解決方案模塊邊界模糊，不支持動(dòng)態(tài)的服務(wù)發(fā)現(xiàn)，可擴(kuò)展性不強(qiáng)，缺少系統(tǒng)故障雪崩效應(yīng)、單點(diǎn)故障的防范和合理的資源使用配置。而本文給出的基于微服務(wù)和Spring Cloud框架的解決方案，支持服務(wù)注冊(cè)發(fā)現(xiàn)、負(fù)載均衡、熔斷保護(hù)等機(jī)制，功能模塊清晰，易于動(dòng)態(tài)服務(wù)部署和維護(hù)。

1 系統(tǒng)架構(gòu)

有毒化學(xué)品的運(yùn)輸活動(dòng)通常與多種人員相關(guān)，如運(yùn)貨商、運(yùn)輸車、監(jiān)管人員和緊急響應(yīng)人員等，各方通常有不同的需求。因此，本文給出一種基于微服務(wù)的有毒化學(xué)品運(yùn)輸泄漏信息系統(tǒng)，可以提供相關(guān)人員需要獲取的信息，在有毒化學(xué)品意外泄露后分析和預(yù)測(cè)有毒化學(xué)品煙羽的分散情況，以便制定有效的規(guī)劃，降低在人口密集地區(qū)運(yùn)輸有毒化學(xué)品的風(fēng)險(xiǎn)。

本系統(tǒng)由多個(gè)子系統(tǒng)組成，包括前端(Web客戶端和移動(dòng)客戶端)以及多個(gè)后端微服務(wù)。圖1是本系統(tǒng)的架構(gòu)示意圖，圖2是系統(tǒng)的后端微服務(wù)組成示意圖。

圖1 系統(tǒng)架構(gòu)圖 圖2 后端微服務(wù)組成

應(yīng)用程序以Docker容器的形式部署為微服務(wù)。如圖2所示，后端系統(tǒng)由許多微服務(wù)組成，每個(gè)微服務(wù)均可以以不同的方式實(shí)現(xiàn)，可以具有不同的體系結(jié)構(gòu)模型，并根據(jù)應(yīng)用程序的性質(zhì)、業(yè)務(wù)需求和優(yōu)先級(jí)使用不同的編程語言和數(shù)據(jù)庫(kù)。所有微服務(wù)都在Eureka注冊(cè)中心進(jìn)行注冊(cè)，都是多實(shí)例部署。API網(wǎng)關(guān)作為外部請(qǐng)求訪問后端的門戶。由于各微服務(wù)都是多實(shí)例部署，故運(yùn)用Ribbon組件實(shí)現(xiàn)負(fù)載均衡。本系統(tǒng)還包括熔斷機(jī)制組件Hystrix，負(fù)責(zé)微服務(wù)間消息傳遞的Kafka分布式消息中間件。

1.1 API網(wǎng)關(guān)

客戶端應(yīng)用程序可以通過API網(wǎng)關(guān)與后端微服務(wù)系統(tǒng)進(jìn)行通信，例如Web客戶端發(fā)出查看運(yùn)輸車輛及有毒化學(xué)品信息的請(qǐng)求，API網(wǎng)關(guān)應(yīng)將該請(qǐng)求根據(jù)定義的轉(zhuǎn)發(fā)規(guī)則轉(zhuǎn)發(fā)到數(shù)據(jù)采集微服務(wù)上，由于各微服務(wù)是多實(shí)例部署，根據(jù)一定的負(fù)載均衡策略和路由規(guī)則轉(zhuǎn)發(fā)到合適的數(shù)據(jù)采集微服務(wù)實(shí)例上，之后通過API網(wǎng)關(guān)返回所需要的數(shù)據(jù)。API網(wǎng)關(guān)對(duì)后端微服務(wù)系統(tǒng)結(jié)構(gòu)進(jìn)行了封裝并為所有客戶端提供了單一入口點(diǎn)，同時(shí)提供了合適的API。API網(wǎng)關(guān)主要完成鑒權(quán)、路由、負(fù)載均衡的功能[4]。在本系統(tǒng)中，使用Spring Cloud框架中的Zuul網(wǎng)關(guān)來實(shí)現(xiàn)API網(wǎng)關(guān)的功能。

Zuul具有路由、過濾的功能，路由指將來自外界客戶端的請(qǐng)求被Zuul網(wǎng)關(guān)分發(fā)到內(nèi)部具體微服務(wù)中的過程；過濾則可以處理來自外界客戶端的請(qǐng)求，以進(jìn)一步實(shí)現(xiàn)對(duì)請(qǐng)求的檢驗(yàn)和服務(wù)間的組合。若要重寫自己的過濾器即定義新的過濾規(guī)則，就需要使重寫的過濾器繼承Zuulfilter父類，將父類的抽象方法重寫[5]。對(duì)于Zuul網(wǎng)關(guān)，定義了4種過濾器的作用域分別為：

(1)pre：路由之前；

(2)routing：路由中；

(3)post：路由之后；

(4)error：發(fā)送錯(cuò)誤調(diào)用。

還可使用FilterOrder定義過濾的順序。用ShouldFilter寫邏輯判斷，是否要過濾；用Run寫過濾器的具體邏輯。

1.2 服務(wù)注冊(cè)中心

服務(wù)的注冊(cè)與發(fā)現(xiàn)是微服務(wù)架構(gòu)中最為核心和基礎(chǔ)的模塊。如圖3所示，本系統(tǒng)中的各個(gè)微服務(wù)都應(yīng)利用服務(wù)注冊(cè)中心完成服務(wù)注冊(cè)和服務(wù)發(fā)現(xiàn)過程，采用Spring Cloud Netflix項(xiàng)目下的服務(wù)注冊(cè)發(fā)現(xiàn)組件Eureka作為服務(wù)注冊(cè)中心。其包含作為服務(wù)注冊(cè)中心的Eureka服務(wù)端和作為一個(gè)Java客戶端的Eureka客戶端。在應(yīng)用啟動(dòng)時(shí)，Eureka客戶端向服務(wù)端注冊(cè)自己的服務(wù)信息，同時(shí)將服務(wù)端的服務(wù)信息緩存到本地?？蛻舳藭?huì)和服務(wù)端周期性的進(jìn)行心跳交互，以更新服務(wù)租約和服務(wù)信息[6]。

圖3 服務(wù)注冊(cè)中心功能示意

1.3 負(fù)載均衡組件

圖4 Ribbon組件功能示意

由于本系統(tǒng)中微服務(wù)為多實(shí)例部署，故需要負(fù)載均衡組件去緩解請(qǐng)求的網(wǎng)絡(luò)壓力。本系統(tǒng)采用Spring Cloud Netflix項(xiàng)目下的Ribbon組件實(shí)現(xiàn)負(fù)載均衡功能。Ribbon是一個(gè)基于HTTP和TCP的客戶端負(fù)載均衡工具，它基于Netflix Ribbon實(shí)現(xiàn)。通過Spring Cloud的封裝，可以讓我們輕松地將面向服務(wù)的REST模版請(qǐng)求自動(dòng)轉(zhuǎn)換成客戶端負(fù)載均衡的服務(wù)調(diào)用[7]。本系統(tǒng)中可同時(shí)存在兩種負(fù)載均衡，客戶端負(fù)載均衡和服務(wù)端負(fù)載均衡。服務(wù)端負(fù)載均衡是由服務(wù)器通過配置特定的組件完成的分發(fā)工作，例如Nginx Web服務(wù)器是由Nginx完成反向代理，實(shí)現(xiàn)負(fù)載均衡。如Web客戶端請(qǐng)求地理可視化微服務(wù)的數(shù)據(jù)，由Nginx完成請(qǐng)求的分發(fā)和負(fù)載均衡，將請(qǐng)求分發(fā)到合適的微服務(wù)實(shí)例之一。在客戶端負(fù)載均衡中，客戶端節(jié)點(diǎn)都有一份自己要訪問的服務(wù)端清單，這些清單統(tǒng)統(tǒng)都是從Eureka服務(wù)注冊(cè)中心獲取的[8]。如圖4所示，當(dāng)?shù)乩砜梢暬⒎?wù)需要調(diào)用數(shù)據(jù)采集微服務(wù)的數(shù)據(jù)時(shí)，地理可視化微服務(wù)作為服務(wù)消費(fèi)者，借助Ribbon組件，并調(diào)用被@LoadBalanced注解修飾過的RestTemplate來實(shí)現(xiàn)面向服務(wù)的接口調(diào)用。此時(shí)多實(shí)例部署的數(shù)據(jù)采集微服務(wù)作為服務(wù)提供者提供數(shù)據(jù)。

1.4 熔斷機(jī)制組件

在本系統(tǒng)的后端微服務(wù)架構(gòu)中，有多種且多實(shí)例部署的微服務(wù)實(shí)例，但若其中一個(gè)實(shí)例出現(xiàn)故障，由于各個(gè)微服務(wù)間存在緊密聯(lián)系的原因，容易引發(fā)故障的連鎖反應(yīng)，甚至導(dǎo)致整體大范圍的故障。因此需要避免該問題的發(fā)生，出現(xiàn)了諸如熔斷機(jī)制等一系列的服務(wù)保護(hù)機(jī)制。本系統(tǒng)使用Spring Cloud Hystrix實(shí)現(xiàn)了斷路器、線程隔離等一系列服務(wù)保護(hù)功能[9]。其中Hystrix Dashboard主要用來實(shí)時(shí)監(jiān)控Hystrix的各項(xiàng)指標(biāo)信息，可以對(duì)單個(gè)實(shí)例進(jìn)行監(jiān)控。通過Hystrix監(jiān)測(cè)的結(jié)果，可以分析出系統(tǒng)運(yùn)行時(shí)的問題，以便針對(duì)性地處理故障。除了可以開啟單個(gè)實(shí)例的監(jiān)控頁(yè)面之外，還可對(duì)多個(gè)實(shí)例進(jìn)行監(jiān)控，監(jiān)控端點(diǎn)/turbine.stream就是對(duì)多實(shí)例集群使用的。從端點(diǎn)的命名中，可以引入Turbine，通過它來匯集監(jiān)控信息，并將聚合后的信息提供給Hystrix Dashboard來集中展示和監(jiān)控。

1.5 分布式消息系統(tǒng)

各個(gè)微服務(wù)間的流處理則由作為分布式消息系統(tǒng)的Kafka集群來完成。在Kafka架構(gòu)中，后端微服務(wù)中的大氣擴(kuò)散微服務(wù)、數(shù)據(jù)采集微服務(wù)、路由微服務(wù)可作為生產(chǎn)者，監(jiān)管微服務(wù)、運(yùn)輸文檔微服務(wù)、地理可視化微服務(wù)可作為消費(fèi)者。Kafka是由Apache軟件基金會(huì)開發(fā)的一個(gè)開源流處理平臺(tái)[10]。該項(xiàng)目的目標(biāo)是實(shí)現(xiàn)統(tǒng)一、高吞吐、低延遲地發(fā)送和接收大量的實(shí)時(shí)事件、日志數(shù)據(jù)。Kafka架構(gòu)內(nèi)部包含Topic和Broker兩個(gè)組件。Topic用來對(duì)消息進(jìn)行分類，每個(gè)進(jìn)入到Kafka的信息都會(huì)被放到一個(gè)Topic下。Broker是用來實(shí)現(xiàn)數(shù)據(jù)存儲(chǔ)的主機(jī)服務(wù)器。而由于各個(gè)Broker是互相獨(dú)立部署的，故還需要一個(gè)中心服務(wù)器來進(jìn)行所有Broker的管理[11]。Apache軟件基金會(huì)的一個(gè)軟件項(xiàng)目Apache ZooKeeper可提供該管理服務(wù)，可為各Broker提供配置、同步服務(wù)，命名注冊(cè)等功能。每個(gè)Broker服務(wù)器在啟動(dòng)時(shí)，都會(huì)到ZooKeeper上進(jìn)行注冊(cè)。

2 后端微服務(wù)設(shè)計(jì)

后端微服務(wù)系統(tǒng)包括：

(1)數(shù)據(jù)采集微服務(wù)：數(shù)據(jù)采集微服務(wù)基于MQTT協(xié)議和Node.js開發(fā)。MQTT(Message Queuing Telemetry Transport)協(xié)議是一個(gè)基于發(fā)布/訂閱范式的消息傳輸協(xié)議，利用broker作為消息中間件來完成多對(duì)多的客戶端之間的數(shù)據(jù)傳輸。如圖5所示，車載傳感器可采集車輛信息、有毒化學(xué)品的理化性質(zhì)數(shù)據(jù)、當(dāng)前環(huán)境的溫度、濕度、壓強(qiáng)、風(fēng)向、風(fēng)速信息，利用全球定位系統(tǒng)(GPS)技術(shù)獲取車輛實(shí)時(shí)位置，通過無線通信技術(shù)傳輸數(shù)據(jù)。采集到的數(shù)據(jù)將通過API網(wǎng)關(guān)發(fā)送給數(shù)據(jù)采集微服務(wù)中。數(shù)據(jù)采集微服務(wù)由于基于MQTT協(xié)議，故采用MQTT broker作為消息中間件，Subscriber作為客戶端訂閱消息。收到數(shù)據(jù)后，微服務(wù)將其存儲(chǔ)到MongoDB數(shù)據(jù)庫(kù)中。MongoDB是一個(gè)基于分布式文件存儲(chǔ)的數(shù)據(jù)庫(kù)。采集到的數(shù)據(jù)將被下文介紹的大氣擴(kuò)散微服務(wù)所利用。

圖5 數(shù)據(jù)采集微服務(wù)

(2)地理可視化微服務(wù)：該微服務(wù)基于AngularJS、LeafletJS、GIS地圖和GPS技術(shù)構(gòu)建。AngularJS是一個(gè)前端JavaScript框架，協(xié)助單一網(wǎng)頁(yè)運(yùn)行。LeafletJS是用來構(gòu)建在線網(wǎng)絡(luò)電子地圖的開源JavaScript庫(kù)，它可以從GeoJSON文件(是一種對(duì)各種地理數(shù)據(jù)結(jié)構(gòu)進(jìn)行編碼的格式)加載地圖數(shù)據(jù)，對(duì)其進(jìn)行樣式設(shè)置并創(chuàng)建交互式圖層，可以顯示在地圖上移動(dòng)的車輛，其中包含相關(guān)重要數(shù)據(jù)和參數(shù)。此外，通過空間查詢技術(shù)，它允許用戶分析任何給定空間層的意義。

(3)路由微服務(wù)：該微服務(wù)基于地理信息系統(tǒng)(GIS)與空間數(shù)據(jù)庫(kù)PostGIS、數(shù)據(jù)庫(kù)管理系統(tǒng)PostgreSQL、PgRouting算法、Node.js構(gòu)建。PostgreSQL是自由的對(duì)象-關(guān)系型數(shù)據(jù)庫(kù)服務(wù)器。PostGIS是一個(gè)開源程序插件，為PostgreSQL提供了地理空間數(shù)據(jù)的支持以使PostgreSQL成為一個(gè)空間數(shù)據(jù)庫(kù)[12]。基于真實(shí)城市道路數(shù)據(jù)量較大且查詢分析操作步驟復(fù)雜與數(shù)據(jù)庫(kù)交互頻繁，服務(wù)端頻繁訪問數(shù)據(jù)庫(kù)導(dǎo)致數(shù)據(jù)庫(kù)開銷壓力較大，分析較慢，故選擇PgRouting在數(shù)據(jù)庫(kù)內(nèi)部實(shí)現(xiàn)算法，提升分析效率。PgRouting是基于開源空間數(shù)據(jù)庫(kù)PostGIS用于網(wǎng)絡(luò)分析的擴(kuò)展模塊，最初被稱作PgDijkstra，因?yàn)樗皇抢肈ijkstra算法實(shí)現(xiàn)最短路徑搜索，之后慢慢添加了其他的路徑分析算法。這里的路徑分析不僅僅是最短路徑，在實(shí)際應(yīng)用中還有最短耗時(shí)、最近距離、道路對(duì)車輛類型限制、道路對(duì)速度限制等因素，交通事故、市政事故導(dǎo)致的交通障礙點(diǎn)等問題。該微服務(wù)旨在處理與道路交通網(wǎng)運(yùn)輸風(fēng)險(xiǎn)有關(guān)的地理數(shù)據(jù)，以找到使有毒化學(xué)品運(yùn)輸風(fēng)險(xiǎn)最小的路線。

(4)運(yùn)輸文檔微服務(wù)：該微服務(wù)基于Alfresco、Node.js開發(fā)，為了便于多方人員(如運(yùn)貨商、監(jiān)管人員和緊急響應(yīng)人員)查看、管理有毒化學(xué)品運(yùn)輸活動(dòng)相關(guān)文檔，本文采用基于Alfresco的內(nèi)容管理系統(tǒng)，可分類、分發(fā)、搜索、存儲(chǔ)文檔。Alfresco是一款應(yīng)用最為廣泛的開源的企業(yè)內(nèi)容管理系統(tǒng)，可實(shí)現(xiàn)企業(yè)需要的日常的文檔管理、協(xié)同工作、網(wǎng)絡(luò)內(nèi)容管理等功能[13]。對(duì)運(yùn)輸活動(dòng)數(shù)據(jù)也可進(jìn)行簡(jiǎn)單的CRUD操作，運(yùn)輸活動(dòng)相關(guān)的數(shù)據(jù)存儲(chǔ)在PostgreSQL中。運(yùn)輸文檔對(duì)于公路運(yùn)輸有毒化學(xué)品至關(guān)重要，因此，提供適當(dāng)權(quán)限的相應(yīng)文檔可以將事故發(fā)生率降至最低。

(5)監(jiān)管微服務(wù)：由于對(duì)道路有毒化學(xué)品運(yùn)輸安全的監(jiān)管極為重要，監(jiān)管微服務(wù)基于Node.js開發(fā)，使用電子版的ADR(危險(xiǎn)貨物道路國(guó)際運(yùn)輸)規(guī)則，記錄有毒化學(xué)品運(yùn)輸相關(guān)的文本數(shù)據(jù)(諸如有毒化學(xué)品分類和標(biāo)識(shí)、包裝和罐裝規(guī)定，運(yùn)輸、裝載、卸載的條件等)，同時(shí)允許簡(jiǎn)單的CRUD操作，這些數(shù)據(jù)依然存儲(chǔ)在PostgreSQL中。該微服務(wù)可允許系統(tǒng)管理人員查看有毒化學(xué)品運(yùn)輸監(jiān)管文本數(shù)據(jù)，對(duì)關(guān)鍵數(shù)據(jù)的修改情況知情。通過該監(jiān)管微服務(wù)，可進(jìn)一步降低事故發(fā)生率。

(6)大氣擴(kuò)散微服務(wù)：為了對(duì)有毒化學(xué)品的泄露進(jìn)行建模，給出了一種大氣擴(kuò)散微服務(wù)，目的是通過將大氣擴(kuò)散模型與GIS技術(shù)相結(jié)合來估算受到有毒化學(xué)品泄露影響的區(qū)域的大小[14]。該微服務(wù)基于Node.js開發(fā)，所產(chǎn)生的數(shù)據(jù)存儲(chǔ)在MongoDB分布式數(shù)據(jù)庫(kù)中。大氣擴(kuò)散微服務(wù)借助ALOHA軟件，包含大約1000種常見危險(xiǎn)化學(xué)品的數(shù)據(jù)庫(kù)，使用該數(shù)據(jù)庫(kù)中的信息，以及泄露事故地點(diǎn)和大氣條件(溫度、風(fēng)速和風(fēng)向等)，ALOHA便可以預(yù)測(cè)釋放危險(xiǎn)氣流造成的威脅范圍。因此ALOHA可對(duì)有毒化學(xué)品的大氣擴(kuò)散進(jìn)行建模。同時(shí)該微服務(wù)應(yīng)與數(shù)據(jù)采集微服務(wù)和地理可視化微服務(wù)進(jìn)行通信，以解決在發(fā)生泄露事故情況下實(shí)時(shí)數(shù)據(jù)的采集和有毒化學(xué)品泄露情況可視化的問題。具體而言，數(shù)據(jù)采集微服務(wù)采集到的有毒化學(xué)品運(yùn)輸相關(guān)數(shù)據(jù)通過Kafka消息中間件輸入到大氣擴(kuò)散微服務(wù)中，而大氣擴(kuò)散微服務(wù)借助ALOHA軟件可根據(jù)大氣擴(kuò)散模型計(jì)算出有毒化學(xué)品的煙羽威脅范圍并生成KML文件(一種標(biāo)記語言，利用XML語法格式描述地理空間數(shù)據(jù))，故需開發(fā)輸出程序?qū)ML格式的文件轉(zhuǎn)化為GeoJSON文件(是一種對(duì)各種地理數(shù)據(jù)結(jié)構(gòu)進(jìn)行編碼的格式)，再通過Kafka消息中間件將其導(dǎo)入到地理可視化微服務(wù)中，以便地理可視化微服務(wù)將GeoJSON文件轉(zhuǎn)化為可在網(wǎng)絡(luò)地圖上顯示的有毒化學(xué)品煙羽威脅區(qū)域。

3 系統(tǒng)實(shí)現(xiàn)

圖6 Eureka服務(wù)注冊(cè)中心界面

圖6為服務(wù)注冊(cè)中心Eureka的運(yùn)行界面，微服務(wù)生態(tài)系統(tǒng)中的各微服務(wù)均已在Eureka中完成注冊(cè)，API網(wǎng)關(guān)Zuul和負(fù)載均衡組件Ribbon也作為Eureka客戶端注冊(cè)到Eureka Server下。

作為API網(wǎng)關(guān)的Zuul具有服務(wù)路由、負(fù)載均衡、服務(wù)過濾功能，在系統(tǒng)部署運(yùn)行之前配置調(diào)用地址，外部請(qǐng)求就可以根據(jù)所定義的規(guī)則來訪問微服務(wù)實(shí)例。如下代碼所示，可在application.yml中定義路由規(guī)則，凡是/data/**的訪問都轉(zhuǎn)發(fā)到數(shù)據(jù)采集微服務(wù)上，凡是/geo/**的訪問都轉(zhuǎn)發(fā)到地理可視化微服務(wù)上。

zuul：

routes：

api-a：

path：/data/**

serviceId：data-collection

api-b：

path：/geo/**

serviceId：geo-visualization

API網(wǎng)關(guān)Zuul通過服務(wù)過濾的功能，可以實(shí)現(xiàn)安全驗(yàn)證，讓客戶端只訪問特定的資源，從而保護(hù)系統(tǒng)的安全性。通過繼承ZuulFilter抽象類，實(shí)現(xiàn)其自定義的4個(gè)抽象函數(shù)，即可自定義過濾器：

(1)filterType：返回過濾器類型；

(2)filterOrder：過濾器的使用順序；

(3)shouldFilter：布爾型，控制是否使用過濾器；

(4)run：實(shí)現(xiàn)過濾器的具體邏輯。

在本系統(tǒng)中Zuul網(wǎng)關(guān)過濾器的具體實(shí)現(xiàn)代碼如下：

@Override

public Object run(){

RequestContext ctx=RequestContext.getCurrentContext()；

HttpServletRequest request = ctx.getRequest()；

Object accessToken = request.getParameter(s："access token")；

if(accessToken == null){

log.warn("access token is empty")；

ctx.setSendZuulResponse(false)；

ctx.setResponseStatusCode(401)；

return null；

}

Log.info("access token ok")；

Return null；

}

圖7 網(wǎng)格表示的威脅區(qū)域

在大氣擴(kuò)散微服務(wù)中，開發(fā)輸入程序用于將數(shù)據(jù)采集微服務(wù)采集到的有毒化學(xué)品和氣象條件等數(shù)據(jù)傳遞給大氣擴(kuò)散微服務(wù)中的ALOHA軟件。輸入程序要與ALOHA通信，需要調(diào)用NERegister()來使用NOAA_32.dll注冊(cè)輸入應(yīng)用程序[15]，通過發(fā)送“REGA”消息(注冊(cè)應(yīng)用程序)，通知ALOHA：外部應(yīng)用程序已準(zhǔn)備好與之進(jìn)行數(shù)據(jù)通信。然后，我們的輸入應(yīng)用程序使用描述我們需求的字符串，調(diào)用NESendMessage()來發(fā)送消息，通過調(diào)用NEGetNextMessage()來接收消息，通過調(diào)用NEBye()取消注冊(cè)應(yīng)用程序。使用此通信方式，輸入程序從數(shù)據(jù)提供者采集微服務(wù)數(shù)據(jù)并將其傳輸給ALOHA。然后ALOHA處理這些數(shù)據(jù)以創(chuàng)建有毒化學(xué)品的煙羽模型[16]，將其輸入到輸出程序中，將ALOHA所產(chǎn)生的KML文件轉(zhuǎn)換為GeoJSON文件并導(dǎo)入地理可視化微服務(wù)。如圖7所示，在ALOHA中可將計(jì)算出的威脅區(qū)域用網(wǎng)格的形式表示出來，分別以不同的顏色(圖形)代表不同的區(qū)域中有害煙羽的濃度。此時(shí)的各項(xiàng)數(shù)據(jù)如泄漏時(shí)間、地點(diǎn)、有毒化學(xué)品及運(yùn)輸載體信息、泄漏地點(diǎn)氣象條件數(shù)據(jù)等如圖8所示。

圖8 有毒化學(xué)品運(yùn)輸相關(guān)數(shù)據(jù)

在網(wǎng)絡(luò)地圖上顯示有毒化學(xué)品煙羽威脅區(qū)域有助于決策者估計(jì)有毒煙羽在人口密集區(qū)域的擴(kuò)散情況，以便緊急響應(yīng)人員確定疏散措施。因此，使用地理可視化微服務(wù)來繪制ALOHA所估算出威脅區(qū)的范圍。一旦將GeoJSON數(shù)據(jù)導(dǎo)入地理可視化微服務(wù)，就可以進(jìn)行分析和決策，從而保護(hù)公共基礎(chǔ)設(shè)施和居民的安全。開發(fā)輸出程序以輔助完成這一過程。為將KML文件轉(zhuǎn)換為GeoJSON格式的數(shù)據(jù)文件，要在基于Node.js構(gòu)建的輸出應(yīng)用程序中使用Togeojson庫(kù)。Togeojson庫(kù)將KML格式的文件轉(zhuǎn)換為GeoJSON格式的文件。第一個(gè)參數(shù)必需是作為XML DOM格式的KML文件，輸出是作為JavaScript對(duì)象的GeoJSON文件，GeoJSON文件可以直接在利用Leaflet.js構(gòu)建的地理可視化微服務(wù)中使用，以在網(wǎng)絡(luò)地圖上呈現(xiàn)出有毒化學(xué)品煙羽的威脅區(qū)域。如圖9所示，可以在Google地圖上以可視化的形式繪制出有毒化學(xué)品泄露的威脅區(qū)域，不同的區(qū)域顏色深淺代表不同的污染物濃度水準(zhǔn)。

圖9 地圖上顯示危險(xiǎn)氣體的擴(kuò)散情況

4 結(jié)束語

本文給出了一種基于微服務(wù)的有毒化學(xué)品運(yùn)輸泄漏信息系統(tǒng)，采用Spring Cloud框架下的服務(wù)注冊(cè)中心、API網(wǎng)關(guān)、負(fù)載均衡、熔斷保護(hù)及分布式消息中間件Kafka等組件來保障整個(gè)系統(tǒng)的高效、平穩(wěn)運(yùn)行。相比傳統(tǒng)單體架構(gòu)等技術(shù)解決方案的復(fù)雜、不易維護(hù)和部署的特點(diǎn)，該系統(tǒng)支持服務(wù)的注冊(cè)發(fā)現(xiàn)機(jī)制，可動(dòng)態(tài)部署，可擴(kuò)展性強(qiáng)，對(duì)系統(tǒng)故障有更好的防范，資源得到更合理的利用。同時(shí)，各微服務(wù)被部署在Docker容器中，提高了運(yùn)維的效率。本系統(tǒng)預(yù)測(cè)了有毒化學(xué)品在道路運(yùn)輸意外泄露后的受威脅區(qū)域，可以幫助決策人員采取有效的措施來降低事故后果，避免不必要的經(jīng)濟(jì)和環(huán)境損失。未來進(jìn)一步的研究工作著眼于對(duì)更加精確預(yù)測(cè)有害化學(xué)品大氣擴(kuò)散建模方法的選擇，并優(yōu)化系統(tǒng)的響應(yīng)時(shí)間，以更加及時(shí)地得到分析預(yù)測(cè)的結(jié)果。