基于GIS的通信管網(wǎng)管理系統(tǒng)架構設計

基于GIS的通信管網(wǎng)管理系統(tǒng)架構設計

創(chuàng)新互聯(lián)建站總部坐落于成都市區(qū)，致力網(wǎng)站建設服務有網(wǎng)站設計、成都網(wǎng)站建設、網(wǎng)絡營銷策劃、網(wǎng)頁設計、網(wǎng)站維護、公眾號搭建、微信平臺小程序開發(fā)、軟件開發(fā)等為企業(yè)提供一整套的信息化建設解決方案。創(chuàng)造真正意義上的網(wǎng)站建設，為互聯(lián)網(wǎng)品牌在互動行銷領域創(chuàng)造價值而不懈努力！

管網(wǎng)資源監(jiān)測管理系統(tǒng)充分利用 GIS 平臺，將分布范圍廣泛的管網(wǎng)設施和地理位置有機地結合，不僅提高了企業(yè)的管理水平，而且提升了企業(yè)的服務能力。因此，該系統(tǒng)研究具有現(xiàn)實意義和廣闊的應用前景。

1 設計方案及原則

1.1 系統(tǒng)設計方案

地理信息系統(tǒng)是對地理環(huán)境中的有關問題進行分析和研究的手段，它是一種采集、處理、傳輸、存儲、管理、查詢檢索、分析、表達和應用地理信息的計算機系統(tǒng)。利用計算機建立地理數(shù)據(jù)庫，將地理環(huán)境中的各種要素，包括它們的地理分布狀況和所具有的屬性數(shù)據(jù)，進行數(shù)字存儲，建立有效的'數(shù)據(jù)管理系統(tǒng)，通過對各個要素的綜合分析，方便快速地獲取信息，滿足應用和研究的需要，并用圖形和數(shù)字的方式來表現(xiàn)結果。

通信管網(wǎng)資源與地理空間位置有著密切的關系，本系統(tǒng)充分利用GIS的特點，通過Visual Basic6.0高級語言嵌入 TopMapActiveX組件進行二次開發(fā)，設計了地理位置信息與管網(wǎng)資源數(shù)據(jù)有機融合的監(jiān)控管理綜合系統(tǒng)。Visual Basic能夠提供創(chuàng)建圖形用戶界面(GUI)的方法，可以方便快捷地調(diào)用外部控件，具有功能強大的數(shù)據(jù)庫訪問特性;TopMap ActiveX地理信息系統(tǒng)開發(fā)組件具有完善的地圖操作功能。利用成熟的技術和可靠的數(shù)據(jù)采集硬件設備，以 Windows 2000/NT為網(wǎng)絡操作系統(tǒng)，使用MicroSoft的SQL Server2000作為后臺數(shù)據(jù)庫系統(tǒng)，利用 ADO技術實現(xiàn)數(shù)據(jù)庫訪問，能夠滿足系統(tǒng)的時實性和可靠性。

1.2 系統(tǒng)設計原則

(1)規(guī)范性。在系統(tǒng)設計中制定資源分類、編碼等一系列方案，同時把通信行業(yè)標準考慮到方案之中，做到系統(tǒng)規(guī)范化。(2)科學性。編碼時采用區(qū)段碼和從屬編碼結構，利于計算機的直接存貯和數(shù)據(jù)庫的管理，便于系統(tǒng)數(shù)據(jù)的快速檢索和更新。(3)擴展性。建立一個開放的系統(tǒng)，留有充分的擴充空間，以便對系統(tǒng)擴充或移植。(4)實時性。能進行動態(tài)數(shù)據(jù)的管理，并保持數(shù)據(jù)的一致性和實時性要求。(5)安全性。對用戶權限進行分級管理。

2 系統(tǒng)結構

2.1 系統(tǒng)功能結構

管網(wǎng)資源監(jiān)控管理系統(tǒng)是對通信站轄區(qū)內(nèi)的通信管網(wǎng)資源(如管道、人井等)進行計算機管理和監(jiān)控，包括管網(wǎng)資源數(shù)據(jù)錄入、查詢、修改、統(tǒng)計分析、打印輸出、地理圖形顯示、監(jiān)控數(shù)據(jù)采集和故障報警顯示等功能。系統(tǒng)的功能結構如圖1所示。

2.2 系統(tǒng)網(wǎng)絡結構

