这次做portal的一些总结（一）

这次做 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 ），后一篇文章再细细道来。