互聯網開發模式的經驗之談【轉】

版權聲明：本文由韓偉原創文章，轉載請註明出處: 
文章原文連接：https://www.qcloud.com/community/article/238

來源：騰雲閣 https://www.qcloud.com/community

 

做者介紹：韓偉，1999年大學實習期加入初創期的網易，成爲第30號員工，8年間從程序員開始，歷任項目經理、產品總監。2007年後創業4年，開發過視頻直播社區，及多款頁遊產品。2011年後就任於騰訊遊戲研發部公共技術中心架構規劃組，專一於通用遊戲技術底層的研發。

互聯網開發的核心問題

當我1999年進入互聯網行業工做的時候，華爲剛剛經過了著名的CMM認證。當時做爲一個小程序員，很是嚮往業界經典的軟件開發模式。由於看上去，若是企業實行了CMM，咱們程序員就不用再每天爲了老闆一個拍腦殼的主意而加班開發了，各類各樣的奇葩需求和無理變動，也會煙消雲散。可是，在接下來的十幾年，幾乎沒有那個互聯網公司再去經過CMM認證。是否CMM這種軟件開發模式，就根本不適合互聯網行業呢？這是一直以來我都在思考的問題。反而是跟隨着互聯網企業的一步步長大，我無心識的體驗了不少如今流行概念的早期實踐：敏捷、重構、持續集成、DevOps，這些實踐一開始都很是的幼稚粗糙，可是卻真正的伴隨着互聯網業務的逐步成長。因此，在討論互聯網服務的開發模式時，我認爲必需要先搞清楚互聯網服務開發的核心問題是什麼。

本質：服務，而不是產品

軟件究竟是「服務」仍是「產品」，這個話題一直都很是具備爭議。做爲程序開發者，其實是很是但願軟件可以是一個產品，由於軟件的後續維護和修改，每每是「致使」項目失敗的最多見緣由。然而事與願違的是，在互聯網企業中，打多數的軟件項目，表現出來的是典型的「服務」特徵：

• 沒有明確的需求合同。這致使了沒有辦法爲軟件設計固定的開發方案，也難以肯定長期目標。
• 沒有預付款和客戶驗收。互聯網服務用戶來了就用，爽了就給錢，不爽了就走，連溝通的機會都不會有。
• 甚至連明顯的銷售環節都沒有。不少互聯網公司只有市場推广部門，而沒有所謂「銷售」部門，由於推廣就幾乎等於銷售，在推廣的同事，就必須把銷售的事情一塊兒作了。

所以，在互聯網行業中，軟件開發更多的是以一種服務的形式存在。這種特徵，在對需求的分析管理；開發技術的選擇；集成與測試；運營和客服四個方面，都致使了不一樣於「產品」型軟件的巨大差別:

• 對於一項服務來講，需求是持續變化的，你能夠找到一些通用的模式，可是必須保持變化。
• 開發效率是第一重要的，由於市場競爭中，應對需求變化快的單位將得到更多的客戶。

因爲服務必須保持長期的穩定可用，又要具有快速的更新部署能力，因此係統集成的效率和質量要求很是高。所幸的是系統運行的環境大多數都是在可控制的空間裏（好比開發公司本身的機房內）。

服務是公司和客戶的一種持續溝通和交互的過程，並不是一個單向的發售行爲，因此互聯網服務須要更多細緻的運營和維護的工具，不然難以作到迅速而細緻的知足海量的互聯網用戶的需求。

小米的MIUI開發節奏

管理：手段.vs.工具

在各類項目管理的課程裏面，陳述了大量針對人去工做的方法。各類會議、報告、表格、評估、測量多不勝數，然而軟件項目進度的控制，依然是一個難度堪比登月的事情。—————對於不少項目經理來講，程序員們基本是一個黑盒子，他們本身都不知道一個事情須要多長時間幹完，就更別提別人怎麼去預估和控制。這裏最大的問題，我以爲是：咱們每每老是想着怎樣「控制」住軟件項目的進度，而忽視瞭如何減小不利於項目進度的因數。實際上影響軟件開發進度的主要因數，通常有一下幾個：

