基于CIM新型智慧城市管理平臺可擴展性架構設計探究

(上海市政工程設計研究總院(集團)有限公司,上海 200092)

1 CIM的定義

目前，在建筑以及市政工程項目領域，建筑信息模型技術(Building Information Modeling，簡稱BIM)作為建設以及運維項目管理工作過程中的信息化管理工具，得到了廣泛的應用。它借助前沿的計算機技術以及信息技術，對現實世界進行虛擬世界的模擬和呈現，并進行信息集成，基于此對工程項目進行多角度、多方位的協同管理，助力工程項目的質量與工期保障、成本節約以及智慧化運維管理，助力實現項目的設計、施工和運維的一體化全生命周期管理。

而城市信息模型(City Information Modeling，簡稱CIM)的概念基于建筑信息模型(BIM)技術而興起，它將BIM對建筑完整信息數字化建模，用于設計、施工、使用、維護全生命周期管理的概念，擴展到了城市領域[1]，提供各個BIM單體之間連接網絡管理能力、空間分析能力以及大規模建筑群的BIM數據管理能力[2]，并以城市信息數據為基礎，建立起三維城市空間模型和城市信息的有機綜合體[3]。它期望提供一種有效的方法，以組織描述城市的信息[4]。建設基于CIM的新型智慧城市管理平臺的目的在于，打通傳統城市中各部門的數據孤島和信息煙囪，減少溝通成本和平臺的重復建設，建立在城市管理中實現政府各機構與社會業務協同的關系網，支持城市規劃、設計、運行、管理等多部門多領域的信息互聯互通與協同工作管理需求的滿足，支持監督、檢查、調度、分析、預測與決策等需求的實現，全面提高政府的公共服務能力和城市治理模式[5]。

當前，在積極推動智慧城市建設的國家政策背景下，基于CIM的新型智慧城市管理平臺的建設尚處于起步階段，因此，在此類平臺架構頂層設計層面需要根據業務特點具備前瞻性和預見性，才能有效滿足平臺后期可擴展、可復用、可維護性、可持續發展的需求，真正避免重復建設，使平臺有效服務于城市治理，并提供有效城市信息價值。然而，目前國內外對于此類平臺的建設方式尚缺乏深入的研究，多數停留在對于相關概念的描述以及對于相關技術的羅列上，鮮有對于具體所面臨的細節問題進行探討的文章。本文就此類平臺建設過程中的可擴展性方面進行探討，并嘗試提出解決方案，供平臺建設的一線工作人員以及城市管理決策者、相關部門參考。

2 可擴展性架構的內涵

軟件架構的可擴展性，從廣義上講，是指降低因平臺為實現新的需求進行的修改而對平臺已有其他功能的影響。對于隨著時間規模會不斷增長、數據體量不斷增大、業務復雜度不斷提高的軟件平臺而言，需要首先考慮的主要有數據存儲、并發等容量和性能方面的問題，以及業務復雜性方面的問題等，如果在頂層架構設計之初沒有對這些問題進行充分考慮，會影響到業務的交付能力，使重構變成常態，浪費大量人力物力財力。

可擴展性作為制定軟件架構設計的重要指標之一，是平臺業務增長時對于增加系統負載問題的必要解決方案。理想的情況下，一個高可擴展性的軟件平臺，資源的使用應該隨著負載線性增加，而不是呈指數型增加[6]。可擴展性主要包括應付以下三方面的增長：不斷增長的數據管理需求、不斷增長的終端用戶需求和不斷增長的功能類型需求[7]。要提高一個軟件平臺的可擴展性，需要在了解業務需求與特點的基礎上，選擇適應于當前軟件平臺業務特點的最佳方案。

3 可擴展性架構的設計方法

3.1 基于CIM新型智慧城市管理平臺基本特點與需求分析

基于CIM的新型智慧城市管理平臺作為服務于政府的大型三維可視化管理平臺，在考慮其可擴展性設計時，所需要考慮的屬于此類型平臺的專有特點以及相應的需求如下：

(1)業務鏈條復雜、繁多且長。平臺在頂層設計之初需要將業務鏈條梳理清晰，支持各有關部門單位進行在線協商、意見跟蹤、信息共享與矛盾協調，并對未來的業務擴展需求進行前瞻性考慮，并在平臺軟件設計上對此納入考慮、預留接口，并考慮到并發需求的承載力。

