作為一個技術(shù)從業(yè)者十年，逛了十年發(fā)現(xiàn)有些知識東一榔頭西一棒槌的得滿世界 看個遍才整理出個頭緒，那咱就系統(tǒng)點的從頭一步一步的說，一個從日幾千訪問的小小網(wǎng)站，到日訪問一兩百萬的小網(wǎng)站，怎么才能讓它平滑的度過這個階段，別在 技術(shù)上出現(xiàn)先天不足，寫給一些技術(shù)人員，也寫給不懂技術(shù)的創(chuàng)業(yè)者。

對互聯(lián)網(wǎng)有了解的人都有自己的想法，有人就把想法付諸實現(xiàn)，做個網(wǎng)站然后開始運營。其實從純網(wǎng)站技術(shù)上來說，因為開源模式的發(fā)展，現(xiàn)在建一個小網(wǎng)站 已經(jīng)很簡單也很便宜。當訪問量到達一定數(shù)量級的時候成本就開始飆升了，問題也開始顯現(xiàn)了。因為帶寬的增加、硬件的擴展、人員的擴張所帶來的成本提高是顯而 易見的，而還有相當大的一部分成本是因為代碼重構(gòu)、架構(gòu)重構(gòu)，甚至底層開發(fā)語言更換引起的，最慘的就是數(shù)據(jù)丟失，辛辛苦苦好幾年，一夜回到創(chuàng)業(yè)前。

減少成本就是增加利潤。很多事情，我們在一開始就可以避免，先打好基礎(chǔ)，往后可以省很多精力，少操很多心。

假設(shè)你是一個參與創(chuàng)業(yè)的技術(shù)人員，當前一窮二白，什么都要自己做，自己出錢，初期幾十萬的資金，做一個應(yīng)用不是特別復(fù)雜的網(wǎng)站，那么就要注意以下幾點：

一、開發(fā)語言

一般來說，技術(shù)人員（程序員）創(chuàng)業(yè)都是根據(jù)自己技術(shù)背景選擇自己最熟悉的語言，不過考慮到不可能永遠是您一個人寫程序，這點還得仔細想想。無論用什么語言，最終代碼質(zhì)量是看管理，所以我們還是從純語言層面來說實際一點?，F(xiàn)在流行的java、php、.net、python、ruby都 有自己的優(yōu)劣，python和ruby，現(xiàn)在人員還是相對難招一些，性能優(yōu)化也會費些力氣，.net平臺買不起windows server。java、php用的還是最多。對于初期，應(yīng)用幾乎都是靠前端支撐的網(wǎng)站來說，php的優(yōu)勢稍大一些，入門簡單、設(shè)計模式簡單、寫起來快、 性能足夠等，不過不注重設(shè)計模式也是它的劣勢，容易變得松散，隱藏bug稍多、難以維護。java的優(yōu)勢在于整套管理流程已經(jīng)有很多成熟工具來輔助，強類 型也能避免一些弱智BUG，大多數(shù)JAVA程序員比較注重設(shè)計模式，別管實不實際，代碼格式看起來還是不錯的。這也是個劣勢，初學(xué)者可能太注重模式而很難 解決實際需求。

前端不只是html、css這類。整個負責(zé)跟用戶交互的部分都是前端，包括處理程序。這類程序還是建議用php，主要原因就是開發(fā)迅速、從業(yè)人員廣泛。至于后端例如行為分析、銀行接口、異步消息處理等，隨便用什么程序，那個只能是根據(jù)不同業(yè)務(wù)需求來選擇不同語言了。

二、代碼版本管理

如果開發(fā)人員之間的網(wǎng)絡(luò)速度差不多，就SVN；比較分散例如跨國，就hg。大多數(shù)人還是svn的.

假設(shè)選了svn，那么有幾點考慮。一是采用什么樹結(jié)構(gòu)。初期可能只有一條主干，往后就需要建立分支，例如一條開發(fā)分支，一條上線分支，再往后，可能 要每個小組一個分支。建議一開始人少時選擇兩條分支，開發(fā)和線上，每個功能本地測試無誤后提交到開發(fā)分支，最后統(tǒng)一測試，可以上線時合并到上線分支。如果 喜歡把svn當做移動硬盤用，寫一點就commit一次也無所謂，就是合并的時候頭大一些，這些人可以自己建個分支甚至建立個本地代碼倉庫，隨便往自己的 分支提交，測試完畢后再提交到開發(fā)分支上。