• 程序員的能力水平。有一些項目其中的技術，是程序員徹底沒接觸過的類型，這裏包含了學習、調試的時間。
• 開發過程當中的各類修改變動。因爲對可行性、需求確認等方面的因數，開發每每會走「回頭路」。有些項目作到通常會發現技術上不可行，須要修改需求；而另一些項目是在項目作到一半甚至快完成的時候，需求方發現須要修改產品設計，由於在產品可體驗以前，徹底沒法想象到最後會是如今的樣子。
• 各類和開發無關的過程當中的事務。這裏包括開會、寫報告、溝通、等待開發電腦編譯、處理開發服務器故障、各類開發環境和測試環境的問題處理等等……這些事情每每都看起來不是很是「有技術含量」，可是實際上會嚴重影響開發進度。由於開發工做須要一個穩定、專心的工做環境，頻頻的被各類事務打斷，會讓程序員反覆的花費時間去「進入」工做狀態————面對成千上萬行程序代碼，要找到以前寫到哪一個部分，其實不是那麼簡單。

針對上面說的幾個問題，不少均可以經過應用更好的開發工具來解決。好比一些新的需求類型，咱們能夠求助於互聯網上豐富的開源軟件和開源庫；面對需求變動，咱們可使用設計模式、單元測試等工具；開發中的事務問題，更是能夠有大量業界先進工具可用：SVN,Git,Jira,Project,IDE,Chef,Docker……

與其咱們拿着鞭子抽打程序員，還不如給程序員更好的開發工具，這樣對於項目進度的推進，其實更有好處。

資產：代碼.vs.流程

互聯網公司是由人組成的，人是會流動的，有一些小型的公司，每每會由於一兩個核心員工的離職，形成整個系統的代碼沒法看懂，沒法修改，從而最後致使公司完蛋。這種糟糕的狀況，不止一次的出現過。然而，若是咱們能有一套完善的開發流程，或者是習慣，以及配合良好的開發環境，加上有必定質量的代碼，是徹底能作到把項目代碼，在不一樣程序員之間順利交接的。惋惜咱們不少公司管理者，並不重視程序員用什麼工具開發軟件，也不知道如何去提升代碼的可讀性，因此形成咱們的項目特別懼怕人員變更。若是咱們把人員變更當作是一個必然會發生的事情，那麼咱們就會更重視整個代碼的開發環境和開發過程，從一開始就把開發規範肯定下來，規定使用什麼環境，應用何種工具，而且堅持執行，同時在實踐過程當中不斷的改進。只有這樣有預備的去作，最後纔會保留的住公司真正的資產。

一家互聯網公司，咱們在評估其開發資產的時候，並不該看他「擁有」多少行代碼，由於這些代碼是沒法直接賣錢的。而互聯網公司的開發速度，以及這個速度背後的能力纔是最重要的。

敏捷開發的意義和實踐

敏捷開發是咱們如今最多見的一個「開發模式」，然而不少時候，咱們看到「敏捷」兩個字，彷佛就是讓程序員多加點班，或者忽略一些過程加快把代碼弄出來，而真正理解「敏捷」含義的並很少。實際上，敏捷並不會加快單位代碼的開發速度！敏捷最主要的目標，是應對需求不明確和需求變動，而這二者正式互聯網服務中最多見的狀況。

需求變動的緣由

