基于中间件智慧城市建设模式

基于中间件的智慧城市建设模式探索摘要：本文首先描述了智慧城市的一般性建设思路，提出基于基础设施推进、数字化建设以及智慧应用的综合的智慧城市建设模式。

从总体来看，阐述智慧城市的建设包括哪些部分，进而深入每个部分，基于中间件进行分析，从实用性和可行性等方面阐述基于中间件建设智慧城市的模式。

进一步阐述在智慧城市的建设中，中间件是如何解决逻辑体系（基础设施层、数据层、业务逻辑处理成、页面展示层等）的各个层面的核心问题的。

关键词：智慧城市；中间件；云计算；物联网；soa中图分类号：tp393.092 文献标识码：a 文章编号：1007-9599 （2012） 23-0000-051 前言发展智慧城市是“十二五”提高城镇化质量、推进城市化进程、提高城市居民生活质量、改善与创新城市管理模式的重要举措。

智慧城市已是目前各个城市建设的主流模式。

目前我国已有上百个地区提出建设智慧城市，28个省市将物联网作为产业发展重点，80%以上城市将物联网列为主导产业。

虽然各大城市相继推出“智慧城市”的建设思路，但是由于各个城市的产业结构、地方特色各异，导致每个智慧城市建设的推进思路不太一致。

国外的智慧城市建设起步较早，基础相对较好，加之充分的“数字化”铺垫，使得智慧城市的建设目标明确，范围清晰。

但是，国外很少有像中国这样为数众多的大型、超大型城市。

在城市化建设过程中，也鲜有如此参差不齐的信息化发展水平。

因此，可借鉴的意义有限，更不能完全照搬，必须有选择地摘取符合地方区域发展特点的建设方式。

比如，国外多从智慧服务着手，强调区别于以往的“数字城市”“信息化建设”，强调所谓“智慧”是以公众服务为核心。

这是因为其信息化起步早，基础设施都已经完备。

但中国大部分城市没有进行达到如此高的信息化水平，或者信息化水平无法一概而论，因此，数字城市等的信息化基础建设作为“智慧城市”的前提条件，也在同时推进过程中。

正因为此，要想缩短这种基础层面的差异、快速发展适合地方建设需要的智慧城市体系，就必须整合现有的建设成果，充分利用国内信息化水平发达行业的经验和理念，迅速汲取经验教训，取其精华。

一方面少走弯路，同时又大胆创新，将先进的技术、业务成果转变为智慧城市建设的利器。

而中间件作为各个行业、各个技术领域最为直接的即有成果，正好适合于这种思路。

一方面因为中间件的产生，本身就是一个行业、一类业务应用、一种建设模式甚至一个功能点不断提炼总结、积累、改进、再发展的过程，是前人留下的宝贵经验；另一方面因为中间件涉及到的具体领域广泛而丰富，能够留存于世的，本身就是经历过创新、帅选以及市场实践的佼佼者。

因此，基于中间件技术，探索发展具有中国地方特色的智慧城市建设模式，结合基础建设、数字化建设与智慧应用共同推进的综合建设模式，为智慧城市建设思路提供了切实可行的方向。

2 智慧城市的组成部分从逻辑架构来说，智慧城市一般分为以下四个层次：智慧应用层、数据服务层、网络传输层、物联网感知层。

本文对智慧城市建设的一般性模式的描述，主要站在普遍性的解决思路角度，提出一般性建设思路，根据不同行业，还会有更为接近行业业务层面的建设模式。

智慧城市从上往下说，逻辑上分为智慧应用层、数据服务层、网络传输层、物联感知层。

以下对各个层次、子层及其涉及到的相关中间件进行了详细说明。

3 智慧应用层3.1 业务逻辑智慧应用存在于城市生活的方方面面，这一层次主要是指基于行业业务领域突破的创新点，能够为城市管理模式、民众生活带来改善的模式。

比如智慧公交中，如何智能安排每个公交车次发车时间，又比如智慧医疗中，如何发掘各种癌症的隐性风险等。

这层虽然不直接与中间件发生关系，但却是站在使用者角度，关于是否智慧最为直接的验证。

3.2 应用支撑层这类的商用软件或是开源软件数不胜数，常见的以java的开发性平台为主，比如j2ee应用服务器jboss、j2ee应用服务器glassfish、web应用服务器的tomcat、servlet容器jetty等等。

使用应用服务器作为应用底层容器已经是十分常见和成熟的模式。

4 数据服务层在数据服务层，主要解决数据资源、信息资源的整合和共享，为智慧城市的各种应用提供数据支撑和应用服务支撑。

构成了逻辑上的两个主要平台，数据共享平台和服务共享平台。

因此，我们能够看出，这一层的侧重在于“整合”和“共享”，所涉及到的系统通常既包括新建的系统，也包括现有的系统。

这两个平台一般基于soa架构，采用松耦合、分布式的体系架构，这样就能够针对不同规模、不同复杂度的应用进行动态伸缩，实现资源的最优化配置，最大程度节约开发、部署与运维成本。

另外，其技术体系与云计算技术体系保持高度兼容，可以与现有各类云计算平台融合，实现既有资源的优化使用。

4.1 资源池管理所有要被使用和管理的对象都能够称为信息资源（或者信息资产）。

这里的资源池可以分为基础设施资源、网络资源、计算资源、服务资源等等，具体分类因建设及管理需要而定。

基础设施资源指机房、空调、服务器设备、网络设备等，对这些资源的管理一般会有专门的信息系统。

网络资源指网管系统、网络数据包、运营支撑系统等。

计算资源指内存、cpu或者虚拟化之后的服务器资源，也就是可以分配给应用系统使用的资源。