整個系統(tǒng)主要由GIS工作站、GIS服務器、數(shù)據(jù)服務器和多通道通信服務器組成，采用客戶/服務器結構，各通信站點通過原有的內(nèi)部 10/100 m網(wǎng)絡訪問。其中：GIS工作站負責本地管網(wǎng)數(shù)據(jù)的維護管理和監(jiān)控;多通道數(shù)據(jù)服務器完成對管網(wǎng)監(jiān)測數(shù)據(jù)的采集與通信;GIS 服務器實現(xiàn)對地理屬性數(shù)據(jù)的存儲;數(shù)據(jù)服務器用來存儲管網(wǎng)資源數(shù)據(jù)信息。系統(tǒng)的網(wǎng)絡結構如圖2所示。

3 監(jiān)控管理模塊設計

3.1 資源數(shù)據(jù)管理

管網(wǎng)資源數(shù)據(jù)管理包括管網(wǎng)數(shù)據(jù)(地理信息數(shù)據(jù)和線路資源數(shù)據(jù))錄入、數(shù)據(jù)查詢、數(shù)據(jù)統(tǒng)計和打印輸出等模塊。

(1)管網(wǎng)數(shù)據(jù)錄入

管網(wǎng)數(shù)據(jù)錄入模塊用于對基礎地理信息和線路資源信息進行錄入、修改、刪除、存儲。數(shù)據(jù)庫服務器完成基礎圖形與數(shù)據(jù)存儲處理等功能;系統(tǒng)管理員有權修改用戶權限、增刪用戶賬號。

(2)數(shù)據(jù)查詢/統(tǒng)計

系統(tǒng)根據(jù)工作人員的需求對基礎地理信息和通信網(wǎng)絡信息進行查詢;按照給定的統(tǒng)計條件對各通信站的分布位置及覆蓋區(qū)域、管道分布、纜線、人井等線路信息進行統(tǒng)計分析。

(3)打印輸出

將GIS中的數(shù)據(jù)經(jīng)過分析、轉換處理，以直觀的圖表形式輸出。

3.2 監(jiān)控數(shù)據(jù)采集

監(jiān)控數(shù)據(jù)采集模塊通過傳感器完成對管網(wǎng)資源狀態(tài)數(shù)據(jù)(壓力、溫度、水位等模擬量)時實采集與通信，實時監(jiān)測主要監(jiān)控點的模擬量是否越限，監(jiān)控數(shù)據(jù)判別流程如圖3所示。

各通信站點通過監(jiān)測設備從監(jiān)測現(xiàn)場采樣數(shù)據(jù)，上報數(shù)據(jù)經(jīng)過預處理后輸入到系統(tǒng)中，通過與監(jiān)控標準庫的數(shù)據(jù)進行對比分析來判斷管網(wǎng)資源是否發(fā)生故障。如果檢測判斷發(fā)生管線受損、模擬量越限時發(fā)出報警信息，并對故障位置進行準確定位。如果檢測判斷沒有發(fā)生故障，系統(tǒng)不報警，同時繼續(xù)監(jiān)測現(xiàn)場數(shù)據(jù)。

3.3 地理圖形/監(jiān)控報警顯示

借助可視化技術，通過圖形及其圖形變換、聲音傳遞消息等手段，可以實現(xiàn)更為人性化的人機交互。系統(tǒng)的顯示包括地理圖形顯示和監(jiān)控報警顯示兩部分。

地理圖形顯示是建立在對該系統(tǒng)內(nèi)所有的管網(wǎng)資源實體分類的基礎上，一類實體建立一個圖層，整個系統(tǒng)是由所有實體相對應的圖層疊加而成的。地理圖形顯示用于電子底圖和線路資源符號的顯示，具有漫游、無極縮放、分層顯示等功能。監(jiān)控報警顯示將實時監(jiān)控數(shù)據(jù)和地理圖形相結合，在地理圖形界面上實時監(jiān)控網(wǎng)管設備的運行情況。當發(fā)生故障時，在GIS 圖形界面上用特殊顏色進行標記，對管網(wǎng)設備故障準確定位顯示，并進行聲光報警，通知維護人員及時搶修。

;

五分鐘學GIS _ 微服務架構