在互聯網服務中，因爲沒有直接的「客戶」下單要求，因此不少需求，都是由公司內部的人「表明」的，最典型的就是咱們的「老闆」們了。正式由於沒有明確的「下訂單」的過程，因此不少傳統的需求分析變得無法作了，由於無論是老闆仍是產品經理，都是面對着成千上萬的客戶去猜想他們的需求，若是他們本身能表明客戶還好，若是猜錯了，項目的代碼確定要修改。不少互聯網公司都很是重視「數據」，緣由就是這些「數據」每每表明了用戶對產品的見解，而這些見解成了互聯網產品設計的惟一客觀標準。然而這些數據自己，會包含了大量複雜性，因爲統計方式、產品形態、季節時間等等，都會產生誤差。咱們的項目需求，每每就是在這些誤差中肯定。這就不免產生需求的變動了。

互聯網的客戶個體多，服務內容豐富，功能變化快，是互聯網項目中需求變動不少的主要緣由。所以這也讓敏捷開發，成爲互聯網項目開發中最重要的方法。————敏捷強調的是用原型來驗證需求，在互聯網服務裏就是，儘快推出服務，經過數據來驗證想法。若是咱們能越頻繁的修正原型，就能越快的接近真正的需求，也就是說，若是咱們的互聯網服務能越快的修正各類問題，同時越快的推出新的版本，就能讓用戶越牢固的「黏在」這個服務上。

架構設計實體化：單元測試

敏捷開發講究要快速的修改代碼，咱們每每會發現，代碼修改的越頻繁，BUG越多，這彷佛是一個沒法解決的矛盾。然而，在敏捷開發方法論中，有一個重要的措施，就是用來防止這種修改形成的BUG增長的。這就是——單元測試。 單元測試本質上，充當着自動的QA人員的角色，若是咱們把全部的設計和需求，都先按單元測試的形式「固化」編寫下來，那麼咱們在修改代碼後，就能快速的、自動的、反覆的去驗證咱們的代碼有沒有問題。若是這些測試足夠全面和詳細，那麼咱們是不會擔憂代碼修改致使大量的BUG的，由於單元測試會自動幫咱們支出問題所在。一旦咱們知道了問題，修正起來反而變成是最簡單的事情了。

假如一個項目的代碼丟失了，但全面的單元測試都還在，那麼要重建這個項目並不困難，由於全部的需求，都被蘊含在這些測試代碼中，程序員們幾乎不須要去從新啃文檔，談需求，他們只要把代碼弄成能經過單元測試就行了。這種需求的「表明物」不可是程序員開發的概念和目標，並且還能夠自動的幫程序員去驗證他們的實現。因此，若是你要使用敏捷開發，要嘗試頻繁修改原型，就必定要使用TDD(測試驅動開發)，特別是高度重視單元測試的做用。

統一軟件設計思路的重要性

曾幾什麼時候，咱們認爲，使用什麼語言開發，用結構化編程，仍是面向對象編程……這些通常人難以深刻理解的事情，都是程序員這夥頑固的傢伙的怪癖，基本屬於私人喜愛的範疇。外人既不該該深刻干預，也沒辦法去影響，由於若是你不識擡舉去在這些事情上冒犯程序員，他們隨時可能一言不合就辭職。既然咱們只須要能夠運行的代碼，咱們爲何冒風險去激怒程序員呢？然而，在互聯網服務的開發過程當中，代碼自己並非某一個固定的、靜態的東西，它須要不斷的與時俱進，須要跟隨這業務的發展而變化，同時也會從某一個程序員手裏，流向整個開發團隊。在這種狀況下，軟件開發習慣、代碼的風格、程序的設計思路，就變成一個很是重要的事情了。

代碼交流：面向對象

確實如今還存在大量的討論，說「面向對象不是萬能的」。說得對，可是，世界上有什麼東西是萬能的呢？我只能說，在需求變動很是快的狀況下，面向對象思想，是如今咱們能選擇的最好工具了。在「數據結構+算法=程序」的時代，軟件主要是以計算任務爲主，電腦是爲了代替人腦進行超乎想像的運算任務而存在。而在互聯網時代，軟件主要的任務已經變成了處理這個真實世界的信息了。信息的存儲、交換的任務，已經遠遠超過了「計算」的任務數量。雖然咱們知道，所謂的信息處理，最底層仍是依賴大量的「計算」，然而，咱們的程序員們，早已再也不須要編寫大量「計算」的代碼，咱們面臨的挑戰，是如何用代碼準確而快速的表達這個世界。

