論劍歸來（一）

應(yīng)朋友邀請，周六早從上海出發(fā)往杭州參加阿里巴巴網(wǎng)俠大會。同行四人，有銳道的macro chen、楊光（還是我?guī)煹埽⒁苿拥耐鮽バ瘢ㄌ亻L是linux和網(wǎng)絡(luò)安全，也是中國linux推廣的先驅(qū)）。一路上，言談甚歡。老莊給我們訂的票，他一早腸胃有恙，仍然堅持把票送到火車站，之后去吊鹽水，下午又出現(xiàn)在會場。確實精神可嘉，建議阿里巴巴頒發(fā)“最佳精神獎”。

到杭州已是中午，錯過了上午大會。下午Robbin進行Java技術(shù)展望和RoR實現(xiàn)REST的演講，既然是朋友，肯定是要捧場的。Robbin旁征博引，以其深厚的技術(shù)功底和對新技術(shù)的敏銳洞察贏得了聽眾。

晚上一堆人去聚會，各路豪杰紛至：有阿里巴巴的，有自己創(chuàng)業(yè)的，有技術(shù)大牛，還有媒體（Infoq），出版社（博文的周總領(lǐng)3員大將赴會）。大家互換名片，認識的不免寒暄幾句，不認識的也很快就熟捻了，還不時有“原來你就是×××”的驚呼，原來網(wǎng)上就“互通心曲”，只是一直沒機會認識罷了。

席間觥籌交錯，具體內(nèi)容暫且不表，只說一件令我感受頗深之事。一個阿里巴巴的員工表現(xiàn)出對公司的無比忠誠，講起公司的獎懲制度，說是一個員工的績效不僅跟所在項目相關(guān)，還與部門、其它部門甚至整個公司的業(yè)績相關(guān)。所以只要是對公司有利的事情，即使與自己現(xiàn)在的工作無關(guān)，他們也會去做。按常理來說，這有點不公平，我只能努力做好自己的事情，而如果別人不努力，我就是白做。但如果大家都努力，又變成了共贏。

這里讓我講一個簡單的博弈問題，就是“囚徒困境”。A和B兩個同犯被抓，因為沒有其它任何證據(jù)和證人，只能讓2人分別交供。如果A和B都矢口否認，那么兩人無罪釋放。如果A承認，B不承認；A是坦白從寬，判1年；B抗拒從嚴，判5年，反之亦然。如果2人都承認，ok證據(jù)確鑿，各判2年。如果2人都是理性人，且沒有互通消息，按照博弈，每個人的最優(yōu)解就是承認，也就是各判2年。其實對2人真正有利的就是打死不承認然后都無罪釋放，而這種狀態(tài)在理性人的假設(shè)下是很難實現(xiàn)的--除非有一個教父，一直灌輸他們不要出賣同伙。

馬云就是這個“教父”！

卡內(nèi)基有篇文章，我總結(jié)成一句話就是：用崇高的理想打動別人。據(jù)說馬云一直是以個人魅力及“創(chuàng)造中國電子商務(wù)的明天”類似的理想，激勵員工的。有了統(tǒng)一的企業(yè)文化，員工都不計較個人得失，努力奮進，最終企業(yè)和所有員工取得共贏，這絕對是擺脫“囚徒困境”的典型案例。

話說回來，阿里巴巴能讓你感受到團隊的力量，一群精英在一塊做很有價值的事情，對每個人也是很好的鍛煉。個人認為，如果有吃苦耐勞的打算，眼光放長遠點，又沒有其它方面的束縛，阿里巴巴的確是不錯的選擇。（得向阿里巴巴收代言費，呵呵！）

第二天聽了多場論道，主要是SAAS，搜索，分詞方面。結(jié)合阿里巴巴的戰(zhàn)略，我把幾點融合起來講一下。這個下篇再細細道來。

 

 

posted @ 2007-05-21 20:35 pesome 閱讀(1138) | 評論 (1) | 編輯 收藏

