这次做portal的一些总结(一)

来源:百度文库 编辑:神马文学网 时间:2024/04/27 14:36:13
这次做 ibm 的 portal ,算是临危受命。做了几个月的 SA 离职,留下一个功能和性能都有很多问题的项目,临时让我顶上。经过一个多月的紧张工作(经常加班,上班上不了网,也没时间上网),总算功能和性能上都能达到客户要求了。而我也由一个不懂 portal 的人,经过项目中实战,不说成为高手,一般的概念、开发、配置、优化等也都有了很多体会。
这次技术上值得推荐的就是合理的使用 ajax ,既加快了首页的 load 速度,又带来了很好的用户体验。开始首页上所有 portlet 都是串行加载,有的 portlet 比如新邮件,依赖于 mail 系统提供的接口。开始这个接口在较大压力下就出现性能瓶颈,后在我们的要求下替换了协议,性能也在 1s-2s 之间。如果采用常规的办法,加上 wps 验证、运算,显示主题、皮肤,加载所有 portlet ,响应时间肯定在 10s 以上。
我在 openfans 中使用了 ajax ,有些经验,所以决定采用异步加载:首页 load 时一些 portlet 直接显示正在 loading 的字样,在 body onload 时再使用 ajax 填充内容;使用 iframe 的 portlet ,也是 src 先指向一个静态的正在 loading 页面, body onload 时再替换 src 到实际地址(这是 ajax 模式的一种)。这样首页登录实际上只经过 wps 内部的验证和显示,所有业务逻辑都是加载成功后再并行进行。实际表现效果就是:头上的主题很快出来,一块块区域显示正在 loading 字样,性能快的 portlet 很快出来,需要几秒的 portlet 随后出来,而不是让用户傻等 10 多 s 再一下全部显示。
使用 ajax 同时也能解决页面刷新问题和获取返回值的问题。比如前面显示新邮件的 portlet ,用户点击了一封邮件,新邮件数应该减 1 ,刚点击的邮件也应该上页面上消失。原始的做法就是刷新整个页面,既加大服务器压力,又带来很差的用户体验。使用 ajax ,在点击后 1s (或者更长,这取决于邮件系统对点击操作的响应快慢)刷新 div 的内容,用户甚至感觉不到内容已经更新。其它 portlet 也不需要重新载入,大大减轻服务器的压力。有的操作需要提交给其它系统,而且可能成功可能失败,这就需要获得返回值。如果使用普通的 form 提交,需要更新整个页面。而使用 ajax 提交,可以方便的获得其返回值,进而显示不同的提示。
另一个架构上的特点就是 portal 服务器职责单一 。开始所有的业务逻辑都是写在 portlet 里,加重了 portlet 服务器的压力。我进来后做的一个大的规划就是,把业务逻辑抽离到其它 server 上,然后通过 ajax 加载到 portlet 中。这样既可以充分利用服务器资源(新的 server 使用单独的内存空间和线程池),又使得 portal 服务器职责更单一:仅进行验证、权限控制、主题、皮肤和 portlet 的展示。
先写这么多。因为使用了 2 台 server 做集群,在分布式环境下,开发也有了更多的要求(比如 cache ),后一篇文章再细细道来。