部署，可以手工部署也可以自動部署。手工部署相對簡單，一般是直接在服務(wù)器上svn update，或者找個新目錄svn checkout，再把web root給ln -s過去。應(yīng)用越復(fù)雜，部署越復(fù)雜，沒有什么統(tǒng)一標準，只要別再用ftp上傳那種形式就好，一是上傳時文件引用不一致錯誤率增加，二是很容易出現(xiàn)開發(fā)人員 的版本跟線上版本不一致，導(dǎo)致本來想改個錯字結(jié)果變成回滾的杯具。如果有多臺服務(wù)器還是建議自動部署，更換代碼的機器從當前服務(wù)池中臨時撤出，更新完畢后 再重新加入。

不管項目多小，養(yǎng)成使用版本管理的好習(xí)慣，最起碼還可以當做你的備份，我的 http://zhiyi.us 雖然就是一個wordpress，可還是svn了，只改動一兩句css那也是勞動成果。

三、服務(wù)器硬件

別羨慕大客戶和有錢人，看看機房散戶區(qū)，一臺服務(wù)器孤獨的支撐的網(wǎng)站數(shù)不清。如果資金稍微充足，建議至少三臺的標準配置，分別用作web處理、數(shù)據(jù) 庫、備份。web服務(wù)器至少要8G內(nèi)存，雙sata raid1，如果經(jīng)濟稍微寬松，或靜態(tài)文件或圖片多，則15k sas raid1+0。數(shù)據(jù)庫至少16G內(nèi)存，15k sas raid 1+0。備份服務(wù)器最好跟數(shù)據(jù)庫服務(wù)器同等配置。硬件可以自己買品牌的底板，也就是機箱配主板和硬盤盒，CPU內(nèi)存硬盤都自己配，也可以上整套品牌，也可 以兼容機。三臺機器，市場行情6、7萬也就配齊了。

web服務(wù)器可以既跑程序又當內(nèi)存緩存，數(shù)據(jù)庫服務(wù)器則只跑主數(shù)據(jù)庫（假如是MySQL的話），備份服務(wù)器干的活就相對多一些，web配置、緩存配置、數(shù)據(jù)庫配置都要跟前兩臺一致，這樣WEB和數(shù)據(jù)庫任意一臺出問題，把備份服務(wù)器換個ip就切換上去了。備份策略，可以drbd，可以rsync，或者其他的很多很多的開源備份方案可選擇。rsync最簡單，放cron里自己跑就行。備份和切換，建議多做測試，選最安全最適合業(yè)務(wù)的，并且盡可能異地備份。

四、機房

三種機房盡量不要選：聯(lián)通訪問特別慢的電信機房、電信訪問特別慢的聯(lián)通機房、電信聯(lián)通訪問特別慢的移動或鐵通機房。那網(wǎng)通機房呢？親，網(wǎng)通聯(lián)通N久 以前合并改叫聯(lián)通了。多多尋找，實地參觀，多多測試，多方打探，北京、上海、廣州等各個主節(jié)點城市，還是有很多優(yōu)質(zhì)機房的，找個網(wǎng)絡(luò)質(zhì)量好，管理嚴格的機 房，特別是管理要嚴格，千萬別網(wǎng)站無法訪問了，打個電話過去才知道別人維護時把你網(wǎng)線碰掉了，這比DOS都頭疼。自己扯了幾根光纖就稱為機房的，看您抗風(fēng) 險程度和心理素質(zhì)了。機房可以說是非常重要，直接關(guān)系到網(wǎng)站訪問速度，網(wǎng)站訪問速度直接關(guān)系到用戶體驗，我可以翻墻看風(fēng)景，但買個網(wǎng)游vpn才能打開你這 個還不怎么知名的網(wǎng)站就有難度了?；蛟S您網(wǎng)站的ajax很出色，可是document怎么也不ready，一些代碼永遠絕緣于用戶。