sitemesh的問題及解決

再說 sitemesh 的問題，同樣是做 openfans 網(wǎng)摘功能出現(xiàn)的。做好了 IE 插件，有 fans 反饋說彈出頁面太大，這也難怪，用了 sitemesh ， head 和 footer 都在頁面上，想縮小頁面，肯定得把 head 和 footer 都去掉，做個干凈點的。既然用了 sitemesh 肯定是希望最方便的搞定這個，而不用動任何邏輯（包括頁面邏輯）。這個好辦，文檔里有說，通過在 sitemesh.xml 中增加

就能搞定，這樣只需要使用參數(shù)如 saveSnippet.html?decorator=simple&confirm=true ，就能讓它使用指定的 decorator 。然后做一個去掉 head 和 footer 只保留必要的 js 和 css 引用的 simple.jsp 頁面，同時在 decorator.xml 中配

就應(yīng)該可以搞定。

但怎么測，就是不使用這個 simple decorator 。沒辦法，只好跟進 sitemesh 源碼中去調(diào)試，進入 ParameterDecoratorMapper 類，它繼承了 AbstractDecoratorMapper 類，然后有一個 init 方法一個 getDecorator 方法。各打一個斷點， init 方法在 tomcat 啟動就會執(zhí)行，也正常初始化了， getDecorator 方法卻始終不調(diào)用，一時想不出辦法。看到篇文章說不自己寫 sitemesh.xml 而使用自帶的 com/opensymphony/module/sitemesh/factory/sitemesh-default.xml 也可以，于是備份并刪除我寫的 sitemesh.xml ，居然成功了。為什么我寫的就不行呢？差別一是我的簡化了很多，只有

< mapper

???? class ="com.opensymphony.module.sitemesh.mapper.ConfigDecoratorMapper" >

??????????? < param? name ="config" ?value ="${decorators-file}" ? />

??????? </ mapper >

和剛加的

ParameterDecoratorMapper ，二就是順序，我的 ParameterDecoratorMapper 放在了 ConfigDecoratorMapper 后面，會不會是順序原因呢，調(diào)換一下，果然成功了。問題是解決了，原理呢？再花點時間跟一下代碼了解下原理，原來使用了 Factory ，它會調(diào)用各個配置的 Mapper 的 init 方法，并放入 map 中，然后到時選擇一個 Mapper ，如果符合條件就使用，否則繼續(xù)往下找。這里就有了順序的問題，因為我在 decorator.xml 中使用了

<decorator?name="default"?page="default.jsp">

