上周硅谷非常熱鬧，重大消息頻繁出現(xiàn)，其中包括了喬布斯因病休假，蘋果的恐怖財(cái)報(bào)等等。對(duì)于我們所關(guān)心的移動(dòng)業(yè)界跟互聯(lián)網(wǎng)來(lái)說(shuō)，Google 換帥是另外一個(gè)重量級(jí)消息。

Quora 上有一個(gè)討論串，題目是“Larry Page 上任之后，Google 的重點(diǎn)應(yīng)該是什么？”，討論相當(dāng)活躍。我也在這里湊個(gè)熱鬧，談一談在我看來(lái)，Larry Page 應(yīng)該如何去改變 Google。

1：關(guān)注核心業(yè)務(wù)，也就是搜索

Google 前段時(shí)間在搜索結(jié)果上算是飽受攻擊，由于與日俱增的垃圾內(nèi)容，搜索結(jié)果的污染狀況越發(fā)嚴(yán)重。Stack Overflow 的創(chuàng)始人之一 Jeff Atwood 在一篇文章里這樣評(píng)價(jià) Google 現(xiàn)在的搜索結(jié)果：

Google ，這個(gè)曾經(jīng)的必備工具，某種程度上已經(jīng)失去了它的優(yōu)勢(shì)地位。垃圾內(nèi)容制造者、以點(diǎn)擊率為終極目標(biāo)的內(nèi)容聚合站點(diǎn)正在走向勝利。

在 這一點(diǎn)上來(lái)說(shuō)，ifanr 感同身受。作為內(nèi)容提供者，我們是創(chuàng)造價(jià)值的人，是在給互聯(lián)網(wǎng)不斷添磚加瓦的一方。而之前在 Google 里搜索我們的原創(chuàng)文章，出現(xiàn)在結(jié)果最頂端的卻往往是是通過(guò)拷貝+粘貼、有時(shí)候還不注明出處進(jìn)行轉(zhuǎn)載的內(nèi)容聚合站點(diǎn)。它們用毫無(wú)成本的方式奪取著應(yīng)該屬于原 作者的訪問(wèn)量。

好在 Google 似乎已經(jīng)認(rèn)識(shí)到了這一點(diǎn)。之前搜索質(zhì)量組的 Matt Cutts 表示他 們已經(jīng)意識(shí)到了垃圾內(nèi)容的增多，以及劣質(zhì)內(nèi)容聚合站點(diǎn)引發(fā)的不滿，并且會(huì)很快進(jìn)行處理。從我今早的實(shí)驗(yàn)來(lái)看，似乎 Google 已經(jīng)采取了措施，最近 ifanr 的原創(chuàng)文章都出現(xiàn)在首頁(yè)頭條。從根子上（點(diǎn)擊量帶來(lái)的經(jīng)濟(jì)利益）驅(qū)逐劣質(zhì)內(nèi)容聚合站點(diǎn)，對(duì)現(xiàn)代互聯(lián)網(wǎng)來(lái)說(shuō)，確實(shí)是件好事

搜索，是 Google 的立身之本，從上周發(fā)布的財(cái)報(bào)來(lái)看，Google 收入的主要增長(zhǎng)點(diǎn)仍然是在網(wǎng)站本身的業(yè)務(wù)。不斷改進(jìn)搜索，添加新的搜索方式，才能保持和增強(qiáng) Google 在這個(gè)領(lǐng)域的領(lǐng)導(dǎo)地位。后院不起火，才有在其他領(lǐng)域發(fā)展的資本。

這一條，是 Larry Page 上任以后最需要關(guān)注的。未來(lái)十年的搜索是什么樣子？如何提高內(nèi)容關(guān)聯(lián)性，改進(jìn)使用體驗(yàn)？怎么樣通過(guò)創(chuàng)新，把 Bing 等競(jìng)爭(zhēng)對(duì)手遠(yuǎn)遠(yuǎn)甩開，對(duì) Google 來(lái)說(shuō)，至關(guān)重要。

2：在社交網(wǎng)絡(luò)方面另辟蹊徑

Google 在社交網(wǎng)絡(luò)方面的試探，到目前為止都是悲劇，坦率地說(shuō)，我個(gè)人認(rèn)為Google 已經(jīng)錯(cuò)過(guò)了第一班社交網(wǎng)絡(luò)的列車。

作為新生事物的社交網(wǎng)絡(luò)，從一開始負(fù)載的是用戶虛擬交流的需求。

目 前的勝利者里面，F(xiàn)acebook 滿足了人們交流的愿望，利用網(wǎng)絡(luò)，表現(xiàn)了某種程度上真實(shí)的人與人關(guān)系，而大量互動(dòng)元素的引入，則是模擬了現(xiàn)實(shí)生活的部分人際往來(lái)，從根底上來(lái)說(shuō)，沒有理念 上的創(chuàng)新，然而它仍然足夠偉大，F(xiàn)acebook 把現(xiàn)實(shí)生活成功投影到了虛擬世界，是真正意義上的創(chuàng)造者。

另一個(gè)贏家是 Twitter，它滿足的，是人們表達(dá)自己的愿望。通過(guò)簡(jiǎn)短的 140 個(gè)字，人與人之間形成了一種奇妙的交流關(guān)系，普通人也可以第一時(shí)間見證重大事件。可以說(shuō)，Twitter 與智能手機(jī)的結(jié)合，創(chuàng)造了一種新媒體。表達(dá)自己，記錄周邊，關(guān)注別人，是 Twitter 類社交網(wǎng)絡(luò)的根本。無(wú)論是變種的 foursquare，還是 Quora，從理念上看，都是這樣的東西。

Google 之前的嘗試呢？ Wave 那個(gè)體驗(yàn)一塌糊涂的東西不去說(shuō)它，出生太早了；Buzz 則是無(wú)限制版本的 Twitter：Google 試圖利用現(xiàn)成的龐大用戶群，但沒有實(shí)質(zhì)性創(chuàng)新，再加上拙劣的整合方式，這個(gè)產(chǎn)品的前景樂(lè)觀不到哪兒去。

社交網(wǎng)絡(luò)走到現(xiàn)在，實(shí)際上已經(jīng)到了一個(gè)重要的關(guān)口，即：虛擬的內(nèi)容如何與現(xiàn)實(shí)社會(huì)結(jié)合起來(lái)，怎樣把線上關(guān)系與實(shí)體經(jīng)濟(jì)整合，創(chuàng)造出一個(gè)嶄新的商業(yè)模式。在我看來(lái)，這才是第二代社交網(wǎng)絡(luò)，也即成熟版本的社交網(wǎng)絡(luò)。這個(gè)方向是未來(lái)兩年的熱點(diǎn)，也是 Google 下一步可以突圍的角度。

Google 的最大優(yōu)勢(shì)是什么？大家應(yīng)該都非常清楚，其一是龐大的用戶群，其二就是信息了。Google 相對(duì)于 Twittter、fousquare 等來(lái)說(shuō)，先天就有信息方面的優(yōu)勢(shì)。而 Google 在建設(shè)社交網(wǎng)絡(luò)的時(shí)候，卻完全忽略了這個(gè)優(yōu)勢(shì)，捆著手腳去從頭開始跟已經(jīng)成熟的對(duì)手競(jìng)爭(zhēng)，怎么可能勝利？

舉個(gè)最簡(jiǎn)單的例子，Google Maps 信息豐富，我經(jīng)常用它來(lái)尋找晚餐地點(diǎn)，最大的好處之一就是可以看到多個(gè)網(wǎng)站的用戶評(píng)價(jià)，看看截圖：

看 到了吧，有 Buzz 選項(xiàng)，然而搞笑的事來(lái)了。我可以看到其他網(wǎng)站的評(píng)價(jià)，可以在 Buzz 上分享這個(gè)地點(diǎn)，然后呢？沒了。我完全看不到 Buzz 關(guān)于這個(gè)餐館的討論，看不到我分享以后朋友的看法——一點(diǎn)也沒有。實(shí)體經(jīng)濟(jì)方面的內(nèi)容本身就是 Google 的長(zhǎng)項(xiàng)，然而在它的任何產(chǎn)品里面，都沒有把這個(gè)長(zhǎng)處跟自己的社交網(wǎng)絡(luò)更緊密得結(jié)合起來(lái)。

放著龐大的現(xiàn)實(shí)數(shù)據(jù)不用，幾個(gè)產(chǎn)品之間幾乎沒有交流，捧著金飯碗要飯，這就是 Google 的社交網(wǎng)絡(luò)。跟現(xiàn)實(shí)社會(huì)結(jié)合的社交網(wǎng)絡(luò)，將是 Google 在這一領(lǐng)域的最后一個(gè)機(jī)會(huì)。

3：細(xì)節(jié)，細(xì)節(jié)，還是細(xì)節(jié)

有一句老話，細(xì)節(jié)決定成敗，然而 Google 現(xiàn)在的很多做法，卻表現(xiàn)了一種對(duì)細(xì)節(jié)的漠視，極大影響了產(chǎn)品的使用體驗(yàn)。還是要以 Android 為例（這玩意簡(jiǎn)直就是反面教材）：

就從簡(jiǎn)單的設(shè)置界面說(shuō)起。Android 平鋪直敘的設(shè)置界面，完全沒有突出重點(diǎn)（我甚至懷疑這幫人安排順序的時(shí)候是不是拍腦門做出的決定。），跟右邊的 iOS 比，孰優(yōu)孰劣，一目了然。

還有應(yīng)用市場(chǎng)，每次談到 Android 的應(yīng)用市場(chǎng)，我都有爆粗口的沖動(dòng)。緩慢的速度、時(shí)常丟失的已下載應(yīng)用列表、遲遲沒有解決的應(yīng)用無(wú)法下載問(wèn)題……這是整個(gè)產(chǎn)業(yè)的核心之一，Google 就準(zhǔn)備這么糊弄下去？

Android 不講究的地方何止這些，工程師文化并不代表著可以不拘小節(jié)，Google 的目光，應(yīng)該多放些在細(xì)節(jié)上。移動(dòng)設(shè)備，用戶體驗(yàn)至關(guān)重要。

4: 繼續(xù)擁抱云，下注新能源產(chǎn)業(yè)

在這個(gè)賣雜貨的、搞 B2C 的、做軟件的都在搞云應(yīng)用平臺(tái)的當(dāng)口，互聯(lián)網(wǎng)界巨頭，擁抱云的先驅(qū)之一，可能擁有著世界上最好硬件以及網(wǎng)絡(luò)設(shè)施的 Google，當(dāng)然也擁有自家的 App Engine。

云 計(jì)算平臺(tái)對(duì)于中小企業(yè)、個(gè)人的意義，無(wú)論如何贊揚(yáng)也不會(huì)過(guò)分，它直接引領(lǐng)了當(dāng)前的互聯(lián)網(wǎng)創(chuàng)業(yè)潮。低廉的平臺(tái)成本，按需付費(fèi)的方式，Amazon EC2 吸引了大量的個(gè)人開發(fā)者，Google 的 App Engine 當(dāng)然不錯(cuò)，但我要說(shuō)，還是不夠靈活，如果能提供更多語(yǔ)言支持，就再好不過(guò)了。

新能源很好理解，隨著碳交易市場(chǎng)的興起，碳排放量眼看就要變成金融市場(chǎng)上的一個(gè)新產(chǎn)品。在這個(gè)趨勢(shì)影響下，每個(gè)企業(yè)都應(yīng)該考慮下自己的能源來(lái)源，為將來(lái)更加嚴(yán)格的排放調(diào)控措施做好準(zhǔn)備，規(guī)避可能的經(jīng)濟(jì)風(fēng)險(xiǎn)。

降低所消耗能源的碳排放，對(duì)于 Google 這種能源消耗大戶來(lái)說(shuō)，是經(jīng)濟(jì)跟政治上都很正確的方向，而且同樣有大量的利益存在。新能源產(chǎn)業(yè)，應(yīng)該成為 Google 下一步的重點(diǎn)投入方向。

5：提高決策速度與質(zhì)量，減少內(nèi)部溝通環(huán)節(jié)

大 家都知道 Google 著名的 20% 規(guī)則：?jiǎn)T工可以把 20% 的上班時(shí)間放在其他項(xiàng)目上。Google 的員工無(wú)疑是優(yōu)秀的，這些業(yè)余時(shí)間做出的項(xiàng)目也應(yīng)該有很多不錯(cuò)的點(diǎn)子，然而，從中孵化的成果卻并不多。其中的部分原因，恐怕與 Google 的內(nèi)部引導(dǎo)以及溝通機(jī)制存在很大的關(guān)系。由于缺乏引導(dǎo)，員工的項(xiàng)目往往與 Google 本身沒什么聯(lián)系，而因?yàn)闇贤▎?wèn)題，好的項(xiàng)目不一定能夠獲得公司的幫助。

Google 的前員工遍布整個(gè)互聯(lián)網(wǎng)業(yè)界，大量創(chuàng)新卻往往出現(xiàn)在他們離開 Google 以后。應(yīng)該如何去引發(fā)員工的創(chuàng)造力、提高內(nèi)部效率跟執(zhí)行力度，Larry Page 需要仔細(xì)考慮，以便調(diào)整內(nèi)部架構(gòu)來(lái)適應(yīng)這個(gè)變化迅速的世界。三星這個(gè)反應(yīng)快到根本不像大公司的大公司在全世界攻城掠地，諾基亞反應(yīng)稍微遲緩一點(diǎn)就束手束 腳，Google，你要快一點(diǎn)，再快一點(diǎn)，才能跟 Facebook 以及數(shù)以千計(jì)的創(chuàng)業(yè)企業(yè)進(jìn)行競(jìng)爭(zhēng)。

轉(zhuǎn)自：http://www.oschina.net/news/14996/larry-page-google-five-things-todo

沒有人能說(shuō)清哪種緩存算法優(yōu)于其他的緩存算法。（以下的幾種緩存算法，有的我也理解不好，如果感興趣，你可以Google一下）

Least Frequently Used（LFU）：

大家好，我是 LFU，我會(huì)計(jì)算為每個(gè)緩存對(duì)象計(jì)算他們被使用的頻率。我會(huì)把最不常用的緩存對(duì)象踢走。

Least Recently User（LRU）：

我是LRU緩存算法，我把最近最少使用的緩存對(duì)象給踢走。

我總是需要去了解在什么時(shí)候，用了哪個(gè)緩存對(duì)象。如果有人想要了解我為什么總能把最近最少使用的對(duì)象踢掉，是非常困難的。

瀏覽器就是使用了我（LRU）作為緩存算法。新的對(duì)象會(huì)被放在緩存的頂部，當(dāng)緩存達(dá)到了容量極限，我會(huì)把底部的對(duì)象踢走，而技巧就是：我會(huì)把最新被訪問(wèn)的緩存對(duì)象，放到緩存池的頂部。

所以，經(jīng)常被讀取的緩存對(duì)象就會(huì)一直呆在緩存池中。有兩種方法可以實(shí)現(xiàn)我，array 或者是 linked list。

我的速度很快，我也可以被數(shù)據(jù)訪問(wèn)模式適配。我有一個(gè)大家庭，他們都可以完善我，甚至做的比我更好（我確實(shí)有時(shí)會(huì)嫉妒，但是沒關(guān)系）。我家庭的一些成員包括LRU2 和 2Q，他們就是為了完善 LRU 而存在的。

Least Recently Used 2（LRU2）：

我是 Least Recently Used 2，有人叫我最近最少使用twice，我更喜歡這個(gè)叫法。我會(huì)把被兩次訪問(wèn)過(guò)的對(duì)象放入緩存池，當(dāng)緩存池滿了之后，我會(huì)把有兩次最少使用的緩存對(duì)象踢走。 因?yàn)樾枰檶?duì)象2次，訪問(wèn)負(fù)載就會(huì)隨著緩存池的增加而增加。如果把我用在大容量的緩存池中，就會(huì)有問(wèn)題。另外，我還需要跟蹤那么不在緩存的對(duì)象，因?yàn)樗?們還沒有被第二次讀取。我比LRU好，而且是 adoptive to access 模式 。

Two Queues（2Q）：

我是 Two Queues；我把被訪問(wèn)的數(shù)據(jù)放到LRU的緩存中，如果這個(gè)對(duì)象再一次被訪問(wèn)，我就把他轉(zhuǎn)移到第二個(gè)、更大的LRU緩存。

我踢走緩存對(duì)象是為了保持第一個(gè)緩存池是第二個(gè)緩存池的1/3。當(dāng)緩存的訪問(wèn)負(fù)載是固定的時(shí)候，把 LRU 換成 LRU2，就比增加緩存的容量更好。這種機(jī)制使得我比 LRU2 更好，我也是 LRU 家族中的一員，而且是 adoptive to access 模式 。

Adaptive Replacement Cache（ARC）：

我是 ARC，有人說(shuō)我是介于 LRU 和 LFU 之間，為了提高效果，我是由2個(gè) LRU 組成，第一個(gè)，也就是 L1，包含的條目是最近只被使用過(guò)一次的，而第二個(gè) LRU，也就是 L2，包含的是最近被使用過(guò)兩次的條目。因此， L1 放的是新的對(duì)象，而 L2 放的是常用的對(duì)象。所以，別人才會(huì)認(rèn)為我是介于 LRU 和 LFU 之間的，不過(guò)沒關(guān)系，我不介意。

我被認(rèn)為是性能最好的緩存算法之一，能夠自調(diào)，并且是低負(fù)載的。我也保存著歷史對(duì)象，這樣，我就可以記住那些被移除的對(duì)象，同時(shí)，也讓我可以看到被移除的對(duì)象是否可以留下，取而代之的是踢走別的對(duì)象。我的記憶力很差，但是我很快，適用性也強(qiáng)。

Most Recently Used（MRU）：

我是 MRU，和 LRU 是對(duì)應(yīng)的。我會(huì)移除最近最多被使用的對(duì)象，你一定會(huì)問(wèn)我為什么。好吧，讓我告訴你，當(dāng)一次訪問(wèn)過(guò)來(lái)的時(shí)候，有些事情是無(wú)法預(yù)測(cè)的，并且在緩存系統(tǒng)中找出最少最近使用的對(duì)象是一項(xiàng)時(shí)間復(fù)雜度非常高的運(yùn)算，這就是為什么我是最好的選擇。

我是數(shù)據(jù)庫(kù)內(nèi)存緩存中是多么的常見！每當(dāng)一次緩存記錄的使用，我會(huì)把它放到棧的頂端。當(dāng)棧滿了的時(shí)候，你猜怎么著？我會(huì)把棧頂?shù)膶?duì)象給換成新進(jìn)來(lái)的對(duì)象！

First in First out（FIFO）：

我是先進(jìn)先出，我是一個(gè)低負(fù)載的算法，并且對(duì)緩存對(duì)象的管理要求不高。我通過(guò)一個(gè)隊(duì)列去跟蹤所有的緩存對(duì)象，最近最常用的緩存對(duì)象放在后面，而更早的緩存對(duì)象放在前面，當(dāng)緩存容量滿時(shí)，排在前面的緩存對(duì)象會(huì)被踢走，然后把新的緩存對(duì)象加進(jìn)去。我很快，但是我并不適用。

Second Chance：

大家好，我是 second chance，我是通過(guò)FIFO修改而來(lái)的，被大家叫做 second chance 緩存算法，我比 FIFO 好的地方是我改善了 FIFO 的成本。我是 FIFO 一樣也是在觀察隊(duì)列的前端，但是很FIFO的立刻踢出不同，我會(huì)檢查即將要被踢出的對(duì)象有沒有之前被使用過(guò)的標(biāo)志（1一個(gè)bit表示），沒有沒有被使用 過(guò)，我就把他踢出；否則，我會(huì)把這個(gè)標(biāo)志位清除，然后把這個(gè)緩存對(duì)象當(dāng)做新增緩存對(duì)象加入隊(duì)列。你可以想象就這就像一個(gè)環(huán)隊(duì)列。當(dāng)我再一次在隊(duì)頭碰到這個(gè) 對(duì)象時(shí)，由于他已經(jīng)沒有這個(gè)標(biāo)志位了，所以我立刻就把他踢開了。我在速度上比FIFO快。

CLock

我是Clock，一個(gè)更好的FIFO，也比 second chance更好。因?yàn)槲也粫?huì)像second chance那樣把有標(biāo)志的緩存對(duì)象放到隊(duì)列的尾部，但是也可以達(dá)到second chance的效果。

我持有一個(gè)裝有緩存對(duì)象的環(huán)形列表，頭指針指向列表中最老的緩存對(duì)象。當(dāng)緩存miss發(fā)生并且沒有新的緩存空間時(shí)，我會(huì)問(wèn)問(wèn)指針指向的緩存對(duì)象的標(biāo) 志位去決定我應(yīng)該怎么做。如果標(biāo)志是0，我會(huì)直接用新的緩存對(duì)象替代這個(gè)緩存對(duì)象；如果標(biāo)志位是1，我會(huì)把頭指針遞增，然后重復(fù)這個(gè)過(guò)程，知道新的緩存對(duì) 象能夠被放入。我比second chance更快。

Simple time-based：

我是 simple time-based 緩存算法，我通過(guò)絕對(duì)的時(shí)間周期去失效那些緩存對(duì)象。對(duì)于新增的對(duì)象，我會(huì)保存特定的時(shí)間。我很快，但是我并不適用。

Extended time-based expiration：

我是 extended time-based expiration 緩存算法，我是通過(guò)相對(duì)時(shí)間去失效緩存對(duì)象的；對(duì)于新增的緩存對(duì)象，我會(huì)保存特定的時(shí)間，比如是每5分鐘，每天的12點(diǎn)。

Sliding time-based expiration：

我是 sliding time-based expiration，與前面不同的是，被我管理的緩存對(duì)象的生命起點(diǎn)是在這個(gè)緩存的最后被訪問(wèn)時(shí)間算起的。我很快，但是我也不太適用。

好了！聽了那么多緩存算法的自我介紹，其他的緩存算法還考慮到了下面幾點(diǎn)：

• 成本。如果緩存對(duì)象有不同的成本，應(yīng)該把那些難以獲得的對(duì)象保存下來(lái)。
• 容量。如果緩存對(duì)象有不同的大小，應(yīng)該把那些大的緩存對(duì)象清除，這樣就可以讓更多的小緩存對(duì)象進(jìn)來(lái)了。
• 時(shí)間。一些緩存還保存著緩存的過(guò)期時(shí)間。電腦會(huì)失效他們，因?yàn)樗麄円呀?jīng)過(guò)期了。

根據(jù)緩存對(duì)象的大小而不管其他的緩存算法可能是有必要的。

原文：http://www.zavakid.com/27

提交 B3log Solo（運(yùn)行在 GAE/J 上的博客程序） 代碼后發(fā)現(xiàn) Google Code 版本控制系統(tǒng)會(huì)將提交日志同步發(fā)布到 Google Buzz 中：

但在 Buzz connected sites 里并沒有看到與 Google Code 關(guān)聯(lián)：

現(xiàn)在一提交代碼就 Buzz，還是比較無(wú)奈的....

有時(shí)我們需要隨機(jī)地獲取數(shù)據(jù)記錄（實(shí)體），比如博客程序中的“隨機(jī)文章”的實(shí)現(xiàn)。

目前 GAE 并沒有 API 可以直接獲取隨機(jī)實(shí)體，要實(shí)現(xiàn)這樣的需求我們只能自己想辦法了 :-)

在 stackoverflow 上也有人提過(guò)該問(wèn)題，總結(jié)如下：

• Generate and store a random number on your entities as you create them, then pick a random number and look (via a query) for the closet record(s) to it.
• Implement some mechanism to ensure your entity ids are "densely" populated, then fetch within the known range using keys.
• Periodically generate random lists of the entities and return entities from those lists. This may take the form of a stack that entities are popped off of, or as actual lists that are returned.

目前 B3log Solo 在處理“隨機(jī)閱讀”上采用的是方法一，即在每個(gè)文章實(shí)體上添加一個(gè)屬性保存 0-1 的隨機(jī)浮點(diǎn)數(shù)。

在獲取隨機(jī)文章時(shí)生成一個(gè) 0-1 的隨機(jī)數(shù)（mid）作為查詢條件，以此查詢條件作為邊界（0 <= mid <=1）來(lái)過(guò)濾實(shí)體保存的隨機(jī)值屬性。

這個(gè)方法基本可以達(dá)到隨機(jī)的效果了，為了讓隨機(jī)的效果更動(dòng)態(tài)一點(diǎn)，我們可以考慮經(jīng)常更新文章實(shí)體中的隨機(jī)浮點(diǎn)值：

• 訪問(wèn)文章時(shí)（即在更新文章瀏覽次數(shù)時(shí)一并更新該文章的隨機(jī)浮點(diǎn)值）
• 后臺(tái)定時(shí)任務(wù)（獲取一定數(shù)量的隨機(jī)文章然后更新它們的隨機(jī)浮點(diǎn)值）
• 用戶做文章更新時(shí)

加上以上處理后，隨機(jī)的效果比較好了 :-)

作者 榮浩 發(fā)布于 2010年12月28日 上午12時(shí)0分

對(duì)jBPM來(lái)說(shuō)，今年最大的事件莫過(guò)于jBPM的創(chuàng)建者Tom Baeyens離開JBoss了。Tom Baeyens離開的具體原因尚不清楚，但他的離開產(chǎn)生了兩個(gè)結(jié)果：一是jBPM的下一個(gè)版本jBPM5完全放棄了jBPM4的基礎(chǔ)代碼，基于Drools Flow重頭來(lái)過(guò)；二是Tom Baeyens加入Alfresco后很快推出了新的基于jBPM4的開源工作流系統(tǒng)Activiti。 由此不難推測(cè)Tom Baeyens離開的部分原因：JBoss內(nèi)部對(duì)jBPM未來(lái)版本的架構(gòu)實(shí)現(xiàn)產(chǎn)生了嚴(yán)重的意見分歧。更加巧合的是12月1日Activiti5剛發(fā)布，緊 接著12月2日jBPM5就發(fā)布了第一個(gè)候選發(fā)布版本，jBPM與Activiti之間的微妙關(guān)系可見一般。

在這篇文章里，我們將一起回顧jBPM從jBPM3到j(luò)BPM5以及Activiti5的發(fā)展歷程，我們可以清晰的看見jBPM（包括 Activiti）設(shè)計(jì)所遵循的一致原則：強(qiáng)調(diào)流程服務(wù)的可嵌入性和可擴(kuò)展性。同時(shí)，從各個(gè)版本之間的變化我們也能看見產(chǎn)品設(shè)計(jì)思路的變化：更加強(qiáng)調(diào)面向 業(yè)務(wù)人員，增加BPMS（業(yè)務(wù)流程管理系統(tǒng)）特性。

在回顧之前，我們首先討論一下BPMS應(yīng)該嵌入還是獨(dú)立部署的問(wèn)題，因?yàn)椴还苁莏BPM還是Activiti，都強(qiáng)調(diào)了流程服務(wù)的可嵌入性。此外，我們還需要討論一下什么是BPMS的特性，它們所解決的問(wèn)題是什么。

一、嵌入式還是獨(dú)立部署？

不管是jBPM還是Activiti，都強(qiáng)調(diào)了流程服務(wù)的可嵌入性。Tom Baeyens在其個(gè)人博客里稱作為獨(dú)立部署的BPMS已死，原因有兩個(gè)：一是獨(dú)立部署的BPMS需要很高的安裝使用成本，需要獨(dú)立部署、需要用戶支出大 量的培訓(xùn)成本和維護(hù)成本；二是獨(dú)立部署的BPMS與外部系統(tǒng)的交互方式是分布式，這使得很多問(wèn)題變得復(fù)雜，例如分布式事務(wù)。Tom Baeyens代表了相當(dāng)一部分人特別是開發(fā)人員的觀點(diǎn)。

Tom Baeyens沒有完全理解BPMS。什么是BPMS？BPMS最重要的目標(biāo)就是需要打破各個(gè)應(yīng)用系統(tǒng)（CRM、ECM、ERP、SCM）之間的界線，將 分散在這些系統(tǒng)中的流程集中管理，這是BPMS的實(shí)質(zhì)。一如流程再造，打破各個(gè)部門之間的壁壘，減少浪費(fèi)，建立流程驅(qū)動(dòng)性的組織。如下圖1所示：

圖 1：BPMS打破應(yīng)用系統(tǒng)之間的界線

BPMS所要解決的問(wèn)題要求其必然是獨(dú)立部署的。Tom Baeyens錯(cuò)誤的根本原因在于其將BPMS與工作流系統(tǒng)的定義混為了一談，他如此定義BPMS：BPMS旨在簡(jiǎn)化對(duì)組織核心流程進(jìn)行支撐的軟件創(chuàng)建。 也就是BPMS面向的是軟件開發(fā)人員，旨在簡(jiǎn)化他們的開發(fā)，降低他們使用流程的門檻。而這正是工作流系統(tǒng)需要解決的問(wèn)題。

BPMS面向企業(yè)用戶，工作流面向開發(fā)社區(qū)和系統(tǒng)集成商。

二、BPMS特性

jBPM4、jBPM5和Activiti5都增加了其BPMS特性，那些特性能夠稱為BPMS特性呢？我們先看一看BPMS需要解決的問(wèn)題，為解決這些問(wèn)題所增加的特性就是BPMS特性。

1. 如何設(shè)計(jì)流程，在組織中高效地對(duì)設(shè)計(jì)出的流程進(jìn)行溝通，取得共識(shí)？

   • 提供跨越組織的流程標(biāo)準(zhǔn)標(biāo)記符號(hào)與術(shù)語(yǔ)（BPMN已經(jīng)成為標(biāo)準(zhǔn)）
   • 流程及相關(guān)文檔的可視化（流程/內(nèi)容存儲(chǔ)倉(cāng)庫(kù)）
   • 提供在組織結(jié)構(gòu)內(nèi)進(jìn)行不同層次之間的流程導(dǎo)航（流程存儲(chǔ)倉(cāng)庫(kù)支持組織模型）
   • 流程定義在各個(gè)層次/部門間的一致性，避免業(yè)務(wù)人員的流程建模轉(zhuǎn)換到IT系統(tǒng)時(shí)受到損耗（流程引擎支持基于圖的建模，支持?jǐn)U展）

2. 如何更好地執(zhí)行流程？

   • 業(yè)務(wù)活動(dòng)的實(shí)時(shí)監(jiān)控，預(yù)警與控制（BAM）
   • 流程執(zhí)行的仿真
   • 流程執(zhí)行的統(tǒng)計(jì)分析與反饋（報(bào)表）
3. 如何更好地管理流程？
   • 打破各個(gè)應(yīng)用系統(tǒng)之間的界線，統(tǒng)一管理所有流程（EAI，與ESB的集成）
   • 對(duì)業(yè)務(wù)人員友好的建模工具
4. 如何在執(zhí)行流程過(guò)程中遵循業(yè)內(nèi)最佳實(shí)踐和規(guī)則？
   • 面向流程的知識(shí)管理
   • 規(guī)則引擎

三、完整的工作流實(shí)現(xiàn)jBPM3

jBPM3的最新版本是3.2.7，其包括了以下組件：基于Eclipse的流程設(shè)計(jì)器、用于監(jiān)控案例（流程實(shí)例）和處理任務(wù)的Web控制臺(tái)以及jPDL核心庫(kù)。如下圖2所示：

圖 2：jBPM3組件

1. 基于Eclipse的流程設(shè)計(jì)器

   提供給開發(fā)人員繪制jPDL流程圖，因?yàn)樵撛O(shè)計(jì)器基于Eclipse，所以生成的流程文件可以與開發(fā)代碼一起組織管理，非常容易進(jìn)行單元測(cè)試。實(shí)現(xiàn)了工作流管理系統(tǒng)參考模型里的接口1。

2. Web管理控制臺(tái)

   主要有兩個(gè)功能：一是作為工作流客戶端應(yīng)用接口，給用戶提供一種手段，以處理案例運(yùn)行過(guò)程中需要人工處理的任務(wù)；二是對(duì)案例的狀態(tài)進(jìn)行監(jiān)控與管理。實(shí)現(xiàn)了工作流管理系統(tǒng)參考模型里的接口2和5。

3. jPDL核心庫(kù)

   jPDL核心庫(kù)是一個(gè)單獨(dú)的JAR包，可以嵌入到目標(biāo)應(yīng)用中執(zhí)行，它包括了：

   • 流程倉(cāng)庫(kù)：解析jPDL流程定義文件并存儲(chǔ)讀取；
   • 流程引擎：對(duì)流程定義進(jìn)行初始化和調(diào)度執(zhí)行，節(jié)點(diǎn)的運(yùn)行期行為與jPDL里定義的節(jié)點(diǎn)類型一一綁定；
   • 任務(wù)管理：生成任務(wù)節(jié)點(diǎn)所對(duì)應(yīng)的工作項(xiàng)，管理工作項(xiàng)的生命周期（初始化、分配執(zhí)行者、執(zhí)行、掛起、結(jié)束、終止）；
   • 事件管理：發(fā)布案例和任務(wù)的開始、結(jié)束事件，通過(guò)監(jiān)聽者模式調(diào)用相應(yīng)的事件處理器；
   • 異步執(zhí)行機(jī)制：通過(guò)線程實(shí)現(xiàn)了Job Executor，進(jìn)行異步工作的處理，這些工作包括了時(shí)間處理、異步動(dòng)作。
   • 身份組件模型：實(shí)現(xiàn)了一套簡(jiǎn)單的身份組件模型，包括了組、用戶和權(quán)限。

   通過(guò)調(diào)用自定義Java代碼實(shí)現(xiàn)了對(duì)外部應(yīng)用的調(diào)用，從而實(shí)現(xiàn)工作流管理系統(tǒng)參考模型里的接口3。

jBPM3是一個(gè)輕量級(jí)的嵌入式工作流系統(tǒng)。它在Java社區(qū)的成功得益于兩個(gè)方面：一是嵌入式，這降低了使用工作流的門檻；二是對(duì)開發(fā)人 員友好，這表現(xiàn)在易讀的jPDL、流程的可測(cè)試性(Eclipse插件)以及節(jié)點(diǎn)行為的可擴(kuò)展性，我們可以非常容易的在流程運(yùn)行中加入自己定制的行為（通 過(guò)事件處理器和Action）。jBPM3面向開發(fā)人員，它解決的問(wèn)題是流程的自動(dòng)化，它的影響力集中在Java開發(fā)社區(qū)，是一個(gè)完整的工作流系統(tǒng)實(shí)現(xiàn)。

四、向BPMS努力的jBPM4

與jBPM3相比，jBPM4最大的變化是引入了流程虛擬機(jī)（PVM），同時(shí)增加了BPMS的特性。jBPM4不再滿足于工作流系統(tǒng)的定位，開始向BPMS努力。

1. 為什么引入流程虛擬機(jī)

   盡管jBPM3在Java社區(qū)取得了很大的成功，但是有一件事始終被人們?cè)嵅。蔷褪撬恢С至鞒陶Z(yǔ)言規(guī)范，從最開始的XPDL、BPEL 到后來(lái)的BPMN，它采用了自定義的jPDL。在jBPM3中，節(jié)點(diǎn)的運(yùn)行期行為與jPDL里定義的節(jié)點(diǎn)類型是一一綁定的，這造成了流程引擎與特定流程語(yǔ) 言的綁定，要支持其他的流程語(yǔ)言變得困難。于是在jBPM4中，jBPM提出了流程虛擬機(jī)的概念，即流程引擎與流程語(yǔ)言解耦，通過(guò)一套通用的流程模型并配 以可定制的節(jié)點(diǎn)運(yùn)行期行為實(shí)現(xiàn)了對(duì)多流程語(yǔ)言的支持。

   流程虛擬機(jī)帶來(lái)的好處是多方面的：第一也是最重要的是jBPM4支持了BPMN。

   第二是實(shí)現(xiàn)了基于流程組件的流程引擎，流程圖(語(yǔ)言)與實(shí)現(xiàn)解耦，我們使用通用編程語(yǔ)言實(shí)現(xiàn)節(jié)點(diǎn)運(yùn)行期行為，稱之為流程組件，通過(guò)將流程圖 與流程組件掛接，避免了圖的損耗。在這一點(diǎn)上，Tom Baeyens對(duì)BPMN到BPEL的轉(zhuǎn)換提出了一針見血的批評(píng)：BPMN和jPDL以及XPDL都是基于圖的，而BPEL是基于塊的，這造成了當(dāng)將業(yè)務(wù) 人員使用BPMN所建立的流程模型向BPEL執(zhí)行模型進(jìn)行轉(zhuǎn)換時(shí)，出現(xiàn)許多的不匹配，最初的流程模型會(huì)扭曲變形。而扭曲的后果就是業(yè)務(wù)人員與開發(fā)人員之間 的協(xié)作困難，這影響了流程從業(yè)務(wù)到技術(shù)的實(shí)現(xiàn)。

   第三個(gè)好處是我們可以定義領(lǐng)域特定語(yǔ)言（DSL），在特定的應(yīng)用里，采用DSL約定并隱藏了大部分的技術(shù)細(xì)節(jié)可能做到業(yè)務(wù)人員對(duì)執(zhí)行流程的直接修改，例如企業(yè)文檔管理里的審批流程。

2. BPMS特性的加入

   這表現(xiàn)在以下三個(gè)方面：第一是支持了BPMN，BPMN已經(jīng)成為業(yè)務(wù)人員的流程建模標(biāo)準(zhǔn)；第二是引入了Signavio作為面向業(yè)務(wù)人員的Web建模器；第三是在已有的Web管理控制臺(tái)加入了對(duì)案例和任務(wù)的統(tǒng)計(jì)功能。jBPM4的組件如下圖3所示：

   

   圖3：jBPM4組件

   和jBPM3一樣，jBPM4依然是輕量級(jí)的、可嵌入的工作流系統(tǒng)。相比jBPM3，它將業(yè)務(wù)人員作為最終用戶之一，增加了部分BPMS特性，同時(shí)PVM的引入使得它的可擴(kuò)展性得到了極大的增強(qiáng)，我們甚至可以定義自己的DSL。

   在BPMS特性里我們提到了應(yīng)該避免業(yè)務(wù)人員的流程建模轉(zhuǎn)換到IT系統(tǒng)時(shí)受到損耗，最理想的情況是業(yè)務(wù)人員與開發(fā)人員共用一個(gè)流程模型，業(yè) 務(wù)人員能夠直接對(duì)流程進(jìn)行調(diào)整（在特定應(yīng)用中，通過(guò)DSL是可以做到的）；其次是通過(guò)BPMS將業(yè)務(wù)人員的模型與實(shí)際執(zhí)行的技術(shù)模型關(guān)聯(lián)起來(lái)（很多商業(yè)產(chǎn) 品已經(jīng)做到了這一點(diǎn)，在Activiti5中我們也會(huì)看到這一點(diǎn)），業(yè)務(wù)人員、開發(fā)人員以及運(yùn)營(yíng)團(tuán)隊(duì)之間能夠做到很好的協(xié)調(diào)；最差是業(yè)務(wù)人員與開發(fā)人員各 自為政，獨(dú)立維護(hù)各自的流程模型，并且模型之間存在極大的不匹配，此時(shí)流程的迅速變化基本上是奢望。

五、鳩占鵲巢的Drools Flow與jBPM5

目前jBPM5剛剛發(fā)布了第一個(gè)候選發(fā)布版本，jBPM5基本上完全拋棄了jBPM4的代碼，所有代碼全部來(lái)自原先的Drools Flow。Drools Flow最初被用來(lái)解決規(guī)則執(zhí)行順序的問(wèn)題。其實(shí)從Drools Flow開始支持BPMN時(shí)起，我們已經(jīng)預(yù)感到它與jBPM的競(jìng)爭(zhēng)關(guān)系。

jBPM5依舊定位為輕量級(jí)的可嵌入的工作流系統(tǒng)。在jBPM5的特性里，有這么兩條引人關(guān)注：一是引入了Guvnor作為流程倉(cāng)庫(kù)，這解決了流程 的可視化問(wèn)題，流程定義作為資源被管理，我們可以對(duì)流程定義進(jìn)行可視化管理以及全文檢索（Guvnor使用了Jackrabbit作為了其存儲(chǔ)實(shí)現(xiàn)，但我 們的經(jīng)驗(yàn)表明Jackrabbit在大數(shù)據(jù)量情況下性能存在嚴(yán)重問(wèn)題）；第二是規(guī)則引擎(Drools Expert)、事件處理引擎(Drools Fusion)與流程引擎的合三為一，這是jBPM5最讓人期待的地方。jBPM5的組件如下圖4所示：

圖 4：jBPM5組件

規(guī)則引擎在流程中的應(yīng)用已經(jīng)非常廣泛了，我們這里說(shuō)說(shuō)事件處理引擎。

事件處理引擎是業(yè)務(wù)活動(dòng)監(jiān)控（BAM）的基礎(chǔ)，BAM的功能及執(zhí)行過(guò)程，如下：

• 捕獲：BAM捕獲各種事件（通過(guò)消息監(jiān)聽器、適配器、代理等）。這些事件來(lái)自應(yīng)用、系統(tǒng)軟件、外部交易伙伴。消息是BAM的核心——它們反應(yīng)底層業(yè)務(wù)流程的狀況。
• 過(guò)濾：BAM過(guò)濾掉沒有直接后果的事件，在很多情況下由支持事件流處理（Event Stream Processing，簡(jiǎn)稱ESP）或復(fù)雜事件處理（Complex Event Processing，簡(jiǎn)稱CEP）引擎來(lái)進(jìn)行過(guò)濾。
• 分析：BAM根據(jù)分析模型和規(guī)則將相關(guān)事件聯(lián)系起來(lái)。
• 警告：BAM向用戶提出警告，以便用戶在必要時(shí)進(jìn)行控制。

如上所示，BAM的執(zhí)行過(guò)程包含四個(gè)步驟，而前三個(gè)步驟都是對(duì)事件進(jìn)行相關(guān)的處理（捕獲事件、過(guò)濾事件、分析事件、關(guān)聯(lián)事件），因此在大多數(shù)BAM的技術(shù)實(shí)現(xiàn)方案中，都基于CEP和ESP的引擎來(lái)實(shí)現(xiàn)BAM的功能。

與jBPM4相比，jBPM5對(duì)PVM的放棄也帶來(lái)了幾個(gè)不小的問(wèn)題：第一是對(duì)開發(fā)人員來(lái)說(shuō)只支持BPMN，不再支持jPDL（當(dāng)然提供了遷移工 具）；第二是流程執(zhí)行的可擴(kuò)展性回到了jBPM3的年代，僅僅支持自定義動(dòng)作（相當(dāng)于jBPM3里的Action）。此外，Web建模器由 Signavio替換為了Oryx Designer。

總而言之，jBPM5通過(guò)引入流程倉(cāng)庫(kù)和BAM繼續(xù)向BPMS邁進(jìn)（目前的進(jìn)展是與流程倉(cāng)庫(kù)的集成還未完成，BAM基于日志進(jìn)行分析），同時(shí)，由于不再支持PVM和jPDL，帶來(lái)了流程擴(kuò)展性的降低和社區(qū)開發(fā)人員的未來(lái)流失。

六、Activiti5的反擊

Activiti5是Tom Baeyens加入Alfresco后推出的新的基于jBPM4的開源工作流系統(tǒng)，1號(hào)剛剛發(fā)布第一個(gè)版本。Activiti的開發(fā)團(tuán)隊(duì)相比與jBPM強(qiáng) 大了許多，有23位核心開發(fā)者。當(dāng)然這也是由于activiti規(guī)劃的功能所致：包括核心引擎、Web的流程建模器、協(xié)作工具Activiti Cycle、Activiti Probe、Activiti Explorer、與Spring的集成、與Mule的集成等。

圖 5：Activiti5的組件

如上圖所示，Activiti5由三種類型的組件組成，分別是：專用工具（Dedicated Tools）、內(nèi)容存儲(chǔ)工具（Stored Content）和協(xié)作工具（Collaboration Tool）。

專用工具包括以下：

• Alfresco—Alfresco公司的企業(yè)級(jí)內(nèi)容管理產(chǎn)品

Alfresco 是一個(gè)開源的、企業(yè)級(jí)的內(nèi)容管理系統(tǒng)，功能包括：文檔管理、協(xié)作、記錄管理、知識(shí)庫(kù)管理、Web內(nèi)容管理等功能。Alfresco與Activiti的深 入集成實(shí)現(xiàn)了流程及相關(guān)文檔的可視化。更重要的是Alfresco支持組織模型，能夠提供在組織結(jié)構(gòu)內(nèi)進(jìn)行不同層次之間的流程導(dǎo)航。

• Activiti Modeler—建模器

基于開源Signavio Web流程編輯器的一個(gè)定制版本，提供了對(duì)BPMN2.0圖形化規(guī)范的支持，建模后的流程以文件格式進(jìn)行存儲(chǔ)。

• Activiti Designer—Eclipse插件形式的建模器
• Activiti probe—管理及監(jiān)控組件

對(duì)流程引擎運(yùn)行期實(shí)例提供管理及監(jiān)控的Web控制臺(tái)。包含部署的管理、流程定義的管理、數(shù)據(jù)庫(kù)表的檢視、日志查看、事務(wù)的平均執(zhí)行時(shí)間、失敗多次的工作等功能。

• Activiti Explorer—任務(wù)管理組件

提供任務(wù)管理功能和對(duì)案例、任務(wù)基于歷史數(shù)據(jù)的統(tǒng)計(jì)分析（報(bào)表）功能。Web應(yīng)用程序。

內(nèi)容存儲(chǔ)工具：包括了文檔倉(cāng)庫(kù)、模型倉(cāng)庫(kù)、SVN倉(cāng)庫(kù)、MVN倉(cāng)庫(kù)和Activiti引擎。其中文檔倉(cāng)庫(kù)、SVN倉(cāng)庫(kù)和MVN倉(cāng)庫(kù)三個(gè)組件為協(xié)作工具（Activiti Cycle）提供底層的支撐。Activiti引擎則是以前的PVM。

協(xié)作工具：與jBPM4相比，Activiti5最令人矚目的特性就在于它的協(xié)作工具組件。

Activiti Cycle完全是一種新類型的BPM組件。它是一個(gè)用來(lái)促進(jìn)業(yè)務(wù)人員、開發(fā)人員和IT運(yùn)營(yíng)人員協(xié)作的Web應(yīng)用程序。 在現(xiàn)實(shí)的場(chǎng)景中，業(yè)務(wù)文檔有業(yè)務(wù)人員所持有，而軟件程序由開發(fā)團(tuán)隊(duì)所管理，被部署的軟件應(yīng)用則被IT管理人員所管理。三者之間不能很好的協(xié)作。我們可以想 象這樣一個(gè)場(chǎng)景，業(yè)務(wù)經(jīng)理用文檔來(lái)維護(hù)需求和visio格式的流程圖，開發(fā)人員管理可執(zhí)行的流程和大量的Java源文件而IT維護(hù)人員則管理部署在 Tomcat中的.war文件和存儲(chǔ)在Activiti數(shù)據(jù)庫(kù)中的流程。

圖 6：Activiti cycle協(xié)作組件邏輯示意圖

Activiti Cycle通過(guò)BusinessLink將與流程相關(guān)的業(yè)務(wù)人員、開發(fā)團(tuán)隊(duì)與IT維護(hù)人員關(guān)聯(lián)起來(lái)，實(shí)現(xiàn)他們之間的協(xié)作。

總而言之，與jBPM4相比，Activiti5目前最重要的增強(qiáng)就是實(shí)現(xiàn)了流程的可視化以及創(chuàng)新的Activiti Cycle協(xié)作組件，此外，通過(guò)與Mule的集成加強(qiáng)了其集成能力。其對(duì)PVM的保留使其繼承了jBPM4強(qiáng)大的可擴(kuò)展能力，對(duì)jBPM的老用戶來(lái)說(shuō)，這是向其遷移的重要理由。

七、總結(jié)

jBPM3是一個(gè)完整的工作流系統(tǒng)實(shí)現(xiàn)，面向開發(fā)人員，目的在于簡(jiǎn)化對(duì)組織核心流程進(jìn)行支撐的軟件創(chuàng)建，不支持標(biāo)準(zhǔn)。

jBPM4引入PVM，使其擁有更強(qiáng)大的擴(kuò)展性，同時(shí)增加BPMS特性，這些特性包括了對(duì)BPMN的支持、面向業(yè)務(wù)人員的Web建模器和簡(jiǎn)單統(tǒng)計(jì)分析功能的加入。

jBPM5基于原先的Drools Flow，支持BPMN，通過(guò)與Drools的合并支持BAM，通過(guò)內(nèi)容倉(cāng)庫(kù)增加對(duì)流程可視化的支持。由于放棄了jBPM4的PVM，引擎的可擴(kuò)展性受到損害，并且不再支持jPDL。

Activiti5基于jBPM4，與Alfresco的集成增加了其流程可視化與管理能力，同時(shí)通過(guò)創(chuàng)新的Activiti Cycle協(xié)作組件支持流程相關(guān)人員之間的協(xié)調(diào)，最后，它加強(qiáng)了集成能力。

對(duì)于工作流應(yīng)用或者jBPM3、jBPM4的老用戶，建議轉(zhuǎn)向Activiti5。

關(guān)于作者

榮浩，ThoughtWorks咨詢師，關(guān)注敏捷和企業(yè)流程改進(jìn)過(guò)程，目前正與辛鵬合著《Head First Process-深入淺出IT流程》一書。博客地址http://ronghao.javaeye.com。

轉(zhuǎn)自：http://www.infoq.com/cn/articles/rh-jbpm5-activiti5

有很多理由都能說(shuō)明為什么我們應(yīng)該寫出清晰、可讀性好的程序。最重要的一點(diǎn)，程序你只寫一次，但以后會(huì)無(wú)數(shù)次的閱讀。當(dāng)你第二天回頭來(lái)看你的代碼 時(shí)，你就要開始閱讀它了。當(dāng)你把代碼拿給其他人看時(shí)，他必須閱讀你的代碼。因此，在編寫時(shí)多花一點(diǎn)時(shí)間，你會(huì)在閱讀它時(shí)節(jié)省大量的時(shí)間。

讓我們看一些基本的編程技巧：

1. 盡量保持方法簡(jiǎn)短
2. 永遠(yuǎn)永遠(yuǎn)不要把同一個(gè)變量用于多個(gè)不同的目的
3. 使用自描述的變量名和方法名
4. 盡可能的把變量定義在靠近使用它的地方
5. 拒絕神秘?cái)?shù)字
6. 友好的對(duì)待你的語(yǔ)言
7. 不要逆常規(guī)而行
8. 警惕過(guò)早優(yōu)化
9. 積極重構(gòu)測(cè)試過(guò)的程序
10. 不要過(guò)度沉迷于技巧
11. 通過(guò)習(xí)例學(xué)習(xí)新知

現(xiàn)在，讓我們把每個(gè)小點(diǎn)展開來(lái)詳細(xì)講一下。

1. 盡量保持方法簡(jiǎn)短

盡管很多人都遵循這個(gè)規(guī)則，但它仍然非常的重要。你寫的方法要始終能在一個(gè)屏幕里放得下。如果你需要去滾動(dòng)屏幕，這會(huì)分散你的注意力，而且你看不到 整個(gè)的上下文。最佳長(zhǎng)度是5-20行，這根據(jù)你的情況而定。當(dāng)然，getters/setters 通常是一行代碼的方法，但與其說(shuō)它們是真正的方法，不如說(shuō)它們只是存取工具。

2. 永遠(yuǎn)永遠(yuǎn)不要把同一個(gè)變量用于多個(gè)不同的目的

一個(gè)變量應(yīng)該始終只為一個(gè)目的服務(wù)。通過(guò)使變量常量化(C++里的const， Java里的final)，使得編譯器能夠優(yōu)化編譯，而且使你的代碼醒目表達(dá)這個(gè)變量是不能改變的，你的程序的可讀性會(huì)變得更好。

3. 使用自描述的變量名和方法名

你的代碼應(yīng)該，對(duì)于任何人來(lái)說(shuō)，只要看一眼就能知道是干嘛的。盡量不要用簡(jiǎn)寫方式，除非有特殊的習(xí)慣，就像下面的：

 src - source
 pos - position
 prev - previous

如果你認(rèn)為描述性的名稱并不是那么有價(jià)值，請(qǐng)對(duì)比一下n, ns, nsisd 和 numTeamMembers, seatCount, numSeatsInStadium。

4. 盡可能的把變量定義在靠近使用它的地方

蓋房子時(shí)，你可不希望把錘子放到別人的院子里。你希望把它們放的離手頭越近越好。定義變量也是同樣的道理。

int foo = 3;
int bar = 5;
// 一大段使用“bar”的代碼，
// 但沒用到“foo”
// ...

baz(foo);

這段代碼可以簡(jiǎn)單的重構(gòu)成

int bar = 5;
// 一大段使用“bar”的代碼，
// 但沒用到“foo”
// ...

int foo = 3;
baz(foo);

當(dāng)你把變量的聲明和第一次用到它的地方間隔太遠(yuǎn)時(shí)(距離超過(guò)一個(gè)屏幕)，這確實(shí)會(huì)成為一個(gè)問(wèn)題。記住上下文關(guān)系會(huì)變得困難，你需要滾動(dòng)屏幕去找哪來(lái)的這個(gè)變量。

5. 拒絕神秘?cái)?shù)字

當(dāng)你要把什么東西跟一個(gè)常量值做比較時(shí)，記得把這個(gè)值定義成常量。沒有什么會(huì)比去猜測(cè)你的同事寫的這樣的代碼更讓人頭疼的事了：

il < 4384

換個(gè)形式感覺如何？

inputLength < MAX_INPUT_LENGTH

6. 友好的對(duì)待你的語(yǔ)言

學(xué)習(xí)新語(yǔ)言是一種很有樂(lè)趣的事情，你能學(xué)到一種新的完成任務(wù)的途徑。當(dāng)一個(gè)對(duì)一種語(yǔ)言已經(jīng)很專業(yè)的人去學(xué)習(xí)另一種語(yǔ)言時(shí)，會(huì)出現(xiàn)一種很大的負(fù)面效應(yīng)。比如說(shuō)你是一個(gè)Java開發(fā)者，試圖去學(xué)習(xí)Ruby。你應(yīng)該學(xué)會(huì)用Ruby的方式解決問(wèn)題，而不是沿用Java的解決問(wèn)題的思想。

當(dāng)你需要重復(fù)5遍”Hello world！“時(shí)，在Java里，你可能會(huì)這樣做：

for (int i = 0; i < 5; i++) {
    System.out.println("Hello world!");
}

在Ruby里，你也許會(huì)禁不住這樣寫：

for i in (0..5)
  puts "Hello world!"
end

這樣看起來(lái)沒問(wèn)題，但有一個(gè)更好的方式：

5.times { puts "Hello world!" }

7. 不要逆常規(guī)而行

每種語(yǔ)言都有自己不同的習(xí)俗約定。一般來(lái)說(shuō)，人們聽的最多的是Java的編碼規(guī)范。讓我們看看其中的一些習(xí)俗規(guī)范：

• 方法名應(yīng)該小寫字母開頭，其后用字母大寫的單詞連接(veryLongVariableName)
• 類名應(yīng)該都使用首字母大寫的單詞連接而成
• 常量名應(yīng)該全部大寫，用下劃線連接(MY_CONSTANT)
• 左大括號(hào)應(yīng)該跟 if 語(yǔ)句在同一行

只有在有必要的理由時(shí)才去打破這些常規(guī)，不要輕易的因?yàn)槟悴桓吲d就違反它。如果你只是在團(tuán)隊(duì)里改變一些這樣的習(xí)慣，那也沒問(wèn)題，但當(dāng)把你代碼拿出來(lái)和其他的沒有這些思想準(zhǔn)備的程序員共享時(shí)，問(wèn)題就會(huì)來(lái)了。

8. 警惕過(guò)早優(yōu)化

過(guò)早優(yōu)化是所有問(wèn)題的根源，至少電視上是這么說(shuō)的 … 你第一應(yīng)該關(guān)心的事情是寫出易于理解的代碼。起初寫的程序不要求快。除非你的程序很慢，否則談優(yōu)化都是為時(shí)太早。如果你想優(yōu)化什么東西，你首先需要知道問(wèn)題出在哪。這就是我們需要profilers這個(gè)工具的原因。

在沒有知道問(wèn)題在哪的情況下試圖對(duì)程序進(jìn)行優(yōu)化，其結(jié)果必然是把程序能壞，至少你的代碼會(huì)喪失可讀性。如果你覺得有些地方很慢，不要盲目的重寫代碼，你應(yīng)先找到慢的證據(jù)。

不要傻乎乎的去解決根本不存在的問(wèn)題。

9. 積極重構(gòu)測(cè)試過(guò)的程序

沒有任何東西會(huì)是完美的。即使你感覺你真正寫出了一段完美的代碼，幾個(gè)月后回頭再看看，你可能會(huì)驚訝道”怎么會(huì)這樣傻？“

改進(jìn)程序的一個(gè)好方法就是重構(gòu)，但要等程序測(cè)試通過(guò)之后。你首先要確保程序是好的可運(yùn)行的，你可以通過(guò)自動(dòng)化測(cè)試或手工測(cè)試完成這個(gè)工作。

之初，你需要的是程序可用。不要期望在第一次就寫出完美的程序，你只需要把它寫出來(lái)，可用。然后重構(gòu)它，使之完美。對(duì)于你們當(dāng)中知道測(cè)試驅(qū)動(dòng)開發(fā) (TDD)的人來(lái)說(shuō)，對(duì)這個(gè)會(huì)很熟悉。這里的關(guān)鍵就在于你要習(xí)慣于重構(gòu)這種事情。如果你使用的是像IntelliJ IDEA這樣強(qiáng)大的集成開發(fā)工具的話，重構(gòu)的工作會(huì)變得簡(jiǎn)單的多。

重構(gòu)之后，你也許會(huì)弄出一些Bug，導(dǎo)致某些功能出問(wèn)題。這就是為什么說(shuō)寫自動(dòng)化測(cè)試的原因。不論何時(shí)重構(gòu)后，只要運(yùn)行一下所有的測(cè)試用例，你就能準(zhǔn)確的知道什么地方出了問(wèn)題。

10. 不要過(guò)度沉迷于技巧

當(dāng)我第一次讀到有關(guān)設(shè)計(jì)模式的知識(shí)時(shí)，我覺得我找到了圣杯。這些精心設(shè)計(jì)的思想作用顯著，它能使你的設(shè)計(jì)易于理解，因?yàn)槟憧梢院?jiǎn)單的說(shuō)”我使用的是 ‘觀察器模式’“，而不用從頭到尾的解釋一遍。那么，有問(wèn)題嗎？一切看起來(lái)都這么自然、簡(jiǎn)單，你開始不論在哪都使用設(shè)計(jì)模式。為什么不把這個(gè)類做成 singleton呢？干嘛不去再創(chuàng)建一些工廠類呢？

于是一個(gè)80行就能寫完的腳本，你最終使用了10個(gè)類，15個(gè)接口，外加一大堆范式和標(biāo)記符。97%的代碼不做任何事情。設(shè)計(jì)模式是一種十分有用的用來(lái)簡(jiǎn)化你的設(shè)計(jì)的工具，但這不意味著你該在所有能用到的地方都用它。你應(yīng)該用它們，但不能濫用。

11. 通過(guò)習(xí)例學(xué)習(xí)新知

編程是一種學(xué)習(xí)新知的過(guò)程。當(dāng)你學(xué)到了新的程序庫(kù)或新語(yǔ)言，你可能會(huì)迫不及待的丟掉舊的代碼，用你新學(xué)到的東西重新寫一遍。有很多的理由都能說(shuō)明你不該這么做。

往現(xiàn)有的應(yīng)用里增加新的類庫(kù)或框架同屬于這種情況。就說(shuō)你寫了一個(gè)Javascript的web應(yīng)用，期間，你發(fā)現(xiàn)了jQuery。現(xiàn)在你突然急切的想丟到你的Javascript程序，重新用jQuery寫，盡管你還從來(lái)沒用過(guò)它。

最好的方式是你先用jQuery寫一些簡(jiǎn)單的例子，通過(guò)這種方式把你在應(yīng)用里將要用到的知識(shí)都學(xué)會(huì)。需要AJAX？在你的項(xiàng)目之外做一些小例子，當(dāng)完全弄懂了后，丟掉例子，應(yīng)用到你的產(chǎn)品里。

如果你非常關(guān)注編程技術(shù)，我強(qiáng)烈的推薦你閱讀Steve McConnell寫的 《代碼大全》 一書。它會(huì)永遠(yuǎn)的改變你對(duì)編程的認(rèn)識(shí)。:)

[英文出處]：11 tips for better code

[譯文來(lái)源]：外刊IT評(píng)論

“我說(shuō)我是警察，也是執(zhí)法 人員，應(yīng)該文明執(zhí)法，但還是被打斷腿！”昨天，躺在病床上，昆明市 公安局民警張俊(化名)說(shuō)起事發(fā)當(dāng)天的情形時(shí)，依然有些憤怒！當(dāng)天他接到母親的電話，說(shuō)轄區(qū)城管要強(qiáng)行拆除小區(qū)內(nèi)的違章建筑，讓他回家收拾東西。不料，張 俊剛到門口表明自己身份時(shí)，卻遭到拆遷執(zhí)法人員的圍毆。據(jù)小區(qū)目擊者稱，張俊被毆打時(shí)，對(duì)方揚(yáng)言“打的就是警察！”。

“我還以為身上有警械，就能夠證明自己身份。”昨天下午，在解放軍昆明總醫(yī)院骨科住院部，記者見到了被打傷的張俊，他向記者講述了事發(fā)經(jīng)過(guò)。

“我是警察，也是執(zhí)法人員。”張俊說(shuō)，為了阻止自己被繼續(xù)毆打，他一邊表明自己的身份，一邊準(zhǔn)備從身上掏證件。慌忙中，張俊只摸到了自己隨身攜帶的一根伸縮警棍，這一摸不要緊，更是遭了對(duì)方一頓暴打。

當(dāng) 時(shí)現(xiàn)場(chǎng)執(zhí)法人員叫張俊放下警棍，然后將他的警棍拿走。張俊說(shuō)，第一次被打之后，自己的鼻子和嘴角已經(jīng)被打出血了。但噩運(yùn)還沒有結(jié)束，之后，他被4名城管反 綁著雙手押到鄰居家的門前。他再次向執(zhí)法人員提出要回家收拾東西，但沒有人理他。聽到他的反復(fù)要求后，一名執(zhí)法人員轉(zhuǎn)頭對(duì)他說(shuō)：“你拿警棍打我，怎么可能 讓你上去。”張俊表示，他拿出警棍根本沒有打到人。“我是市公安局的，也是執(zhí)法者，執(zhí)法要文明。”張俊說(shuō)完時(shí)就聽到對(duì)方一句狂噴：“你敢用手指頭指我，兄 弟們，拿下。”

張俊說(shuō)，他只感覺周圍的20多名城管全部圍了上來(lái)，用警棍和鐵棍將他打倒在地，還有人上前用腳踩他。當(dāng)時(shí)他感覺自己的右腿很疼，他大聲懇求：“求求你們別打了，我的腿斷了。”隨后，他被打暈在地。

現(xiàn) 場(chǎng)很多小區(qū)業(yè)主都目睹了張俊被毆打的過(guò)程，“總共被打了兩次。”張俊的鄰居老邢說(shuō)。同樣目睹事情經(jīng)過(guò)的程先生也說(shuō)，張俊大概被毆打了10多分鐘，他遠(yuǎn)遠(yuǎn)看 著張俊滿臉都是血，倒在地上。他聽到在場(chǎng)的一位執(zhí)法人員對(duì)著幾乎快暈厥過(guò)去的張俊喊道：“裝死。”張俊的好友陳小姐說(shuō)，現(xiàn)場(chǎng)就有執(zhí)法人員帶去的救護(hù)車，但 沒有對(duì)他進(jìn)行救治。

而對(duì)此，當(dāng)時(shí)執(zhí)法拆除違章建筑的昆明市綜合行政執(zhí)法局盤龍分局負(fù)責(zé)人稱，是張俊先揮舞警棍導(dǎo)致沖突發(fā)生。

據(jù)知情人稱，事件發(fā)生之后，已經(jīng)有一名參與沖突的執(zhí)法隊(duì)長(zhǎng)被拘留，但此說(shuō)法未得到有關(guān)部門的證實(shí)。

轉(zhuǎn)自：http://news.qq.com/a/20110103/000492.htm?qq=0&ADUIN=845765&ADSESSION=1294033435&ADTAG=CLIENT.QQ.3187_.0

過(guò)去與今天
詞 \ 黃家駒. 曲 \ 黃家駒. 主唱 \ 黃家駒.

夜雨街中里寧與靜
霧色燈影照我身
在我的心里常會(huì)問(wèn)
幻變的都市四周
可知我已放棄舊日的理想
知否我也有個(gè)夢(mèng) 要我醉倒
就像 就像 就像
像那方的星光閃動(dòng) 眼也會(huì)發(fā)光
仰望浮云常變不定 暗里嘆一聲
沖出他朝崎嶇道上 哪怕會(huì)退倒
試問(wèn)誰(shuí)人曾會(huì)考慮 過(guò)去與今天
踏破這黑暗寧與靜
誰(shuí)會(huì)管失意冷風(fēng)
幻變的都市誰(shuí)問(wèn)過(guò)
讓暖風(fēng)緊靠我身

EverBox 是一款由盛大創(chuàng)新院推出的網(wǎng)盤產(chǎn)品，提供數(shù)據(jù)存儲(chǔ)和同步服務(wù)。EverBox 提供了 10GB 超大免費(fèi)存儲(chǔ)空間，支持文件同步、文件分享、在線瀏覽照片、在線聽音樂(lè)等功能，并支持?jǐn)?shù)據(jù)同步客戶端。需要邀請(qǐng)的朋友可以改我留言 :-)

主要功能：

支持?jǐn)?shù)據(jù)同步客戶端：安裝 EverBox后，您所需的文件都將自動(dòng)同步到設(shè)備上，可以隨時(shí)、隨地的使用手邊的任意一款設(shè)備訪問(wèn)文件了。目前提供了 Windows 客戶端程序，支持 Windows XP，Windows Vista 和 Windows 7。在以后的版本中，EverBox 將會(huì)陸續(xù)推出其他客戶端程序，如： Android，iPhone，iPad，Mac，Linux 等。

容災(zāi)備份服務(wù)：EverBox 會(huì)自動(dòng)的、實(shí)時(shí)的備份文件數(shù)據(jù)到 EverBox 安全服務(wù)器，因此，當(dāng)您本地的設(shè)備壞損或丟失時(shí)，不必?fù)?dān)心由于數(shù)據(jù)丟失造成的損失，恢復(fù)數(shù)據(jù)易如反掌！

在線音樂(lè)播放：EverBox 支持在線音樂(lè)播放功能，幾乎支持所有常用的音頻格式，使用簡(jiǎn)單、便捷，無(wú)需操作即可連續(xù)播放 EverBox 當(dāng)前目錄中的歌曲，很適于一邊使用電腦一邊聽歌時(shí)使用。

在線瀏覽圖片：EverBox 支持在線瀏覽圖片功能，幾乎支持所有常用的圖片格式，操作簡(jiǎn)單、便捷，并支持自動(dòng)播放 EverBox 當(dāng)前目錄中的圖片文件。

EverBox 功能特性

1. 10GB 超大免費(fèi)空間

   成功注冊(cè) EverBox 即可獲得 2GB 免費(fèi)空間，完成指定任務(wù)可升級(jí)空間到 10GB！EverBox 在隨后的版本中將會(huì)有更多的獎(jiǎng)勵(lì)措施，贈(zèng)送活躍用戶更多空間，敬請(qǐng)期待！

   

2. 支持?jǐn)?shù)據(jù)同步客戶端

   您是不是經(jīng)常遇到以下的情況？“我喜歡在外出時(shí)用 iPhone 聽歌，但是我需要從 PC 下載歌曲再用數(shù)據(jù)線將 MP3 導(dǎo)到 iPhone”；“我經(jīng)常出差，但是程序和文件都在笨重的 PC 上，而我只帶著筆記本”；“我到 XX 會(huì)議做演講，但是保存 PPT 的 U 盤壞掉了”。

   現(xiàn)在有了 EverBox，這些問(wèn)題將迎刃而解！只需安裝 EverBox，您所需的文件都將自動(dòng)同步到設(shè)備上，您就可以隨時(shí)、隨地的使用手邊的任意一款設(shè)備訪問(wèn)文件了。當(dāng)然，使用瀏覽器一樣可以訪問(wèn)到您需要的文件。

   

3. 容災(zāi)備份服務(wù)

   硬盤損壞？數(shù)據(jù)無(wú)法訪問(wèn)？筆記本電腦被盜？完了，重要的數(shù)據(jù)丟失了！

   不用擔(dān)心，有了 EverBox，這一切都不會(huì)再是問(wèn)題。EverBox 會(huì)自動(dòng)的、實(shí)時(shí)的備份文件數(shù)據(jù)到 EverBox 安全服務(wù)器，因此，當(dāng)您本地的設(shè)備壞損或丟失時(shí)，不必?fù)?dān)心由于數(shù)據(jù)丟失造成的損失，恢復(fù)數(shù)據(jù)易如反掌！

   

4. 在線音樂(lè)播放

   EverBox 支持在線音樂(lè)播放功能，幾乎支持所有常用的音頻格式，使用簡(jiǎn)單、便捷，無(wú)需操作即可連續(xù)播放 EverBox 當(dāng)前目錄中的歌曲，很適于一邊使用電腦一邊聽歌時(shí)使用。

   

5. 在線瀏覽圖片

   EverBox 支持在線瀏覽圖片功能，幾乎支持所有常用的圖片格式，操作簡(jiǎn)單、便捷，并支持自動(dòng)播放 EverBox 當(dāng)前目錄中的圖片文件。

   

    

GAE 博客 —— B³LOG Solo 0.2.5 Beta1 發(fā)布了。

該版本除了修復(fù) Bugs，還增加了草稿夾、多人寫作、改進(jìn)了緩存，以及加入了新皮膚 community。

借此機(jī)會(huì)，祝大家圣誕節(jié)愉快，一切平安 :-)

新特性

• 多人寫作
• 鏈接排序
• 新皮膚——community（多人寫作皮膚）

Bug 修復(fù)

• 緩存多實(shí)例不一致
• 文章訪問(wèn)次數(shù)統(tǒng)計(jì)失效
• IE8 下 Feed 不能顯示

改進(jìn)

• 存儲(chǔ)對(duì)象緩存
• 自定義頁(yè)面排序方式
• 改進(jìn)了頁(yè)面緩存

具體改動(dòng)看這里。

升級(jí)

如果您是 0.2.1 的用戶，那么請(qǐng)?jiān)诓渴鹜?0.2.5 Beta1 后登錄后臺(tái)，訪問(wèn) http://${application-id}.appspot.com/upgrade/v021-v025.do 進(jìn)行升級(jí)。

項(xiàng)目

如果在使用、測(cè)試中發(fā)現(xiàn)任何問(wèn)題，如果您有任何意見或建議，請(qǐng)告知我們 :-)

• 項(xiàng)目地址：http://code.google.com/p/b3log-solo/
• 下載：http://b3log-solo.googlecode.com/files/b3log-solo-0.2.5-beta1.zip
• Bug/特性提交：http://code.google.com/p/b3log-solo/issues/list

發(fā)布計(jì)劃

• 2011 年 1 月 21 日發(fā)布 0.2.5 Beta2
• 2011 年 2 月 14 日發(fā)布 0.2.5

作者博客

• 簡(jiǎn)約設(shè)計(jì)の藝術(shù)
• Vanessa
• 羔羊<>沉默

發(fā)布?xì)v史

1. GAE 博客——B3log Solo 0.2.1 發(fā)布了！
2. GAE 博客——B3log Solo 0.2.0 發(fā)布了！
3. GAE 博客——B3log Solo 0.1.1 發(fā)布了！
4. B3log Solo 0.1.0 發(fā)布了！
5. B3log Solo 0.1.0-preview2 發(fā)布了！
6. Solo 0.1.0-Preview1 發(fā)布了

最近一個(gè)潛在客戶要求我們比較一下 Amazon EC2 和 Google App Engine，正好我們剛剛在 EC2 和 Google App Engine 上完成了兩個(gè)相對(duì)來(lái)說(shuō)規(guī)模較大的項(xiàng)目，因此有必要做一下總結(jié)。

我打算從三個(gè)角度來(lái)對(duì)比這兩大云計(jì)算平臺(tái)：技術(shù)，業(yè)務(wù)和未來(lái)發(fā)展趨勢(shì)，本文是技術(shù)方面的對(duì)比，ok，準(zhǔn)備好咖啡，我們開始吧！

如果按平臺(tái)類型來(lái)分，大家可能已經(jīng)知道Google App Engine屬于PaaS（平臺(tái)即服務(wù)），而Amazon EC2屬于IaaS（基礎(chǔ)設(shè)施即服務(wù)），Amazon EC2給你一個(gè)安裝了操作系統(tǒng)的“盒子”，你可以自己安裝應(yīng)用程序，也可以使用AMI（Amazon Machine Image），如果你想構(gòu)建一個(gè)高度復(fù)雜的定制應(yīng)用，Amazon EC2是不二之選，它允許你控制環(huán)境參數(shù)，底層操作系統(tǒng)，存儲(chǔ)和網(wǎng)絡(luò)需求，從技術(shù)上講，它屬于很底層的服務(wù)，你可以調(diào)整你需要的大部分東西。

Google App Engine給你一個(gè)完整的平臺(tái)，包括完整的SDK（以及Eclipse插件）和服務(wù)，你可以構(gòu)建和部署你自己的應(yīng)用程序，但你不能很好地控制操作系統(tǒng)， 硬件和存儲(chǔ)，諸如寫文件系統(tǒng)，使用線程等操作都有限制，這樣設(shè)計(jì)的目的是為了確保平臺(tái)不會(huì)被某個(gè)應(yīng)用程序綁架。

簡(jiǎn)單起來(lái)就是：

IaaS：原始硬件（處理器，網(wǎng)絡(luò)和存儲(chǔ)）

PaaS：操作系統(tǒng)，系統(tǒng)軟件，開發(fā)框架和虛擬機(jī)。

下面從技術(shù)角度來(lái)比較一下這兩個(gè)平臺(tái)。

1、提供的服務(wù)

Google App Engine憑借豐富的服務(wù)擊敗Amazon EC2，Google App Engine提供的服務(wù)可以讓開發(fā)人員快速進(jìn)入開發(fā)狀態(tài)。如 Blobstore，Images，Mail，Memcache，Multitenancy，Oauth，Task Queues，URL Fetch，Users，XMPP這些服務(wù)在Amazon EC2上是需要自己安裝的，為了便于比較，假設(shè)你已經(jīng)為Memcache，Mail和多租戶搭建好了基礎(chǔ)設(shè)施，看看在EC2上你用了多長(zhǎng)時(shí)間安裝，我敢打 賭你會(huì)超過(guò)一個(gè)小時(shí)，使用Google App Engine時(shí)，這些服務(wù)都是現(xiàn)成的，就象果盤中插好牙簽的水果一樣，你可以隨時(shí)享用。

2、管理

Google App Engine再次勝出，因?yàn)橐坏┠愕膽?yīng)用程序部署成功后，它幾乎不需要管理，當(dāng)你的應(yīng)用程序負(fù)載變大時(shí)，你不需要向服務(wù)注入新的實(shí)例，Google App Engine可以自由擴(kuò)大負(fù)載能力，新實(shí)例是實(shí)時(shí)剝離的。使用Amazon EC2時(shí)，你必須時(shí)刻跟蹤通信流量（現(xiàn)在可以通過(guò)腳本自動(dòng)跟蹤了），新實(shí)例是在你的配置基礎(chǔ)上剝離的，因此，如果我的峰值負(fù)載是2x+y，那么需要?jiǎng)冸x2 個(gè)以上的應(yīng)用程序服務(wù)器。

此外，使用Google App Engine升級(jí)應(yīng)用程序服務(wù)器實(shí)例，安裝新的負(fù)載均衡器時(shí)，沒有管理開銷，這一切都是自動(dòng)執(zhí)行的。

3、抽象水平

和上一條聯(lián)系緊密的是抽象水平，Google App Engine抽象得比較好，你只需要關(guān)心你的應(yīng)用程序和業(yè)務(wù)邏輯，不用擔(dān)心底層基礎(chǔ)設(shè)施的管理，正如Nick Johnson所說(shuō)的那樣，抽象水平應(yīng)作為挑選云計(jì)算平臺(tái)的一個(gè)基本原則，你需要做的是駕駛，不需要研究引擎蓋以下的東西。在我看來(lái)，如果你的核心業(yè)務(wù)是 貨物運(yùn)輸，那么你應(yīng)該買一輛卡車，它能高效地把你的貨物從A地運(yùn)輸?shù)紹地，相反，你不應(yīng)該考慮如何購(gòu)買零部件自己組裝一輛卡車。

在軟件開發(fā)領(lǐng)域，我們看到有Grails，RoR等框架，它們大受歡迎，是因?yàn)樗鼈兲峁┝烁咚降某橄螅绻闶且幻嗤呓常鼈兙拖笫悄_手架，你可以踩在它們上面干你的工作。

4、可靠性

從我個(gè)人的認(rèn)識(shí)來(lái)講，兩者都很可靠，這一點(diǎn)從它們的用戶數(shù)量就可以知道一二，用戶可以時(shí)刻查看Google App Engine的狀態(tài)，它是透明的，但從歷史數(shù)據(jù)來(lái)看，Amazon EC2的正常運(yùn)行時(shí)間比Google App Engine要好。

5、可移植性

從使用的底層操作系統(tǒng)和開發(fā)框架來(lái)看，Amazon EC2具有更好的可移植性，但也不要擔(dān)心你會(huì)被Google App Engine給鎖住，Google已經(jīng)給出了遷移指南，指導(dǎo)你如何從轉(zhuǎn)移出Google App Engine平臺(tái)，當(dāng)然包含你所有的數(shù)據(jù)在內(nèi)。還有AppScale這樣的程序可以幫助你將Google App Engine上的程序轉(zhuǎn)移到Amazom EC2或其它云平臺(tái)上，AppScale已經(jīng)可以支持EC2，Eucalyptus，Xen和KVM。

6、存儲(chǔ)

Google App Engine目前嚴(yán)重依賴于BigTable，開發(fā)人員需要從一個(gè)完全不同的角度來(lái)認(rèn)識(shí)和學(xué)習(xí)它，特別是對(duì)于那些特熟悉關(guān)系數(shù)據(jù)庫(kù)，被關(guān)系數(shù)據(jù)庫(kù)理論束縛 的人更需要洗洗腦，它提供了一個(gè)JPA&JDO訪問(wèn)接口，但它不支持所有的JPA&JDO功能，特別是關(guān)系部分，Google最近也高調(diào) 宣布要讓Google App Engine支持傳統(tǒng)的SQL數(shù)據(jù)庫(kù)。Amazon EC2已經(jīng)支持SQL數(shù)據(jù)庫(kù)，你可以使用Oracle，MySQL等你所熟悉的關(guān)系數(shù)據(jù)庫(kù)。

7、應(yīng)用程序維護(hù)和升級(jí)

對(duì)Google App Engine來(lái)說(shuō)，應(yīng)用程序維護(hù)和升級(jí)是件輕而易舉的事，它為各種應(yīng)用程序提供了一個(gè)詳細(xì)的管理面板，包括日志查看器和數(shù)據(jù)查看器，一個(gè)程序可以有多個(gè)版 本，當(dāng)新版本經(jīng)過(guò)測(cè)試，可以用于生產(chǎn)環(huán)境時(shí)，你可以將其設(shè)為默認(rèn)的版本，而Amazon EC2就麻煩多了，因?yàn)樗鼘儆贗aaS類型，所有維護(hù)和升級(jí)相關(guān)的事情你必須親力親為。

8、開發(fā)限制

使用Google App Engine時(shí)，你必須受到平臺(tái)的限制，如果你的查詢處于僵死狀態(tài)，很難將其殺掉，此外，Google App Engine沒有線程，提供的SDK也是受限的，有些類和功能被列入黑名單，因此不能被使用，也不能寫文件系統(tǒng)等等。

從表面上看這些限制是不可理喻的，但如果有朝一日你也要提供PaaS類型的平臺(tái)時(shí)，你就能理解為什么Google要做這些限制了，這樣才能確保運(yùn)行 在平臺(tái)上的應(yīng)用程序不會(huì)違反平臺(tái)的規(guī)則，否則平臺(tái)就可能被應(yīng)用程序綁架，從而變得不可使用，平臺(tái)上的其它應(yīng)用程序就會(huì)收到牽連。

即便有這些限制，90%的商業(yè)應(yīng)用程序仍然可以在Google App Engine上正常運(yùn)行，但對(duì)于那些要使用線程，或?qū)懳募到y(tǒng)的應(yīng)用，最好還是選擇Amazon EC2，因?yàn)樗峁┝怂械讓釉L問(wèn)和控制權(quán)。

9、語(yǔ)言支持

截至目前，Google App Engine支持Java和Python，但任何可以轉(zhuǎn)換成字節(jié)碼，可在JVM上執(zhí)行的任何編程語(yǔ)言都可以在Google App Engine上運(yùn)行，如果你喜歡其它編程語(yǔ)言，最好選擇Amazon EC2，因?yàn)槟憧梢栽谒牟僮飨到y(tǒng)上面安裝語(yǔ)言運(yùn)行時(shí)環(huán)境，你擁有幾乎完整的硬件和操作系統(tǒng)控制權(quán)，還有什么不能做的呢？在Amazon EC2上也托管了許多有趣的C#，.NET，ASP.NET MVC/Visual Studio項(xiàng)目，具有諷刺意味著的是，盡管還有Microsoft Azure，但許多以MS技術(shù)開發(fā)的項(xiàng)目卻托管在Amazon EC2上。

概括地說(shuō)，Amazon EC2是進(jìn)入云計(jì)算的早期嘗試者，它利用互聯(lián)網(wǎng)標(biāo)準(zhǔn)和開放平臺(tái)創(chuàng)建了一個(gè)非常靈活的云計(jì)算平臺(tái)，Google則利用了它在大型數(shù)據(jù)庫(kù)方面的研究成果和它內(nèi) 部實(shí)現(xiàn)的一些技術(shù)創(chuàng)建了一個(gè)強(qiáng)大，但有更多限制的云計(jì)算環(huán)境。從核心技術(shù)來(lái)講，Amazon EC2允許你擴(kuò)展任何計(jì)算機(jī)實(shí)例到多個(gè)實(shí)例，因此你擁有每個(gè)虛擬盒子的完全控制權(quán)，Google App Engine從操作系統(tǒng)抽象而來(lái)，沒有計(jì)算機(jī)實(shí)例的概念，如果你的Web應(yīng)用程序不需要操作系統(tǒng)相關(guān)的功能，那么Google App Engine無(wú)疑是最好的選擇，如果需要更好地控制你的系統(tǒng)環(huán)境，特別是操作系統(tǒng)相關(guān)的控制，那么最好選擇Amazon EC2。

原文名：Comparing Google App Engine and Amazon EC2 on Technology 作者：Vikas Hazrati

不出意料地，他得到了一大堆回答。

通常情況下，你需要把所有人的發(fā)言從頭到尾讀一遍。但是，Stack Overflow有一個(gè)很貼心的設(shè)計(jì)，它允許在問(wèn)題下方開設(shè)一個(gè)wiki區(qū)，讓所有人共同編輯一個(gè)最佳答案。于是，就有了下面這篇文章，一共總結(jié)出六個(gè)方面共計(jì)61條"網(wǎng)站開發(fā)須知"。

我發(fā)現(xiàn)，這種概述性的問(wèn)題，最適合這種集合群智、頭腦風(fēng)暴式的回答方式了。這也是我第一次覺得，Stack Overflow做到了Wikipedia做不到的事。（難怪它最近擠進(jìn)了全美前400大網(wǎng)站。）

在我的印象中，關(guān)于網(wǎng)站開發(fā)，這樣全面的概述性文章非常少見，因此也就非常有用。大家不妨看看，61件事情中你做到了多少？

（更新：剛剛發(fā)現(xiàn)，一共應(yīng)該是62條建議，我先前數(shù)錯(cuò)了，這個(gè)......太窘了。）

=============================

網(wǎng)站開發(fā)人員應(yīng)該知道的61件事

原文網(wǎng)址：http://stackoverflow.com/questions/72394

譯者：阮一峰

一、界面和用戶體驗(yàn)（Interface and User Experience）

1.1

知道各大瀏覽器執(zhí)行Web標(biāo)準(zhǔn)的情況，保證你的站點(diǎn)在主要瀏覽器上都能正常運(yùn)行。你至少要測(cè)試以下引擎：Gecko（用于Firefox）、Webkit（用于Safari、Chrome和一些手機(jī)瀏覽器）、IE（你可以利用微軟發(fā)布的Application Compatibility VPC Images進(jìn)行測(cè)試）和Opera。同時(shí)，不同的操作系統(tǒng)，可能也會(huì)影響瀏覽器如何呈現(xiàn)你的網(wǎng)站。

1.2

除了瀏覽器，網(wǎng)站還有其他使用方式：手機(jī)、屏幕朗讀器、搜索引擎等等。你應(yīng)該知道在這些情況下，你的網(wǎng)站的運(yùn)行狀況。MobiForge提供了手機(jī)網(wǎng)站開發(fā)的一些相關(guān)知識(shí)。

1.3

知道如何在基本不影響用戶使用的情況下升級(jí)網(wǎng)站。通常來(lái)說(shuō)，你必須有版本控制系統(tǒng)（CVS、Subversion、Git等等）和數(shù)據(jù)備份機(jī)制（backup）。

1.4

不要讓用戶看到那些不友好的出錯(cuò)提示。

1.5

不要直接顯示用戶的Email地址，至少不要用純文本顯示。

1.6

為你的網(wǎng)站設(shè)置一些合理的使用限制，一旦超過(guò)門檻值，就自動(dòng)停止服務(wù)。（這也與網(wǎng)站安全相關(guān)。）

1.7

知道如何實(shí)現(xiàn)網(wǎng)頁(yè)的漸進(jìn)式增強(qiáng)（progressive enhancement）。

1.8

用戶發(fā)出POST請(qǐng)求后，總是將其重導(dǎo)向（redirect）至另外一個(gè)網(wǎng)頁(yè)。

1.9

不要忘記網(wǎng)站的可訪問(wèn)性（accessibility，即殘疾人如何使用網(wǎng)站）。對(duì)于美國(guó)網(wǎng)站來(lái)說(shuō)，有時(shí)這是法定要求。WAI-ARIA有一些這方面很好的參考資料。

二、安全性（Security）

2.1

閱讀《OWASP開發(fā)指南》，它提供了全面的網(wǎng)站安全指導(dǎo)。

2.2

了解SQL注入（SQL injection）及其預(yù)防方法。

2.3

永遠(yuǎn)不要信任用戶提交的數(shù)據(jù)（cookie也是用戶端提交的！）。

2.4

不要明文（plain-text）儲(chǔ)存用戶的密碼，要hash處理后再儲(chǔ)存。

2.5

不要對(duì)你的用戶認(rèn)證系統(tǒng)太自信，它可能很容易就被攻破，而你事先根本沒意識(shí)到存在相關(guān)漏洞。

2.6

了解如何處理信用卡。

2.7

在登錄頁(yè)面及其他處理敏感信息的頁(yè)面，使用SSL/HTTPS。

2.8

知道如何對(duì)付session劫持（session hijacking）。

2.9

避免"跨站點(diǎn)執(zhí)行"（cross site scripting，XSS）。

2.10

避免"跨域偽造請(qǐng)求"（cross site request forgeries，XSRF）。

2.11

及時(shí)打上補(bǔ)丁，讓你的系統(tǒng)始終跟上最新版本。

2.12

確認(rèn)你的數(shù)據(jù)庫(kù)連接信息的安全性。

2.13

跟蹤攻擊技術(shù)的最新發(fā)展，以及你使用的平臺(tái)的最新安全漏洞。

2.14

閱讀Google的《瀏覽器安全手冊(cè)》（Browser Security Handbook）。

2.15

閱讀《網(wǎng)絡(luò)軟件的黑客手冊(cè)》（The Web Application Hackers Handbook）。

三、性能（Performance）

3.1

只要有可能，就使用緩存（caching）。正確理解和使用HTTP caching與HTML5離線儲(chǔ)存。

3.2

優(yōu)化圖片。不要把一個(gè)20KB的圖片文件，作為重復(fù)出現(xiàn)的網(wǎng)頁(yè)背景圖案。

3.3

學(xué)習(xí)如何用gzip/deflate壓縮內(nèi)容（deflate方式更可取）。

3.4

將多個(gè)樣式表文件或腳本文件，合為一個(gè)文件，這樣可以減少瀏覽器的http請(qǐng)求數(shù)，以及減小gzip壓縮后的文件總體積。

3.5

瀏覽Yahoo的Exceptional Performance網(wǎng)站，里面有大量提升前端性能的優(yōu)秀建議，還有他們的YSlow工具。Google的page speed則是另一個(gè)用來(lái)分析網(wǎng)頁(yè)性能的工具。兩者都要求安裝Firebug。

3.6

如果你的網(wǎng)頁(yè)用到大量的小體積圖片（比如工具欄），就應(yīng)該使用CSS Image Sprite，目的是減少http請(qǐng)求數(shù)。

3.7

大流量的網(wǎng)站應(yīng)該考慮將網(wǎng)頁(yè)對(duì)象分散在多個(gè)域名（split components across domains）。

3.8

靜態(tài)內(nèi)容（比如圖片、CSS、JavaScript、以及其他cookie無(wú)關(guān)的網(wǎng)頁(yè)內(nèi)容）都應(yīng)該放在一個(gè)不需要使用cookie的獨(dú)立域名之上。因?yàn)橛蛎氯绻衏ookie，那么客戶端向該域名發(fā)出的每次http請(qǐng)求，都會(huì)附上cookie內(nèi)容。這里的一個(gè)好方法就是使用"內(nèi)容分發(fā)網(wǎng)絡(luò)"（Content Delivery Network，CDN）。

3.9

將瀏覽器完成網(wǎng)頁(yè)渲染所需要的http請(qǐng)求數(shù)最小化。

3.10

使用Google的Closure Compiler壓縮JavaScript文件，YUI Compressor亦可。

3.11

確保網(wǎng)站根目錄下有favicon.ico文件，因?yàn)榧词咕W(wǎng)頁(yè)中根本不包括這個(gè)文件，瀏覽器也會(huì)自動(dòng)發(fā)出對(duì)它的請(qǐng)求。所以如果這個(gè)文件不存在，就會(huì)產(chǎn)生大量的404錯(cuò)誤，消耗光你的服務(wù)器的帶寬。

四、搜索引擎優(yōu)化（Search Engine Optimization，SEO）

4.1

使用"搜索引擎友好"的URL形式，比如example.com/pages/45-article-title，而不是example.com/index.php?page=45。

4.2

不要使用"點(diǎn)擊這里"之類的超級(jí)鏈接，因?yàn)檫@樣等于浪費(fèi)了一個(gè)SEO機(jī)會(huì)，而且降低了"屏幕朗讀器"（screen reader）的使用效果。

4.3

創(chuàng)建一個(gè)XML sitemap文件，它的缺省位置一般是/sitemap.xml（即放在網(wǎng)站根目錄下）。

4.4

當(dāng)你有多個(gè)URL指向同一個(gè)內(nèi)容時(shí)，在網(wǎng)頁(yè)代碼中使用<link rel="canonical" ... />。

4.5

使用Google的Webmaster Tools和Yahoo的Site Explorer。

4.6

從一開始就使用Google Analytics（或者開源的訪問(wèn)量分析工具Piwik）。

4.7

知道robots.txt的作用，以及搜索引擎蜘蛛的工作原理。

4.8

將www.example.com的訪問(wèn)請(qǐng)求導(dǎo)向example.com（使用301 Moved Permanently重定向），或者采用相反的做法，目的是防止Google把它們當(dāng)做兩個(gè)網(wǎng)站，分開計(jì)算排名。

4.9

知道存在著惡意或行為不正當(dāng)?shù)木W(wǎng)絡(luò)蜘蛛。

4.10

如果你的網(wǎng)站有非文本的內(nèi)容（比如視頻、音頻等等），你應(yīng)該參考Google的sitemap擴(kuò)展協(xié)議。

五、技術(shù)（Technology）

5.1

理解HTTP協(xié)議，以及諸如GET、POST、sessions、cookies之類的概念，包括"無(wú)狀態(tài)"（stateless）是什么意思。

5.2

確保你的XHTML/HTML和CSS符合W3C標(biāo)準(zhǔn)，使得它們能夠通過(guò)檢驗(yàn)。這可以使你的網(wǎng)頁(yè)避免觸發(fā)瀏覽器的古怪行為（quirk），而且使它在"屏幕朗讀器"和手機(jī)上也能正常工作。

5.3

理解瀏覽器如何處理JavaScript腳本。

5.4

理解網(wǎng)頁(yè)上的JavaScript文件、樣式表文件和其他資源是如何裝載及運(yùn)行的，考慮它們對(duì)頁(yè)面性能有何影響。在某些情況下，可能應(yīng)該將腳本文件放置在網(wǎng)頁(yè)的尾部。

5.5

理解JavaScript沙箱（Javascript sandbox）的工作原理，尤其是如果你打算使用iframe。

5.6

知道JavaScript可能無(wú)法使用或被禁用，以及Ajax并不是一定會(huì)運(yùn)行。記住，"不允許腳本運(yùn)行"（NoScript）正在某些用戶中變得流行，手機(jī)瀏覽器對(duì)腳本的支持千差萬(wàn)別，而Google索引網(wǎng)頁(yè)時(shí)不運(yùn)行大部分的腳本文件。

5.7

了解301重定向和302重定向之間的區(qū)別（這也是一個(gè)SEO相關(guān)問(wèn)題）。

5.8

盡可能多得了解你的部署平臺(tái)（deployment platform）。

5.9

考慮使用樣式表重置（Reset Style Sheet）。

5.10

考慮使用JavaScript框架（比如jQuery、MooTools、Prototype），它們可以使你不用考慮瀏覽器之間的差異。

六、解決bug

6.1

理解程序員20%的時(shí)間用于編碼，80%的時(shí)間用于維護(hù)，根據(jù)這一點(diǎn)相應(yīng)安排時(shí)間。

6.2

建立一個(gè)有效的錯(cuò)誤報(bào)告機(jī)制。

6.3

建立某些途徑或系統(tǒng)，讓用戶可以與你接觸，向你提出建議和批評(píng)。

6.4

為將來(lái)的維護(hù)和客服人員撰寫文檔，解釋清楚系統(tǒng)是怎么運(yùn)行的。

6.5

經(jīng)常備份！（并且確保這些備份是有效的。）除了備份機(jī)制，你還必須有一個(gè)恢復(fù)機(jī)制。

6.6

使用某種版本控制系統(tǒng)儲(chǔ)存你的文件，比如Subversion或Git。

6.7

不要忘記做單元測(cè)試（Unit Testing），Selenium之類的框架會(huì)對(duì)你有用。

（完）

轉(zhuǎn)自：http://www.ruanyifeng.com/blog/2010/11/61_things_every_web_developer_should_know.html

簡(jiǎn)介： 開源 memcached 工具是一個(gè)用來(lái)存儲(chǔ)常用信息的緩存，有了它，您便無(wú)需從緩慢的資源，比如磁盤或數(shù)據(jù)庫(kù)，加載（并處理）信息了。該工具可部署在專用的情況下，也可作為用完 現(xiàn)有環(huán)境內(nèi)的多余內(nèi)存的一種方法。盡管 memcached 十分簡(jiǎn)便，但有時(shí)它仍被不當(dāng)使用，或被用在錯(cuò)誤的環(huán)境類型中。在本文中，了解使用 memcached 的最佳時(shí)機(jī)。

簡(jiǎn)介

memcached 常被用來(lái)加速應(yīng)用程序的處理，在這里，我們將著重于介紹將它部署于應(yīng)用程序和環(huán)境中的最佳實(shí)踐。這包括應(yīng)該存儲(chǔ)或不應(yīng)存儲(chǔ)哪些、如何處理數(shù)據(jù)的靈活分布以 及如何調(diào)節(jié)用來(lái)更新 memcached 和所存儲(chǔ)數(shù)據(jù)的方法。我們還將介紹對(duì)高可用性的解決方案的支持，比如 IBM WebSphere® eXtreme Scale。

所有的應(yīng)用程序，特別是很多 web 應(yīng)用程序都需要優(yōu)化它們?cè)L問(wèn)客戶機(jī)和將信息返回至客戶機(jī)的速度。可是，通常，返回的都是相同的信息。從數(shù)據(jù)源（數(shù)據(jù)庫(kù)或文件系統(tǒng)）加載數(shù)據(jù)十分低效，若是每次想要訪問(wèn)該信息時(shí)都運(yùn)行相同的查詢，就尤顯低效。

雖然很多 web 服務(wù)器都可被配置成使用緩存發(fā)回信息，但那與大多數(shù)應(yīng)用程序的動(dòng)態(tài)特性無(wú)法相適。而這正是 memcached 的用武之地。它提供了一個(gè)通用的內(nèi)存存儲(chǔ)器，可保存任何東西，包括本地語(yǔ)言的對(duì)象，這就讓您可以存儲(chǔ)各種各樣的信息并可以從諸多的應(yīng)用程序和環(huán)境訪問(wèn)這些信息。

基礎(chǔ)知識(shí)

memcached 是一個(gè)開源項(xiàng)目，旨在利用多個(gè)服務(wù)器內(nèi)的多余 RAM 來(lái)充當(dāng)一個(gè)可存放經(jīng)常被訪問(wèn)信息的內(nèi)存緩存。這里的關(guān)鍵是使用了術(shù)語(yǔ)緩存：memcached 為加載自他處的信息提供的是內(nèi)存中的暫時(shí)存儲(chǔ)。

比如，考慮這樣一個(gè)典型的基于 web 的應(yīng)用程序。即便是一個(gè)動(dòng)態(tài)網(wǎng)站可能也會(huì)有一些組件或信息常量是貫穿頁(yè)面整個(gè)生命周期的。在一個(gè)博客站點(diǎn)內(nèi)，針對(duì)單個(gè) blog post 的類別列表不大可能在頁(yè)面查看間經(jīng)常性地變更。每次都通過(guò)一個(gè)對(duì)數(shù)據(jù)庫(kù)的查詢加載此信息相對(duì)比較昂貴，特別是在數(shù)據(jù)沒有更改的情況下，就更是如此。從圖 1 可以看到一個(gè)博客站點(diǎn)內(nèi)可被緩存的頁(yè)面分區(qū)。

圖 1. 一個(gè)典型的博客頁(yè)面內(nèi)的可緩存元素

將這種結(jié)構(gòu)放在 blog 站點(diǎn)的其他元素，poster 信息、注釋 — 設(shè)置 blog post 本身 — 進(jìn)行推斷，可以看出為了顯示主頁(yè)的內(nèi)容很可能需要發(fā)生 10-20 次數(shù)據(jù)庫(kù)查詢和格式化。 每天對(duì)數(shù)百甚至數(shù)千的的頁(yè)面查看重復(fù)此過(guò)程，那么您的服務(wù)器和應(yīng)用程序執(zhí)行的查詢要遠(yuǎn)遠(yuǎn)多于為了顯示頁(yè)面內(nèi)容所需執(zhí)行的查詢。

通過(guò)使用 memcached，可以將加載自數(shù)據(jù)庫(kù)的格式化信息存儲(chǔ)為一種可直接用在 Web 頁(yè)面上的格式。并且由于信息是從 RAM 而不是通過(guò)數(shù)據(jù)庫(kù)和其他處理從磁盤加載的，所以對(duì)信息的訪問(wèn)幾乎是瞬時(shí)的。

再?gòu)?qiáng)調(diào)一下，memcached 是一個(gè)用來(lái)存儲(chǔ)常用信息的緩存，有了它，您便無(wú)需從緩慢的資源，比如磁盤或數(shù)據(jù)庫(kù)，加載并處理信息了。

對(duì) memcached 的接口是通過(guò)網(wǎng)絡(luò)連接提供的。這意味著您可以在多個(gè)客戶機(jī)間共享單個(gè)的 memcached 服務(wù)器（或多個(gè)服務(wù)器，如本文稍后所示的）。這個(gè)網(wǎng)絡(luò)接口非常迅速，并且為了改善性能，服務(wù)器會(huì)故意不支持身份驗(yàn)證或安全性通信。但這不應(yīng)限制部署選項(xiàng)。 memcached 服務(wù)器應(yīng)該存在于您網(wǎng)絡(luò)的內(nèi)部。網(wǎng)絡(luò)接口的實(shí)用性以及可以部署多個(gè) memcached 實(shí)例的簡(jiǎn)便性讓您可以使用多個(gè)機(jī)器上的多余 RAM 來(lái)提高您緩存的整體大小。

memcached 的存儲(chǔ)方法是一個(gè)簡(jiǎn)單的鍵/值對(duì)，類似于很多語(yǔ)言內(nèi)的散列或關(guān)聯(lián)數(shù)組。通過(guò)提供鍵和值來(lái)將信息存儲(chǔ)到 memcached 內(nèi)，通過(guò)按特定的鍵請(qǐng)求信息來(lái)恢復(fù)信息。

信息會(huì)無(wú)限期地保留在緩存內(nèi)，除非發(fā)生如下的情況：

1. 為緩存分配的內(nèi)存耗盡 — 在這種情況下，memcached 使用 LRU（最近最少使用）方法從此緩存刪除條目。最近未曾使用的條目會(huì)從此緩存中先刪除，最舊的最先訪問(wèn)。
2. 條目被明確刪除 — 總是可以從此緩存內(nèi)刪除條目。
3. 條目過(guò)期失效 — 各條目均有一個(gè)有效的期限以便針對(duì)此鍵存儲(chǔ)的信息在過(guò)于陳舊時(shí)可從緩存中清除這些條目。

上述這些情況可以與您應(yīng)用程序的邏輯綜合使用以便確保緩存內(nèi)的信息是最新的。有了這些基礎(chǔ)知識(shí)后，讓我們來(lái)看看在應(yīng)用程序內(nèi)如何能最好地利用 memcached。

何時(shí)使用 memcached

在使用 memcached 改進(jìn)應(yīng)用程序性能時(shí)，可以對(duì)一些關(guān)鍵的過(guò)程和步驟進(jìn)行修改。

在加載信息時(shí)，典型的場(chǎng)景如圖 2 所示。

圖 2. 加載要顯示的信息的典型順序

一般而言，這些步驟是：

1. 執(zhí)行一個(gè)或多個(gè)查詢來(lái)從數(shù)據(jù)庫(kù)加載信息
2. 格式化適合于顯示（或進(jìn)一步處理）的信息
3. 使用或顯示格式化了的數(shù)據(jù)

在使用 memcached 時(shí)，為配合這個(gè)緩存，可對(duì)應(yīng)用程序的邏輯進(jìn)行稍許修改：

• 盡量從緩存加載信息
• 如果存在，使用信息的被緩存版本
• 如果它不存在：
  1. 執(zhí)行一個(gè)或多個(gè)查詢來(lái)從數(shù)據(jù)庫(kù)加載信息
  2. 格式化適合于顯示或進(jìn)一步處理的信息
  3. 將信息存儲(chǔ)到緩存內(nèi)
  4. 使用格式化了的數(shù)據(jù)

圖 3 是對(duì)這些步驟的總結(jié)。

圖 3. 在使用 memcached 時(shí)加載適合于顯示的信息

數(shù)據(jù)加載成為了至多三個(gè)步驟的一個(gè)過(guò)程，從緩存加載數(shù)據(jù)或從數(shù)據(jù)庫(kù)（視情況而定）加載數(shù)據(jù)并存儲(chǔ)在緩存內(nèi)。

當(dāng)這個(gè)過(guò)程首次發(fā)生時(shí)，數(shù)據(jù)將正常地從數(shù)據(jù)庫(kù)或其他數(shù)據(jù)源加載，然后再存儲(chǔ)到 memcached 內(nèi)。當(dāng)下一次訪問(wèn)此信息時(shí)，它就會(huì)從 memcached 拉出，而不是從數(shù)據(jù)庫(kù)加載，節(jié)省了時(shí)間和 CPU 循環(huán)。

問(wèn)題的另一個(gè)方面是要確保如果更改了要存儲(chǔ)在 memcached 內(nèi)的信息，在更新后端信息的同時(shí)還要更新 memcached 的版本。這會(huì)讓圖 4 內(nèi)所示的這個(gè)典型順序發(fā)生稍許變化，如 圖 5 所示。

圖 4. 在一個(gè)典型的應(yīng)用程序內(nèi)更新或存儲(chǔ)數(shù)據(jù)

圖 5 顯示了使用 memcached 后發(fā)生了變化的流程。

圖 5. 在使用 memcached 時(shí)更新或存儲(chǔ)數(shù)據(jù)

比如，仍以博客站點(diǎn)為例，在博客系統(tǒng)更新數(shù)據(jù)庫(kù)內(nèi)的類別列表時(shí)，更新應(yīng)該遵循如下順序：

1. 更新數(shù)據(jù)庫(kù)內(nèi)的類別列表
2. 格式化信息
3. 將信息存儲(chǔ)到 memcached 內(nèi)
4. 將信息返回至客戶機(jī)

memcached 內(nèi)的存儲(chǔ)操作是原子的，所以信息的更新不會(huì)讓客戶機(jī)只獲得部分?jǐn)?shù)據(jù)；它們獲得的或者是老版本，或者是新版本。

對(duì)于大多數(shù)應(yīng)用程序，這兩個(gè)操作是您惟一需要注意的。在訪問(wèn)他人使用的數(shù)據(jù)時(shí)，它會(huì)自動(dòng)被添加到這個(gè)緩存內(nèi)，而且如果對(duì)該數(shù)據(jù)進(jìn)行了更改，此緩存內(nèi)也會(huì)自動(dòng)進(jìn)行更新。

鍵、名稱空間和值

memcached 另一個(gè)需要重點(diǎn)考慮的因素是如何組織和命名存儲(chǔ)在緩存內(nèi)的這些數(shù)據(jù)。從之前博客站點(diǎn)的例子中，不難看出需要使用一種一致的命名結(jié)構(gòu)以便您能加載博客類別、歷史和其他信息，然后再在加載信息（并更新緩存）時(shí)或者在更新數(shù)據(jù)（同樣也要更新緩存）時(shí)使用。

使用的何種具體的命名系統(tǒng)特定于應(yīng)用程序，但通常可以使用一種與現(xiàn)有應(yīng)用程序類似的結(jié)構(gòu)，并且這種結(jié)構(gòu)很可能基于某種惟一識(shí)別符。當(dāng)從數(shù)據(jù)庫(kù)拉出信息或在整理信息集時(shí)，就會(huì)發(fā)生這種情況。

以 blog post 為例，可以在一個(gè)具有鍵 category-list 的項(xiàng)中存儲(chǔ)類別列表。與此 post ID 對(duì)應(yīng)的單個(gè) post，比如 blogpost-29 相關(guān)的值都可以使用，而該項(xiàng)的注釋則可以存儲(chǔ)在 blogcomments-29 內(nèi)，其中 29 就是這個(gè) blog post 的 ID。這樣一來(lái)， 您就可以將各種各樣的信息存儲(chǔ)在緩存內(nèi)，使用不同的前綴來(lái)標(biāo)識(shí)這些信息。

memcached 鍵/值存儲(chǔ)的簡(jiǎn)便性（以及安全性的缺乏）意味著如果您想要在使用同一個(gè) memcached 服務(wù)器的同時(shí)支持多個(gè)應(yīng)用程序，那么就可以考慮使用其他格式的量詞來(lái)標(biāo)識(shí)數(shù)據(jù)屬于某種特定的應(yīng)用程序。比如，可以添加像 blogapp:blogpost-29 這樣的應(yīng)用程序前綴。這些鍵是沒有格式的，所以可以使用任何字符串作為鍵的名稱。

在存儲(chǔ)值的方面，應(yīng)該確保存儲(chǔ)在緩存內(nèi)的信息適合于您的應(yīng)用程序。比如，對(duì)于這個(gè)博客系統(tǒng)，您可能想要存儲(chǔ)被博客應(yīng)用程序使用的對(duì)象以便格式化博客信息，而不是原始的 HTML。如果同一個(gè)基礎(chǔ)結(jié)構(gòu)用在應(yīng)用程序內(nèi)的多個(gè)地方，這一點(diǎn)更具實(shí)用性。

大多數(shù)語(yǔ)言的接口，包括 Java™、Perl、PHP 等，都能串行化語(yǔ)言對(duì)象以便存儲(chǔ)在 memcached 內(nèi)。這就讓您可以存儲(chǔ)并隨后從內(nèi)存存儲(chǔ)恢復(fù)全部對(duì)象，而不是在您的應(yīng)用程序內(nèi)手動(dòng)重構(gòu)它們。 很多對(duì)象，或它們使用的結(jié)構(gòu)，都基于某種散列或數(shù)組結(jié)構(gòu)。對(duì)于跨語(yǔ)言的環(huán)境，比如在 JSP 環(huán)境和 JavaScript 環(huán)境間共享相同信息，可以使用一種架構(gòu)中立的格式，比如 JavaScript Object Notation (JSON) 甚或 XML。

填充并使用 memcached

作為一種開源產(chǎn)品以及一種最初開發(fā)用來(lái)工作于現(xiàn)有開源環(huán)境內(nèi)的產(chǎn)品，memcached 受大量環(huán)境和平臺(tái)支持。與 memcached 服務(wù)器通信的接口有很多，并常常具有針對(duì)所有語(yǔ)言的多個(gè)實(shí)現(xiàn)。參見 參考資料 以獲得常用的庫(kù)和工具箱。

要列出所有受支持的接口和環(huán)境不太可能，但它們均支持 memcached 協(xié)議提供的基礎(chǔ) API。這些描述已經(jīng)被簡(jiǎn)化并應(yīng)用在不同語(yǔ)言的上下文內(nèi)，在這些語(yǔ)言中，使用不同的值可指示錯(cuò)誤。主要的函數(shù)有：

