這次做
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
),后一篇文章再細細道來。