基于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建设成果向资产化、服务化、云化(或微服务化)的方向发展，提升其治理能力和服务水平。

本文所选取的软件工程技术方法并非唯一可行方式，意见仅作参考。在实际开发建设过程中，尚需对于具体工作细节进行更深入的探究，才能将可扩展性架构运用到平台建设的实践中。后续可以从平台的物理架构以及实现平台架构的具体技术细节等角度出发，进行进一步的研究。