Web 2.0中的LAMP結構開發與運營

文 / 錢宏武

Web2.0，讓我喜歡讓我憂

 “Web2.0時代主角的光環頭一次照在了程序員的腦袋上，一直默默無聞、辛勤工作的工程師不再是后臺不為人知的工作人員，也開始走到前臺。而歷史告訴我們，每一個成功的主角背后，都是血淚和汗水。一個互動系統，作為公司的核心，或者說領導關注的重點，工程師的日子大概不會像以前普通的工作人員那樣省心。

 首先就是系統的不穩定成了無數程序員的夢魘。不過做程序的都知道，花了無數錢的Windows，當機那是家常便飯，所以對于自己程序的設計缺陷，上線運行，偶爾當當，只要不造成數據丟失，大概每個人都會認為是正常。“等一會，重啟一下”也成了每個開發者的口頭禪，而在互聯網，在把流量和錢劃等號的領導面前，這個口頭禪和搶他錢沒什么兩樣，在領導可以殺死你的眼光下，每個工程師都是極其頭疼。

其次就是Web2.0中間無數突發奇想的功能。由于動態產品重點不在于內容，于是功能成了很多產品的發展或者考核的重點。但是，凡有一點程序開發常識的人都知道，功能眾多是程序穩定的大忌，在第一個問題都還沒有解決的情況下，第二個問題又成了一個巨大的包袱。

最后，需求朝令夕改。這是程序員最不喜歡的。很多情況一般是一個外行的領導，或者說有一些不負責任的產品。但更多的時候，產品設計人員有時也很委屈，不是他們想不明白，這個世界變化太快。

Web2.0互動產品開發的三個思想誤區

以上三個問題，是Web 2.0的開發人員最常碰見的。對于這三個問題，我初次碰到的時候，也是快崩潰了，后來慢慢找到解決方法。在解決這些問題中發現，對于這種互動產品的開發，很多理念和傳統的開發是有差別的，甚至有些是完全相反。也就是說，如果要解決這些問題，首先是解決我們思維中的一些禁錮，或者說思想上的一些錯誤觀點。

第一種錯誤觀點就是認為數據是寶貴的，寧可出錯，也不能丟失數據。在傳統系統中（如財務系統），數據很多都是涉及到錢的，丟了一條，就會出現財務賬面對不上。而在互聯網運行的產品中，數據從來都是第二位的，因為數據大部分都是文章，或者博客，很多統計也是點擊數。這些數據，點擊數少幾個多幾個、文章的發表數量的統計少幾篇多幾篇沒人會說什么。如果一定要追求完美，程序的復雜程度將增加許多，而這種復雜程度將直接導致系統的故障頻繁。

第二種，就是真實，這是很多優秀程序員最容易犯的錯誤。系統出錯了，老老實實報一個大錯，有時候還怕別人不知道，用大大的紅字提醒。在此，我借用產品的一個詞，就是用戶感受度。因為對于互動產品來說，很多人過來用，都是尋一開心，博客也罷，論壇也罷，貼吧也罷，都是能有一個愉悅的心情。是否是真的，他并不在乎。所以出了錯，最好的方式是向那些政客們學習，掩蓋住，別讓用戶知道。如果有較真的用戶，系統可以再提示他出了一些小問題。很多時候，系統有點小故障，一會也就過去了。在這一點上，一定要注意把握好度，你不能什么都欺騙，而具體的度在哪里，就看個人的掌握。

第三種，系統之間，關聯度比較小。很多人在設計互動架構的時候，由于第一種思維方式，系統和系統之間、機器和機器之間、模塊和模塊之間，耦合度非常高，這種高耦合度的好處就是保證數據的完整和真實，但對應的就是開發的成本和穩定運行就會很差。

以上幾點，我覺得是互聯網互動產品和傳統開發中，思考方式最大的區別。在總結這么多問題的前提下，下面我來談談自己對互動產品開發和運維方式的一些感受。

開發和運維

對于互動產品來說，一期開發完畢并且上線，只是走完了萬里長城的第一步，接下來將面對越來越大的問題和劫難。對于Web2.0互動產品來說，一般有一個臨界點。在這個點之前，一切都很順利，性能穩定、速度快、用戶反應也很好，開發也是有條不紊。突然有一天，一切都改變了，系統開始不穩定、速度變得極慢、各個方面的需求開始增多，開發開始出現混亂。這么多問題，怎么解決？是先解決穩定問題，還是先招人解決開發問題，還是加機器？

我的建議是，如果問題已經產生了，首要解決的一定是穩定。穩定一般都是由數據庫引起的，優化數據庫、索引，然后更改讀取的方式，把數據進行分拆，都是你可以做的。優化完了之后，砍掉一期開發中華而不實的功能。注意，一般的互動產品通常是讀取具體內容的那個頁面訪問量最大，所以那個程序需要做到最簡單——什么功能都不要帶，就是讀取，最好是讀取的靜態頁面。至于動態的部分，可以使用js回填的方式來控制，如果能跑出來，當然是完美的頁面，如果這個動態部分跑不出來，也不影響用戶瀏覽主要的內容。這些做完后，下面的工作才是重點。

如何高效率地開發