五、架構(gòu)

初期架構(gòu)一般比較簡單，web負載均衡+數(shù)據(jù)庫主從+緩存+分布式存儲+隊列。大方向上也確實就這幾樣?xùn)|西，細節(jié)上也無數(shù)文章都重復(fù)過了，按照將來 會有N多WEB，N多主從關(guān)系，N多緩存，N多xxx設(shè)計就行，基本方案都是現(xiàn)成的，只是您比其他人厲害之處就在于設(shè)計上考慮到緩存失效時的雪崩效應(yīng)、主 從同步的數(shù)據(jù)一致性和時間差、隊列的穩(wěn)定性和失敗后的重試策略、文件存儲的效率和備份方式等等意外情況。緩存總有一天會失效，數(shù)據(jù)庫復(fù)制總有一天會斷掉， 隊列總有一天會寫不進去，電源總有一天會燒壞。根據(jù)墨菲定律，如果不考慮這些，網(wǎng)站早晚會成為茶幾。

六、服務(wù)器軟件

Linux、nginx、php、mysql，幾乎是標配，我們除了看名字，還得選版本。Linux發(fā)行版眾多，只要沒特殊要求，就選個用的人最多的，社區(qū)最活躍的，配置最方便的，軟件包最全最新的，例如debian、ubuntu。 至于RHEL之類的嘛，你用只能在RHEL上才能運行的軟件么？剩下的nginx、php、mysql、activemq、其他的等等，除非你改過這些軟 件或你的程序真的不兼容新版本，否則盡量版本越新越好，版本新，意味著新特性增多、BUG減少、性能增加?？傆行┑缆犕菊f的人跟你說老的版本穩(wěn)定。所謂穩(wěn) 定，是相對于特殊業(yè)務(wù)來說的，而就一個php寫的網(wǎng)站，大多數(shù)人都沒改過任何服務(wù)器軟件源代碼，絕大多數(shù)情況是能平穩(wěn)的升級到新版本的。類似于jdk5到 jdk6，python2到python3這類變動比較大的升級還是比較少見的?？纯碈hangeLog，看看升級說明，結(jié)合自己情況評估一下，越早升級 越好，別人家都用php6寫程序了這邊還php4的逛游呢。優(yōu)秀的開源程序升級還是很負責(zé)任的，看好文檔，別怕。

以上這六點準備完畢，現(xiàn)在我們有了運行環(huán)境，有了基本架構(gòu)骨架，有了備份和切換方案，應(yīng)該開始著手設(shè)計開發(fā)方面的事情了。開發(fā)方面的事情無數(shù)，下一篇會先說一些重點。

原文地址

七、數(shù)據(jù)庫

幾乎所有操作最后都要落到數(shù)據(jù)庫身上，它又最難擴展（存儲也挺難）。對于mysql，什么樣的表用myisam，什么樣的表用innodb，在開發(fā) 之前要確定。復(fù)制策略、分片策略，也要確定。表引擎方面，一般，更新不多、不需要事務(wù)的表可以用myisam，需要行鎖定、事務(wù)支持的，用innodb。 myisam的鎖表不一定是性能低下的根源，innodb也不一定全是行鎖，具體細節(jié)要多看相關(guān)的文檔，熟悉了引擎特性才能用的更好?，F(xiàn)代WEB應(yīng)用越來 越復(fù)雜了，我們設(shè)計表結(jié)構(gòu)時常常設(shè)計很多冗余，雖然不符合傳統(tǒng)范式，但為了速度考慮還是值得的，要求高的情況下甚至要杜絕聯(lián)合查詢。編程時得多注意數(shù)據(jù)一 致性。

復(fù)制策略方面，多主多從結(jié)構(gòu)也最好一開始就設(shè)計好，代碼直接按照多主多從來編寫，用一些小技巧來避免復(fù)制延時問題，并且還要解決多數(shù)據(jù)庫數(shù)據(jù)是否一致，可以自己寫或者找現(xiàn)成的運維工具。

分片策略?？倳心敲磶讉€表數(shù)據(jù)量超大，這時分片必不可免。分片有很多策略，從簡單的分區(qū)到根據(jù)熱度自動調(diào)整，依照具體業(yè)務(wù)選擇一個適合自己的。避免自增ID作為主鍵，不利于分片。