(2)所管理的物理空間跨度和廣度大，所需存儲的數據種類繁多、總量巨大，并有多種具有實時更新需求的數據種類，例如物聯網(IoT)監測數據等。因此平臺需要對海量多維數據能夠進行有效的存儲與歸類分析，面對高并發的海量I/O需求呈現出穩定的數據承載及調度能力； 同時，要選取優秀的大片區三維渲染引擎，展現流暢清晰的虛擬空間顯示界面，提高平臺的服務質量。

(3)所對接的口徑多，尤其是法律法規標準、管理指標口徑多； 現有各部門數據孤島、信息煙囪林立。因此相關業務數據交付標準的制定、數據清洗的工具的開發和完善、與現有的平臺系統的對接與取舍迫在眉睫，需要各單位的多方協調工作，為平臺的數據庫設計和業務流程標準化做出鋪墊性工作。

在以上的三類需求中，設計出合理的軟件可擴展性架構是滿足前兩類需求的必要不充分條件。下面，本文將對如何進行針對此類平臺的可擴展性架構設計做出探討與分析。

3.2 管理平臺的可擴展性架構需求分析

3.2.1 平臺業務角度

基于CIM的智慧城市管理平臺需要支持多管理部門、多種類、復雜流程的長鏈條業務類型，例如廣州的CIM試點平臺中[8]，擬開發的應用包括房屋管理應用、建設工程消防設計審查和驗收應用、城市更新領域應用、公共設施應用、美麗鄉村應用、建筑行業應用、城市體檢應用、建筑能耗監測應用與和其他系統(例如BIM施工圖三維數字化審查系統、基于BIM的施工質量安全管理和竣工圖數字化備案系統等)的對接等。其中每一領域的應用都有一系列的業務，并且會隨著時間的推移不斷擴展。

除此之外，平臺的業務還涉及多個階段的模型及屬性信息的入庫、查詢、分析等基本功能，作為以上各領域應用的前提條件和基礎支撐，這些業務在操作的時候，需要相應的數據庫具有穩定安全的存儲能力，并且其響應速度應該在用戶的接受范圍之內； 同時平臺業務中還可能涉及多個審批流程，隨著時間的變化，平臺可能需要根據政策的改變靈活地設置相應的報批審批步驟等。

在進行以上業務的時候，流暢、清晰、豐富、多種風格的三維展示效果是平臺等通用性需求，因此平臺需要選取卓越的三維圖形引擎作為承載。

3.2.2 平臺用戶的典型操作

平臺用戶的典型操作主要包括：各相關單位、部門的數據管理員或平臺操作員、規劃建設研究人員進行數據一體化入庫與數據更新、數據查詢分析、審批流程操作、自動導出所需信息和報告、城市模擬仿真等操作，以及有關單位的領導與管理人員對三維數據及分析數據的瀏覽與查看； 后期還會有公眾用戶對平臺進行瀏覽操作等。

3.2.3 平臺性能要求的側重點

一般而言，軟件平臺的性能包括容錯性和高性能兩方面，不同類型的平臺對這兩方面有不同的程度的側重。

(1)對于平臺性能要求而言，軟件平臺的容錯性包括兩方面，其一是因軟件平臺的內部錯誤而發生錯誤時，仍然能夠在一定程度上完成用戶操作指定的預期功能； 其二能夠在一定程度上，從錯誤的狀態自動恢復到正確的狀態。基于CIM的智慧城市管理平臺作為多用戶多部門單位協同操作的平臺，需要具有較高的容錯性，使單人操作造成的錯誤不至于頻繁的影響到平臺其他功能以及其他部門人員的使用，減輕平臺運維工作人員的工作復雜度。

(2)對于軟件平臺的高性能要求而言，關注的指標包括響應時間、TPS、服務器資源利用率(CPU使用)、系統響應時間和應用延遲時間、吞吐量、并發用戶數等。對于該平臺而言，對服務器資源利用率和吞吐量的要求較高，對于響應時間、TPS、系統響應時間和應用延遲時間的要求中等，但也不能夠過于卡頓，而并發用戶數會隨著時間而緩慢增長。

3.2.4 平臺容易出現的性能瓶頸