服务资源是指业务系统层面能够提供的服务，比如webservice，文件服务，传输服务等。

（1）计算资源管理模式一：iaas+中间件这种模式，底层是iaas层或者虚拟化层，可见的是一个一个的虚拟机和虚拟机管理工具。

对于用户来说，看到的虚拟机就是一台服务器机器，在上面部署应用服务器，再部署应用程序，与直接在物理服务器上的部署是完全一样的。

虚拟机负责对硬件资源进行动态的管理和调配，按照应用服务器的配置的虚拟化硬件资源对硬件进行有效利用。

部署方式如下图所示，这里的中间件与传统意义上的中间件没有区别，存在于红色的虚线部分，与传统的非虚拟化的区别就在于增加了一层虚拟化层，所有应用服务器中间件部署在虚拟化层上，而传统的方式是直接部署在硬件服务器的操作系统上。

对于这种部署模式，可以采用虚拟机镜像的方式，将操作系统、应用中间件、应用程序的部署制作成一个镜像，通过直接拷贝镜像完成多台应用的快速部署，许多行业中号称虚拟化平台的实际做法就是这样。

当然，这样在实际部署实施过程中可以节省大量的工作量。

模式二：paas这种模式下，底层是用paas平台作为基础部署平台。

paas除了提供底层的硬件虚拟化层之外，还提供快速部署的高可用环境。

paas平台中包含了一个类似应用服务器的云中间件产品，依托于该产品，能够实现对硬件以及虚拟化资源的细粒度划分和管理，以及对应用进行按需供应计算资源。

涉及到的中间件产品就是红色虚线内的paas平台。

定位于快速部署的paas功能简述：提供比iaas更为细粒度的资源划分，也就是在一个虚拟机上还可以更细致的划分计算资源。

这个资源称为一个实例。

这也就意味着应用程序能够更加充分的利用系统资源。

提供集群功能，多个实例可以同时支撑一个业务应用系统，以保证高并发下的系统稳定性和可靠性。

快速部署。

用户的业务程序，可以无需改动，直接部署在tongapplaud平台上。

相比较而言，模式一目前采用的较多，因为平台实现相对简单，与传统应用系统部署建设模式类似；而模式二虽然平台建设复杂，一旦建成，将大量减少应用系统部署工作量。

（2）网络资源管理大型规模的业务应用系统可能会有专门的网管系统，比如电信运营商有专门的oss域系统管理各类网管系统。

对网络资源的管理主要依托于这些网管设备和网管系统。

较为常见的管理方式是建设一个综合的网管平台，比如综合资源管理、综合网络监控等，通过使用集成类中间件，将这些现成的、分散的网络资源进行集中整合。

这也是目前各大电信运营商采用的建设思路。

使用的中间件包括：1）传输类中间件（如消息中间件、或者文件交换中间件）对各网管系统的整合过程中，必然存在异地、异构平台的系统整合，消息中间件作为底层基础是必不可少的连接组件。

对于消息中间件，不论是商用还是开源，都有不少成熟产品，开源的比如active mq等。

一般的部署使用方式就是对等部署，在每个需要交换的点上安装消息中间件。

应用系统通过统一的api调用消息中间件，告知其要传输的消息内容以及传输规则和策略。

消息中间件作为目前常用的底层传输软件设施，已经被嵌入在众多的核心业务系统中，尤其是大规模分布式的业务应用，必然有跨地域、跨节点、跨应用交换数据的需求。

2）数据集成中间件各个网管系统建设厂家不同、技术体系可能不同、依照的标准也可能不相同，因此如何能够让这些多方面不同的网管系统的数据进行汇总，对营运支撑进行更有效的分析，对分析结果进行统一展现、以及提供决策的展示图表，通过数据集成中间件配合以消息传输类软件就能够完成所有规模的网络资源管理。

3）服务集成中间件以更为业务标准化（相对于技术标准化）的方式进行整合时，就需要使用esb类的产品。

作为智慧城市建设的一部分，可以使用智慧城市中综合的服务整合平台（一般都有esb）中的esb，因此这里就可以省去单独建设服务集成平台的部分。

当然，智慧城市的建设周期一般很长，另一种做法就是各个子部分的esb单独建设，都后期再从平台层面进行更高层整合，这个过程要比直接从各个业务系统层面整合要容易实现。

4）门户内容管理中间件portalportal类产品不是必需的，通过数据集成和服务集成中间件都可以实现类似的功能，要看具体需求。

当项目中特别注重网页的动态变化和每个用户的个性化展现时，portal是个很好的选择，如果只是普通的网站，侧重在数据的进行统一展现、系统的统一入口的话，使用了portal，反而造成不必要的开发成本，因为portal有自己的一套开发规则，必须按照其约束的规则进行开发，不但没有利用到portal的动态展现的优势，反而造成投资浪费。

（3）服务资源管理所谓服务，也就是使用和消耗计算资源的最小单位，但事实上目前能够做到按需供给计算资源的只能到应用系统一层，还无法达到功能服务层面。

这里的服务就是soa项目中的“服务”概念，也就是一些用webservice实现的、标准化后的业务功能。

之所以在这里提出对服务资源的管理，是因为soa在许多信息化推进过程中是不争的事实标准，不论是否是智慧的应用，但通过soa实现架构的合理分层、业务系统之间的可插拔式对接，是大规模业务应用系统的不二选择。

服务资源管理从广义上说，是对所有标准化后的服务的统一管理、调度；从狭义上说，主要指soa中的服务治理相关内容，包括服务生命周期管理、服务版本管理、服务依赖关系管理等。

目前业界有专门的服务治理软件，一般与esb产品配合使用，但都存在功能不完整，使用不方便等问题。

但对于服务资源的管控是项目可持续发展必须要考虑的问题。