面向對象思想包括分析、設計、編碼三個部分（OOA/OOD/OOP）。這些思想看起來繁文縟節，彷佛很是囉嗦。然而，其核心思想卻很是簡單：從表達過程，轉向表達對象。人類的思惟中，對象、或物體，是一個個具有本身的信息特徵的個體，而行爲和過程，每每是依附於這些個體的。好比鳥會飛、帳號會鎖定、汽車會死火等等。因此若是咱們的代碼，是以表達對象，把信息和行爲統一塊兒來，是最接近於咱們的認識規律的。

在互聯網開發領域，因爲網絡無處不在，涉及到的領域異常普遍，若是咱們沒有一個能把代碼世界和現實世界聯繫的紐帶，咱們的項目將很是難以理解。——難以理解的項目，就難以變化，從而就失去了互聯網最顯著的特徵。因此我認爲，面向對象的思想，是每個互聯網開發人員都應該理解的，而且應該是面對大部分業務時，首先考慮選擇的。

代碼架構與重構

我見過無數的代碼架構圖，裏面畫滿了進程和服務器的拓撲，各類線條上標註了通信協議，編碼格式，還有各類流程圖和協做圖，然而，這些架構設計，無一例外的對於需求變動毫無幫助。由於它們描述的是一種現狀，甚至連現狀都不是，只是一種猜想，一種關於現狀的猜想。隨着項目代碼的不斷變化，代碼數量和關係都會膨脹，這種進程、通信級別的結構，除了愈來愈複雜之外，根本對於指導項目如何應對各類「代碼腐化」毫無用處。

所以咱們想到了流行的「重構」，然而，若是咱們只是重構進程的關係，通訊的層次，那些錯綜複雜的代碼調用關係同樣存在。各類回調、事件、耦合仍是讓代碼沒法理解。咱們只是在試圖把混亂塞到一些瓶子裏面，並無解決混亂自己。因此，咱們須要的另一個思想武器：代碼結構。只有咱們從另一個角度，另一個視圖去觀察代碼，才能把握代碼之間耦合的狀況。正如建築裏的平面圖和立面圖，都是不可或缺的。

因此咱們應該高度重視「代碼架構」，也就是描述代碼之間的關係的架構，而不是進程之間的關係的架構。在關注代碼互相調用、耦合的關係上，咱們能把混亂複雜的代碼關係理清，整理出一個便於理解，便於修改的代碼外觀。這些工做看起來徹底是針對開發人員的，可是實際上，這些工做是能提升整個開發效率的。它能讓代碼從難以修改，變得容易修改，從而得以支持快速的業務需求變化，這是對業務、對產品最重要的支持能力。

持續集成的意義和實踐

無論是敏捷開發的快速迭代，仍是重構系統，咱們都將頻繁的編譯代碼、部署、測試，也就是所謂的集成。若是咱們的系統集成效率過低，那麼快速的迭代可能變成慢速的迭代，重構系統的頻率也會大大下降。有一些項目，每一次集成，都要最少經歷兩三個小時，若是不順利的話，搞一個通宵都未必能完成。「發版本」是不少程序員和運維管理人員的常見加班緣由。對於這個問題，不少小型公司開始的時候，並無給與足夠的重視，認爲這些事情不過是程序員或者運維的本分工做之一，也是最平常的工做。真正獲得出問題了，才發現重要性。
在任何一個互聯網應用業務中，咱們都會須要「發版」：出新功能、修改BUG、啓動運營活動、甚至是機房搬遷。全部的這些，若是沒有一套合適的工具來保障，每次發版都會是一場噩夢。因此持續集成（CI），很天然的成爲互聯網企業中最流行的、研究最普遍的技術之一。

全部資產歸入版本管理