平臺容易出現的性能瓶頸包括三維引擎承載力瓶頸、業務穩定性與安全性瓶頸、數據計算速度瓶頸、以及海量多維數據錄入、存儲、查詢與I/O瓶頸等。

3.2.5 可擴展性架構需求

根據以上的分析，基于CIM的智慧城市管理平臺的可擴展性架構需求有如下幾類，見表1。

表1 基于CIM的智慧城市管理平臺的可擴展性架構需求

3.3 可擴展性架構設計的方法分析

為了滿足基于CIM的智慧城市管理平臺的可擴展性架構需求，在總體原則上，需要開發以模塊化、松耦合、可擴展、易升級、開放式、粗粒度為特征，通過標準化接口連接形成的開放、有機整體的平臺。針對上文所提到的平臺可擴展性架構需求，從平臺服務的組織方式和數據存儲兩方面進行重點分析，并對不同架構形式進行優缺點比較，為后面選取合適軟件架構提供參考依據。

3.3.1 對服務的拆分與重組

根據文獻[9]所提出的可擴展模型——AKF可擴展立方(Scalability Cube)理論，在上文提到的面對多種而復雜的業務類型、平臺高性能要求和高容錯性需求等方面，可擴展性的架構設計常用的設計方法是對于服務進行拆分與重組，具體參考以下三個維度的方法：

(1)對服務或數據進行無差別的復制

該方法主要關注數據和服務克隆，即通過絕對平等地復制服務與數據并且無偏向地將工作任務分配給它們，以解決容量和可用性的問題，其中各個復制品之間不共享任何工作內容。完成這個方案的主要技術方法有兩個，其一為負載均衡，即通過負載均衡器將用戶的訪問請求均衡分配給“復制品”集群，如果某一復制品出現故障，則將工作任務分配給其他復制品。其中涉及到的具體技術點包括反向代理、DNS輪詢、哈希負載均衡算法(一致性哈希)、動態節點負載均衡(如按CPU，I/O)等，這種方法可以在某種程度上提高服務的穩定性和用戶請求處理效率； 其二為數據復制，這種方式主要是為了解決存儲層I/O瓶頸以及可用性的問題，因而對數據存儲層進行平等的數據遷移。分布式數據庫系統的三個特性：一致性、可用性和分區容差是不能被同時滿足的，需要根據業務的具體特點來進行取舍。

(2)根據職責與功能對服務進行拆分

該方法關注應用中職責的劃分，即為了提高服務的工作效率將一個服務拆分成一組服務，使每一個子服務的工作更簡單純粹，效率更高。其中在工作中最常見的方法為運用微服務架構SOA，旨在利用松耦合的服務帶來業務重用。

對于本平臺可考慮的SOA架構有兩種方式[10]：

1)ESB企業服務總線模式，這種模式本質上是為了解決異構系統的交互問題，采用集群部署的方式進行壓力分擔。這種模式能夠改善服務調用關系和服務管理，但缺點是每次企業服務總線的擴容都會帶來在軟件授權和硬件資源上的不小投入，當超過承載量的用戶并發操作時易造成“雪崩”。

2)“去中心化”服務架構模式。這種模式主要解決系統擴展性問題，更快進行業務響應、支持業務創新，服務提供者和服務調用者之間在進行服務交互的時候無需通過任何服務路由中介，避免因為“中心點”帶來平臺能力難以擴展以及“雪崩”影響，但缺點是可能帶來服務調用關系與數量上的混亂。這種服務調用模式一般運行在企業內部網絡環境中，基于統一技術接口標準、網絡協議、規范進行交互。

另外，SOA架構中包含有日志和監控機制，能夠盡快檢測故障、恢復故障，滿足平臺的容錯性性能需求[11]。

(3)根據服務或數據的優先級對服務進行劃分。該方法關注服務和數據的優先級劃分，即基于服務請求者獨特的需求進行系統劃分，并使得劃分出來的子系統是相互隔離但又是完整的，它是以上兩種服務拆分方法的組合。其實現技術方法主要有單元化架構、數據分區，而數據分區在帶來好處的同時也有代價，它將增加數據運維的難度和關聯搜索的復雜度。

3.3.2 數據的存儲