用存儲過程是比較難擴展的，這種情形多發(fā)生于傳統(tǒng)C/S，特別是OA系統(tǒng)轉(zhuǎn)換過來的開發(fā)人員。低成本網(wǎng)站不是一兩臺小型機跑一個數(shù)據(jù)庫處理所有業(yè)務(wù)的模式，是機海作戰(zhàn)。方便水平擴展比那點預(yù)分析時間和網(wǎng)絡(luò)傳輸流量要重要的多的多。

NoSQL。這只是一個概念。實際應(yīng)用中，網(wǎng)站有著越來越多的密集寫操作、上億的簡單關(guān)系數(shù)據(jù)讀取、熱備等，這都不是傳統(tǒng)關(guān)系數(shù)據(jù)庫所擅長的，于是 就產(chǎn)生了很多非關(guān)系型數(shù)據(jù)庫，比如Redis/TCTT/MongoDB/Memcachedb等，在測試中，這些幾乎都達到了每秒至少一萬次 的寫操作，內(nèi)存型的甚至5萬以上。例如MongoDB，幾句配置就可以組建一個復(fù)制+自動分片+failover的環(huán)境，文檔化的存儲也簡化了傳統(tǒng)設(shè)計庫 結(jié)構(gòu)再開發(fā)的模式。很多業(yè)務(wù)是可以用這類數(shù)據(jù)庫來替代mysql的。

八、緩存。

數(shù)據(jù)庫很脆弱，一定要有緩存在前面擋著，其實我們優(yōu)化速度，幾乎就是優(yōu)化緩存，能用緩存的地方，就不要再跑到后端數(shù)據(jù)庫那折騰。緩存有持久化緩存、 內(nèi)存緩存，生成靜態(tài)頁面是最容易理解的持久化緩存了，還有很多比如varnish的分塊緩存、前面提到的memcachedb等，內(nèi)存緩 存，memcached首當其沖。緩存更新可用被動更新和主動更新。被動更新的好處是設(shè)計簡單，緩存空了就自動去數(shù)據(jù)庫取數(shù)據(jù)再把緩存填上，但容易引發(fā)雪 崩效應(yīng)，一旦緩存大面積失效，數(shù)據(jù)庫的壓力直線上升很可能掛掉。主動緩存可避免這點但是可能引發(fā)程序取不到數(shù)據(jù)的問題。這兩者之間如何配合，程序設(shè)計要多 動腦筋。

九、隊列。

用戶一個操作很可能引發(fā)一系列資源和功能的調(diào)動，這些調(diào)動如果同時發(fā)生，壓力無法控制，用戶體驗也不好，可以把這樣一些操作放入隊列，由另幾個模塊 去異步執(zhí)行，例如發(fā)送郵件，發(fā)送手機短信。開源隊列服務(wù)器很多，性能要求不高用數(shù)據(jù)庫當做隊列也可以，只要保證程序讀寫隊列的接口不變，底層隊列服務(wù)可隨 時更換就可以，類似Zend Framework里的Zend_Queue類，java.util.Queue接口等。

十、文件存儲。

除了結(jié)構(gòu)化數(shù)據(jù)，我們經(jīng)常要存放其他的數(shù)據(jù)，像圖片之類的。這類數(shù)據(jù)數(shù)量繁多、訪問量大。典型的就是圖片，從用戶頭像到用戶上傳的照片，還要生成不 同的縮略圖尺寸。存儲的分布幾乎跟數(shù)據(jù)庫擴展一樣艱難。不使用專業(yè)存儲的情況下，基本都是靠自己的NAS。這就涉及到結(jié)構(gòu)。拿圖片存儲舉例，圖片是非常容 易產(chǎn)生熱點的，有些圖片上傳后就不再有人看，有些可能每天被訪問數(shù)十萬次，而且大量小文件的異步備份也很耗費時間。

