2006年12月13日
應(yīng)朋友邀請(qǐng),周六早從上海出發(fā)往杭州參加阿里巴巴網(wǎng)俠大會(huì)。同行四人,有銳道的macro chen、楊光(還是我?guī)煹埽⒁苿?dòng)的王偉旭(特長是linux和網(wǎng)絡(luò)安全,也是中國linux推廣的先驅(qū))。一路上,言談甚歡。老莊給我們訂的票,他一早腸胃有恙,仍然堅(jiān)持把票送到火車站,之后去吊鹽水,下午又出現(xiàn)在會(huì)場(chǎng)。確實(shí)精神可嘉,建議阿里巴巴頒發(fā)“最佳精神獎(jiǎng)”。
到杭州已是中午,錯(cuò)過了上午大會(huì)。下午Robbin進(jìn)行Java技術(shù)展望和RoR實(shí)現(xiàn)REST的演講,既然是朋友,肯定是要捧場(chǎng)的。Robbin旁征博引,以其深厚的技術(shù)功底和對(duì)新技術(shù)的敏銳洞察贏得了聽眾。
晚上一堆人去聚會(huì),各路豪杰紛至:有阿里巴巴的,有自己創(chuàng)業(yè)的,有技術(shù)大牛,還有媒體(Infoq),出版社(博文的周總領(lǐng)3員大將赴會(huì))。大家互換名片,認(rèn)識(shí)的不免寒暄幾句,不認(rèn)識(shí)的也很快就熟捻了,還不時(shí)有“原來你就是×××”的驚呼,原來網(wǎng)上就“互通心曲”,只是一直沒機(jī)會(huì)認(rèn)識(shí)罷了。
席間觥籌交錯(cuò),具體內(nèi)容暫且不表,只說一件令我感受頗深之事。一個(gè)阿里巴巴的員工表現(xiàn)出對(duì)公司的無比忠誠,講起公司的獎(jiǎng)懲制度,說是一個(gè)員工的績效不僅跟所在項(xiàng)目相關(guān),還與部門、其它部門甚至整個(gè)公司的業(yè)績相關(guān)。所以只要是對(duì)公司有利的事情,即使與自己現(xiàn)在的工作無關(guān),他們也會(huì)去做。按常理來說,這有點(diǎn)不公平,我只能努力做好自己的事情,而如果別人不努力,我就是白做。但如果大家都努力,又變成了共贏。
這里讓我講一個(gè)簡單的博弈問題,就是“囚徒困境”。A和B兩個(gè)同犯被抓,因?yàn)闆]有其它任何證據(jù)和證人,只能讓2人分別交供。如果A和B都矢口否認(rèn),那么兩人無罪釋放。如果A承認(rèn),B不承認(rèn);A是坦白從寬,判1年;B抗拒從嚴(yán),判5年,反之亦然。如果2人都承認(rèn),ok證據(jù)確鑿,各判2年。如果2人都是理性人,且沒有互通消息,按照博弈,每個(gè)人的最優(yōu)解就是承認(rèn),也就是各判2年。其實(shí)對(duì)2人真正有利的就是打死不承認(rèn)然后都無罪釋放,而這種狀態(tài)在理性人的假設(shè)下是很難實(shí)現(xiàn)的--除非有一個(gè)教父,一直灌輸他們不要出賣同伙。
馬云就是這個(gè)“教父”!
卡內(nèi)基有篇文章,我總結(jié)成一句話就是:用崇高的理想打動(dòng)別人。據(jù)說馬云一直是以個(gè)人魅力及“創(chuàng)造中國電子商務(wù)的明天”類似的理想,激勵(lì)員工的。有了統(tǒng)一的企業(yè)文化,員工都不計(jì)較個(gè)人得失,努力奮進(jìn),最終企業(yè)和所有員工取得共贏,這絕對(duì)是擺脫“囚徒困境”的典型案例。
話說回來,阿里巴巴能讓你感受到團(tuán)隊(duì)的力量,一群精英在一塊做很有價(jià)值的事情,對(duì)每個(gè)人也是很好的鍛煉。個(gè)人認(rèn)為,如果有吃苦耐勞的打算,眼光放長遠(yuǎn)點(diǎn),又沒有其它方面的束縛,阿里巴巴的確是不錯(cuò)的選擇。(得向阿里巴巴收代言費(fèi),呵呵!)
第二天聽了多場(chǎng)論道,主要是SAAS,搜索,分詞方面。結(jié)合阿里巴巴的戰(zhàn)略,我把幾點(diǎn)融合起來講一下。這個(gè)下篇再細(xì)細(xì)道來。
這次給
openfans
做網(wǎng)摘功能,主體程序倒是很快就寫完了,另外要做個(gè)
IE
插件,卻碰到了不少問題。
IE
插件其實(shí)很簡單,就是用
js
獲得頁面的標(biāo)題、
url
和選擇的內(nèi)容,然后通過彈出窗口,將其送到服務(wù)器。這里就有中文的問題了,開始使用
escape
,如
escape(title)
形式,
request.getParameter
碰到中文就為
null
,網(wǎng)上搜了一通,說是可以通過
java
編碼搞定,但拿到就為
null
了,還怎么換編碼?忙活了好幾個(gè)小時(shí),又是
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")
進(jìn)行處理。注意這里用的
tomcat
,它的默認(rèn)編碼就是
"ISO-8859-1"
,如果改了編碼程序也得做相應(yīng)的改動(dòng)了。
今天為了在本機(jī)裝個(gè)wordpress玩玩,搞了搞php5+mysql5+apache2。網(wǎng)上搜了一篇文檔,很快就讓php與apache跑起來了,但連mysql始終不行。報(bào)錯(cuò):Call to undefined function mysql_connect()。查了一下半天,就是php關(guān)于mysql的ext沒配好,但我改了php.ini啊,也把"extension=php_mysql.dll"放出來了。查了好久,看到一篇說php5需要加上"extension=php_mysqli.dll",試了下果然好了。
???? 然后需要以index.php作為默認(rèn)的welcomefile(不知道怎么叫,web.xml里是這個(gè)),需要在"DirectoryIndex index.html index.html.var"后加上 index.php就行。
然后飛快的裝了phpmyadmin、dvbbs的php版。發(fā)現(xiàn)php應(yīng)用的安裝的確很是方便,解壓,拷貝到htdocs下,馬上就能運(yùn)行了,比java應(yīng)用簡單的多,更別提復(fù)雜的要死的企業(yè)應(yīng)用了。這點(diǎn)上java要好好向php學(xué)習(xí)啊。
項(xiàng)目需要,開始研究電子支付。國外的電子支付提供商,得好好研究它的文檔和api。全是e文,只能慢慢看了。
? 學(xué)習(xí)了下spring2.0。對(duì)openfans而言,有2個(gè)比較重要的改進(jìn)。首先是aspectj的支持,可以方便的使用aspectj語法定義aspect和pointcut了,openfans準(zhǔn)備在domain object的自動(dòng)注入上和權(quán)限等方面使用aop。另外就是spring form標(biāo)簽庫的引入,現(xiàn)在springmvc也有自己的標(biāo)簽庫,以前自己給checkbox和radio寫的request.getParameter可以改寫了。
摘要: 應(yīng)項(xiàng)目需要做了一個(gè)定時(shí)更新的
cache
框架,采用
spring+quartz
很方便的實(shí)現(xiàn),可以適用任何需要定時(shí)才更新的地方,比如靜態(tài)網(wǎng)頁
cache
等。代碼很簡單:
---------------------------------QuartzCacheHandler-------------------...
閱讀全文
接著前面的寫。上文主要寫了
ajax
在
portal
中的使用,這篇寫集群方面的體會(huì)。現(xiàn)在比較流行的架構(gòu)就是前端
F5
做負(fù)載均衡,后面
2
臺(tái)
websphere server
做成集群,各自都有
HttpServer
,每個(gè)
HttpServer
都向
2
臺(tái)
was
做轉(zhuǎn)發(fā)。這樣每臺(tái)都能獨(dú)立完成從
HttpServer
到
was
的流程。一臺(tái)出現(xiàn)故障,
F5
首先進(jìn)行切換,只向正常
server
的
HttpServer
發(fā)起請(qǐng)求,這臺(tái)
HttpServer
再進(jìn)行切換只向同一臺(tái)
server
上的
was
做轉(zhuǎn)發(fā)。這次
portal
就是采用的這種架構(gòu),不妨稱為架構(gòu)
A
。
另一種簡單點(diǎn)的架構(gòu)就是只做
F5
負(fù)載均衡,不做
was
集群,每臺(tái)
websphere server
上的
HttpServer
接受
F5
轉(zhuǎn)發(fā)的請(qǐng)求,只向本
server
的
was
轉(zhuǎn)發(fā)。這樣每臺(tái)
websphere server
保持獨(dú)立,相互間沒有數(shù)據(jù)交換和轉(zhuǎn)發(fā)。不妨稱為架構(gòu)
B
。
架構(gòu)
A
和
B
各有優(yōu)劣,適合不同的需要,下面進(jìn)行些比較:
?????????
從應(yīng)用部署上看:
A
使用了
websphere
集群,由一個(gè)
DeployManager
進(jìn)行分發(fā),部署應(yīng)用,只需部署一次,由
DM
分發(fā)到幾個(gè)節(jié)點(diǎn)上。而
B
每個(gè)
server
都是獨(dú)立的,部署應(yīng)用只能一臺(tái)臺(tái)部署,如果
server
較少差別還不明顯,如果達(dá)到
10
臺(tái)以上,一臺(tái)臺(tái)部署將是一個(gè)比較痛苦的事情。
?????????
從
session
上看:
A
使用了
websphere
集群,可以使用集群提供的
session
復(fù)制,對(duì)于一些關(guān)鍵應(yīng)用(某臺(tái)服務(wù)器宕機(jī),
session
也必須保持的應(yīng)用)很有必要。而對(duì)于一些能夠允許
session
丟失的應(yīng)用,才可以使用
B
。當(dāng)然
A
也可以關(guān)閉
session
復(fù)制,因?yàn)?/span>
session
復(fù)制不管是使用數(shù)據(jù)庫方式還是內(nèi)存方式,總會(huì)消耗一定的性能。具體消耗多少性能,就要看不同的
application server
的
session
復(fù)制方案了,想深入了解,可以看集群方面的文檔,我也只記得一個(gè)比較簡單的
round robbin
了。
?????????
從架構(gòu)復(fù)雜性看:
B
更為簡單,因?yàn)闆]有
DM
的概念,每臺(tái)
server
都保持獨(dú)立。而使用了
DM
有時(shí)也會(huì)出現(xiàn)莫名奇妙的問題,這當(dāng)然是由于不了解
DM
的機(jī)制所致,但總歸也增加了復(fù)雜度,這點(diǎn)在后面的教訓(xùn)中進(jìn)行說明。
?????????
從水平擴(kuò)展性上看:
B
肯定更勝一籌。只要
F5
能支持,多少臺(tái)
server
都沒關(guān)系。而
A
多臺(tái)
server
做集群,要看
websphere
支持的節(jié)點(diǎn)數(shù)量,應(yīng)該不會(huì)太大。這個(gè)如果哪位同學(xué)知道,敬請(qǐng)告知。
當(dāng)然
A
和
B
在服務(wù)器較多的情況下是可以共存的,可以考慮幾臺(tái)機(jī)器做集群,然后集群間做負(fù)載均衡,這樣既可以減少部署的復(fù)雜度,又可以帶來較好的水平擴(kuò)展。由于沒做過更大型的項(xiàng)目,這個(gè)也只是我的假象,請(qǐng)做過的同學(xué)斧正。
?
說一說集群中碰到的問題。
?????????
首先是對(duì)各節(jié)點(diǎn)的同步:
有時(shí)為了方便測(cè)試,我們只對(duì)其中一個(gè)節(jié)點(diǎn)進(jìn)行更改,測(cè)試通過再放到其它節(jié)點(diǎn)。而如果測(cè)試周期較長,有時(shí)就會(huì)造成節(jié)點(diǎn)的不同步,出現(xiàn)各種各樣莫名其妙的問題。一個(gè)經(jīng)驗(yàn)就是:無論如何,在每天下班前要保證各節(jié)點(diǎn)的同步,不同步的現(xiàn)象不要過夜。
?????????
然后是對(duì)
DM
的理解:
我現(xiàn)在還只是實(shí)踐階段,沒有看過相關(guān)文檔。從意義上看,它控制了相關(guān)的配置文件,如果進(jìn)行節(jié)點(diǎn)同步,就會(huì)由它把配置文件同步到它管理的節(jié)點(diǎn)上。這對(duì)配置文件的修改提出了要求。我們開始只修改節(jié)點(diǎn)的配置文件而沒有修改
DM
的,結(jié)果進(jìn)行節(jié)點(diǎn)同步就會(huì)覆蓋修改的配置文件,帶來很多不必要的工作。經(jīng)驗(yàn)就是:或者修改
DM
的配置文件,然后進(jìn)行節(jié)點(diǎn)同步,或者直接同時(shí)修改所有節(jié)點(diǎn)和
DM
的。
?????????
還有關(guān)于
cache
的:
Cache
是性能優(yōu)化的一個(gè)有效手段。在單機(jī)環(huán)境下,最簡單的就是內(nèi)存
cache
,使用
static
的
Map
就行。而在集群環(huán)境中,
cache
就變的比較復(fù)雜了。首先還是從應(yīng)用需求入手,是否要保持每臺(tái)機(jī)器的
cache
同步。如果只是信息展示等要求不高的
cache
,不需保證
cache
的同步,問題也比較簡單,自己寫內(nèi)存
cache
,或者使用開源的
cache
組件如
ehcache,oscache
等就可以很好的解決問題。而如果需要
cache
在幾個(gè)節(jié)點(diǎn)保持同步,就需要特殊的機(jī)制了,
ehcache
等號(hào)稱支持分布式
cache
,但好像需要
jgroup
,配置比較麻煩,我沒有用過,有用過的同學(xué)請(qǐng)指教。我本來想使用
session
保存,然后進(jìn)行
session
同步,后來
IBM
建議使用數(shù)據(jù)庫
cache
,即自己寫代碼,
cache
在數(shù)據(jù)庫中。這樣不需要
session
同步,對(duì)象不大,性能也能得到保證,現(xiàn)在用下來效果還可以。
?