上文提到的海量多維數據存儲、查詢、分析等需求，可以通過選取合適的數據存儲與查詢方式得到滿足，平臺高性能要求和高容錯性等方面，同樣依托于合適的數據存儲與查詢方式。

傳統的關系型數據庫管理系統(RDBMS)，例如MySQL、Microsoft SQL Server數據庫、Oracle數據庫等，一般由單個的服務器提供，當數據量增大時采取分區方式，將數據分到不同的機器上，這樣的方式增加了方案的復雜度、不支持動態擴展、查詢速度慢、且故障率高，不適宜海量數據的存儲。

新興的非關系型數據庫，例如Hbase、HDFS、MongoDB、Elasticsearch等，為分布式數據存儲系統，能夠在普通PC上搭建大規模結構化存儲集群，為海量多維空間數據存儲提供底層平臺，成為了平臺的可參考數據庫選擇。而不同種類的分布式數據庫在性能上各有千秋，其中最主要的性能關注點主要是存儲和查詢的速度。一般而言，存儲和查詢的速度不能被同時兼顧，需要根據業務的特點做出取舍，選擇合適的數據庫。例如，對于諸如物聯網大數據等海量多維數據需要數據庫擁有足夠的寫入速度，以滿足它的實時存儲需求，同時，如果要對物聯網數據進行實時的分析和可視化展現，則需要數據庫在復雜查詢檢索方面也表現出色； 而對于城市三維空間數據、城市基礎底圖數據等而言，數據庫的寫入速度并不是第一重要的考慮因素，而數據庫的讀取速度則是非常重要的，用以滿足用戶對城市三維空間的流暢瀏覽需求。

在以上幾種數據庫中，HBase引擎最大的優點是存儲容量大、擴展能力強，能夠把巨大的表分布到很多臺機器上面，對于海量的數據進行支持，具有高性能、可彈性伸縮及分布式特性，支持PB級大數據存儲，滿足千萬級并發，適合于實現對海量城市空間大數據的存儲； 但缺點是對于數據的讀取局限性非常大，不能夠支持復雜的查詢功能。MongoDB是文檔數據庫的典型代表，數據庫中的每一行數據只是簡單的被轉化成Json格式后存儲，表結構靈活可變，字段類型可以隨時修改，對于大數據規模的查詢和存儲均表現優良，但缺點是不適合多表查詢、復雜事務等高級操作，它能夠滿足對柵格瓦片、矢量瓦片和三維瓦片等城市基礎底圖的存儲支持，也能夠支持無需進行復雜查詢的海量靜態數據的存儲。 Elasticsearch是會自動對所有字段建立索引，以實現高性能的復雜聚合查詢，但它的短處在于字段類型無法修改、寫入和存儲的速度和性能較低和高硬件資源消耗； 而HDFS引擎是為以流式數據訪問模式存儲超大文件而設計的文件系統，適用于大文件的存儲和流式讀取的方式，支持非結構化的數據存儲，也提供了數據的空間化能力和空間索引技術，適合寫入一次、讀取多次的應用場景，但缺點是不適用于大量小文件的存儲和隨機性強的寫入和修改數據。它適用于大量城市矢量靜態數據的存儲[12]。在平臺的搭建過程中，可以將不同類型的數據分類，根據所儲存的數據特征和實際業務需求，分別選擇合適的數據庫服務對其進行存儲，作為平臺的支撐。

3.4 基于可擴展性需求的平臺開發方式選擇

根據以上對可擴展性架構設計方法的分析，本章結合平臺的需求選取適宜的技術方法，以滿足平臺的可擴展性需求，具體如下：

3.4.1 對服務的拆分與組織的方式選擇

對于平臺的服務的組織方式而言，對于服務的拆分主要是為了滿足平臺多種且復雜的不斷增加的業務類型、高服務器資源利用率和高吞吐量、用戶能夠接受的程序相應時間、逐漸增長的服務并發數量和一定的容錯性。因此，根據3.3章節的分析，本文認為，平臺內的組件之間可以根據需求通過標準化的接口以“去中心化”SOA服務架構進行分布式部署、組合和使用，在具體的部署上，宜采取建立數字中臺的模式，以模塊化、松耦合、粗粒度為特征，運用服務編排的技術通過標準化接口對于平臺的業務進行部署，提高其業務的擴展承載能力。而對于在使用中會被頻繁調用的子服務，宜采取服務克隆的方式來提高該子服務的承載能力，并通過負載均衡器將任務平均分配給各克隆服務，達到負載均衡的目的。這樣的架構設計方式可以有效地解決系統擴展性問題，實現更快進行業務響應、支持業務創新，避免因為“中心點”帶來平臺能力難以擴展以及“雪崩”影響。