????????<pattern>/*.html</pattern>

????</decorator>

，這樣如果 ConfigDecoratorMapper 放在前面，他就先找這個 Mapper ，一看 saveSnippet.html?decorator=simple&confirm=true ，符合 pattern 啊，就使用它了，另一個 ParameterDecoratorMapper 根本得不到機會，所以也進不了它的 getDecorator 方法。換了順序就是它先進去，所以執(zhí)行，其它的 url 也是先找它，但不匹配，就又交給 ConfigDecoratorMapper 了。呵呵，問題也解決了，對 sitemesh 的認識又進了一步。

posted @ 2007-03-11 22:54 pesome 閱讀(2999) | 評論 (0) | 編輯 收藏

中文問題的解決

這次給 openfans 做網(wǎng)摘功能，主體程序倒是很快就寫完了，另外要做個 IE 插件，卻碰到了不少問題。 IE 插件其實很簡單，就是用 js 獲得頁面的標題、 url 和選擇的內(nèi)容，然后通過彈出窗口，將其送到服務(wù)器。這里就有中文的問題了，開始使用 escape ，如 escape(title) 形式， request.getParameter 碰到中文就為 null ，網(wǎng)上搜了一通，說是可以通過 java 編碼搞定，但拿到就為 null 了，還怎么換編碼？忙活了好幾個小時，又是 alert ，又是 document.write ，看上去也沒什么問題。不 escape ，直接在瀏覽器中輸入帶中文的 url ，拿到的不為 null 了，拿到后，通過 new String(str.getBytes("ISO-8859-1"), "UTF-8"); 還真顯示正常了。但用 window.open 又出亂碼了。看到文章說還有 encodeURIComponent 方法可用，就試了下，把 escape 換成 encodeURIComponent 居然搞定了，服務(wù)端還是得用 new String(str.getBytes("ISO-8859-1"), "UTF-8") 進行處理。注意這里用的 tomcat ，它的默認編碼就是 "ISO-8859-1" ，如果改了編碼程序也得做相應(yīng)的改動了。

posted @ 2007-03-11 22:51 pesome 閱讀(1047) | 評論 (0) | 編輯 收藏

hibernate native sql的小技巧

為了性能考慮，使用了 native sql 。因為需要分頁，需要 2 個 sql ，一個獲取 list 一個取得總數(shù)。獲取 list 很好寫：

?

?

獲取總數(shù)查了下 hibernate 的 reference, 試了幾次才明白用法 :

?1 private ?BigInteger?getCountByNativeSQL( final ?String?sql)? {
?2
?3 ??????? return ?(BigInteger)?getHibernateTemplate().execute(
?4
?5 ?????????????? new ?HibernateCallback()? {
?6
?7 ?????????????????? public ?Object?doInHibernate(Session?session)
?8
?9 ????????????????????????? throws ?HibernateException? {
10
11 ????????????????????? return ?(BigInteger)?(session.createSQLQuery(sql).uniqueResult());
12
13 ??????????????????}
14
15 ??????????????} );
16
17 ????}
18

這里的

sql 是“ select count(*) 開頭的”。這里大家可能要問，為什么要使用 BigInteger ，因為如果用 uniqueResult() 默認就返回 BigInteger ，而 BigInteger cast 成 Integer 會出錯。那么如果我就是要返回 Integer 呢，可以通過下面的辦法實現(xiàn)：

?1 private ?Integer?getCountByNativeSQL( final ?String?sql)? {
?2
?3 ??????? return ?(Integer)?getHibernateTemplate().execute(
?4
?5 ?????????????? new ?HibernateCallback()? {
?6
?7 ?????????????????? public ?Object?doInHibernate(Session?session)
?8
?9 ????????????????????????? throws ?HibernateException? {
10
11 ????????????????????? return ?(Integer)?(session.createSQLQuery(sql).addScalar( " count " ,?Hibernate.INTEGER).uniqueResult());
12
13 ??????????????????}
14
15 ??????????????} );
16
17 ????}
18

大家注意粗體的部分，這里是給一個

alias 賦予類型，那么 sql 就需要變成以 ”select count(*) as count ” 開頭了。

posted @ 2007-03-02 10:52 pesome 閱讀(5261) | 評論 (2) | 編輯 收藏

php5+mysql5+apache2需要注意的幾點

今天為了在本機裝個wordpress玩玩，搞了搞php5+mysql5+apache2。網(wǎng)上搜了一篇文檔，很快就讓php與apache跑起來了，但連mysql始終不行。報錯：Call to undefined function mysql_connect()。查了一下半天，就是php關(guān)于mysql的ext沒配好，但我改了php.ini啊，也把"extension=php_mysql.dll"放出來了。查了好久，看到一篇說php5需要加上"extension=php_mysqli.dll"，試了下果然好了。
???? 然后需要以index.php作為默認的welcomefile(不知道怎么叫，web.xml里是這個)，需要在"DirectoryIndex index.html index.html.var"后加上 index.php就行。
然后飛快的裝了phpmyadmin、dvbbs的php版。發(fā)現(xiàn)php應(yīng)用的安裝的確很是方便，解壓，拷貝到htdocs下，馬上就能運行了，比java應(yīng)用簡單的多，更別提復(fù)雜的要死的企業(yè)應(yīng)用了。這點上java要好好向php學(xué)習(xí)啊。

posted @ 2007-01-14 17:34 pesome 閱讀(1300) | 評論 (0) | 編輯 收藏

開始研究電子支付

項目需要，開始研究電子支付。國外的電子支付提供商，得好好研究它的文檔和api。全是e文，只能慢慢看了。

posted @ 2007-01-12 15:41 pesome 閱讀(1299) | 評論 (1) | 編輯 收藏

準備給openfans添加spring2.0支持

? 學(xué)習(xí)了下spring2.0。對openfans而言，有2個比較重要的改進。首先是aspectj的支持，可以方便的使用aspectj語法定義aspect和pointcut了，openfans準備在domain object的自動注入上和權(quán)限等方面使用aop。另外就是spring form標簽庫的引入，現(xiàn)在springmvc也有自己的標簽庫，以前自己給checkbox和radio寫的request.getParameter可以改寫了。

posted @ 2006-12-28 15:15 pesome 閱讀(1138) | 評論 (1) | 編輯 收藏

一個定時更新cache框架

     摘要: 應(yīng)項目需要做了一個定時更新的 cache 框架，采用 spring+quartz 很方便的實現(xiàn)，可以適用任何需要定時才更新的地方，比如靜態(tài)網(wǎng)頁 cache 等。代碼很簡單： ---------------------------------QuartzCacheHandler-------------------...  閱讀全文

posted @ 2006-12-13 14:46 pesome 閱讀(4141) | 評論 (7) | 編輯 收藏

這次做portal的一些總結(jié)（二）

接著前面的寫。上文主要寫了 ajax 在 portal 中的使用，這篇寫集群方面的體會。現(xiàn)在比較流行的架構(gòu)就是前端 F5 做負載均衡，后面 2 臺 websphere server 做成集群，各自都有 HttpServer ，每個 HttpServer 都向 2 臺 was 做轉(zhuǎn)發(fā)。這樣每臺都能獨立完成從 HttpServer 到 was 的流程。一臺出現(xiàn)故障， F5 首先進行切換，只向正常 server 的 HttpServer 發(fā)起請求，這臺 HttpServer 再進行切換只向同一臺 server 上的 was 做轉(zhuǎn)發(fā)。這次 portal 就是采用的這種架構(gòu)，不妨稱為架構(gòu) A 。

另一種簡單點的架構(gòu)就是只做 F5 負載均衡，不做 was 集群，每臺 websphere server 上的 HttpServer 接受 F5 轉(zhuǎn)發(fā)的請求，只向本 server 的 was 轉(zhuǎn)發(fā)。這樣每臺 websphere server 保持獨立，相互間沒有數(shù)據(jù)交換和轉(zhuǎn)發(fā)。不妨稱為架構(gòu) B 。

架構(gòu) A 和 B 各有優(yōu)劣，適合不同的需要，下面進行些比較：

????????? 從應(yīng)用部署上看：

A 使用了 websphere 集群，由一個 DeployManager 進行分發(fā)，部署應(yīng)用，只需部署一次，由 DM 分發(fā)到幾個節(jié)點上。而 B 每個 server 都是獨立的，部署應(yīng)用只能一臺臺部署，如果 server 較少差別還不明顯，如果達到 10 臺以上，一臺臺部署將是一個比較痛苦的事情。

????????? 從 session 上看：

A 使用了 websphere 集群，可以使用集群提供的 session 復(fù)制，對于一些關(guān)鍵應(yīng)用（某臺服務(wù)器宕機， session 也必須保持的應(yīng)用）很有必要。而對于一些能夠允許 session 丟失的應(yīng)用，才可以使用 B 。當然 A 也可以關(guān)閉 session 復(fù)制，因為 session 復(fù)制不管是使用數(shù)據(jù)庫方式還是內(nèi)存方式，總會消耗一定的性能。具體消耗多少性能，就要看不同的 application server 的 session 復(fù)制方案了，想深入了解，可以看集群方面的文檔，我也只記得一個比較簡單的 round robbin 了。

????????? 從架構(gòu)復(fù)雜性看：

B 更為簡單，因為沒有 DM 的概念，每臺 server 都保持獨立。而使用了 DM 有時也會出現(xiàn)莫名奇妙的問題，這當然是由于不了解 DM 的機制所致，但總歸也增加了復(fù)雜度，這點在后面的教訓(xùn)中進行說明。

????????? 從水平擴展性上看：

B 肯定更勝一籌。只要 F5 能支持，多少臺 server 都沒關(guān)系。而 A 多臺 server 做集群，要看 websphere 支持的節(jié)點數(shù)量，應(yīng)該不會太大。這個如果哪位同學(xué)知道，敬請告知。

當然 A 和 B 在服務(wù)器較多的情況下是可以共存的，可以考慮幾臺機器做集群，然后集群間做負載均衡，這樣既可以減少部署的復(fù)雜度，又可以帶來較好的水平擴展。由于沒做過更大型的項目，這個也只是我的假象，請做過的同學(xué)斧正。

?

說一說集群中碰到的問題。

????????? 首先是對各節(jié)點的同步：

有時為了方便測試，我們只對其中一個節(jié)點進行更改，測試通過再放到其它節(jié)點。而如果測試周期較長，有時就會造成節(jié)點的不同步，出現(xiàn)各種各樣莫名其妙的問題。一個經(jīng)驗就是：無論如何，在每天下班前要保證各節(jié)點的同步，不同步的現(xiàn)象不要過夜。

????????? 然后是對 DM 的理解：

我現(xiàn)在還只是實踐階段，沒有看過相關(guān)文檔。從意義上看，它控制了相關(guān)的配置文件，如果進行節(jié)點同步，就會由它把配置文件同步到它管理的節(jié)點上。這對配置文件的修改提出了要求。我們開始只修改節(jié)點的配置文件而沒有修改 DM 的，結(jié)果進行節(jié)點同步就會覆蓋修改的配置文件，帶來很多不必要的工作。經(jīng)驗就是：或者修改 DM 的配置文件，然后進行節(jié)點同步，或者直接同時修改所有節(jié)點和 DM 的。

????????? 還有關(guān)于 cache 的：

Cache 是性能優(yōu)化的一個有效手段。在單機環(huán)境下，最簡單的就是內(nèi)存 cache ，使用 static 的 Map 就行。而在集群環(huán)境中， cache 就變的比較復(fù)雜了。首先還是從應(yīng)用需求入手，是否要保持每臺機器的 cache 同步。如果只是信息展示等要求不高的 cache ，不需保證 cache 的同步，問題也比較簡單，自己寫內(nèi)存 cache ，或者使用開源的 cache 組件如 ehcache,oscache 等就可以很好的解決問題。而如果需要 cache 在幾個節(jié)點保持同步，就需要特殊的機制了， ehcache 等號稱支持分布式 cache ，但好像需要 jgroup ，配置比較麻煩，我沒有用過，有用過的同學(xué)請指教。我本來想使用 session 保存，然后進行 session 同步，后來 IBM 建議使用數(shù)據(jù)庫 cache ，即自己寫代碼， cache 在數(shù)據(jù)庫中。這樣不需要 session 同步，對象不大，性能也能得到保證，現(xiàn)在用下來效果還可以。

?

posted @ 2006-12-13 13:39 pesome 閱讀(3812) | 評論 (9) | 編輯 收藏

這次做portal的一些總結(jié)（一）

這次做 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 ，響應(yīng)時間肯定在 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ù)應(yīng)該減 1 ，剛點擊的郵件也應(yīng)該上頁面上消失。原始的做法就是刷新整個頁面，既加大服務(wù)器壓力，又帶來很差的用戶體驗。使用 ajax ，在點擊后 1s （或者更長，這取決于郵件系統(tǒng)對點擊操作的響應(yī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 ），后一篇文章再細細道來。

posted @ 2006-11-28 14:49 pesome 閱讀(3666) | 評論 (9) | 編輯 收藏