為了將來圖片走cdn做準備，一開始最好就將圖片的域名分開，且不用主域名。很多網(wǎng)站都將cookie設(shè)置到了.domain.ltd，如果圖片也在這個域名下，很可能因為cookie而造成緩存失效，并且占多余流量，還可能因為瀏覽器并發(fā)線程限制造成訪問緩慢。

如果用普通的文件系統(tǒng)存儲圖片，有一個簡單的方法。計算文件的hash值，比如md5，以結(jié)果第一位作為第一級目錄，這樣第一級有16個目錄。從0 到F，可以把這個字母作為域名，0.yourimg.com到f.yourimg.com（客戶端dns壓力會增大），還可以擴展到最多16個NAS集群 上。第二級可用年月例如，201011，第三級用日，第四級可選，根據(jù)上傳量，比如am/pm，甚至小時。最終的目錄結(jié)構(gòu)可能會是 e/201008/25/am/e43ae391c839d82801920cf.jpg。rsync備份時可以用腳本只同步某年某日某時的文件，避免計 算大量文件帶來的開銷。當然最好是能用專門的分布式文件系統(tǒng)或更專業(yè)點的存儲解決方案。

下面，我們要談?wù)劥a了。

這一系列的最后一篇寫給普通編程人員，如果不感興趣可直接看本文最后幾段。開始設(shè)計代碼結(jié)構(gòu)之前，先回顧一下之前準備過的事情：我們有負載均衡的 WEB服務(wù)器，有主從DB服務(wù)器并可能分片，有緩存，有可擴展的存儲。在組織代碼的各個方面，跟這些準備息息相關(guān)，我一二三的列出來分別說，并且每一條都以“前面講到”這個經(jīng)典句式開頭，為了方便對照。

別著急看經(jīng)典句式，我思維跳躍了，插一段。實際開發(fā)中，我們總會在性能和代碼優(yōu)雅性上作折中。對于當今的計算機和語言解釋器，多幾層少幾層對象調(diào) 用、聲明變量為Map還是HashMap這種問題是最后才需要考慮的問題，永遠要考慮系統(tǒng)最慢的部分，從最慢的部分解決。例如看看你用的ORM是不是做了 很多你用不到的事情，是不是有重復(fù)的數(shù)據(jù)調(diào)用。我們做的是web應(yīng)用開發(fā)，不是底層框架API，代碼易讀易懂是保證質(zhì)量很重要的一方面，你的程序是為了什 么而設(shè)計，有不同的方法……算了，這個話題另起一篇文章來說，扯遠了，想交流可關(guān)注我的微博 http://t.sina.com.cn/liuzhiyi，咱繼續(xù)……

前面講到，WEB 服務(wù)器是要做負載均衡的，圖片服務(wù)器是要分開的。對于這點，代碼在處理客戶端狀態(tài)時，不要把狀態(tài)放到單機上，舉例，不要用文件session，嗯，常識。 如果有可能，最好在一開始就做好用戶單點認證的統(tǒng)一接口，包括跨域如何判斷狀態(tài)、靜態(tài)頁面如何判斷狀態(tài)，需要登錄時的跳轉(zhuǎn)和返回參數(shù)定義，底層給好接口， 應(yīng)用層直接就用（可參考GAE的 user服務(wù)）。登錄方面的設(shè)計要考慮移動設(shè)備的特性，比如電腦可以用浮動層窗口，但NOKIA自帶的瀏覽器或UCWEB就無法處理這種表現(xiàn)形式，程序一 定既能處理AJAX請求又能直接通過URL來處理請求。圖片服務(wù)器分開，資源文件最好也布局到圖片服務(wù)器，也就是WEB服務(wù)器只服務(wù)動態(tài)程序。雖然開發(fā)測 試時稍微復(fù)雜（因為需要絕對URI才能訪問），但將來頁面前端優(yōu)化上會輕松許多，并且你的WEB服務(wù)器IO優(yōu)化也輕松許多。程序引用資源文件時，要有一個 統(tǒng)一的處理方法，在方法內(nèi)部可以自動完成很多事情，例如將css/js根據(jù)組合，拼成一個文件，或者自動在生成的URI后面加上QUERYSTRING， 如果將來前端用了緩存服務(wù)，那生成QUERYSTRING是最簡單的刷新服務(wù)端緩存和客戶端緩存的辦法。