3.4.2 對數據的存儲方式的選擇

對于數據的存儲而言，合理的存儲方式應考慮到平臺中不同類型的數據存儲查詢的需求，以及不同業務類型分別選取不同的數據庫對數據進行存儲。基于前文對Hbase、HDFS、MongoDB、Elasticsearch這四種數據庫性能的分析和比較，本文認為，用MongoDB引擎來存取柵格瓦片、矢量瓦片和三維瓦片等城市基礎底圖數據，用HDFS或者HBase來存取海量的城市矢量靜態數據以及無需進行復雜查詢的城市空間大數據是不錯的選擇，而涉及到海量數據復雜查詢的業務，用Elasticsearch引擎是不錯的選擇，但是由于Elasticsearch引擎較慢的數據寫入速度，涉及到海量數據復雜查詢的數據存儲需要Elasticsearch引擎與HDFS或者HBase配合使用； 綜上所述，選取HBase、MongoDB和Elasticsearch三種分布式數據庫的組合或者HDFS、MongoDB和Elasticsearch的組合能夠很好的覆蓋到基于CIM的新型智慧城市管理平臺對于海量城市基礎地圖、城市矢量靜態數據和物聯網的實時數據的存儲需求。

3.4.3 平臺可擴展性架構設計

根據以上對于架構方式的選擇，本文得出了平臺的可擴展性架構設計，如圖1。

圖1 基于CIM的新型智慧城市管理平臺的 可擴展性架構設計圖

4 結論

綜上所述，經過對基于CIM的新型智慧城市管理平臺的基本特點和需求的分析，以及對于可擴展性架構設計的方法分析，本文從對服務的拆分與組織的方式選擇、數據的存儲兩方面選取了適用于該平臺可擴展性架構的設計方式，供城市管理決策者、相關部門以及一線的平臺開發建設工作人員參考。具體如下：

(1)對服務的拆分與組織的方式選擇

在服務的組織方式方面，服務之間宜根據需求通過標準化的接口以“去中心化”SOA服務架構進行分布式部署、組合和使用，以提高業務的擴展承載能力； 其中，在使用中被頻繁調用的服務宜采取對其進行服務克隆的方式來提高該服務的承載能力，并通過負載均衡器將任務平均分配給各克隆服務，達到負載均衡的目的，形成一個集廣泛信息采集、多維統計分析、智慧應用操作與展示等功能于一體的城市運行管理與服務系統。

(2)數據的存儲

而在數據存儲方面，宜選取HBase、MongoDB和Elasticsearch三種分布式數據庫的組合或者HDFS、MongoDB和Elasticsearch的組合方式，作為數據存儲的有力支撐。其中，HDFS引擎或者HBase引擎用來存取海量的城市矢量靜態數據以及無需進行復雜查詢的城市空間大數據，MongoDB引擎用來存取柵格瓦片、矢量瓦片和三維瓦片等城市基礎底圖數據，Elasticsearch引擎與HDFS或者HBase配合使用，來對海量數據復雜查詢進行存儲和查詢。通過采取上述的架構設計方法，基于CIM的新型智慧城市管理平臺可擴展性需求可以在一定程度上得到滿足。

設計合理的可擴展性軟件架構是構建以數字中臺為代表的新型基礎設施建設的基礎，目的是為業務應用提供規范化的可復用組件和服務資源，滿足平臺可擴展、可復用、可維護性、可持續發展的需求，避免平臺的重復建設，促進政府部門的現有IT建設成果向資產化、服務化、云化(或微服務化)的方向發展，提升其治理能力和服務水平。

本文所選取的軟件工程技術方法并非唯一可行方式，意見僅作參考。在實際開發建設過程中，尚需對于具體工作細節進行更深入的探究，才能將可擴展性架構運用到平臺建設的實踐中。后續可以從平臺的物理架構以及實現平臺架構的具體技術細節等角度出發，進行進一步的研究。