• get(key) — 從存儲(chǔ)了特定鍵的 memcached 獲得信息。 如果鍵不存在，就返回錯(cuò)誤。
• set(key, value [, expiry]) — 使用緩存內(nèi)的標(biāo)識(shí)符鍵存儲(chǔ)這個(gè)特定的值。如果鍵已經(jīng)存在，那么它就會(huì)被更新。期滿時(shí)間的單位為秒，并且如果值小于 30 天 (30*24*60*60)，那么就用作相對(duì)時(shí)間，如果值大于 30 天，那么就用作絕對(duì)時(shí)間 (epoch)。
• add(key, value [, expiry]) — 如果鍵不存在就將這個(gè)鍵添加到緩存內(nèi)，如果鍵已經(jīng)存在就返回錯(cuò)誤。如果您想要顯式地添加一個(gè)新鍵而又不會(huì)因它已經(jīng)存在而更新它，那么這個(gè)函數(shù)將十分有用。
• replace(key, value [, expiry]) — 更新此特定鍵的值，如果鍵不存在就返回一個(gè)錯(cuò)誤。
• delete(key [, time]) — 從緩存中刪除此鍵/值對(duì)。如果您提供一個(gè)時(shí)間，那么添加具有此鍵的一個(gè)新值就會(huì)被阻塞這個(gè)特定的時(shí)期。超時(shí)讓您可以確保此值總是可以重新讀取自您的數(shù)據(jù)中心。
• incr(key [, value]) — 為特定的鍵增 1 或特定的值。只適用于數(shù)值。
• decr(key [, value]) — 為特定的鍵減 1 或特定的值，只適用于數(shù)值。
• flush_all — 讓緩存內(nèi)的所有當(dāng)前條目無(wú)效（或到期失效）。

比如，在 Perl 內(nèi)，基本 set 操作可以如清單 1 所示的那樣處理。

清單 1. Perl 內(nèi)的基本 set 操作

				
use Cache::Memcached;

my $cache = new Cache::Memcached {
    'servers' => [
                   'localhost:11211',
                   ],
    };

$cache->set('mykey', 'myvalue');

Ruby 內(nèi)的相同的基本操作如清單 2 所示。

清單 2. Ruby 內(nèi)的基本 set 操作

				
require 'memcache'
memc = MemCache::new '192.168.0.100:11211'

memc["mykey"] = "myvalue"

在兩個(gè)例子中可以看到相同的基本結(jié)構(gòu)：設(shè)置 memcached 服務(wù)器，然后分配或設(shè)置值。其他的接口也可用，包括適合于 Java 技術(shù)的那些接口，讓您可以在 WebSphere 應(yīng)用程序內(nèi)使用 memcached。memcached 接口類允許將 Java 對(duì)象直接序列化到 memcached 以便于存儲(chǔ)和加載復(fù)雜的結(jié)構(gòu)。當(dāng)在像 WebSphere 這樣的環(huán)境內(nèi)進(jìn)行部署時(shí)，有兩個(gè)事情非常重要：服務(wù)的彈性（在 memcached 不可用時(shí)如何做）以及如何提高緩存存儲(chǔ)量來(lái)改進(jìn)在使用多個(gè)應(yīng)用程序服務(wù)器或在使用像 WebSphere eXtreme Scale 這樣的環(huán)境時(shí)的性能。我們接下來(lái)就來(lái)看看這兩個(gè)問(wèn)題。

彈性和可用性

有關(guān) memcached 最常見的一個(gè)問(wèn)題是：“若緩存不可用了，會(huì)發(fā)生什么情況呢？”正如之前章節(jié)中明示的，緩存內(nèi)的信息不應(yīng)該成為信息的的惟一資源。必須要能夠從其他位置加載存儲(chǔ)在緩存內(nèi)的數(shù)據(jù)。

雖然，無(wú)法從緩存訪問(wèn)信息將會(huì)減緩應(yīng)用程序的性能，但它不應(yīng)該阻止應(yīng)用程序的運(yùn)轉(zhuǎn)。可能會(huì)發(fā)生這樣幾個(gè)場(chǎng)景：

1. 如果 memcached 服務(wù)宕掉，應(yīng)用程序應(yīng)該回退到從原始數(shù)據(jù)源加載信息并對(duì)信息進(jìn)行顯示所需的格式化。此應(yīng)用程序還應(yīng)繼續(xù)嘗試在 memcached 內(nèi)加載和存儲(chǔ)信息。
2. 一旦 memcached 服務(wù)器恢復(fù)可用，應(yīng)用程序就應(yīng)該自動(dòng)嘗試存儲(chǔ)數(shù)據(jù)。沒有必要強(qiáng)制重載已緩存了的數(shù)據(jù)，可以使用標(biāo)準(zhǔn)的訪問(wèn)來(lái)用信息加載和填充緩存。最終，緩存將會(huì)被最常用的數(shù)據(jù)重新填充。

再次重申，memcached 是信息的緩存但并非惟一的數(shù)據(jù)源。memcached 服務(wù)器不可用不應(yīng)該是應(yīng)用程序的終結(jié)，雖然這意味著在 memcached 服務(wù)器恢復(fù)正常之前性能會(huì)有所降低。實(shí)際上，memcached 服務(wù)器相對(duì)簡(jiǎn)單，并且雖然不是絕對(duì)無(wú)故障的，但它的簡(jiǎn)單性的結(jié)果就是它很少會(huì)出錯(cuò)。

分配緩存

memcached 服務(wù)器只是網(wǎng)絡(luò)上針對(duì)一些鍵存儲(chǔ)值的一個(gè)緩存。如果有多臺(tái)機(jī)器，那么很自然地會(huì)想要在所有多余機(jī)器上設(shè)置一個(gè) memcached 的實(shí)例來(lái)提供一個(gè)超大的聯(lián)網(wǎng) RAM 緩存存儲(chǔ)。

有了這個(gè)想法后，還有一種想當(dāng)然是需要使用某種分配或復(fù)制機(jī)制來(lái)在機(jī)器之間復(fù)制鍵/值對(duì)。這種方式的問(wèn)題是如果這么做反而會(huì)減少可用的 RAM 緩存，而不是增加。如圖 6 所示，可以看出這里有三個(gè)應(yīng)用程序服務(wù)器，每個(gè)服務(wù)器都可以訪問(wèn)一個(gè) memcached 實(shí)例。

圖 6. 多重 memcached 實(shí)例的不正確使用

盡管每個(gè) memcached 實(shí)例都是 1 GB 的大小（產(chǎn)生 3 GB 的 RAM 緩存），但如果每個(gè)應(yīng)用程序服務(wù)器只有其自己的緩存（或者在 memcached 之間存在著數(shù)據(jù)的復(fù)制），那么整個(gè)安裝也仍只能有 1 GB 的緩存在每個(gè)實(shí)例間復(fù)制。

由于 memcached 通過(guò)一個(gè)網(wǎng)絡(luò)接口提供信息，因此單個(gè)的客戶機(jī)可以從它所能訪問(wèn)的任何一個(gè) memcached 實(shí)例訪問(wèn)數(shù)據(jù)。如果數(shù)據(jù)沒有跨每個(gè)實(shí)例被復(fù)制，那么最終在每個(gè)應(yīng)用程序服務(wù)器上，就可以有 3 GB 的 RAM 緩存可用，如圖 7 所示。

圖 7. 多重 memcached 實(shí)例的正確使用

這個(gè)方法的問(wèn)題是選擇哪個(gè)服務(wù)器來(lái)儲(chǔ)存鍵/值對(duì)，以及當(dāng)想要重新獲得一個(gè)值時(shí)，如何決定要與哪個(gè) memcached 服務(wù)器對(duì)話。問(wèn)題的解決方案就是忽略復(fù)雜的東西，比如查找表，或是寄望 memcached 服務(wù)器來(lái)為您處理這個(gè)過(guò)程。而 memcached 客戶機(jī)則必須要力求簡(jiǎn)單。

memcached 客戶機(jī)不必決定此信息，它只需對(duì)在存儲(chǔ)信息時(shí)指定的鍵使用一個(gè)簡(jiǎn)單的散列算法。當(dāng)想要從一列 memcached 服務(wù)器存儲(chǔ)或獲取信息時(shí)，memcached 客戶機(jī)就會(huì)用一個(gè)一致的散列算法從這個(gè)鍵獲取一個(gè)數(shù)值。舉個(gè)例子，鍵 mykey 被轉(zhuǎn)換成數(shù)值 23875 。是保存還是獲取信息無(wú)關(guān)緊要，這個(gè)鍵將總是被用作惟一標(biāo)識(shí)符來(lái)從 memcached 服務(wù)器加載，因此在本例中，“mykey” 散列轉(zhuǎn)化后對(duì)應(yīng)的值總是 23875。

如果有兩個(gè)服務(wù)器，那么 memcached 客戶機(jī)將對(duì)這個(gè)數(shù)值進(jìn)行一個(gè)簡(jiǎn)單的運(yùn)算（例如，系數(shù)）來(lái)決定它應(yīng)將此值存儲(chǔ)在第一個(gè)還是第二個(gè)配置了的 memcached 實(shí)例上。

當(dāng)存儲(chǔ)一個(gè)值時(shí)，客戶機(jī)會(huì)從這個(gè)鍵確定出散列值以及它原來(lái)存儲(chǔ)在哪個(gè)服務(wù)器上。當(dāng)獲取一個(gè)值時(shí)，客戶機(jī)會(huì)從這個(gè)鍵確定出相同的散列值并會(huì)選擇相同的服務(wù)器來(lái)獲取信息。

如果在每個(gè)應(yīng)用程序服務(wù)器上使用的是相同的服務(wù)器列表（并且順序相同），那么當(dāng)需要保存或檢索同一個(gè)鍵時(shí)，每個(gè)應(yīng)用程序服務(wù)器都將選擇同一個(gè) 服務(wù)器。現(xiàn)在，在這個(gè)例子中，有 3GB 的 memcached 空間可以共享，而不是同一個(gè) 1 GB 的空間的復(fù)制，這就帶來(lái)了更多的可用緩存，并很有可能會(huì)提高有多個(gè)用戶情況下的應(yīng)用程序的性能。

這個(gè)過(guò)程也有其復(fù)雜性（比如當(dāng)一個(gè)服務(wù)器不可用時(shí)會(huì)怎樣），更多信息，請(qǐng)參見相關(guān)文檔（參見 參考資料）。

如何能不使用 memcached

盡管 memcached 很簡(jiǎn)單，但 memcached 實(shí)例有時(shí)候還是會(huì)被不正確地使用。

memcached 不是一個(gè)數(shù)據(jù)庫(kù)

最常見的 memcached 誤用就是把它用作一個(gè)數(shù)據(jù)存儲(chǔ)，而不是一個(gè)緩存。memcached 的首要目的就是加快數(shù)據(jù)的響應(yīng)時(shí)間，否則數(shù)據(jù)從其他數(shù)據(jù)源構(gòu)建或恢復(fù)需要很長(zhǎng)時(shí)間。一個(gè)典型的例子就是從一個(gè)數(shù)據(jù)庫(kù)中恢復(fù)信息，特別是在信息顯示給用戶前 需要對(duì)信息進(jìn)行格式化或處理的時(shí)候。Memcached 被設(shè)計(jì)用來(lái)將信息存儲(chǔ)在內(nèi)存中以避免每次在數(shù)據(jù)需要恢復(fù)時(shí)重復(fù)執(zhí)行相同的任務(wù)。

切不可將 memcached 用作運(yùn)行應(yīng)用程序所需信息的惟一信息源；數(shù)據(jù)應(yīng)總是可以從其他信息源獲取。此外，要記住 memcached 只是一個(gè)鍵/值的存儲(chǔ)。不能在數(shù)據(jù)上執(zhí)行查詢，或者對(duì)內(nèi)容進(jìn)行迭代來(lái)提取信息。應(yīng)該使用它來(lái)存儲(chǔ)數(shù)據(jù)塊或?qū)ο笠詡渑渴褂谩?/p>

不要緩存數(shù)據(jù)庫(kù)行或文件

雖然可以使用 memcached 存儲(chǔ)加載自數(shù)據(jù)庫(kù)的數(shù)據(jù)行，但這實(shí)際上是查詢緩存，并且大多數(shù)數(shù)據(jù)庫(kù)都提供各自的查詢緩存的機(jī)制。其他的對(duì)象，比如文件系統(tǒng)的圖像或文件的情況與此相同。很多應(yīng)用程序和 web 服務(wù)器針對(duì)此類工作已經(jīng)有了一些很好的解決方案。

如果在加載和格式化后，使用它來(lái)存儲(chǔ)全部信息塊，就可以從 memcached 獲得更多的實(shí)用工具和性能上的改善。仍以我們的博客站點(diǎn)為例，存儲(chǔ)信息的最佳點(diǎn)是在將博客類別格式化為對(duì)象，甚至是在格式化成 HTML 后。博客頁(yè)面的構(gòu)造可通過(guò)從 memcached 加載各個(gè)組件（比如 blog post、category list、post history 等）并將完成的 HTML 寫回至客戶機(jī)實(shí)現(xiàn)。

memcached 并不安全

為了確保最佳性能，memcached 并未提供任何形式的安全性，沒有身份驗(yàn)證，也沒有加密。這意味著對(duì) memcached 服務(wù)器的訪問(wèn)應(yīng)該這么處理：一是通過(guò)將它們放到應(yīng)用程序部署環(huán)境相同的私有側(cè)，二是如果安全性是必須的，那么就使用 UNIX® socket 并只允許當(dāng)前主機(jī)上的應(yīng)用程序訪問(wèn)此 memcached 服務(wù)器。

這多少犧牲了一些靈活性和彈性，以及跨網(wǎng)絡(luò)上的多臺(tái)機(jī)器共享 RAM 緩存的能力，但這是在目前的情況下確保 memcached 數(shù)據(jù)安全性的惟一一種解決方案。

不要限制自己

除了不應(yīng)該使用 memcached 實(shí)例的情況外，memcached 的靈活性不應(yīng)忽視。由于 memcached 與應(yīng)用程序處于相同的架構(gòu)水平，所以很容易集成并連接到它。并且更改應(yīng)用程序以便利用 memcached 也并不復(fù)雜。此外，由于 memcached 只是一個(gè)緩存，所以在出現(xiàn)問(wèn)題時(shí)它不會(huì)停止應(yīng)用程序的執(zhí)行。如果使用正確的話，它所做的是減輕其余服務(wù)器基礎(chǔ)設(shè)施的負(fù)載（減少對(duì)數(shù)據(jù)庫(kù)和數(shù)據(jù)源的讀操 作），這意味著無(wú)需更多的硬件就可以支持更多的客戶機(jī)。

但請(qǐng)記住，它僅僅是個(gè)緩存！

結(jié)束語(yǔ)

在本文中，我們了解了 memcached 以及如何最佳地使用它。我們看到了信息如何存儲(chǔ)、如何選擇合理的鍵以及如何選擇要存儲(chǔ)的信息。我們還討論了所有 memcached 用戶都要遇到的一些關(guān)鍵的部署問(wèn)題，包括多服務(wù)器的使用、當(dāng) memcached 實(shí)例消亡時(shí)該怎么做，以及（也許最為重要的）在哪些情況下不能使用 memcached。

作為一種開源的應(yīng)用程序并且是目的簡(jiǎn)單而直白的應(yīng)用程序，memcached 的功能和實(shí)用性均來(lái)自于這種簡(jiǎn)單性。通過(guò)為信息提供巨大的 RAM 存儲(chǔ)空間、讓它在網(wǎng)絡(luò)上可用，然后再讓它可通過(guò)各種不同的接口和語(yǔ)言訪問(wèn)到，memcached 可被集成到多種多樣的安裝和環(huán)境中。

參考資料

學(xué)習(xí)

• MySQL memcached 文檔 提供了很多有關(guān)如何在一個(gè)典型的數(shù)據(jù)庫(kù)部署環(huán)境內(nèi)使用 memcached 的信息。
• 通過(guò)體驗(yàn) IBM solidDB 產(chǎn)品家族，了解 IBM 的商業(yè)緩存解決方案 solidDB®。
• 隨時(shí)關(guān)注 developerWorks 技術(shù)活動(dòng)和網(wǎng)絡(luò)廣播。
• 查閱最近將在全球舉辦的面向 IBM 開放源碼開發(fā)人員的研討會(huì)、交易展覽、網(wǎng)絡(luò)廣播和其他 活動(dòng)。
• 訪問(wèn) developerWorks Open source 專區(qū)獲得豐富的 how-to 信息、工具和項(xiàng)目更新以及最受歡迎的文章和教程，幫助您用開放源碼技術(shù)進(jìn)行開發(fā)，并將它們與 IBM 產(chǎn)品結(jié)合使用。
• 查看免費(fèi)的 developerWorks On demand 演示，觀看并了解 IBM 及開源技術(shù)和產(chǎn)品功能。
  
  

獲得產(chǎn)品和技術(shù)

• memcached.org 提供了有關(guān) memcached 以及如何下載并安裝它的信息。
• Cache::Memcached interface for Perl 提供了一個(gè)廣泛的接口。
• 對(duì)于 Java 技術(shù)，可使用 com.danga.MemCached 類，它會(huì)提供一些額外的故障轉(zhuǎn)換及多實(shí)例擴(kuò)展。
• 使用 IBM 產(chǎn)品評(píng)估試用版軟件 改進(jìn)您的下一個(gè)開發(fā)項(xiàng)目，這些軟件可以通過(guò)下載獲得。
• 下載 IBM 產(chǎn)品評(píng)估試用版軟件 或 IBM SOA Sandbox for People，并開始使用來(lái)自 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 的應(yīng)用程序開發(fā)工具和中間件產(chǎn)品。

討論

• 參與 developerWorks 博客 加入 developerWorks 社區(qū)。
• 歡迎加入 My developerWorks 中文社區(qū)。
  
  

關(guān)于作者

“比心情更好的是你的選擇！”這條掛在“天驕北麓”售樓部房頂上的廣告詞極其充滿誘惑，與之形成鮮明反差的是上百準(zhǔn)業(yè)主半月來(lái)的維權(quán)，比其心情更糟的是“天驕北麓”背后“那點(diǎn)房事”。12月18日，位于紅云路上的“天驕北麓”在準(zhǔn)業(yè)主們的不滿和遭遇雞糞灑門中迎來(lái)了開盤。