持續集成的全部東西，都應該來源於版本管理系統（SVN/Git）。除此以外，軟件資產不該該存放在任何其餘地方。版本管理系統應該是開發團隊的保險箱和金庫，除了代碼之外，全部的數據文件，配置，腳本，文檔，都應該放入這個保險庫。因爲版本管理系統能夠追溯到任何一個是時間點，這可讓故障恢復，問題回溯有良好的支持。

關於源代碼使用版本管理系統，已經有很長曆史了。可是互聯網服務中，除了代碼，還有不少其餘的資源，好比圖片、數據、腳本等等。除了產品項目外，咱們的不少額外系統，好比運維工具、產品文檔等等，都是須要妥善保管的，這些也都應該存放到版本管理系統中。

通常如今的版本管理系統，都有「分支」的功能，簡單來講就是相似於「拷貝」了一份新的資源出來，在這之上的修改，能夠由咱們選擇合併到其餘分支或者放棄。因此SVN的經常使用方案，是啓動三個類型的分支：trunk/branch/tag，專門針對「測試」、「開發」、「運營」。若是咱們按預約的分支模型來設計版本管理系統的使用，那麼咱們的持續集成就能夠很細緻的選擇集成哪個版本的內容。

而在Git裏面，每一個使用者，均可以擁有本身的資源庫，這對於開發測試能夠更加的靈活，可是對於使用者的要求更高一些：在不一樣的資源庫合併的過程當中，須要更好的版本管理策略。持續集成系統能夠本身擁有一個或者多個Git資源庫，這樣他們能夠徹底脫離版本管理服務器來獨立運行。

自動化部署

咱們曾經無數次的登陸服務器，無數次的拷貝文件，無數次的修改配置，無數次的導入數據到數據庫，無數次的……若是咱們對這些重複，並且容易出錯的工做熟視無睹，咱們將永遠的被這些本該機器去作的事情困住。
自動化部署，是整個持續集成工做中最重要的步驟。當咱們每次發版都要很仔細的修改不少文件的時候，咱們是沒法避免在某次倒黴的事故後被挨批的。只有咱們能把部署工做，也用咱們的開發能力去解決，編寫自動部署工具以後，咱們才真正的能提高部署這個事情到一個新的臺階————咱們終於可再也不擔憂發版。

和自動化測試同樣，自動部署腳本，也是把一系列的技術需求，從紙面文檔+人手處理，改爲用代碼實體化，而且可積累改善的方法。自動化部署工具在開源界也很是熱門，好比jekins，還有chef等等，都是爲了解決部署問題而發明的軟件工具。也許對於你來講，本身用bash開發一套腳本纔是合乎你的品味，可是無論怎樣，必定要有這樣的工具。就算要花費較長的開發時間，調動項目開發的程序員，一塊兒來認真的開發一段時間自動部署功能，都是很是值得的。由於從今之後，你就能夠擁有一個本身的部署系統，這個系統不但能夠積累你的運營部署經驗，還能加入不少錯誤、故障的自動檢查，讓你再也不須要導出找「永遠不出錯的」運維人員。

自動化部署系統中，最核心的部分就是配置管理。擁有一個對現有環境資源集中管理的數據倉庫是很是重要的。若是每一個你的腳本能夠識別本身所在的環境，以主動的方式去「申請」本身的配置文件和安裝任務，是很是好的一個模式。由於從一個節點主動去分發程序，比不上多個節點向中心集羣請求部署任務，來的更容易穩定。由於在節點上的部署代理程序，能更準確的知道本身環境的狀況，也能夠作本地的測試。

自動化集成測試

前面曾經說過，敏捷開發很是依賴於自動化的單元測試。實際上持續集成，也很是依賴於自動化的集成測試。集成測試能夠把自動化部署的結果進行檢驗，避免手工進行反覆驗證。若是隻有自動化部署，而沒有自動化測試，那麼集成工做，其實仍是很是浪費人力的。更重要的是，咱們在每次「發版本」以後，總會擔憂新的修改，致使一些舊的功能失效。這種問題其實是很常見的，若是沒法自動化的作這種迴歸性的測試，那麼咱們每次發版仍是要忍受漫長的測試工做進度。

