這次做
ibm
的
portal
，算是臨危受命。做了幾個月的
SA
離職，留下一個功能和性能都有很多問題的項目，臨時讓我頂上。經(jīng)過一個多月的緊張工作（經(jīng)常加班，上班上不了網(wǎng)，也沒時間上網(wǎng)），總算功能和性能上都能達到客戶要求了。而我也由一個不懂
portal
的人，經(jīng)過項目中實戰(zhàn)，不說成為高手，一般的概念、開發(fā)、配置、優(yōu)化等也都有了很多體會。
這次技術(shù)上值得推薦的就是合理的使用
ajax
，既加快了首頁的
load
速度，又帶來了很好的用戶體驗。開始首頁上所有
portlet
都是串行加載，有的
portlet
比如新郵件，依賴于
mail
系統(tǒng)提供的接口。開始這個接口在較大壓力下就出現(xiàn)性能瓶頸，后在我們的要求下替換了協(xié)議，性能也在
1s-2s
之間。如果采用常規(guī)的辦法，加上
wps
驗證、運算，顯示主題、皮膚，加載所有
portlet
，響應時間肯定在
10s
以上。
我在
openfans
中使用了
ajax
，有些經(jīng)驗，所以決定采用異步加載：首頁
load
時一些
portlet
直接顯示正在
loading
的字樣，在
body onload
時再使用
ajax
填充內(nèi)容；使用
iframe
的
portlet
，也是
src
先指向一個靜態(tài)的正在
loading
頁面，
body onload
時再替換
src
到實際地址（這是
ajax
模式的一種）。這樣首頁登錄實際上只經(jīng)過
wps
內(nèi)部的驗證和顯示，所有業(yè)務(wù)邏輯都是加載成功后再并行進行。實際表現(xiàn)效果就是：頭上的主題很快出來，一塊塊區(qū)域顯示正在
loading
字樣，性能快的
portlet
很快出來，需要幾秒的
portlet
隨后出來，而不是讓用戶傻等
10
多
s
再一下全部顯示。
使用
ajax
同時也能解決頁面刷新問題和獲取返回值的問題。比如前面顯示新郵件的
portlet
，用戶點擊了一封郵件，新郵件數(shù)應該減
1
，剛點擊的郵件也應該上頁面上消失。原始的做法就是刷新整個頁面，既加大服務(wù)器壓力，又帶來很差的用戶體驗。使用
ajax
，在點擊后
1s
（或者更長，這取決于郵件系統(tǒng)對點擊操作的響應快慢）刷新
div
的內(nèi)容，用戶甚至感覺不到內(nèi)容已經(jīng)更新。其它
portlet
也不需要重新載入，大大減輕服務(wù)器的壓力。有的操作需要提交給其它系統(tǒng)，而且可能成功可能失敗，這就需要獲得返回值。如果使用普通的
form
提交，需要更新整個頁面。而使用
ajax
提交，可以方便的獲得其返回值，進而顯示不同的提示。
另一個架構(gòu)上的特點就是
portal
服務(wù)器職責單一
。開始所有的業(yè)務(wù)邏輯都是寫在
portlet
里，加重了
portlet
服務(wù)器的壓力。我進來后做的一個大的規(guī)劃就是，把業(yè)務(wù)邏輯抽離到其它
server
上，然后通過
ajax
加載到
portlet
中。這樣既可以充分利用服務(wù)器資源（新的
server
使用單獨的內(nèi)存空間和線程池），又使得
portal
服務(wù)器職責更單一：僅進行驗證、權(quán)限控制、主題、皮膚和
portlet
的展示。
先寫這么多。因為使用了
2
臺
server
做集群，在分布式環(huán)境下，開發(fā)也有了更多的要求（比如
cache
），后一篇文章再細細道來。