前面講到， 數(shù)據(jù)庫會有復(fù)制，可能會多主多從，可能會分片。我們程序在處理數(shù)據(jù)的過程中，最好能抽象出來單獨放做一層。拿現(xiàn)在流行的MVC模式來說，就是在M層下方再 放一個數(shù)據(jù)層，這個數(shù)據(jù)層不是通常所說的JDBC/PDO/ActiveRecord等，而是你自己的存取數(shù)據(jù)層，僅對外暴露方法，隱藏數(shù)據(jù)存取細節(jié)。這 個數(shù)據(jù)層內(nèi)部不要怕寫的難看，但一定要提供所有的數(shù)據(jù)存儲功能，其他任何層次不要看到跟數(shù)據(jù)庫打交道的字眼。之所以這樣做，是因為在單關(guān)系數(shù)據(jù)庫的情況 下，可能會SELECT…JOIN…或直接INSERT…INTO…，可你可能會將一些表放到key-value數(shù)據(jù)庫里存儲，或者分片，這么做之后原來 的語句和方式要全部改變，如果過于分散，則移植時會耗費很大精力，或得到一個很大的Model。在數(shù)據(jù)層面的設(shè)計上，盡量避免JOIN查詢，我們可以多做 冗余，多做緩存，每種數(shù)據(jù)盡量只需要一次查詢，然后在你的程序里面進行組合。對于比較復(fù)雜的數(shù)據(jù)組合，在實時性要求不高的情況下，可采用異步處理，用戶訪 問時只取處理后的結(jié)果。在對于主鍵的處理上，避免使用自增ID，可以用一定規(guī)則生成的唯一值當做主鍵，這種主鍵是最簡單的分片分布策略。即使用自增ID， 也最好用一個自增ID發(fā)生器，否則從數(shù)據(jù)庫不小心被寫了一下，那主鍵很容易沖突。

前面講到，咱數(shù)據(jù)庫前面還有某些緩存擋著。別把 mysql的query cache當緩存，應(yīng)用稍復(fù)雜的時候QUERY CACHE反而會成為累贅。緩存跟數(shù)據(jù)庫和業(yè)務(wù)結(jié)合的很緊密，正因為跟業(yè)務(wù)關(guān)系緊密，所以這點沒有放之四海而皆準的方法。但我們還是有一些規(guī)則可參照。規(guī) 則一：越接近前端，緩存的顆粒度越大。例如在WEB最前端緩存整個頁面，再往后一層緩存部分頁面區(qū)域，再往后緩存區(qū)域內(nèi)的單條記錄。因為越靠近后端，我們 的可操作性越靈活，并且變化最多的前端代碼也比較方便編寫。在實踐中，因為產(chǎn)品需求變化速度非?？?，迭代周期越來越短，有時很難將Controller和 Model分的那么清楚，Controller層面處理部分緩存必不可免，但要保證如果出現(xiàn)這種情況，Controller所操作的緩存一定不要影響其他 數(shù)據(jù)需求方，也就是要保證這個緩存數(shù)據(jù)只有這一個Controller在用。規(guī)則二：沒有緩存時程序不能出錯。在不考慮緩存失效引發(fā)的雪崩效應(yīng)時，你的程 序要有緩存跟沒緩存一個樣，不能像新浪微博一樣，緩存一失效，粉絲微博全空，整個應(yīng)用都亂套了。在緩存必不可少的情況下，給用戶出錯信息都比給一個讓人誤 解的信息強。規(guī)則三，緩存更新要保證原子性或稱作線程安全，特別是采用被動緩存的方式時，很可能兩個用戶訪問時導(dǎo)致同一個緩存被更新，通常情況這不是大問 題，可緩存失效后重建時很可能是引發(fā)連鎖反應(yīng)的原因之一。規(guī)則四：緩存也是有成本的。不只是技術(shù)成本，還有人工時間成本。如果一個功能使用緩存和不使用， 在可預(yù)見的訪問量情況下區(qū)別微小，但使用緩存會使復(fù)雜度增加，那就不用，我們可以加個TODO標注，在下次迭代的時候加上緩存處理。