自動化集成測試也有不少開源的工具可供選擇，特別是基於B/S模式開發的WEB程序，但若是是手機APP的項目，或者客戶端C/S程序（好比網絡遊戲），對於這類服務器系統的集成測試，每每須要咱們本身根據業務來編寫測試程序。對於服務器系統來講，通常咱們針對其通訊協議編寫測試程序便可，而對於客戶端系統，若是是GUI系統的，咱們還能夠根據GUI的內部調度命令（安卓就有這樣的套件）來測試，但若是是相似遊戲這類業務，就只能用圖形識別技術了。
在持續集成的流程中，集成測試每每是最後一步的檢驗關口。若是集成測試失敗，應該給全部關注集成的人員發送警報（實際上，若是成功也應該報告）。如今企業每每會用郵件、IM、微信、短信或者別的一些東西接收這種消息。

DevOps的意義和實踐

在互聯網企業初始的階段，運維工做每每是服務器端開發人員兼任的。當我在承擔這種既是開發又是運維的工做時，每每很是羨慕那些「開發、運維分離」的公司。由於做爲開發人員，沒有三班倒的值班備份人力，每每是7X24小時的待命狀態，工做壓力很是大。然而，當我本身參與到一些真正開發、運維分離的項目的時候，卻發現，項目運營事故中，最少有70%的事故，是由運維的緣由形成的。除了常見的硬件、網絡故障，操做系統配置出錯，日誌清理出問題，部署配置搞錯，進程不當心殺掉等等都出現過。看來服務器端開發和運維還真是難解難分，而DevOps的思想，就是爲了努力解決這種矛盾。咱們不該該再把開發和運維對立起來，而應該認識到，運維是開發的一種延續，運維的需求也是服務器端系統的功能需求；運維是開發的目地，便利的、通用的運維工具，自己是能提升開發效率的一種專業產品。

運維與開發的一體性：運維、運營、QA

能夠把DevOps看做開發（軟件工程）、技術運營和質量保障（QA）三者的交集

一個互聯網軟件的上線運營，每每是由開發人員編寫出來，而後通過QA人員測試，最後放在運營環境裏進行運營。這個過程並不是是單向的過程，基於前文說的，互聯網服務都是在反覆修改迭代中完善的，因此項目自己，必定是由多個版本，反覆在開發、QA、運維之間循環交接。舉例來講，一個網絡遊戲，在第一次開發出來後，都會通過比較仔細的QA測試，而後經過運維人員進行上線部署，最後由運營推廣人員進行宣傳，同時也要配合這些宣傳開啓遊戲內部的一些功能，客服人員也會在開始運營後參與進來，除了提供客戶諮詢外，抓做弊玩家和封賬號也會持續進行。而做爲開發人員的遊戲策劃，馬上會關注遊戲系統的各類統計數據，以期在下一個版本中改善遊戲設計。這個過程，能夠看到在產品開發出來以後，整個團隊幾乎都仍是須要以各類方式「使用」此服務器端系統的。因此咱們在開發互聯網服務的時候，不能僅僅面向互聯網上的通常用戶，同時也須要考慮整個開發團隊的使用需求。

現代的互聯網軟件系統每每都帶有服務器端部分。而這些服務器程序須要7X24運行，所以產生了兩類很是明顯的需求：

• 運維需求：這類需求每每表現爲非功能性需求，它要求服務器程序可以適應大規模用戶訪問和持續穩定運行。
• 運營需求：這裏需求一般是功能性需求，由於產品上線後，產品和運營、客服、測試人員，還須要持續不斷的使用這個系統，和互聯網的海量用戶進行互動。

運營：客服、活動

