浅谈在线内容管理系统的业务化改造

韩 超

(衢州市气象局, 浙江 衢州 324000)

浅谈在线内容管理系统的业务化改造

韩 超

(衢州市气象局, 浙江 衢州 324000)

结合气象部门的业务环境特点，通过对在线内容管理系统内部URL机制的分析、数据模型的拓展以及功能模块的改造构建一个基于Web Service技术的数据交互平台。让运行在移动平台、桌面系统平台和网页平台的气象业务系统能够跨平台、跨语言并且无需任何第三方附加得进行数据交互，让分布于不同节点以及不同类型的数据库在这个交互系统中能够协同调用。让这个交互系统能够基于网络进行针对性的优化开发。

业务平台；数据交互；CMS;Web Service

0 引 言

在线数据的交互机制对于一些基于网络服务的气象业务来说，起着至关重要的作用。尤其是近年来移动互联技术的迅猛发展，伴随着移动智能终端数量的急剧增加，给网络内容推送的流畅性和稳定性带来了空前的压力。一个没有缓存机制和交互逻辑的网络内容管理系统，不仅会大幅增加我们的硬件维护成本，更让我们的网络服务平台在面对大量数据请求时陷入瘫痪。目前一些基于PHP语言开发的内容管理系统，虽然在工作逻辑和认证方法上有着较为成熟的解决方案，但却无法满足气象部门复杂数据环境的要求。因而了解这些内容管理系统的工作机制，并结合气象部门自身的网络环境特点加以改造，将对气象网络平台的服务体验有着极其重要的意义。

1 系统概述与选择

内容管理系统也叫“Content Management System”,一般简称为CMS系统。是一种介于Web服务器和办公流程之间的软件系统。它重点解决了各种非结构化或半结构化数字资源的采集、管理、利用、传递和增值，并能有机集成到结构化数据的商业智能环境中。随着网络服务复杂度和功能性需求的不断增长，如今以内容管理为应用核心的CMS产品大有百花争艳的感觉。这些CMS大致上基于两套框架编写：PHP+MySQL和.NET+MSSQL。前者相比后者更具开放性和便携性，能运行于UNIX、LINUX、WINDOWS下，且PHP和MySQL兼具开源免费的特点，使得基于PHP+MySQL的CMS在市场采用率和系统成熟度上要优于.Net+MSSQL的CMS。

近年来我国气象事业的不断发展使气象业务发生了根本性的变化。如今的气象部门以高分辨率、多方位连续监测的观测方式为主。这决定了气象资料采集的高密度和庞大的数据量，并形成了资料存储以结构化数据库为主非结构化数据资料并重的现状。Access、MsSQL、Oracle等多种数据库在不同的气象业务领域都发挥着不同的作用。气象服务也从传统的天气预报领域向环境领域不断拓展，伴随而来的则是服务平台、服务内容和受众群体的持续增长。气象部门在新形势下的诸多特点要求一个合格的内容管理系统因当具备以下3点特质：首先，系统不能局限于单一的数据库类型，要具备将不同的数据表内容分散到不同数据库中的功能。优化系统实现负载均衡的同时，还连接了分散在不同气象领域的各个数据库。其次，内容管理系统对于气象资料的推送不能局限于纯静态或动态生成的方式，应当能够响应不同软件平台的要求分类推送不同性质的内容。拥有这种灵活的内容缓存机制，才能通过网络流畅稳定得将气象数据推送到性质不同的终端上去。第三，系统还应该拥有Web Service技术的一些特质，支持跨语言跨系统平台之间的数据交互。综合考虑这些特质，决定采用对二次开发比较友好的Phpcms系统作为业务化改造的基础系统，借由这个系统的数据交互逻辑并在数据模型的支持上加以改造。

2 运作模式

Phpcms是一个基于MVC框架模式设计的CMS系统。它采用单一的入口文件，并且系统中的数据逻辑、数据显示和用户交互的处理部分都相互独立。这种低耦合的构建方式使得系统本身的视图层和业务层分离，让我们能以最小的代价对系统业务逻辑进行拓展和改造。

系统启动从入口文件index.php开始，在这里加载并初始化了位于phpcms目录下的框架入口文件base.php，在base.php里完成了一系列的系统变量及模型文件加载机制定义，最后进入phpcm/lisbs/classes目录下的应用程序创建类application.class.php，实例化application之后系统实现了MVC框架里最重要的控制器功能并进入了真正的程序逻辑部分：至此系统初始化工作基本完成，其逻辑流程如图1所示。

图1 系统初始化流程

2.1 URL路由机制

PHPCMS的控制器指向是由URL路由机制实现的，它是整个系统最关键的部分。这种路由机制是URL链接和系统模块之间的桥梁，负责将进入浏览器的请求映射到系统的各个控制器，以此让系统作出不同的逻辑处理。它从系统入口文件index.php开始，附加3个名为“m”、“c”、“a”的固定url参数，用来表示请求执行模型“M”下名为“C”的控制器中名为“A”的方法。系统内部的各个模型统一存放在modules文件夹下，所以一个形如index.php?m=content&c=index&a=show&catid=9&id=1链接的具体实现为， Url传入后在application类的实例中对各个参数进行拆解分类，筛选出“M”、“C”和“A”3个变量为系统固定参数其余变量为函数参数，然后通过在base.php中定义的方法，在系统固定路径下以变量“M”为文件名的模型文件夹中，找到以变量“C”为文件名的控制器文件，并最后在此文件中执行以变量“A”为方法名的函数。所以这个链接的具体含义为执行系统路径下modules/content/index.php文件中的index->show方法，并且执行的同时给show方法传入catid=9和id=1两个参数。

这种简便有效的控制器载入机制不仅局限于在网页浏览器上展示网站内容，它更支持通过HTTP协议的post和get方法与远程服务器进行交互，以此可以在气象业务网络环境中建立一系列跨平台跨语言的数据交互接口。例如一个气象数据查询平台，它的界面展示部分由delphi或C#语言开发，它的数据查询和数据逻辑部分基于CMS系统开发并通过Url的形式获取。此时CMS系统不仅可以方便得对所有桌面程序的请求内容和请求频率进行统计，还可以基于统计的结果进行优化并以缓存的形式推送，即是将请求频率较高的查询内容以xml、xsd、json文件的形式事先打包缓存在服务器。此外这个气象数据查询平台的服务端URL请求链接可以用API文档的形式组织起来并在气象内网上共享，其它业务开发或者平台自身向ios、android系统拓展时都能作为一种宝贵资源被再次利用。

3 数据模型的改造

3.1 工厂模式

气象部门基于数据库所开发的业务平台有很多，但能用多态性的编程理念，做到各类数据库统一调用管理的平台却并不多见。PHPCMS系统虽然用工厂模式实现了这个机制，但系统本身的数据库扩展只停留在了MySql这一个类型上。所以理解CMS系统数据库的多态性扩展方式，并针对气象部门拥有的数据库类型进行扩展，成了业务改造工作中的重点。

PHPCMS数据库操作的工厂模式通俗来说就是用一个能够创建多种数据库实例的提供者类，根据配置设置或者程序逻辑来决定实例化哪一种数据库。所以在PHPCMS系统内部主要由以下4种类来实现数据库的多态性机制：1)能够根据配置提供不同数据库实例的工厂类。以db_factory.class.php命名，位于phpcms/libs/classes/目录下；2)负责告诉工厂类应该实例化哪种数据库的配置类。以database.php命名，位于caches/configs/目录下；3)用来被工厂类实例化并且负责实现数据库具体操作的产品类。这种类文件的命名以数据库名称开头，后面附加.class.php，形如mssql.class.php，位于phpcms/libs/classes/目录下；4)根据工厂类可能提供的不同数据库实例，实现不同数据库实例同一化操作的模型类，为向后基于功能模块的扩展提供基类。以model.class.php命名，位于phpcms/libs/classes/目录下。以上4种文件共同构成了系统数据库操作的基石，其功能布局和业务逻辑如图2所示。

图2 数据库多态性扩展的实现逻辑

3.2 数据库操作模型的拓展

系统数据操作方面的改造工作首先应当从底层驱动的扩展开始。PHP作为开源免费的项目多年来一直受到各大IT厂商的青睐，所以PHP对各类数据库都有很不错的驱动支持。在PHP官方主页https://pecl.php.net的Database专栏下提供了55种功能各异特性不同的数据库驱动，包括在气象业务工作中可能用到的Mssql、Oracle、Mysql、Sqlite甚至是DB2和Lotus Notes的驱动。对同一种数据库的驱动选择上，尽管以PDO为代表的驱动能在不同数据库之间提供统一的API接口，但非统一接口的驱动在运行效率、功能性和版本兼容性上都要优于PDO驱动。在获得所需的驱动文件后，手动修改PHP的配置文件php.ini，加载相应驱动文件即可实现对数据库驱动的拓展支持。在服务平台有了对各类数据库的基本支持后，相应代码的编写工作可以从工厂模式下的四种类库着手，重点是新建mysql.class.php为代表的产品类，小幅修改db_factory.class.php工厂类和model.class.php模型基类。

首先是产品类的拓展。一系列的产品类不仅关系到各种数据库的直接操作，在系统内部更负责向工厂类提供一致的实例化接口，向模型类model.class.php提供一致的数据库操作方法，所以在代码组织上要求各种产品类的方法函数要有一致的名称，以及产品类之间的功能交集要大于等于模型类中调用到的方法函数，只有这样才能保证后面的模型类在拿到工厂类提供的数据库实例后，能用统一的函数名实现功能一致的方法。所以在函数方法名称上必须以mysql.class.php类为参照标准，用“open”、“close”作为开启和关闭数据库连接资源的名称标识以备db_factory.class.php在实例化时调用，并以“select、get_one、query、insert、update、delete、count、affected_rows、get_primary、get_fields、table_exists、field_exists”为数据查询的功能布局。在整个产品类的功能交集中，除了“select”方法所涉及到的分表查询在不同数据库中略有区别外，其它功能方法都能在各自的驱动接口API上找到。在mysql数据库中分表查询可以通过“limit”语句轻松实现，而在mssql和oracle中则需分别通过“ROW_NUMBER”和“RANK”来实现。在Oracle中需通过如图3所示方式实现。

图3 Oracle实现Limit分页查询的方法

在mssql中需通过图4所示方式实现。

图4 Mssql实现Limit分页查询的方法

产品类编写完毕后，需要对PHPCMS系统原有的工厂类文件db_factory.class.php做小幅的改动，以适应新增数据库类型的实例化工作。db_factory.class.php类是基于单件模式设计的，类成员函数“get_database”通过接收一个代表数据库类型的字符串参数，来决定向外界传递何种类型的数据库实例。

而这种类型初始化的选择机制是通过一个switch-case语言来实现的。所以想要拓展工厂类所能支持的数据库类型，只需在类函数“connect“内的switch语句中，新增case选择条件即可。例如“case′ mssql′:

pc_base::load_sys_class('mssql','',0);＄object=new mssql();break;”这样简单的几行语句即可完成一类数据库的扩展工作。

在完成db_factory.class.php工厂类的改造工作后，再配合原系统的model.class.php模型基类，可以说基本已经完成了数据库平台支持的拓展工作。但鉴于部分数据库对于数据库表名称大小写的特殊要求，还需要模型基类在读取数据库参数设置时做一些针对性的处理。例如在模型基类的构造函数里添加“if(＄this->db_config[＄this->db_setting]['type']=='oracle');＄this->table_name=strtoupper(＄this->table_name);”，用来将database.php里的数据库表名统一成大写字母。

4 功能模块的开发设计

在系统数据操作类库拓展完毕之后，可基于这种多态性的数据模型结构，并结合气象业务的特点进一步开展气象业务模块的开发工作。由于phpcms系统是基于MVC框架构建的，受益于这种高内聚、低耦合的代码组织方式，我们的模块开发工作可清晰的分为两个部分：1)数据库操作模型的拓展，在系统路径“phpcms/mode/”下派生模型基类model.class.php，并且在database.php中完成相关参数配置；2)功能模块的开发，在系统路径“phpcms/modules/”下新建以模块名称命名的文件夹，并在此文件中完成数据交互逻辑相关类库的开发。

4.1 数据库操作模型的拓展

拓展工作主要涉及database.php和model.class.php这两个类文件。database.php并不是一个类文件，它仅作为一个代码片段存在于phpcms系统的配置文件夹下，主要功能是向包含它的类库文件返回一个数据库配置信息列表以供变量成员挑选并赋值。database.php的代码结构由一个二维数组构成，数据库的连接参数以库为单位存储在这个数组里。数组的第一个维度是配置参数的自定义名称，第二个维度则是这个名称所对应的具体参数。所以在database.php中新增数据库参数配置，只需在文件返回的二维数组中新增一条形如“test=>array(…数据库参数…)”的记录即可。其次是在model.class.php类的基础上派生新的数据模型。这个数据模型是基于表设计并且能被高度重用的。它仅表示数据库操作层面的一种模型并不确切指向前台的某种交互逻辑。数据模型与功能模块之间的低耦合性，使得一个模块功能的数据操作可以由多个指向不同类型数据库的模型共同组成。model.class.php类的派生编写工作也很简单，新的子类只需要在重载构造函数时重新定义参数配置名和数据表名即可。

4.2 模块的开发

系统模块的根目录位于“phpcms/modules/”路径下，目录中是以具体功能为分类命名的各个模块文件夹，文件夹内包含的类文件则是各类数据交互的执行逻辑。在类文件的执行方法中，以“＄this->db = pc_base::load_model('xsweb_168_nowcasting');”的形式，在加载相应数据模型的同时即可完成数据模型的初始化工作，然后根据model.class.php类中提供的方法函数，便可完成数据库的交互操作。只要熟知系统的URL机制和模块加载机制，模块类可按需推送图片链接、二进制文件链接或者直接推送明文或二进制文件等各类数据格式。

模块的开发工作可充分利用网络语言的特点进行深度优化。仅以推送不同时间跨度的降水量统计数据为例：1)可在推送数据的同时，模块向系统自身提交一条url链接以统计请求的频率和数量。如此可在不影响数据推送的同时完成统计工作；2)基于这种统计，当某时间跨度的雨量请求数量达一定量级时，系统在更新请求数值的同时，在特定目录生成一个以时间戳和特定ID命名的内容为空的标识文件，并以此文件为信号决定是否在响应请求时生成json或xml等格式的静态文件缓存在服务器，在第二次响应相同的请求时将静态文件的内容直接发送给客户端；3)系统平台可以是分布式存在于多个节点之中的。用一台服务器作为响应请求的入口，以请求客户端的地理分布为条件向其它服务器分别发送请求信息并最终获取请求结果反馈给客户端；4)可将特定内容提前生成缓存文件，在响应请求时不经过数据库和其它执行逻辑直接发送给客户端。

5 Web Service带来的改变

“历史上的今天”是衢州气象内网页面中的一个数据展示模块，栏目内容包含“历史上的今天”、“历史上的明天”、“历史上的未来三天”和“历史上的未来十天”4个方面，栏目数据涉及衢州各县市建站以来各项温度数据，降水数据以及降水频率的分类统计。由于网站本身通过对phpcms改造而构建出一个Web Service平台，所以给栏目本身的多平台拓展和优化带来了巨大的改变。

5.1 多平台的拓展

从栏目内容上看，这类历史均值、极值统计模块的应用范围比较广泛，在各类气象网站、手机APP终端或桌面业务平台中都非常常见。然而对于开发者来说，要在特性和编程语言都不尽相同的各个平台中开发功能相近的项目，意味着大量重复且无法避免的数据库编程工作。但基于web service平台开发后，栏目在安卓平台上推出时可由栏目现成的Url获取数据并直接介入界面UI的开发,其开发流程如图5所示。

图5 基于WebService技术的系统多平台开发流程

5.2 优化和效益评估

项目的跨平台工作通常会带来两个不可避免的问题。首先是支撑服务器维护的工作量会成倍增加。其次，随着平台数量的增加和客户端系统的差异化加剧，系统的整体稳定性会受到严峻的考验，并导致系统优化的难度不断加大。然而通过改造Phpcms系统构建一套基于web service技术的数据推送平台，能够将这些难题化零为整，统一优化一劳永逸。

在“历史上的今天”这个栏目中，为了提高栏目本身的稳定性和应对大量客户端并发请求的负载性能。

我设计了这样一个简单而有效的php进程协同模式：应对短时间内大量的并发请求时，数百个各自独立的php处理进程并不会抢着向数据库服务器要统计数据，众多进程间会等待第一个向服务器发出请求的进程，直至该进程拿到统计数据并形成缓存文件，其他进程再获取这个缓存文件内的统计结果。

为检验栏目在如此改造后的工作效率，特别设计了这样一个对比实验：实验通过并发线程的方式模拟数百个客户端在500 ms的时间内随机向服务器请求栏目所需的统计数据，随着并发客户端数量的增加记录每个客户端完成统计需要的毫秒数并取平均值。实验的前提：1)实验的客户端都是通过j2se编程的桌面程序；2)客户端向服务器请求数据之前，服务器端不存在任何现成的缓存数据。

图6 常规平台与WebService优化平台对于短时并发请求的查询效率对比

实验结果如图6所示。其中，运用常规方法统计数据的客户端在并发数量达到400个时，出现了大量数据库连接超时的情形，并且随着并发请求数量的不断增加，单个线程完成统计所需的平均耗时从最初的3～5 s延迟到了1 min多钟，甚至无法完成统计。但基于web service技术来请求数据的客户端因为收益于web平台本身的并发特性优势和一系列的优化措施，其工作效率几乎不受请求客户端数量的影响。最后，基于web service的客户端再次向服务器请求相同的统计数时，由于服务器已有统计完成的缓存数据，400个并发线程请求完成的平均时间只需要15 ms。

6 结 语

通过对Phpcms系统的分析和内部数据模型的改造，建立了一个基于phpcms系统内核并且能够实现Web Service技术的数据交互平台。新平台基于URL的路由机制使得数据交互能够跨语言跨操作系统，新平台基于数据库多态性的机制实现了不同数据库的协同开发。新平台基于网络语言的优化使得来自不同特性的客户端请求有了一个高度整合和统一维护的平台。

改造后的新平台能使运行在不同机器上的不同应用无须借助附加的、专门的第三方软件或硬件，就可相互交换数据或集成。系统本身也很容易部署， 因为它们基于一些常规的产业标准以及已有的一些技术，诸如XML、HTTP、PHP。它不仅具有良好的维护性和扩展性，它更为气象部门的各个业务平台在数据交互上提供了一个通用的机制，使得移动气象平台，桌面气象平台和网页气象平台在交互上形成一个统一的整体，使我们的开发维护工作能够基于3种平台统筹兼顾。

[1] Ethan Cerami(美).Web Services Essentials[M].美国：O′Reilly,2003

[2] 沈伯青,杨宗凯.WEB服务的基石:UDDI技术[J].计算机工程与应用,2003:147-150.

[3] 邓 莹，冯向科.探讨Web Service的关键技术及其实现[J].电脑知识与技术，2006(35):28.

2015-04-22