前面講到，文件存儲是獨立的，那么所有的文件操作就都是遠程調(diào)用。可以在文件服務(wù)器上提供一個很簡單的RESTful接口，也可以提供xmlrpc 或json serveice，WEB服務(wù)器端所生成和處理的文件，全部通過接口通知文件服務(wù)器去處理，WEB服務(wù)器本身不要提供任何文件存儲。你會發(fā)現(xiàn)很多大網(wǎng)站的 上傳圖片跟保存文章是分兩步完成的，就是基于這個原因。

以上幾條“前面講到”，其實無數(shù)人都講過，我也只是結(jié)合前幾篇文章用自己的話重復(fù)了一遍，真正分析起來精髓很簡單——除了良好的功能邏輯分層，我們 還要為數(shù)據(jù)庫存儲、緩存、隊列、文件服務(wù)等程序外層資源調(diào)用單獨設(shè)計接口，你可以把你的程序想象成是運行在 Amazon EC2 上并用他的所有web service服務(wù)，你的數(shù)據(jù)庫就是它的SimpleDB，你的隊列就是他的SQS，你的存儲就是他的S3，唯一不同是amazon的接口是遠程調(diào)用，你的是內(nèi)部調(diào)用。

將支撐服務(wù)接口化，意味著將MySQL更換到PostgreSQL不需要更改業(yè)務(wù)處理程序，移植團隊甚至不需要跟業(yè)務(wù)開發(fā)團隊過多溝通；意味著業(yè)務(wù)開發(fā)團隊是對接口編程而不是對數(shù)據(jù)庫編程；意味著不會因為某個業(yè)務(wù)開發(fā)人員的失誤而拖垮性能。

對程序掃盲不感興趣的直接看這里——

產(chǎn)品設(shè)計完了，程序框架搭完了，可能有矛盾在這個節(jié)骨眼兒產(chǎn)生了。不斷有產(chǎn)品設(shè)計抱怨說他的創(chuàng)意沒實現(xiàn)到預(yù)期效果，有程序員抱怨說產(chǎn)品設(shè)計不切實 際。這種抱怨多緣于產(chǎn)品人員不懂技術(shù)，技術(shù)人員不理解產(chǎn)品。從廣義上來講，產(chǎn)品包含市場策略、營銷手段、功能設(shè)計，產(chǎn)品和技術(shù)在爭論時往往把焦點放在功能 上，而實際重點是，實現(xiàn)這個功能所消耗的成本跟能這個功能帶來的利益能否換算，能否取其輕重。若可以，爭議解決。若不能，則拋硬幣看運氣。因為一個功能的 加強而引發(fā)指標井噴，或因項目拖延而導(dǎo)致貽誤戰(zhàn)機的例子比比皆是。激進的決策者注重利益，保守的決策者注重損失，聰明的決策者會考慮這個問題是否真的那么 嚴重。

關(guān)系到未來的事情誰都說不準，要不怎么說創(chuàng)業(yè)一半靠運氣呢。不過總有能說的準的事情，那就得靠數(shù)據(jù)說話。

沒有100%也有99.9%的網(wǎng)站安裝了訪問統(tǒng)計代碼，連我的 http://zhiyi.us 也不例外，新聞聯(lián)播也總說科學(xué)決策科學(xué)發(fā)展的。有了統(tǒng)計，能確定的事情就很多了。例如，可以根據(jù)來源-目標轉(zhuǎn)化率來分析哪類渠道的人均獲取成本低，根據(jù)來 源-內(nèi)容訪問猜測用戶跳出率原因，根據(jù)用戶點擊行為判斷鏈接位置是否合理等。將數(shù)據(jù)以不同方式組合起來，找到內(nèi)在聯(lián)系，分析內(nèi)因外因，制定對應(yīng)策略，減少 拍腦門決策?？繑?shù)據(jù)支撐運營是個非常專業(yè)的事情，雖然不懂深奧的數(shù)學(xué)模型不會復(fù)雜的公式計算，漸漸學(xué)會因為A所以B，因為A和B所以C還是相對簡單的。

全系列完畢。老話，大半夜連抽煙帶碼字的挺傷身，轉(zhuǎn)載請注明出處