在互聯網服務中，運營是一個很是重要的環節。客戶除了直接使用互聯網軟件的功能外，背後其實每每還有大量的從業人員在經過這個軟件提供服務。
其中最多見的就是客服服務。客服每每最須要的是查詢功能————可以查到系統中特定用戶的使用數據，從而協助客戶解決問題。客服的另一個主要工做，是封賬號和封IP。如今互聯網黑色產業鏈很是龐大，互聯網企業保護本身的手段其實很少，而客服是其中一個重要的環節，避免黑色產業侵襲本身的利益，就須要互聯網服務系統有人工干預其數據的能力。

運營互聯網服務另一個常見的行爲就是「活動」，也就是開放一些限時的服務。就和超市同樣，互聯網服務也要定時或不定時的加入或關閉一些特別的服務。這些工做很是細緻和瑣碎，須要服務器系統可以提供人工參與或者機器定時啓動的一些功能。在《魔獸世界》這個網遊中，大部分的活動都是自動的和定時的，能夠從遊戲裏的一個日曆功能查到。而在國產的互聯網產品中，的不少是臨時加入，須要人工維護的，如「雙十一購物節」這種。這些對於服務器系統的版本更新，功能修改，都提出了更高的要求。

所以通常咱們在設計互聯網服務系統的時候，就應該一開始就把運營需求，也做爲版本目標歸入開發計劃中。一些比較好的團隊，會抽象和總結同類互聯網項目（好比遊戲、電商類型）在客服、運營活動上的共性，造成一套標準的服務規範以及實現這個規範的接口。由互聯網服務開發團隊去實現這些規範的接口，提供功能上的支持，而另一個運營開發小組，則負責根據這個接口，開發供運營團隊人員使用的界面、內部管理系統等。好比遊戲的運營規範會要求遊戲提供查詢角色區服、賬號的名字、等級等數據，提供接口在遊戲中發佈任務；電商系統的運營規範會要求網店提供本店銷售排行查詢、優惠券折扣接口等等。

運維：部署(虛擬機)、監控、統計

做爲非功能性的需求來講，部署需求是第一位的。頻繁的部署是互聯網服務快速演變的基礎能力。另外，互聯網用戶的增長（和消退）也是很是迅速的，這致使了咱們可能須要快速的進行服務器擴容，或者縮容。這種狀況都須要涉及到部署。因此咱們在開發服務器系統的時候，部署需求是第一個須要考慮。加上若是咱們但願實行持續集成，那麼就更加須要重視部署的能力。做爲服務器端系統，若是被設計成帶有很是複雜的進程種類和進程通信關係的話，要作好部署就會變得更加複雜。加上可能部署的環境還不統一，可能出現的問題就更復雜了。因此如今有大量的技術嘗試改善這個方面。首先被你們普遍接受的是虛擬機技術，也就是所謂雲服務器（IAAS），這種技術能讓你無需直接操做硬件，不用扛機器到機房來進行部署，是一種巨大的進步。然後如今咱們有了Docker這種基於Linux容器技術的工具，這能夠把服務器操做系統層的差別環境，都統一成一個個image文件，部署的時候只要運行image文件便可。可是這些依然沒法簡化錯綜複雜的服務器進程關係，因此如今有了各類「隊列服務」技術，好比Kafka，RabbitMQ, ActiveMQ等等，這些隊列服務把進程間通信簡化成專門的服務，減小了部署的複雜性。而ZooKeeper的普遍使用，讓咱們在多進程間協調和監控有了更多的手段。在具體部署工具方面，Chef這一類軟件作了各類有益的嘗試，這些都是能讓咱們優化部署需求功能的工具。

