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

Quora 上有一個(gè)討論串，題目是“Larry Page 上任之后，Google 的重點(diǎn)應(yīng)該是什么？”，討論相當(dāng)活躍。我也在這里湊個(gè)熱鬧，談一談在我看來，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)上來說，ifanr 感同身受。作為內(nèi)容提供者，我們是創(chuàng)造價(jià)值的人，是在給互聯(lián)網(wǎng)不斷添磚加瓦的一方。而之前在 Google 里搜索我們的原創(chuàng)文章，出現(xiàn)在結(jié)果最頂端的卻往往是是通過拷貝+粘貼、有時(shí)候還不注明出處進(jìn)行轉(zhuǎn)載的內(nèi)容聚合站點(diǎn)。它們用毫無成本的方式奪取著應(yīng)該屬于原 作者的訪問量。

好在 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)來看，似乎 Google 已經(jīng)采取了措施，最近 ifanr 的原創(chuàng)文章都出現(xiàn)在首頁頭條。從根子上（點(diǎn)擊量帶來的經(jīng)濟(jì)利益）驅(qū)逐劣質(zhì)內(nèi)容聚合站點(diǎn)，對(duì)現(xiàn)代互聯(lián)網(wǎng)來說，確實(shí)是件好事

搜索，是 Google 的立身之本，從上周發(fā)布的財(cái)報(bào)來看，Google 收入的主要增長點(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)注的。未來十年的搜索是什么樣子？如何提高內(nèi)容關(guān)聯(lián)性，改進(jìn)使用體驗(yàn)？怎么樣通過創(chuàng)新，把 Bing 等競(jìng)爭(zhēng)對(duì)手遠(yuǎn)遠(yuǎn)甩開，對(duì) Google 來說，至關(guān)重要。

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

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

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

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

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

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

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

Google 的最大優(yōu)勢(shì)是什么？大家應(yīng)該都非常清楚，其一是龐大的用戶群，其二就是信息了。Google 相對(duì)于 Twittter、fousquare 等來說，先天就有信息方面的優(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)常用它來尋找晚餐地點(diǎn)，最大的好處之一就是可以看到多個(gè)網(wǎng)站的用戶評(píng)價(jià)，看看截圖：

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

放著龐大的現(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è)置界面說起。Android 平鋪直敘的設(shè)置界面，完全沒有突出重點(diǎn)（我甚至懷疑這幫人安排順序的時(shí)候是不是拍腦門做出的決定。），跟右邊的 iOS 比，孰優(yōu)孰劣，一目了然。

還有應(yīng)用市場(chǎng)，每次談到 Android 的應(yīng)用市場(chǎng)，我都有爆粗口的沖動(dòng)。緩慢的速度、時(shí)常丟失的已下載應(yīng)用列表、遲遲沒有解決的應(yīng)用無法下載問題……這是整個(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è)人的意義，無論如何贊揚(yáng)也不會(huì)過分，它直接引領(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ò)，但我要說，還是不夠靈活，如果能提供更多語言支持，就再好不過了。

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