系統穩定后，需要考慮運維中長期會碰到的問題，畢竟對于穩定來說，最后其實就是通過系統架構，完成一個可以通過添加機器來完成對整體流量的上漲平衡。但對于日常的開發，一旦處理不好，每天就會疲于應付那些新需求，不太可能有精力投入對新系統的構架和開發。其實，對于那些突發奇想的功能，一般按照劃分，最多的就是對內容的操作，畢竟現在所謂的2.0產品，歸到底，個人感覺就是圍繞文章如何分類的問題。

編輯或者產品的需求，一般最常見的也就是突發奇想的幾種分類或者排序而已，只是由于他們很在乎這種體現形式，如紅的還是藍的、帶圖還是不帶圖、或者是純圖，系統自動出還是他來選擇、用戶能看不能看等。這些東西開發人員可能覺得不起眼，但對于編輯或者產品來說很重要，他們就是靠這些來實現他們的想法和創意，實現產品的推廣和運營。對此，很多負責開發的人一般是兩種態度。

第一種是來者不拒，一視同仁，排期，一個一個做。這種做法一般是被下屬罵死，使得工程師流失率極高。由于流失率大，開發的質量和速度自然不能保證。第二種來者皆拒，我這里很忙，我系統要升級。這種態度一般開始是慢慢地沒人搭理，后來就直接被投訴，然后

被干掉。

對于這些，最好的方式應該是有選擇地答應用戶的需求，要達到90%的需求都能滿足，然后自己開發一個開發平臺。不要覺得那是微軟或Borland才能做的事情，其實自己設計一個開發平臺很容易。當那些瑣碎且重復的需求在你的工作計劃中占了2/3的時候，就需要這樣一個開發平臺了。

這個基本的開發思想，就是程序生成程序，完成開發中80%代碼重復的部分，然后完成剩下的20%。在開發說明中，按照要求一步一步去做，最后完成需求。面對這樣一個需求，一個初級工程師也能在30分鐘左右完成，并且保質保量。這樣，你設置一個半人，就能應付所有的需求。我見過很多人都有類似的自己代碼生成系統，這里我講一下我當時是怎么設計的。

當時的工作主要是更新網站的內容頁面，當時有近30個頻道，每個頻道都有一個社區首頁，每個頻道基本是3 個月要求整體改一個版。平均下來，就是每三天就會有一個頻道需要改版。其他小的改動，基本每個頻道是每2周會有一個。也就說，一周的工作計劃中，一般會有2個大的頁面開發，15 個的改動。分析后發現，就是圖、文、人繞來繞去，不同的形式顯示，寫了三個對象：

l  圖的對象

l  文字的對象

l  人的對象

然后，根據對象寫一個代碼生成，這個初期設計也比較簡單。就是說，就是幾種方案，就是文字取的方式和顯示方式，他們當時就幾種，或者大類選取，比方說整個女人購物分類。下面所有版面的文章，然后顯示出最新的10條，開發一個選擇的條件，根據選擇的條件，選擇不同的類對象的代碼，然后傳入對象方法中的參數，再把代碼顯示在一個頁面中，拷貝后，放在程序中。熟練后，一個工程師在幾分鐘就能完成一個版塊。一般小的需求，都是一個版塊，大的頁面，也就是20~30個版面。這樣，小的需求基本是當時來，當時就能完成；大的也是上午提交需求，下午就能給用戶，這樣有很多好處。大體結構圖如下：

1由于基本類可以集中很好的人來開發，核心代碼質量代碼很高，初級的人員由于只寫表現層，不涉及數據庫和底層的操作，不會影響整個系統。

2 由于速度非常快，需求還沒來得及換，我已經寫完并且上線了，對方沒有時間提，避免了需求朝令夕改。

3 由于對具體操作人員要求很低，而且能保證時間和質量。

4 大量瑣碎的工作可以由初級員工完成，這樣一個可以鍛煉他們對于程序的理解，也避免了高級工程師做這種大量重復而低級的工作。

 有人曾經建議過我用模板的方式來寫，就是大家常說MVC的模式，顯示和邏輯完全分開。這個我考慮后，個人覺得不太適合互動產品，主要是從效率來考慮，畢竟，很多傳統的開發中間速度一般是不太考慮的。而對于互動產品來說，如果慢或者說消耗系統資源巨大，那么這個開發基本是非常失敗的。

結語

對于互動產品的開發和維護來說，需要抓住開發的重點，而歸結起來，就是效率。很多項目經理能注意到程序本身的效率以及修改的效率，其實更重要的是開發本身的效率，就是通過開發的積累，把很多開發的工作，變得像流水線一樣，可以讓比較初級的人員處理大量重復簡單的工作，這樣才能保證本部門人員慢慢從日常繁雜的開發中抽出時間做一些更基礎的工作。

作者簡介：

錢宏武，職脈網技術合作人，原搜狐互動產品開發部主管，構架并開發能承擔6000萬/日訪問的社區論壇，協助設計并運營搜狐體育直播間，最高承擔48萬人同時在線觀看NBA直播，對于LAMP下的互動產品開發，有7 年的開發管理經驗。聯系方式：msn:qhw108@hotmail.com；qq: 690889126。