不論是“站在巨人肩上”双藕，還是“不要重復(fù)造輪子”，都在不斷的提醒我們要充分利用周遭的各種有利條件降低自己的成本阳仔，而降低下來(lái)的成本就是利潤(rùn)忧陪。對(duì)軟件開(kāi)發(fā)而言也是如此，如果可以充分的有效的利用現(xiàn)有的各種開(kāi)源軟件項(xiàng)目的確可以大大降低軟件研發(fā)成本近范，提高軟件成熟度嘶摊，縮短軟件投入市場(chǎng)的時(shí)間。然而開(kāi)源項(xiàng)目是“雙刃劍”评矩，一方面引入開(kāi)源項(xiàng)目可以節(jié)省一定的成本叶堆，但是這也就使得一個(gè)軟件項(xiàng)目與另一個(gè)開(kāi)源項(xiàng)目有了關(guān)聯(lián)，甚至可能出現(xiàn)“開(kāi)源軟件項(xiàng)目的選取的優(yōu)劣將直接影響了項(xiàng)目的成敗”的情況斥杜。因此合理的評(píng)估一個(gè)開(kāi)源軟件項(xiàng)目就顯得尤為重要了虱颗。
本文希望提出幾個(gè)可以用于評(píng)估開(kāi)源軟件項(xiàng)目的指標(biāo)。
1蔗喂、背景
雖然說(shuō)“英雄不問(wèn)出身”忘渔，但是一般來(lái)說(shuō)一個(gè)由大型的專業(yè)化軟件組織推進(jìn)和維護(hù)的開(kāi)源項(xiàng)目比一個(gè)不知名的小團(tuán)隊(duì)維護(hù)的項(xiàng)目要靠譜的多；
2缰儿、應(yīng)用
應(yīng)用是否廣泛是評(píng)估開(kāi)源項(xiàng)目的最重要的指標(biāo)畦粮，因?yàn)椤叭航M的眼睛是雪亮的”，一般情況下，大家都說(shuō)好宣赔，都愿意使用的項(xiàng)目预麸，品質(zhì)一定不差。另外儒将，應(yīng)用在一個(gè)大型的軟件公司要比應(yīng)用在一個(gè)小型的軟件項(xiàng)目中更有說(shuō)服力吏祸；
3、活力
所謂“活性”主要看這個(gè)開(kāi)源項(xiàng)目更新的頻度和最近的一次更新的時(shí)間如何椅棺。因?yàn)閷?duì)軟件而言犁罩，“有問(wèn)題是必然的”，因此對(duì)一個(gè)軟件項(xiàng)目而言两疚，持續(xù)的更新和維護(hù)是必不可少的床估。選用一個(gè)已經(jīng)長(zhǎng)期沒(méi)有更新的項(xiàng)目是要承擔(dān)相當(dāng)風(fēng)險(xiǎn)的，因?yàn)橐坏┯袉?wèn)題诱渤，這個(gè)問(wèn)題往往就只能自己硬著頭皮解決丐巫；
4、社區(qū)
雖然“社區(qū)”可以被認(rèn)為是活力的一個(gè)方面勺美，但老土認(rèn)為有必要單獨(dú)拿出來(lái)作為一個(gè)獨(dú)立評(píng)價(jià)因素递胧。“眾人拾柴火焰高”赡茸，一個(gè)活躍的社區(qū)相當(dāng)于為你的項(xiàng)目團(tuán)隊(duì)增加了一批技術(shù)人員缎脾。這里需要特別說(shuō)明的是，通過(guò)向開(kāi)源社區(qū)貢獻(xiàn)代碼是提高個(gè)人技術(shù)影響力的重要手段占卧。
5遗菠、規(guī)模
打一個(gè)不太恰當(dāng)?shù)谋确骄椭肋@點(diǎn)指的是什么，你的軟件項(xiàng)目代碼有500行华蜒，結(jié)果為了這個(gè)項(xiàng)目引入了一個(gè)10萬(wàn)行級(jí)別的開(kāi)源項(xiàng)目辙纬。這本身就是一個(gè)笑話。當(dāng)然還要考慮BUG是與軟件規(guī)模成正比的叭喜，一個(gè)項(xiàng)目的規(guī)模越大贺拣，出問(wèn)題的可能性就越大，排查這個(gè)問(wèn)題的難度往往也會(huì)更大捂蕴，解決難度和周期也更長(zhǎng)譬涡。
6、文檔
文檔真的很重要啥辨。如果沒(méi)有好的文檔昂儒，想要從論壇中的一言兩語(yǔ)中理解一個(gè)項(xiàng)目，想要通過(guò)閱讀源代碼理解一個(gè)項(xiàng)目委可，那是非常難渊跋，非常耗時(shí)間的腊嗡。當(dāng)然有文檔，與有好的可用的文檔還是有差異的拾酝。不過(guò)這里說(shuō)的文檔不一定是大布頭的幫助文件燕少，也可能是wiki或是其他形式。
7蒿囤、獲取
獲取代碼的便利程度當(dāng)然很重要客们。如果是Python的開(kāi)源項(xiàng)目，自然是希望加入PyPI支持"pip install"的方式安裝材诽；如果是Java的開(kāi)源庫(kù)底挫，能從Maven中心庫(kù)獲得當(dāng)然最好。當(dāng)然github也是關(guān)鍵渠道脸侥！
下面轉(zhuǎn)一篇文章建邓，其中以在項(xiàng)目中引入MapReduce為例，探討了在引入某個(gè)開(kāi)源項(xiàng)目之前必要進(jìn)行的“考察和分析”睁枕。其中提出了UNPHAT方法官边，老土覺(jué)得不錯(cuò)，可以與老土在上面提出的方法結(jié)合使用外遇。老土提出的方法是從軟件項(xiàng)目的角度的評(píng)估注簿，而UNPHAT方法則是從技術(shù)適用性的角度的考量。
一拍腦袋就要用MapReduce跳仿？你以為你是Google肮羁省！（http://www.sohu.com/a/166385713_308467）
MapReduce,Hadoop,Kafka……似乎每天都有新的名詞出現(xiàn)菲语，每天都會(huì)有看似很酷的新技術(shù)誕生玩徊。是否我們現(xiàn)在的系統(tǒng)框架已經(jīng)過(guò)時(shí)了？是否應(yīng)該效仿谷歌谨究、亞馬遜或者領(lǐng)英的技術(shù)和方式？
本文作者提出的UNPHAT方法非常實(shí)用泣棋，它教你如何在急著行動(dòng)前胶哲，清醒的想一想，最適合自己的選擇才是對(duì)的潭辈。
除了技術(shù)/系統(tǒng)框架的抉擇鸯屿，這個(gè)方法對(duì)解決生活中的任何問(wèn)題都是不錯(cuò)的啟發(fā)。
21世紀(jì)把敢，每個(gè)人都多少有些谷歌狂熱癥寄摆，似乎按照谷歌的方式做事，我就能得到谷歌的財(cái)富修赞。比如婶恼，作為一名軟件工程師桑阶，我是否該效仿谷歌建立MapReduce框架？是否應(yīng)該像領(lǐng)英一樣用Kafka來(lái)搭建系統(tǒng)勾邦？
伯克利計(jì)算機(jī)學(xué)院教授Joe Hellerstein會(huì)在每次課上會(huì)告誡他的本科生：“你不是谷歌蚣录，你經(jīng)營(yíng)的可不是全球最大的互聯(lián)網(wǎng)數(shù)據(jù)服務(wù)【炱”
有興趣可參考視頻：https://archive.org/details/ucberkeley_webcast_NSKvCVFmk2E
事實(shí)上萎河，這個(gè)世界上目前只有5家公司在運(yùn)行著足夠巨大需要MapReduce框架的程序。而對(duì)于其他公司蕉饼，只是在 I/O(輸入輸出)上做了很多不必須的防錯(cuò)工作虐杯。
你們的數(shù)據(jù)中心大樓有多少層？谷歌的有4層昧港，上圖就是他們位于俄克拉荷馬州梅斯縣的數(shù)據(jù)中心擎椰。
這當(dāng)然也涉及了更多不必要的費(fèi)用的產(chǎn)生：一方面你需要做更多的I/O，另一方面你需要從一個(gè)使用了很久慨飘、相對(duì)成熟的系統(tǒng)轉(zhuǎn)移到一個(gè)你并不熟悉的系統(tǒng)确憨。這其實(shí)是一種大的退步。有多少Hadoop的用戶清醒地權(quán)衡過(guò)這些得失瓤的？又有多少用戶能對(duì)此做出明智的決定休弃？
如果你正在使用的技術(shù)來(lái)源于一家大公司，但是你的業(yè)務(wù)情景完全不同圈膏，你將很難從容地用他們的技術(shù)來(lái)實(shí)現(xiàn)同樣的效果塔猾。
恩，是的稽坤，這是另一篇“不要盲目崇拜新技術(shù)”的文章丈甸。
嘗試新技術(shù)前，先試試UNPHAT法則
軟件工程師有時(shí)會(huì)為些荒誕不羈的事情而瘋狂尿褪。當(dāng)需要選擇實(shí)用哪一種技術(shù)時(shí)睦擂，我們會(huì)從社交網(wǎng)絡(luò)里中某人的評(píng)論，跳到另一個(gè)人的博客杖玲，不斷的搖擺不定下不了決心顿仇，最終陷入到一種瘋狂的狀態(tài)。迷茫中摆马，我們總是朝著那些好像最耀眼的光芒漂游著臼闻，卻忘記了我們真正尋找的是什么。
下一次囤采，當(dāng)你發(fā)現(xiàn)自己在網(wǎng)上了搜索 某些很酷的技術(shù)去（重新）搭建架構(gòu)時(shí)述呐，請(qǐng)先用這個(gè)UNPHAT 法則對(duì)這個(gè)新技術(shù)進(jìn)行審視：
Understand (理解）：在你理解問(wèn)題之前，不要開(kāi)始思考解決方案蕉毯。應(yīng)該從問(wèn)題入手乓搬，而不是從答案入手思犁。在問(wèn)題的領(lǐng)域思考如何結(jié)局，而不是在“解決方案的領(lǐng)域”里選擇解決辦法缤谎。
Numerate(列舉）：請(qǐng)列舉出多個(gè)候選方案抒倚，而不是直接選擇你喜歡的那個(gè)。
Paper (論文）：選定一個(gè)候選方案坷澡。如果你找到一篇候選方案的論文的話托呕，請(qǐng)閱讀它。
Historical Context (歷史背景）：在設(shè)計(jì)和開(kāi)發(fā)候選方案時(shí)频敛，請(qǐng)考慮相關(guān)方法的歷史背景项郊。
Advantage （優(yōu)勢(shì)）：權(quán)衡利弊。決定使用什么樣的優(yōu)先級(jí)來(lái)排序所列出的利弊斟赚。
Think! (思考着降！)： 冷靜而謙遜地思考這個(gè)解決方案與你的問(wèn)題的匹配狀況∞志考慮出現(xiàn)什么樣的情況任洞，你會(huì)改變自己的想法？例如发侵，數(shù)據(jù)集小到什么程度交掏，你會(huì)決定放棄使用Hadoop？
你不是亞馬遜
下面是一個(gè)很簡(jiǎn)單的使用UNPHAT方法的例子刃鳄。我最近和某家公司就是否使用Cassandra對(duì)夜間產(chǎn)生的大批量工作流數(shù)據(jù)進(jìn)行讀取的問(wèn)題展開(kāi)了討論盅弛。
我讀過(guò)Dynamo的論文，而且我知道Cassandra是一個(gè)Dynamo的衍生物叔锐，所以我清楚地了解這些分布式數(shù)據(jù)庫(kù)將讀寫可用性放在第一位（亞馬遜希望所有的“添加到購(gòu)物車”行為永遠(yuǎn)不會(huì)失斉才簟）。我也知道他們是通過(guò)部分降低數(shù)據(jù)庫(kù)的一致性來(lái)提高它的讀寫可用性愉烙，這會(huì)對(duì)傳統(tǒng)關(guān)系型數(shù)據(jù)管理系統(tǒng)中的幾乎所有特性都會(huì)產(chǎn)生一定影響讨盒。但是與我交談的這家公司并不需要將讀寫可用性放在第一位，因?yàn)樗麄兊膫鬏斈Ｊ绞且惶爝M(jìn)行一次大批量的讀寫步责。
亞馬遜出售大批量商品返顺。如果“添加到購(gòu)物車”功能偶爾發(fā)生故障，他們可能會(huì)損失很多收益勺择，但是你的使用場(chǎng)景也是這樣嗎？
這家公司之所以想要使用Cassandra是因?yàn)镻ostgreSQL在讀取文件時(shí)需要好幾分鐘的時(shí)間伦忠，他們認(rèn)為這是一個(gè)硬件限制問(wèn)題省核。在問(wèn)了幾個(gè)問(wèn)題后，我們確定了如果需要從固態(tài)硬盤中讀取一個(gè)5000萬(wàn)行昆码、80字節(jié)寬的表格的完整的文件气忠，大概需要5秒邻储。雖然這個(gè)速度比較慢，但是仍比實(shí)際查詢快了2個(gè)數(shù)量級(jí)旧噪。
此時(shí)吨娜，我需要再多問(wèn)一些問(wèn)題（來(lái)理解他們的問(wèn)題），并衡量為防止問(wèn)題變得嚴(yán)重的5個(gè)策略（列出多個(gè)候選方案Ｌ灾印）宦赠，但是我已經(jīng)很清楚地知道使用Cassandra是一個(gè)完全錯(cuò)誤的解決方案。他們需要去做的是耐心調(diào)試原有的結(jié)構(gòu)米母，或者重新搭建一些數(shù)據(jù)結(jié)構(gòu)勾扭，或者選擇其他的技術(shù)方案（應(yīng)該不需要）……但肯定不是亞馬遜為購(gòu)物車所搭建的高讀寫可用性的關(guān)鍵值存儲(chǔ)方案！
你不是領(lǐng)英
我很驚奇地發(fā)現(xiàn)有個(gè)學(xué)生的公司選擇使用Kafka來(lái)搭建他們的系統(tǒng)铁瞒。而他們的業(yè)務(wù)流程只有每天幾十條高價(jià)值交易妙色，如果生意好的話，可能一百多條慧耍。對(duì)于這個(gè)吞吐量而言身辨，一個(gè)人手工去進(jìn)行記錄就可以完成數(shù)據(jù)庫(kù)存儲(chǔ)了。
相對(duì)而言芍碧，Kafka是為了處理領(lǐng)英上所有的待分析的事件而設(shè)計(jì)的：這是一個(gè)很巨大的數(shù)字煌珊。即使是幾年前，這個(gè)數(shù)字可以達(dá)到每天處理萬(wàn)億事件师枣，在高峰時(shí)期可以超過(guò)每秒一千萬(wàn)的信息量怪瓶。我同意Kafka對(duì)于低吞吐量的工作負(fù)荷同樣有效，但是相比之下践美，低了十個(gè)數(shù)量級(jí)的數(shù)據(jù)真的需要Kafka嗎洗贰？
或許工程師們根據(jù)預(yù)期需要和對(duì)Kafka理論基礎(chǔ)的充分理解陨倡，“確實(shí)”做了一個(gè)經(jīng)過(guò)考量的決定敛滋。但我估計(jì)他們是被一些社交網(wǎng)站（通常是合理的評(píng)論）中對(duì)Kafka的熱情所洗腦，而幾乎沒(méi)有考慮它是否適合這個(gè)問(wèn)題兴革。畢竟……這個(gè)是差了十個(gè)數(shù)量級(jí)的情況绎晃。
回到亞馬遜
比亞馬遜分布式數(shù)據(jù)存儲(chǔ)架構(gòu)更受歡迎的是能支持他們規(guī)模化的面向服務(wù)的體系結(jié)構(gòu)：service-oriented architecture（SOA）杂曲。Werner Vogels在2006年對(duì)Jim Gray的采訪中提到庶艾，在2001年亞馬遜意識(shí)到他們擴(kuò)展前端受到限制，從而設(shè)計(jì)了一個(gè)面向服務(wù)的架構(gòu)最終解決了這個(gè)問(wèn)題擎勘。這種想法在工程師中產(chǎn)生了巨大影響咱揍，甚至只有幾個(gè)工程師和很少的用戶的創(chuàng)業(yè)公司都開(kāi)始將他們的APP分解為一系列的迷你服務(wù)了。
但是當(dāng)亞馬遜決定遷移到SOA的時(shí)候棚饵，他們已有大概7800名雇員煤裙，而且銷售額超過(guò)了三十億美金掩完。
而亞馬遜決定轉(zhuǎn)向到面向服務(wù)的框架（SOA）的時(shí)候，它的雇員大約有7800人硼砰。
我并不是說(shuō)當(dāng)你有7800名雇員的時(shí)候你才可以轉(zhuǎn)向SOA且蓬。只是希望你可以思考，SOA對(duì)你的問(wèn)題而言是最好的解決方案嗎题翰？你的問(wèn)題到底是什么恶阴，以及你是否可以使用其他方法解決？
如果你說(shuō)你的50人的工程師團(tuán)隊(duì)如果沒(méi)有SOA就會(huì)難以運(yùn)轉(zhuǎn)遍愿，那么我會(huì)很好奇為什么那么多大公司使用一個(gè)很大但是管理得很好的單個(gè)應(yīng)用程序也可以做的很好存淫。
即使谷歌也不是谷歌
使用大型數(shù)據(jù)流引擎類似Hadoop和Spark也會(huì)特別有趣：通常，傳統(tǒng)的數(shù)據(jù)庫(kù)管理系統(tǒng)（DBMS）更適合于整體的工作負(fù)載沼填，有時(shí)候數(shù)據(jù)量非常小桅咆，甚至可以存儲(chǔ)在內(nèi)存中。你知道可以使用10000美元購(gòu)買一個(gè)千兆的內(nèi)存條（RAM）嗎坞笙？即使您擁有十億用戶岩饼，它仍可以為每個(gè)用戶提供1kb的內(nèi)存。
或許對(duì)于你的工作負(fù)載而言可能還不夠薛夜，你需要對(duì)硬盤進(jìn)行讀寫籍茧。但是你需要對(duì)數(shù)以千計(jì)的磁盤進(jìn)行讀寫嗎？確切的說(shuō)梯澜，你擁有多少數(shù)據(jù)呢寞冯？GFS（可擴(kuò)展的分布式文件系統(tǒng)）和MapReduce是為了處理整個(gè)網(wǎng)絡(luò)的計(jì)算量而創(chuàng)造的，例如晚伙，在整個(gè)網(wǎng)絡(luò)上重建搜索引擎……
上圖：硬盤驅(qū)動(dòng)器的每千兆字節(jié)的成本（美元）吮龄。今天的硬盤驅(qū)動(dòng)器價(jià)格比2003年（GFS研究論文發(fā)布那年）低了很多很多。
或許你已經(jīng)閱讀了GFS和MapReduce的相關(guān)論文咆疗，而且很感謝谷歌的問(wèn)題出現(xiàn)在輸入輸出量而不是容量上：他們進(jìn)行分布式存儲(chǔ)漓帚，因?yàn)榇疟P存儲(chǔ)需要太長(zhǎng)時(shí)間。在2017年你將使用的硬件設(shè)備會(huì)有多大的輸入輸出量呢午磁？考慮到你不會(huì)需要和谷歌一樣的輸入輸出量尝抖，你是否只需要買一個(gè)更好的磁盤呢？使用SSD你會(huì)花多少錢呢迅皇？
或許你期望可以進(jìn)行規(guī)拿亮桑化。但是你有進(jìn)行過(guò)數(shù)學(xué)計(jì)算嗎登颓？你累積數(shù)據(jù)的速度會(huì)比SSD價(jià)格下降的速度更快嗎搅荞？你的業(yè)務(wù)需要增長(zhǎng)多少，你的數(shù)據(jù)才會(huì)多到不能放在一臺(tái)機(jī)器上。在2016年取具，Stack Exchange網(wǎng)站每天收到2億個(gè)請(qǐng)求，而他們的后臺(tái)僅僅是4臺(tái)SQL服務(wù)器扁耐，一臺(tái)主要服務(wù)于Stack Overflow網(wǎng)站暇检，一臺(tái)為其他事物服務(wù)，其他兩臺(tái)用來(lái)保存副本婉称。
再次重申块仆，你走完整個(gè)UNPHAT流程后，可能仍然決定使用Hadoop或者Spark王暗。這個(gè)決定有可能是正確的悔据。最重要的是俗壹，對(duì)于這個(gè)問(wèn)題绷雏，你真的選擇了最合適的工具涎显。在這一點(diǎn)上，谷歌做的很好：當(dāng)他們發(fā)現(xiàn)MapReduce不是構(gòu)建索引最合適的工具后早歇，他們就不再使用它了箭跳。
最重要的是理解問(wèn)題
我上面提到的并不是全新的內(nèi)容衅码，但也許它能引起你的思考脊岳，或許使用UNPHAT對(duì)你來(lái)說(shuō)有難以置信的效果割捅。如果是這樣亿驾，你可以嘗試Rich Hickey談話中（https://www.youtube.com/watch?v=f84n5oFoZBc）所提到的“吊床推動(dòng)發(fā)展”，或者Polya書中（https://www.amazon.com/How-Solve-Mathematical-Princeton-Science/dp/069111966X）寫到的“如何解決一個(gè)問(wèn)題”儡蔓，或者Hamming的課程中（https://www.youtube.com/playlist?list=PL2FF649D0C4407B30）所提到的“科學(xué)和工程實(shí)踐的藝術(shù)”。我們希望你可以去思考并真正的了解你正在嘗試解決的問(wèn)題召锈！
最后获询，我想以Ploya書中令人警醒的一段話作為結(jié)尾：
去回答一個(gè)你不明白的問(wèn)題是愚蠢的。為了一個(gè)你并不想要的結(jié)局而努力是悲哀的梢薪。