降低所消耗能源的碳排放，對(duì)于 Google 這種能源消耗大戶來說，是經(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 的員工無疑是優(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)闇贤▎栴}，好的項(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)來適應(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

沒有人能說清哪種緩存算法優(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ì)把最新被訪問的緩存對(duì)象，放到緩存池的頂部。

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

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

Least Recently Used 2（LRU2）：

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

Two Queues（2Q）：

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

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

Adaptive Replacement Cache（ARC）：

我是 ARC，有人說我是介于 LRU 和 LFU 之間，為了提高效果，我是由2個(gè) LRU 組成，第一個(gè)，也就是 L1，包含的條目是最近只被使用過一次的，而第二個(gè) LRU，也就是 L2，包含的是最近被使用過兩次的條目。因此， L1 放的是新的對(duì)象，而 L2 放的是常用的對(duì)象。所以，別人才會(huì)認(rèn)為我是介于 LRU 和 LFU 之間的，不過沒關(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ì)問我為什么。好吧，讓我告訴你，當(dāng)一次訪問過來的時(shí)候，有些事情是無法預(yù)測(cè)的，并且在緩存系統(tǒng)中找出最少最近使用的對(duì)象是一項(xiàng)時(shí)間復(fù)雜度非常高的運(yùn)算，這就是為什么我是最好的選擇。

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

First in First out（FIFO）：

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

Second Chance：

大家好，我是 second chance，我是通過FIFO修改而來的，被大家叫做 second chance 緩存算法，我比 FIFO 好的地方是我改善了 FIFO 的成本。我是 FIFO 一樣也是在觀察隊(duì)列的前端，但是很FIFO的立刻踢出不同，我會(huì)檢查即將要被踢出的對(duì)象有沒有之前被使用過的標(biāo)志（1一個(gè)bit表示），沒有沒有被使用 過，我就把他踢出；否則，我會(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ì)問問指針指向的緩存對(duì)象的標(biāo) 志位去決定我應(yīng)該怎么做。如果標(biāo)志是0，我會(huì)直接用新的緩存對(duì)象替代這個(gè)緩存對(duì)象；如果標(biāo)志位是1，我會(huì)把頭指針遞增，然后重復(fù)這個(gè)過程，知道新的緩存對(duì) 象能夠被放入。我比second chance更快。

Simple time-based：

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

Extended time-based expiration：

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

Sliding time-based expiration：

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

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

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

根據(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，還是比較無奈的....

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

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

在 stackoverflow 上也有人提過該問題，總結(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）來過濾實(shí)體保存的隨機(jī)值屬性。

這個(gè)方法基本可以達(dá)到隨機(jī)的效果了，為了讓隨機(jī)的效果更動(dòng)態(tài)一點(diǎn)，我們可以考慮經(jīng)常更新文章實(shí)體中的隨機(jī)浮點(diǎ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來說，今年最大的事件莫過于jBPM的創(chuàng)建者Tom Baeyens離開JBoss了。Tom Baeyens離開的具體原因尚不清楚，但他的離開產(chǎn)生了兩個(gè)結(jié)果：一是jBPM的下一個(gè)版本jBPM5完全放棄了jBPM4的基礎(chǔ)代碼，基于Drools Flow重頭來過；二是Tom Baeyens加入Alfresco后很快推出了新的基于jBPM4的開源工作流系統(tǒng)Activiti。 由此不難推測(cè)Tom Baeyens離開的部分原因：JBoss內(nèi)部對(duì)jBPM未來版本的架構(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ú)立部署的問題，因?yàn)椴还苁莏BPM還是Activiti，都強(qiáng)調(diào)了流程服務(wù)的可嵌入性。此外，我們還需要討論一下什么是BPMS的特性，它們所解決的問題是什么。

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

不管是jBPM還是Activiti，都強(qiáng)調(diào)了流程服務(wù)的可嵌入性。Tom Baeyens在其個(gè)人博客里稱作為獨(dú)立部署的BPMS已死，原因有兩個(gè)：一是獨(dú)立部署的BPMS需要很高的安裝使用成本，需要獨(dú)立部署、需要用戶支出大 量的培訓(xùn)成本和維護(hù)成本；二是獨(dú)立部署的BPMS與外部系統(tǒng)的交互方式是分布式，這使得很多問題變得復(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所要解決的問題要求其必然是獨(dú)立部署的。Tom Baeyens錯(cuò)誤的根本原因在于其將BPMS與工作流系統(tǒng)的定義混為了一談，他如此定義BPMS：BPMS旨在簡(jiǎn)化對(duì)組織核心流程進(jìn)行支撐的軟件創(chuàng)建。 也就是BPMS面向的是軟件開發(fā)人員，旨在簡(jiǎn)化他們的開發(fā)，降低他們使用流程的門檻。而這正是工作流系統(tǒng)需要解決的問題。

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

二、BPMS特性

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

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

   • 提供跨越組織的流程標(biāo)準(zhǔn)標(biāo)記符號(hào)與術(shù)語（BPMN已經(jīng)成為標(biāo)準(zhǔn)）
   • 流程及相關(guān)文檔的可視化（流程/內(nèi)容存儲(chǔ)倉庫）
   • 提供在組織結(jié)構(gòu)內(nèi)進(jìn)行不同層次之間的流程導(dǎo)航（流程存儲(chǔ)倉庫支持組織模型）
   • 流程定義在各個(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í)行流程過程中遵循業(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核心庫。如下圖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)行過程中需要人工處理的任務(wù)；二是對(duì)案例的狀態(tài)進(jìn)行監(jiān)控與管理。實(shí)現(xiàn)了工作流管理系統(tǒng)參考模型里的接口2和5。

3. jPDL核心庫

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

   • 流程倉庫：解析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é)束事件，通過監(jiān)聽者模式調(diào)用相應(yīng)的事件處理器；
   • 異步執(zhí)行機(jī)制：通過線程實(shí)現(xiàn)了Job Executor，進(jìn)行異步工作的處理，這些工作包括了時(shí)間處理、異步動(dòng)作。
   • 身份組件模型：實(shí)現(xiàn)了一套簡(jiǎn)單的身份組件模型，包括了組、用戶和權(quán)限。

   通過調(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)行中加入自己定制的行為（通 過事件處理器和Action）。jBPM3面向開發(fā)人員，它解決的問題是流程的自動(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言規(guī)范，從最開始的XPDL、BPEL 到后來的BPMN，它采用了自定義的jPDL。在jBPM3中，節(jié)點(diǎn)的運(yùn)行期行為與jPDL里定義的節(jié)點(diǎn)類型是一一綁定的，這造成了流程引擎與特定流程語 言的綁定，要支持其他的流程語言變得困難。于是在jBPM4中，jBPM提出了流程虛擬機(jī)的概念，即流程引擎與流程語言解耦，通過一套通用的流程模型并配 以可定制的節(jié)點(diǎn)運(yùn)行期行為實(shí)現(xiàn)了對(duì)多流程語言的支持。

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

   第二是實(shí)現(xiàn)了基于流程組件的流程引擎，流程圖(語言)與實(shí)現(xiàn)解耦，我們使用通用編程語言實(shí)現(xiàn)節(jié)點(diǎn)運(yùn)行期行為，稱之為流程組件，通過將流程圖 與流程組件掛接，避免了圖的損耗。在這一點(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)域特定語言（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)用中，通過DSL是可以做到的）；其次是通過BPMS將業(yè)務(wù)人員的模型與實(shí)際執(zhí)行的技術(shù)模型關(guān)聯(lián)起來（很多商業(yè)產(chǎn) 品已經(jīng)做到了這一點(diǎn)，在Activiti5中我們也會(huì)看到這一點(diǎn)），業(yè)務(wù)人員、開發(fā)人員以及運(yùn)營團(tuán)隊(duì)之間能夠做到很好的協(xié)調(diào)；最差是業(yè)務(wù)人員與開發(fā)人員各 自為政，獨(dú)立維護(hù)各自的流程模型，并且模型之間存在極大的不匹配，此時(shí)流程的迅速變化基本上是奢望。

五、鳩占鵲巢的Drools Flow與jBPM5

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

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

圖 4：jBPM5組件

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

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

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

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

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

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

六、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í)庫管理、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ù)庫表的檢視、日志查看、事務(wù)的平均執(zhí)行時(shí)間、失敗多次的工作等功能。

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

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

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

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

Activiti Cycle完全是一種新類型的BPM組件。它是一個(gè)用來促進(jìn)業(yè)務(wù)人員、開發(fā)人員和IT運(yùn)營人員協(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)理用文檔來維護(hù)需求和visio格式的流程圖，開發(fā)人員管理可執(zhí)行的流程和大量的Java源文件而IT維護(hù)人員則管理部署在 Tomcat中的.war文件和存儲(chǔ)在Activiti數(shù)據(jù)庫中的流程。

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

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

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

七、總結(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，通過與Drools的合并支持BAM，通過內(nèi)容倉庫增加對(duì)流程可視化的支持。由于放棄了jBPM4的PVM，引擎的可擴(kuò)展性受到損害，并且不再支持jPDL。

Activiti5基于jBPM4，與Alfresco的集成增加了其流程可視化與管理能力，同時(shí)通過創(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)過程，目前正與辛鵬合著《Head First Process-深入淺出IT流程》一書。博客地址http://ronghao.javaeye.com。

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

有很多理由都能說明為什么我們應(yīng)該寫出清晰、可讀性好的程序。最重要的一點(diǎn)，程序你只寫一次，但以后會(huì)無數(shù)次的閱讀。當(dāng)你第二天回頭來看你的代碼 時(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ì)待你的語言
7. 不要逆常規(guī)而行
8. 警惕過早優(yōu)化
9. 積極重構(gòu)測(cè)試過的程序
10. 不要過度沉迷于技巧
11. 通過習(xí)例學(xué)習(xí)新知

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

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

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

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

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

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

你的代碼應(yīng)該，對(duì)于任何人來說，只要看一眼就能知道是干嘛的。盡量不要用簡(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í)(距離超過一個(gè)屏幕)，這確實(shí)會(huì)成為一個(gè)問題。記住上下文關(guān)系會(huì)變得困難，你需要滾動(dòng)屏幕去找哪來的這個(gè)變量。

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

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

il < 4384

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

inputLength < MAX_INPUT_LENGTH

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

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

當(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

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

5.times { puts "Hello world!" }

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

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

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

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

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

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

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

不要傻乎乎的去解決根本不存在的問題。

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

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

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

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

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

10. 不要過度沉迷于技巧

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

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

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

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

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

最好的方式是你先用jQuery寫一些簡(jiǎn)單的例子，通過這種方式把你在應(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

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

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

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

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

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

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

現(xiàn) 場(chǎng)很多小區(qū)業(yè)主都目睹了張俊被毆打的過程，“總共被打了兩次。”張俊的鄰居老邢說。同樣目睹事情經(jīng)過的程先生也說，張俊大概被毆打了10多分鐘，他遠(yuǎn)遠(yuǎn)看 著張俊滿臉都是血，倒在地上。他聽到在場(chǎng)的一位執(zhí)法人員對(duì)著幾乎快暈厥過去的張俊喊道：“裝死。”張俊的好友陳小姐說，現(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ì)長被拘留，但此說法未得到有關(guān)部門的證實(shí)。

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

過去與今天
詞 \ 黃家駒. 曲 \ 黃家駒. 主唱 \ 黃家駒.

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

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

主要功能：

支持?jǐn)?shù)據(jù)同步客戶端：安裝 EverBox后，您所需的文件都將自動(dòng)同步到設(shè)備上，可以隨時(shí)、隨地的使用手邊的任意一款設(shè)備訪問文件了。目前提供了 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ù)易如反掌！

在線音樂播放：EverBox 支持在線音樂播放功能，幾乎支持所有常用的音頻格式，使用簡(jiǎn)單、便捷，無需操作即可連續(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，這些問題將迎刃而解！只需安裝 EverBox，您所需的文件都將自動(dòng)同步到設(shè)備上，您就可以隨時(shí)、隨地的使用手邊的任意一款設(shè)備訪問文件了。當(dāng)然，使用瀏覽器一樣可以訪問到您需要的文件。

   

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

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

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

   

4. 在線音樂播放

   EverBox 支持在線音樂播放功能，幾乎支持所有常用的音頻格式，使用簡(jiǎn)單、便捷，無需操作即可連續(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í)例不一致
• 文章訪問次數(shù)統(tǒng)計(jì)失效
• IE8 下 Feed 不能顯示

改進(jìn)

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

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

升級(jí)

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

項(xiàng)目

如果在使用、測(cè)試中發(fā)現(xià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ì)來說規(guī)模較大的項(xiàng)目，因此有必要做一下總結(jié)。

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

如果按平臺(tá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)單起來就是：

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

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

下面從技術(shù)角度來比較一下這兩個(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上你用了多長時(shí)間安裝，我敢打 賭你會(huì)超過一個(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)在可以通過腳本自動(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所說的那樣，抽象水平應(yīng)作為挑選云計(jì)算平臺(tái)的一個(gè)基本原則，你需要做的是駕駛，不需要研究引擎蓋以下的東西。在我看來，如果你的核心業(yè)務(wù)是 貨物運(yùn)輸，那么你應(yīng)該買一輛卡車，它能高效地把你的貨物從A地運(yùn)輸?shù)紹地，相反，你不應(yīng)該考慮如何購買零部件自己組裝一輛卡車。

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

4、可靠性

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

5、可移植性

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

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

對(duì)Google App Engine來說，應(yīng)用程序維護(hù)和升級(jí)是件輕而易舉的事，它為各種應(yīng)用程序提供了一個(gè)詳細(xì)的管理面板，包括日志查看器和數(shù)據(jù)查看器，一個(gè)程序可以有多個(gè)版 本，當(dāng)新版本經(jīng)過測(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問和控制權(quán)。

9、語言支持

截至目前，Google App Engine支持Java和Python，但任何可以轉(zhuǎn)換成字節(jié)碼，可在JVM上執(zhí)行的任何編程語言都可以在Google App Engine上運(yùn)行，如果你喜歡其它編程語言，最好選擇Amazon EC2，因?yàn)槟憧梢栽谒牟僮飨到y(tǒng)上面安裝語言運(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上。

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

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