這 場(chǎng)被媒體和市民高度關(guān)注的房事，其實(shí)是一場(chǎng)赤裸裸的利益紛爭(zhēng)，以及一個(gè)企業(yè)在市場(chǎng)經(jīng)濟(jì)下，面對(duì)市場(chǎng)風(fēng)險(xiǎn)如何做到誠(chéng)實(shí)守信？對(duì)于準(zhǔn)業(yè)主們來(lái)說(shuō)，需要思考的是 在市場(chǎng)經(jīng)濟(jì)下，如何用法律來(lái)保障自己的權(quán)益。市場(chǎng)經(jīng)濟(jì)就是法治經(jīng)濟(jì)，道德、誠(chéng)信這些沒有落在紙上具有法律約束力的字眼，在利益面前顯得蒼白無(wú)力。

為防不測(cè)，防暴警察也來(lái)到現(xiàn)場(chǎng)

昨天上午，“天驕北麓”迎來(lái)開盤。由于上百準(zhǔn)業(yè)主的不滿和抗議，讓這次開盤顯得格外謹(jǐn)慎和受到外界廣泛關(guān)注。數(shù)十警察趕到現(xiàn)場(chǎng)維持秩序，為了防止不測(cè)，防暴警察也來(lái)到現(xiàn)場(chǎng)。

中 午12點(diǎn)39分左右，準(zhǔn)房主們把早已準(zhǔn)備好的兩箱雞糞灑在了售樓部的門口。頓時(shí)，現(xiàn)場(chǎng)出現(xiàn)了一點(diǎn)騷亂，在旁邊維持秩序的警察開始前去阻攔。就在這時(shí)，一礦 泉水瓶砸向售樓部大門，站在門口的一名保安拿著警棍朝著準(zhǔn)業(yè)主們指了指，幾個(gè)情緒激動(dòng)的準(zhǔn)業(yè)主向保安沖去，被維持秩序的警察攔下，在其他保安的勸說(shuō)下，該 名保安走進(jìn)了售樓部。

56歲的代阿姨，是這次“天驕北麓”團(tuán)購(gòu)房的一名準(zhǔn)業(yè)主，交了20萬(wàn)元。維權(quán)15天以來(lái)，代阿姨有著不少的委屈和不滿。為了換一套大一點(diǎn)的房子，代阿姨把原來(lái)的房子賣了，手里攥著60多萬(wàn)元，本想把這60多萬(wàn)投向“天驕北麓”，買大一點(diǎn)的房子，等待她的卻是一場(chǎng)紛爭(zhēng)。

“比心情更壞的是花言巧言設(shè)下的陷阱，一個(gè)沒有出口、巷道林立的購(gòu)房迷宮。”代阿姨說(shuō)。

說(shuō)起購(gòu)買“天驕北麓”的房子，患有高血壓的代阿姨苦不堪言，當(dāng)她7月初從中介公司獲知4800元一平方米就可以購(gòu)買天驕北麓的房子時(shí)，義無(wú)反顧地交了1.7萬(wàn)元的轉(zhuǎn)讓金，并與這家中介公司簽下合約。7月10日選房時(shí)，她交了20萬(wàn)元。

本以為可以圓一個(gè)住房夢(mèng)的她，每天都在盼著房子開盤，日子就這么一天天過(guò)去，代阿姨也沒感到有什么煩惱。

當(dāng)12月1日獲知她交了20萬(wàn)元參與團(tuán)購(gòu)的“天驕北麓”價(jià)格比當(dāng)初和中介公司簽下合約的房?jī)r(jià)高出一倍時(shí)，代阿姨蒙了。自12月4日起，代阿姨和上百團(tuán)購(gòu)者開始了維權(quán)。由于身體不好，上了年紀(jì)，每天的維權(quán)之路，代阿姨還是吃不消。

和代阿姨一樣的購(gòu)房者還有來(lái)自四川的周女士。周女士交了6萬(wàn)元的購(gòu)房意向金，結(jié)果也陷入了這場(chǎng)紛爭(zhēng)。欲哭無(wú)淚的周女士昨天上午后悔不已，當(dāng)初不該草率地賣了房子來(lái)購(gòu)買“天驕北麓”。在這起購(gòu)房中，還有她的10多個(gè)老鄉(xiāng)。

“開發(fā)商的一小步，維權(quán)者的一大步”

在這些準(zhǔn)業(yè)主提供的協(xié)議中，記者沒有看到一份真正的購(gòu)房合同，聽到和看到的只是團(tuán)購(gòu)、意向金，這些不明不白的詞語(yǔ)，讓人眼花繚亂。

在“天驕北麓”售樓部，一張由云南倫華房地產(chǎn)有限公司貼出的通告里稱，對(duì)未選中房子的購(gòu)房客戶，公司愿意現(xiàn)金一次性補(bǔ)償，以中國(guó)人民銀行公布的現(xiàn)行兩年定期存款率3.25%為計(jì)算標(biāo)準(zhǔn)。

對(duì)于此，準(zhǔn)業(yè)主霍先生把其稱為“開發(fā)商的一小步，維權(quán)者的一大步”。霍先生說(shuō)，在各方壓力和他們準(zhǔn)業(yè)主的努力下，開發(fā)商愿意為返還意向金支付利息，來(lái)之不易。

代阿姨說(shuō)，她交了20萬(wàn)元的意向金，可以得到6500多元的利息，對(duì)于她來(lái)說(shuō)，這點(diǎn)利息已經(jīng)對(duì)其沒有多少用處，因?yàn)檫@幾個(gè)月來(lái)，看著往上漲的房子，她付出去的更多，已經(jīng)耽誤了她買房。

中午12點(diǎn)51分，準(zhǔn)業(yè)主們開始從售樓部撤離，環(huán)衛(wèi)工人開始打掃門口的雞糞。下午1點(diǎn)10分左右，“天驕北麓”恢復(fù)了暫時(shí)的安寧。掛在售樓部西邊“所有關(guān)于生活的夢(mèng)想從這一刻開啟”的廣告詞，是否會(huì)因?yàn)橐恍?zhǔn)業(yè)主們的離開而開啟更多準(zhǔn)業(yè)主們生活的夢(mèng)想呢？

背景

“天驕北麓”團(tuán)購(gòu)風(fēng)波

2009年11月，由云南倫華房地產(chǎn)有限公司開發(fā)的“天驕北麓”項(xiàng)目開始認(rèn)購(gòu)，打出的廣告上稱項(xiàng)目房源最低售價(jià)3660元/平米，均價(jià)4300元/平米，并承諾如正式開盤時(shí)提價(jià)，團(tuán)購(gòu)房源價(jià)格不變，上萬(wàn)的團(tuán)購(gòu)者繳納了2至30萬(wàn)元不等的意向金預(yù)訂房源。

2010年12月1日，“天驕北麓”項(xiàng)目公布了每套房源價(jià)格，均價(jià)上調(diào)。開發(fā)商稱所有房源按照公布價(jià)格出售，不想買房的，無(wú)息返還意向金。

當(dāng) 準(zhǔn)業(yè)主們獲知這個(gè)消息后，猶如五雷轟頂，當(dāng)初不是說(shuō)好了3660元到4300元嗎？怎么會(huì)有這么大的差距呢？一種不滿的情緒開始在準(zhǔn)業(yè)主中蔓延。12月1 日，因開盤價(jià)格遠(yuǎn)遠(yuǎn)高于已經(jīng)交了認(rèn)購(gòu)金的購(gòu)房者的心理底線，這些準(zhǔn)業(yè)主們一氣之下砸了售樓部的沙盤模型。12月4日、5日，準(zhǔn)業(yè)主們聚集售樓部，用番茄雞 蛋來(lái)招呼開發(fā)商，表達(dá)對(duì)開發(fā)商行為的不滿。

記者秦聰俊（都市時(shí)報(bào)）

轉(zhuǎn)自：http://news.qq.com/a/20101219/001080.htm?qq=0&ADUIN=84588990&ADSESSION=1292750641&ADTAG=CLIENT.QQ.3073_.0

騰訊微博開放平臺(tái)API開放啦，使用騰訊微博開放平臺(tái)提供的API創(chuàng)建自己的應(yīng)用，需要首先填寫個(gè)人資料，通過(guò)聯(lián)系郵箱驗(yàn)證，獲取開發(fā)者資格，就能 創(chuàng)建自己的應(yīng)用。騰訊微博開放平臺(tái)，是基于騰訊微博系統(tǒng)，為廣大開發(fā)者和用戶提供的開放數(shù)據(jù)分享與傳播平臺(tái)。廣大開發(fā)者和用戶登錄平臺(tái)后，就可以使用平臺(tái) 提供的開放API接口，創(chuàng)建應(yīng)用從微博系統(tǒng)獲取信息，或?qū)⑿碌男畔鞑サ秸麄€(gè)微博系統(tǒng)中，豐富多樣的API接口和應(yīng)用，加上你的智慧，將創(chuàng)造出無(wú)窮的應(yīng)用和樂(lè)趣。

騰訊微博開放平臺(tái)，是基于騰訊微博系統(tǒng)，為廣大開發(fā)者和用戶提供的開放數(shù)據(jù)分享與傳播平臺(tái)。廣大開發(fā)者和用戶登錄平臺(tái)后，就可以使用平臺(tái)提供的開放 API接口，創(chuàng)建應(yīng)用從微博系統(tǒng)獲取信息，或?qū)⑿碌男畔鞑サ秸麄€(gè)微博系統(tǒng)中，豐富多樣的API接口和應(yīng)用，加上你的智慧，將創(chuàng)造出無(wú)窮的應(yīng)用和樂(lè)趣！

平臺(tái)介紹 — 在微博開放平臺(tái)能獲取到的資源及優(yōu)勢(shì)

應(yīng)用開發(fā)說(shuō)明 — 說(shuō)明如何成為一個(gè)開發(fā)者并創(chuàng)建應(yīng)用

應(yīng)用審核流程 — 審核應(yīng)用的來(lái)源字段能獲得的好處，以及如何審核

開發(fā)者協(xié)議 — 在此查看騰訊微博開放平臺(tái)開發(fā)者服務(wù)協(xié)議

如何開發(fā)微博應(yīng)用？（馬上成為開發(fā)者）

你只需要按照如下步驟操作：

第一步：填寫你的開發(fā)者信息；

第二步：聯(lián)系郵箱通過(guò)驗(yàn)證；（電子郵箱將作為我們聯(lián)系你的重要方式，請(qǐng)?zhí)峁┏Ｓ绵]箱地址）

第三步：填寫要?jiǎng)?chuàng)建的應(yīng)用信息。

就能馬上獲取到微博App Key和App Secret，調(diào)用微博API，進(jìn)行應(yīng)用開發(fā)。 查看詳細(xì)說(shuō)明

----

代表著中國(guó)最先進(jìn)的互聯(lián)網(wǎng)技術(shù)的騰訊終于走出了開放的第一步 :-)

轉(zhuǎn)自：http://www.oschina.net/news/13863/tencent-open-micro-blogging-api

好久沒貼過(guò)代碼了，心血來(lái)潮。

/*
 * Copyright (c) 2009, 2010, B3log Team
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package org.b3log.latke.servlet.filter;

import java.io.IOException;
import java.io.OutputStreamWriter;
import java.io.PrintWriter;
import java.util.logging.Level;
import java.util.logging.Logger;
import java.util.zip.GZIPOutputStream;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletOutputStream;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpServletResponseWrapper;

/**
 * Abstract HTTP response GZIP filter.
 *
 * @author Liang Ding
 * @version 1.0.0.1, Dec 16, 2010
 */
public abstract class AbstractGZIPFilter implements Filter {

    /**
     * Logger.
     */
    private static final Logger LOGGER =
            Logger.getLogger(AbstractGZIPFilter.class.getName());

    @Override
    public void init(final FilterConfig cfg) throws ServletException {
    }

    /**
     * Wraps the http servlet response with GZIP if could.
     *
     * @param request the specified request
     * @param response the specified response
     * @param chain filter chain
     * @throws IOException io exception
     * @throws ServletException servlet exception
     */
    @Override
    public void doFilter(final ServletRequest request,
                         final ServletResponse response,
                         final FilterChain chain) throws IOException,
                                                         ServletException {
        final HttpServletRequest httpServletRequest =
                (HttpServletRequest) request;
        final String requestURI = httpServletRequest.getRequestURI();
        if (shouldSkip(requestURI)) {
            LOGGER.log(Level.FINEST, "Skip GZIP filter request[URI={0}]",
                       requestURI);
            chain.doFilter(request, response);

            return;
        }

        final String acceptEncoding =
                httpServletRequest.getHeader("Accept-Encoding");
        boolean supportGZIP = false;
        if (null != acceptEncoding
            && 0 <= acceptEncoding.indexOf("gzip")) {
            supportGZIP = true;
        }

        if (!supportGZIP) {
            LOGGER.info("Gzip NOT be supported");
            chain.doFilter(request, response);

            return;
        }

        final HttpServletResponse httpServletResponse =
                (HttpServletResponse) response;
        httpServletResponse.addHeader("Content-Encoding", "gzip");
        httpServletResponse.addHeader("Vary", "Accept-Encoding");
        chain.doFilter(request,
                       new GZIPServletResponseWrapper(httpServletResponse));
    }

    /**
     * Determines whether the specified request URI should be skipped filter.
     *
     * 

     *   Note: This method SHOULD be invoked for all filters with pattern
     *   "/*".
     * 
     *
     * @param requestURI the specified request URI
     * @return {@code true} if should be skipped, {@code false} otherwise
     */
    public abstract boolean shouldSkip(final String requestURI);

    @Override
    public void destroy() {
    }

    /**
     * HTTP response wrapper for GZIP.
     *
     * @author Liang Ding
     * @version 1.0.0.0, Dec 16, 2010
     */
    private class GZIPServletResponseWrapper extends HttpServletResponseWrapper {

        /**
         * GZIP output stream.
         */
        private GZIPOutputStream gzipStream;
        /**
         * Servlet output stream.
         */
        private ServletOutputStream servletOutputStream;
        /**
         * Print writer.
         */
        private PrintWriter printWriter;

        /**
         * Constructs an {@link GZIPServletResponseWrapper} object with the
         * specified http servlet response.
         *
         * @param httpServletResponse the specified http servlet response
         * @throws IOException io exception
         */
        GZIPServletResponseWrapper(final HttpServletResponse httpServletResponse)
                throws IOException {
            super(httpServletResponse);
        }

        @Override
        public ServletOutputStream getOutputStream() throws IOException {
            if (null == servletOutputStream) {
                servletOutputStream = createOutputStream();
            }

            return servletOutputStream;
        }

        @Override
        public PrintWriter getWriter() throws IOException {
            if (null == printWriter) {
                printWriter = new PrintWriter(
                        new OutputStreamWriter(getOutputStream(),
                                               getCharacterEncoding()));
            }

            return printWriter;
        }

        /**
         * Creates output stream with GZIP delegation.
         *
         * @return servlet output stream
         * @throws IOException io exception
         */
        private ServletOutputStream createOutputStream() throws IOException {
            final ServletResponse servletResponse = this.getResponse();
            gzipStream = new GZIPOutputStream(servletResponse.getOutputStream());

            return new ServletOutputStream() {

                @Override
                public void write(final int b) throws IOException {
                    gzipStream.write(b);
                }

                @Override
                public void flush() throws IOException {
                    gzipStream.flush();
                }

                @Override
                public void close() throws IOException {
                    gzipStream.close();
                }

                /*
                 * These two are not absolutely needed. They are here simply
                 * because they were overriden by GZIPOutputStream.
                 */
                @Override
                public void write(final byte[] b) throws IOException {
                    gzipStream.write(b);
                }

                @Override
                public void write(final byte[] b, final int off, final int len)
                        throws IOException {
                    gzipStream.write(b, off, len);
                }
            };
        }
    }
}

WebSocket 協(xié)議是實(shí)現(xiàn)了瀏覽器與服務(wù)器全雙工通信的 HTML5 新協(xié)議之一。傳統(tǒng)瀏覽器只允許通過(guò) HTTP 與網(wǎng)站互動(dòng)，然而對(duì)于富 Web 應(yīng)用 如聊天和游戲，HTTP 的效率不太高，因此HTML5 提供了socket API，只需一個(gè)握手動(dòng)作就能在瀏覽器和服務(wù)器之間建立快速通道。

然而在 11 月 26 日，安全研究人員發(fā)表了一篇研究報(bào)告（PDF），他們發(fā)現(xiàn) WebSocket 和透明代理存在嚴(yán)重安全問(wèn)題，他們演示了基于 Upgrade 和 CONNECT 的緩存中毒攻擊，研究人員提議修改握手方式。在 Bugzilla 上，F(xiàn)irefox 開發(fā)者討論了該問(wèn)題，他們最后決定Firefox 4 將默認(rèn)不啟用 WebSockets，從 Firefox 4 beta 8 開始用戶將需要修改設(shè)置才能啟用 WebSockets。未來(lái)在解決安全問(wèn)題后，F(xiàn)irefox 會(huì)選擇默認(rèn)啟用。

轉(zhuǎn)自：http://www.oschina.net/news/13668/disabling-websockets-for-firefox-4

自從發(fā)布第一個(gè)版本來(lái)，大家給了很多建議，謝謝了 :-)

下個(gè)版本 0.2.5 將于明年 2 月 14 日發(fā)布，其中加入兩個(gè)大的特性：

• 多用戶
  Solo 不再是單用戶博客了。多人可以一起在一個(gè)博客里進(jìn)行文章撰寫，非常適合團(tuán)隊(duì)博客。另外，如果是情侶博客的話，哼哼....
• 草稿夾
  想發(fā)布再發(fā)布吧！當(dāng)然，發(fā)布了也可以再草稿化....

這個(gè)版本的改變比較大（數(shù)據(jù)存儲(chǔ)、邏輯控制、視圖），除了 Solo 上述兩個(gè)大特性的加入，還有 Latke 框架上的增強(qiáng)：

• 存儲(chǔ)緩存
  本地測(cè)試可以提升單一實(shí)體按 Key 訪問(wèn)時(shí)速度 400 倍左右。當(dāng)然，部署到 GAE 后可能沒這么好的效果 - -~

（廣告：Latke 是 GAE 上的一個(gè)應(yīng)用框架，主要整合了 Guice、FreeMarker、Jabsorb，數(shù)據(jù)模型從視圖到存儲(chǔ)都以 JSON 貫穿）

下個(gè)版本是 B3log Solo 的第一個(gè)正式版吧 :-)

P.S. 情侶博客？?jī)蓚€(gè)人也是多用戶嘛，0.2.5 中將加入一款皮膚，非常適合情侶寫作！謝謝 Lamb 這么給力！