微服務是一種架構思想。將原有的單個業(yè)務系統(tǒng)拆分為多個可以獨立開發(fā)，設計，運行和運維的“小系統(tǒng)”。這些“小系統(tǒng)”之間通過服務完成交互和集成。每個”小系統(tǒng)”除了能處理本身的業(yè)務功能外，同時也將自身的能力朝外部發(fā)布為服務。

SOA

SOA（面向服務的架構）是一個組件模型，它將應用程序的不同功能單元（稱為服務）的緊耦合系統(tǒng)，劃分為面向業(yè)務的，粗粒度，松耦合，無狀態(tài)的服務。服務發(fā)布出來后，供其他服務調(diào)用，一組互相依賴的服務就構成了SOA架構下的系統(tǒng)。

微服務是 SOA 的升級版，做到更細的粒度，處理了更多的問題。

例如圖1中將所有的功能打包在一個WAR包里，基本沒有外部依賴（除了容器），部署在一個JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等所有邏輯，缺點也非常明顯，部署不靈活以及擴展性不夠，但我們?nèi)绻凑請D2的為方式，按照業(yè)務而不是技術來劃分組織，內(nèi)部各個服務通過REST方式進行溝通，那么可以使平臺使部署、管理和服務功能交付變得更加簡單。

如果一句話來談SOA和微服務的區(qū)別，即微服務不再強調(diào)傳統(tǒng)SOA架構里面比較重的ESB企業(yè)服務總線，同時SOA的思想進入到單個業(yè)務系統(tǒng)內(nèi)部實現(xiàn)真正的組件化。

微服務與

一般提到微服務都離不開Docker與DevOps，理解微服務架構是核心，Docker是工具，是手段。

Docker容器技術的出現(xiàn)，為微服務提供了更便利的條件，比如更小的部署單元，每個服務可以通過類似Node.js或Spring Boot的技術跑在自己的進程中?？赡茉趲资_計算機中運行成千上萬個Docker容器，每個容器都運行著服務的一個實例。隨時可以增加某個服務的實例數(shù)，或者某個實例崩潰后，在其他的計算機上再創(chuàng)建該服務的新的實例。

DevOps即開發(fā)測試和部署運維的一體化。當我們的單體應用拆分為多個“小系統(tǒng)”后，雖然整體架構可以松耦合和可擴展，但是如果拆分的組件越多，這些組件之間本身的部署運維就越復雜。DevOps夠實現(xiàn)開發(fā)設計到部署運維的一體化。

微服務優(yōu)勢

1. 通過分解巨大單體式應用為多個服務方法解決了復雜性問題。 在功能不變的情況下，應用被分解為多個可管理的分支或服務。微服務架構模式給采用單體式編碼方式很難實現(xiàn)的功能提供了模塊化的解決方案，由此，單個服務很容易開發(fā)、理解和維護。

2. 這種架構使得每個服務都可以有專門開發(fā)團隊來開發(fā)。 開發(fā)者可以自由選擇開發(fā)技術，提供API服務，實現(xiàn)敏捷開發(fā)。

3. 微服務架構模式是每個微服務獨立的部署。 開發(fā)者不再需要協(xié)調(diào)其它服務部署對本服務的影響。這種改變可以加快部署速度。

4. 微服務架構模式使得每個服務獨立擴展。 你可以根據(jù)每個服務的規(guī)模來部署滿足需求的規(guī)模。甚至于，你可以使用更適合于服務資源需求的硬件。

四駕馬車

最后再談談咱們SuperMap家族中的四駕馬車（iServer、iExpress、iPortal、iCloudManager），這些產(chǎn)品也是借鑒了微服務設計思想，例如iCloudManager，它可以管理成千上萬的Docker容器，將每個Docker完全做到進程級別的隔離，資源占用率又很小，滿足微服務架構開發(fā)與測試以及自動化部署運維。

WEBGIS系統(tǒng)開發(fā)常用的技術框架有哪些，從前端到

前端：

1、老一代兩大富應用（RIA）框架（目前已經(jīng)停止更新）：flex、silverlight

2、其他開源（早期項目較多）：openlayer2、amap、bmap、ArcgisAPI4JS（3系列版本）

3、較新框架：openlayer3、cesiums、ArcgisAPI4JS（4.0之后版本）、

4、輕型框架（需要二次封裝）：WebGL(例如d3.js、three.js)

后端：arcgisServer、geoserver、mapserver

部分效果如下

flex:

img src="" class="content_image"

openlayers:

img src="" class="content_image"

cesiums: