在政府机构中, 工商、公安等机构基本都拥有自己的门户网站;在企事业单位中, 各中大型企业、医院、学校等也有相应的办公门户.在这些门户网站中, 往往会碰到信息陈旧、板块空缺、布局杂乱、进入层次太深、系统更新缓慢、用户很难找到自己关注信息等问题.导致这些现象的因素很多, 有的因为经费不足而缺少维护;有的因为测试不全面导致系统稳定性差;有的因为缺少规划而赶不上发展速度;还有因为无法利用现有系统资源, 机构小而没有内容支撑门户网站建设等原因.
作为企事业单位中的信息部门, 面对系统扁平化、个性化需求的增加, 导致系统定制化趋势越来越明显, 信息部门除了创建数量庞大的系统来满足用户不断变化和增加的需求之外, 还有其他应对措施吗?大多数人都知道, 传统网站架构往往是根据业务需求、现有团队等因素考虑设计, 主要解决的是通用需求和当前业务, 团队成员之间也相对了解, 能快速完成一个个独立的信息系统.但这样的系统设计与开发团队耦合性太紧密, 一旦团队核心人员变动, 往往会导致系统可扩展性和稳定性受到极大的影响, 或一旦需求变化太大, 系统就必须大规模重新设计才能满足需求.在越来越依赖信息化的今天, 需求快速变化是比较正常的, 这就导致上述各种现象.为了规避这些现象, 信息部门必须具备以下的能力才能够应对挑战:1) 持续提高创新能力, 使系统的技术含量越来越高, 以满足客户需求;2) 不断缩短系统研发时间, 快速响应用户需求;3) 不断强化成本控制能力, 通过优化产品生命周期内的各种成本来控制系统总成本, 取得投入产出比优势;4) 持续稳定的质量改进能力.
经验表明, 设计信息系统一方面必须利用业务模块的批量化、标准化和通用化来缩短系统上线周期、降低研发成本、提高模块重用性和系统稳定性, 另一方面还要不断地进行研发创新使系统越来越个性化, 满足用户的定制需求.这样, 如何平衡系统的标准化、通用化与定制化、稳定性之间的矛盾, 成为赢得竞争的关键因素.基于这两方面的考虑, 设计一套基于模块化的弹性扩展门户网站架构.该设计把业务拆分为一个个模块, 通过这些模块的组合可以向分支机构、下属单位、甚至岗位、人员提供相应的个性化门户系统, 不仅解决了企事业单位整体的系统建设成本, 而且也解决了门户网站内容不足、内容复用、组织机构之间信息交互等问题.对软件开发团队来说, 也解决了系统迭代的稳定性、模块之间的耦合度、用户需求的个性化、开发团队分工与协助等问题.
1 系统分析与建模
1.1 架构需求
企业门户是一个联接企业内部和外部的网站, 它把各种应用系统、数据资源、业务处理与企业各部门、分支机构等需求统一集成到门户之下, 可以为企业提供一个单一的访问企业各种信息资源的入口, 企业的员工、分支机构、合作伙伴等都可以通过这个门户获得个性化的信息和服务.经过多次整理归纳, 明确了企业及用户对架构的主要需求内容如下:
1) 企业门户统一入口地址, 针对特定节假日有换肤功能, 每个分支机构和部门有独立的门户, 特定岗位和特定角色也有特定门户.
2) 企业门户、部门门户等内部常规门户必须包含总公司的公告、邮件、流程审批等模块.
3) 特定用户可能在多个部门任职, 则该用户的门户可能是包含多部门信息的独立门户, 也可能是采用切换的方式访问多个部门的门户.
4) 每个用户登录到门户首页, “第一眼”就能看到自己当天的待办工作和关注信息.
5) 每个模块只开发一次, 后期只是各模块单独升级, 可以重复利用, 不要重复开发.
6) 每个门户的关注点和导航都不相同, 但是相同模块在不同门户里的具体内容相同, 导航页面之间的切换不能改变用户的默认选择.
7) 每个模块相对独立, 不能影响其他模块及整体系统的使用.
1.2 系统选型
无架构, 不系统, 架构选型是门户系统成功的关键.面对清晰的业务架构, 而现有OA系统和零散业务系统无法满足企业发展.在考察过单体式应用架构、分布式架构、SOA架构等架构后, 最后集中在OSGI框架平台和自主研发基于模块化的弹性扩展门户网站架构的选择上.
OSGi (open service gateway initiative) 技术是Java动态化模块化系统的一系列规范.基于该规范, 一些开源社区和厂商实现具体的OSGI开发平台, 如Java开发的Felix和Equinox, 以及.NET平台实现的OSGi.NET.这些基于OSGI规范的架构, 基本解决了软件复用、团队协作、软件可维护性、开放性等问题.但是基于这些架构开发出来的产品, 很难解决系统美观性和友好性问题, 以及用户个性化需求的问题.基于开源的OSGI架构平台思路, 考虑到系统之间的集成和现有开发团队, 最终选择自主研发基于模块化的弹性扩展门户网站架构.
1.3 系统建模
在本企业门户中, 业务参与者包括各部门、分支机构、分 (子) 公司的全体人员.系统管理员指整个门户系统的管理者.用例指各个业务场景, 不同的业务场景可能由不同团队或人员独立开发.图1是以财务人员、人力人员、财务总监为例, 说明各个模块之间的关系.
2 定制首页设计
门户首页是门户的精华所在, 是企事业单位的办公和精神集中地, 往往用户记住和使用最多的是门户首页.当用户看到首页, 就知道门户是做什么, 用户从这里得到哪些服务, 获得哪些信息, 下一步用户将到哪里去, 最终目的就是给用户带来极佳体验, 并吸引足够多的注意力.同样引导什么功能呢, 用户进入门户首页不可能只停留在首页, 他会根据自己的工作和目的来决定去点击链接.而如何引导用户用最快的时间找到自己想要做和去的地方, 则是对门户设计、用户体验和引导的综合考量.门户首页模块化设计的目的就是最大程度满足多样化用户需求, 最大程度给每位用户带来极佳体验.
网页的模块化和汽车生产是如出一辙, 首先把一个页面的每一个部分按照内容的独立性和关联性分成不同的模块, 这样一个页面就由背景和很多个模块组成, 然后再将每个模块按照业务类别、外观样式等因素分配给不同的组员进行开发, 并最终又将这些模块按用户所需拼合在一起, 形成一个完整的门户首页。
后台配置设计
从定制首页设计中可预知, 系统管理员需要在后台把页面主题、模板、模框、模块等信息配置完毕供门户首页呈现调用.下面先解释几者之间的关系, 再详细说明每一项的具体含义。
一个模板对应多个模框, 具体对应多少个模框是根据用户首页建模拆分出的模框研究性和创新性.模框与模块是一对一关系, 每个模块都需要一个模框装载才能在页面上渲染.模框只是为了达到模块在设计和开发上的分离和渲染上的融合, 以及模块复用的功能才在模板和模块之间抽象出的中间逻辑, 是模块在模板上的一个预占位.对一个集体来说, 统一主题制作不仅节省主题开发成本, 而且可以更好地适配页面.对用户来说, 能看到和关注的是模板上最终呈现的那些内容 (即那些模块) .在常规页面看似简单的开发, 但在模块化的门户首页中, 门户首页渲染是通过系统、页面、模框、模块层层入栈传递参数, 层层出栈构造页面结果.首页的渲染不只是模块的规则组合, 而且还需页面风格、用户语言等参数的搭配渲染.下面是几项核心配置的简要说明:
1) 主题配置:用于指定门户CSS样式、图片、语言包等调用的文件夹, 主要属性包括主题名称、主题语言、描述.
2) 模板配置:用于体现门户首页模框位置的固化和配置模块的定位.主要属性包括名称、模板文件名、URL地址、宽度、高度、模框总数、设计预览图、语言类别.
3) 模框配置:用于描述将来配置特定模块呈现在页面上的固定位置以及模框与页面的关系.主要属性包括模框名称、标记、宽度、高度、适配说明.图4是模板、模框的配置展示.
4) 模块配置:用于描述每个业务模块基本信息, 主要供系统管理员或用户选择查看.主要属性包括显示名称、类名、相对路径、宽度、高度、类型、是否异步加载、是否可调整、语言类别.
5) 模块与模板配置:用于配置首页呈现的内容形态, 主要是配置模板与门户导航和模块的关系.图5是模板与模块配置说明图.
6) 主题与模板配置:用于配置最终首页呈现样式, 一个模板可以配置多个主题, 一个主题可以配置多个模板.
后台配置及用户设置的最终目的是生成加载门户首页的配置信息。
根据以上“后台配置设计”介绍, 结合“定制化首页”设计思路, 推导出门户首页渲染过程如下:首先, 针对不同用户的个性化需求进行逐一建模, 并挖掘出不同首页模板.然后, 在后台根据首页建模的布局和用户岗位、角色、部门等信息进行首页模板、模框、模块的配置, 并最终生成不同的“门户首页配置信息”配置关系.最后, 不同的首页模板根据相应配置文件渲染出个性化的首页.
4 模块开发
4.1 总体开发思路
模块是构成门户的一部分, 一般具有独立完整的功能, 具有一致的前后端接口和加载方式, 相同形态的模块在门户中可以相互替换, 不同模块的按需组合就构成了最终个性化首页.为什么要这样设计呢?我们发现在一个项目里, 需求提出者往往参照某一两个系统而提出, 在这些系统页面中, 都会存在内容和外观相同或相似的部分, 如果我们按照模块化来设计与开发, 不同的业务已经变成了一个个的模块, 那么这些相同业务或相似界面的模块就可以分给同一个团队或个人来开发.假如不同模块之间互不影响, 或不同模块相互之间交互都有相应规范, 那么不同开发团队可以同步进行开发, 这样效率必将有很大的提高, 且代码的质量和系统稳定性也会得到相应保证.由于每个模块都是单独存在的, 所以当任何门户首页需要用到这个模块时, 都可以很便捷地直接将这个模块配置到首页使用, 而不必再次重新开发, 大大增强了模块复用性.
怎样设计开发出这种具有通用性、互换性、相对独立性的模块呢?在“后台配置设计”中已经了解模块呈现过程关系设计的基础上, 再简要介绍模块的交互设计思路.首先把模块类型分为:列表自适应型、焦点图型、导航条型、广告型.其次在列表自适应型中, 已经定义好模块自适应模框的样式和供前端调用的常用方法, 业务开发人员不在关注怎样适应模框、模块加载处理等共性问题, 只需关注列表数据来源及列表对应二级、三级业务页面, 而且在二级、三级等页面开发中, 业务开发人员也只需关注页面内容, 而页面导航、风格等共性问题不需要花费精力.同样, 焦点图型的模块基类已经定义好适配模框方法和图片切换方法, 导航条型基类已经处理好相同的页面在不同门户自动加载不同导航条的方法;只有广告型模块约束相对较少, 适合模块扩展和特殊处理场景.针对不同的业务版块, 不同团队可以按照微服务的方式同步开发首页模块和相应二级、三级页面, 也可以按照常规方式开发首页模块.
4.2 基本实现思路
在了解上面设计思路后, 下面以3个核心基类来说明主要实现思路. 门户首页基类BaseHomePage、门户首页模块基类BaseUserControl、其他二三级页面基类BasePage.门户首页基类除了当前主题、语言和用户信息外, 其中最重要的方法就是加载模块方法 (LoadControls) , 在页面基类方法中已经实现了从缓存及配置文件中自动加载模块的方法, 后期开发人员只需关注“定制首页设计”中的首页建模和特殊细节处理.门户首页模块基类主要目的是提供标准启动方法 (On Start) 供首页通过反射的方式调用, 并把用户及配置信息传递给具体模块初始化使用;在常规模块的开发中, 模块开发人员只需考虑采用前端或后台的方式获取后端数据并进行模块渲染, 不再关心常规权限、换肤、日志等通用功能.二三级页面基类虽然只提供了当前用户信息及配置信息供调用, 但在页面前端提供了导航、样式等动态生成内容和通用处理方法.
对于业务复杂、流量及并发大的模块, 团队成员可以考虑采用微服务的方式处理模块业务逻辑, 为了交互方便, 架构也提供了共享session和单点登录集成方式.在整个项目开发中, 为了提高开发效率、系统稳定性、分工明确性.为此, 在本架构设计过程中, 同步编写了“门户开发规范及过程管控”的规范化文档, 为开发实践打下了良好的基础.
4.3 开发实践
有了以上的设计和开发思路, 在进行实际开发过程中还需考虑基本规范、模块前端、模块后端及模块交互等系列问题.基本规范包括那些呢?首先, 在按照不同业务进行团队分工后, 需要防止不同开发团队的命名冲突, 否则可能导致模块加载失败;其次, 需要考虑不同模块的并发控制;最后, 还需考虑模块与系统间的集成.
在实际开发过程中, 针对该架构制定了前端、后端及数据库开发规范.在进行单个模块开发时, 需要根据规划确定模块的简写, 如系统模块简写是“SYS”.规定命名空间 (java叫包) 以模块简写单独结尾, 这样在加载模块的时候就不会造成冲突.同样, 在前端的css样式文件和javascript脚本文件中也把不同模块的文件放在以模块简写的文件夹下面;并且在脚本中涉及相同的函数名称添加模块前缀, 在样式文件中涉及到样式文件采用模块简称的类限定, 防止样式文件冲突.在数据库层面, 除了基本数据库规范外, 主要是在表名的前缀添加模块简写的方式区分和防止不必要的冲突;当然, 根据模块流量和并非情况, 不同模块数据可以放在同一数据库, 也可以把单个模块存放在一个或多个独立数据库中.
在模块前端开发过程中, 除了遵守基本前端规范之外, 本设计提炼出常用的前端模块样式和通用javascript函数, 如多种列表样式、图片切换样式及相应的自适应样式等, 当模块开发人员发现自己开发的模块存在对应模块样式时, 只需按照前端文档进行调用, 减少前端调试时间.样式文件、脚本及图片等静态文件按照规范统一放在主题包文件夹下面, 整个主题包可以单独部署在单独二级域名下的服务器上, 也可以部署在网站的子目录下.当配置文件配置为相对路径时, 则模块前端和后端调用相对路径下的静态文件;同理, 配置为二级域名时, 前后端则自动调用独立服务器下的静态资源.
在模块后端开发过程中, 我们推荐采用模块后台代码轻量化方式, 结合微服务处理后端业务逻辑方式.当然没有后台业务代码逻辑, 或把简单业务逻辑直接写在后台也是可以正确进行模块渲染.主要是根据模块业务复杂性和模块并发大小来综合考虑是否在后端采用微服务方式处理业务逻辑, 是否提供统一的API供模块后台调用, 以及后端数据库是否分库和集群等方式.在模块与各系统交互过程中, 如果是自主开发的系统, 推荐采用Session共享集成方式, 否则推荐采用单点登录集成方式.