互聯網服務的24X7持續服務能力，實際上會收到各類挑戰，除了版本發佈可能致使的問題外，在大量機器硬件裏面，硬件故障率是一個固定的比例。網絡抖動，機房線路故障也經常會出現。更容易出現的是異常的用戶訪問波動：一大波用戶洶涌而來，可是也有多是DDOS攻擊。無論怎樣，你都須要隨時掌握服務器系統的工做狀態。這時你就須要一個監控系統，但若是產品上線才發現要作，那每每已經很遲了。由於一個系統是否有問題，並非簡單的從內存、CPU、網卡流量就能看出端倪的，咱們每每須要在服務開發之初，就定義好各類須要監控的指標，傳統常見的指標有：每秒主循環的次數、每秒處理業務包的次數、服務器中緩存的會話數等等……一些作的好的系統，還會有不少業務層面的監控指標，好比某個特定服務的處理效率、處理成功率等等。

既然一個系統有大量的監控指標，就涉及如何生成和管理這些數據的問題。傳統的作法是在系統中「埋入」這些監控程序，系統一邊運行一邊統計這些指標，而後定時生成日誌或者經過網絡上報給某個監控系統。可是這種作法的缺點是：若是你須要更多的指標，或者修改指標的統計方法，你就被迫要修改代碼，重啓服務，這樣會影響正在運行的服務。如今另一個作法是，由系統把運行的原始信息記錄成日誌，而後把日誌集中上報到一個監控系統中，這個監控系統通常都帶有分佈式的文件存儲系統和分佈式計算統計能力。在蒐集到大量實時日誌的同時，這個系統根據預設的指標統計方法，不停的進行日誌統計，一旦發現統計結果有問題，就會報警。而這種統計因爲是在大數據處理能力的平臺上生成的，因此每每發現問題的時間差能縮小到分鐘級甚至秒級。這種作法因爲蒐集的是原始日誌記錄，因此就能夠靈活的在系統運行時定製不少統計和報警的策略，但徹底不會增長服務系統的壓力，也不須要修改服務系統的代碼。

最後說說統計，任何一個互聯網系統，都是在用戶的使用中不斷優化的，這個優化的依據，最重要的客觀依據，就是統計數據。而統計數據，通常由兩部分構成：

1. 用戶的行爲數據。好比登陸行爲，就能夠給系統留下用戶的IP、登陸時間、登出時間等數據；購買行爲，就能夠留下購買商品，購買價格，購買時間這些數據。
2. 根據用戶的行爲的關聯，統計出來的數據。好比根據登陸行爲，咱們能夠統計出用戶的在線時長，用戶重複登陸的次數，用戶重複登陸的間隔，還有什麼第二天存留、七天存留等等……；根據購買行爲，咱們更是能夠整理出用戶的購買商品傾向，ARPU值，甚至同類用戶的購買共性，這些也是所謂大數據作商品統計的主要方向。

根據上面的分析，咱們能夠發現，實際上統計系統也是應該分兩個部分設計，一個是儘可能記錄用戶行爲的基礎數據，第二個是以複雜多變的統計條件，去挖掘這些用戶行爲數據中包含的規律。對於第一部分，一個能夠存放海量日誌數據的分佈式存儲系統很是重要；對於第二部分，分佈式的統計運算系統是必不可少的。對於這個體系，Google的Hadoop提供了業界的示範。可是若是你願意，也可使用這個思路本身來建設本身的統計系統，也許你的數據量無須要用到Hadoop那麼複雜。

總結

互聯網開發模式，是針對於互聯網本質上是一個「服務」而發展起來的。由於是「服務」而不是產品，因此應對快速變化的能力是最高的技術標準。咱們傾向採用更適合表達需求的軟件開發技術、自動化程度更高的開發工具，來提升咱們的開發效率，而不是靠單純的「激勵主觀能動性」來作管理。所以咱們在基於自動化測試、自動化部署等持續集成工具的平臺上，使用重視原型迭代的方法來開發項目，在反覆以原型確認需求，以及適應需求變化的過程當中，逐步的完善整個開發生產線。而且把開發和運營視爲一個總體，在服務的運營過程當中，不斷的完善互聯網服務的運營工具，讓開發和運營在同一個生命週期裏生長。