門戶網站運維abc

對於網站運維，感覺大家還是比較迷惘與不解，確實，這是一個新興崗位；近來閑而無事，在此結合自已以往的一些經歷，與大家先共同探討一下「什麼是門戶網站運維」？ 以下是自已的一些經驗和感受請大家斧正，希望和大家一起探討，共同進步
 
 
 一、什麼是門戶網站運維?
 
      首先明確一下，全文所講的」運維「是指：門戶網站應用運維，與其它運維如網路、系統的區別還是蠻大的；然後我們再對大型網站與小型網站進行範圍定義，此定義主要從運維複雜性角度考慮，如網站規範、知名度、伺服器量級、pv量等考慮，其它因素不是重點；因此，我們先定義伺服器規模大於1000台，pv每天至少上千萬（至少國內排名前20），如sina、alibaba、sohu、baidu、網易等等；其它小型網站可能沒有真正意義上的運維工程師，這與網站規範不夠和成本因素有關，更多的是集合網路、系統、開發工作於一身的「複合性人才」，就如本版有些同僚將公司的合同採購都納入了運維職責範圍，還有如IDC網路規劃也納入運維職責，這是網路工程師的工作，我們就不要搶人家飯碗了:)，但是，非常重要一定需要明白：網站應用運維對其它關聯工種必須非常了解熟悉：網路運維、系統運維、應用開發、內容；但這些非自已的本職工作，我在這裡所講的運維工程師就是指專職應用運維工程師
    我們再來說說一個般產品的「出生」流程：
 1、首先公司BOSS層給出指導思想，PM定位市場需求（或copy成熟應用）進行調研、分析、最終給出詳細設計
 2、開發工程師將設計code實現出來、測試工程師對應用進行測試（同一產品事業部）
 3、網路\系統工程師根據產品設計的需求，如pv大小預估、伺服器規模、應用架構等因素完成網路規劃及設備上的調整（基本上對網路變動不大，除非大項目）、SA系統工程師負責產品伺服器上架準備工作，伺服器系統安裝、網路、IP、通用工具集安裝
 
 4、好，到運維工程師出馬了，首先明確一點不是說前三步就與運維工作無關了，恰恰相反，前三步與運維關係很大：應用的前期架構設計、軟/硬體資源評估申請採購、應用設計性能隱患及評估、IDC、服務性能\安全調優、伺服器系統級優化（與特定應用有關）等都需運維全程參與，並主導整個應用上線項目；運維工程師需要對上線的應用系統架構是否合理、是否具備可擴展性、及安全隱患等因素負責，並負責最後將產品（程序）、網路、系統三者進行拼接並最優化的組合在一起，最終完成產品上線提供用戶使用，並周而復使：需求->開發（升級）->測試->上線（性能、安全問題等之前預估外的問題隨之慢慢就全出來了）在這裡提一點：網站開發模式與傳統軟體開發完全不一樣，網站一天開發上線1~5個升級版本是家常便飯，用戶體驗為王嘛，如果某個線上問題像M$需要1年解決，用戶早跑光了；應用上線后，運維工作才剛開始，具體工作可能包括：升級版本上線工作、服務監控、應用狀態統計、日常服務狀態巡檢、突發故障處理、服務日常變更調整、集群管理、服務性能評估優化、資料庫管理優化（大於50台）、隨著應用PV增減進行應用架構的伸縮、安全、運維開發工作：a 盡量將日常機械性手工工作通過工具實現（如服務監控、應用狀態統計、服務上線等等），提高效率 b 、解決現實中服務存在的問題，如高可靠性、可擴展性問題等，c、大規模集群管理工具的開發，如1萬台機器如何在1分鐘內完成密碼修改、或運行指定任務？2000台伺服器如何快速安裝操作系統？各分散式IDC、存儲集群中數BT級的數據如何快速的存儲、共享、分析？等一系列挑戰都需運維工程師的努力。
 
 在此說明一下其它配合工種情況，在整個項目中，前端應用對於網路/系統工程師來說是黑匣子，同時開發工程師職責只是負責完成應用的功能性開發，並對應用本身性能、安全性等應用本身負責，它不負責或關心網路/系統架構方面事宜，當然軟/硬體採購人員等事業部其它同事也不會關心這些問題，各司其職，但項目的核心是運維工程師~！所有其它部門的橋樑
 
     上面說了很多，我想大家應該對運維有一些概念了，在此打個比方吧，如果我們是一輛高速行駛在高速公路上的汽車，那運維工程師就是司機兼維修工，這個司機不簡單，有時需要在高速行駛過程中換輪胎、並根據道路情況換檔位、當汽車速度越來越快，汽車本身不能滿足高速度時對汽車性能調優或零件升級、高速行進中解決汽車故障及性能問題、時刻關注前方安全問題，並先知先覺的採取規避手段。。。這就是運維工作~！
 
     最後說一下運維工程師的職責：」確保線上穩定「，看似簡單，但實屬不容易，運維工程師必須在諸多不利因素中進行權衡：新產品模式對現有架構及技術的衝擊、產品高頻度的升級帶來的線上BUG隱患、運維自動化管理承度不高導致的人為失誤、IT行業追求的高效率導致流程執行上的缺失、用戶增漲帶來的性能及架構上的壓力、IT行業寬鬆的技術管理文化、創新風險、網際網路安全性問題等因素，都會是網站穩定的大敵，運維工程師必須把控好這最後一關，需具體高度的責任感、原則性及協調能力，如果能做到各因素的最佳平衡，那就是一名優秀的運維工程師了
 
     另外在此聊點題外話，我在本版看到有很多人要sina、網易、sohu、baidu等聊自已的運維方面的經驗，其實這對於它們有點免為其難：
 a、各公司自已網路架構、規模、或多或少還算是公司的核心秘密，要保密，另外，對於大家所熟知的通用軟體、架構，由於很多公司會根據自已實際業務需要，同時因為原版性能、安全性、已知bug、功能等原因，進行過二次開發（如apache,php,mysql...），操作系統內核也會根據不同業務類型進行定製的，如某些應用屬於運算型、某些是高IO型、或大儲存大內存型。。。根據這些特點進行內核優化定製，如sina就在memcache上進行過二次開發，搞出了一個memcache DB，具體做得如何我們不談，但開源了，是值得稱讚的，國內公司對於開源基本上是索取，沒有貢獻；另外，伺服器也不是大家所熟知的型號，根據業務特點，大部份都是找DELL/HP/sun/ibm進行過定製；另外，在分散式儲存方面都有自已解決方案，要不就是使用現成開源hadoop等解決方案，或自已開發。但90%都是借鑒google GFS的思想:分散式存儲、計算、大表。
 b、各公司業務方向不一樣，會導致運維模式或方法都不一樣，如alibaba和baidu運維肯定區別很大，因為他們業務模式決定了其架構、伺服器量級、IDC分佈、網路結構、通用技術都會不一樣，主打新聞門戶的sina與主打網游的盛大運維模式差異就非常大,甚至職責都不大一樣；但有一點，通用技術及大致架構上都大同小異，大家不要太神化，更多的公司只是玩壘積木的遊戲罷了，沒什麼技術含量。
 c、如我上面所講，目前門戶網站運維還處於幼年時期理念和經驗都比較零散，沒有成熟的知識體系，我相信大家也講不出所以然來（我現在也中抓破腦袋擠出這點字，呵呵），可能具體什麼是運維，大家都要先思索一番，或壓根沒想過，真正討論也只是運維工作的冰山一角，局限於具體技術細節，或某某著名網站大的框架，真正運維體系化東西沒有，這也許是目前網上運維相關資料比較少的原故吧。。
 
 
 續。。。。10月6日
 
 
 二、運維工作師需要什麼樣的技能及素質
 
     做為一名運維工程師需要什麼樣的技能及素質呢，首先說說技能吧，如大家上面所看到，運維是一個集多IT工種技能與一身的崗位，對系統->網路->存儲->協議->需求->開發->測試->安全等各環節都需要了解一些，但對於某些環節需熟悉甚至精通，如系統(基本操作系統的熟悉使用,*nix,windows..)、協議、開發(日常很重要的工作是自動運維化相關開發、大規模集群工具開發、管理）、通用應用（如lvs、ha、web server、db、中間件、存儲等。。。）、網路（至少要對應用所處網路環境非常了解）；
 技能方面總結以下幾點：
 1、開發能力，這點非常重要，因為運維工具都需要自已開發，開發語言：c/c++（必備其中之一）、perl、python、php（其中之一）、shell（awk,sed,expect....等），需要有過實際開發經驗，否則工作會非常痛苦
 2、通用應用方面需要了解：操作系統（目前國內主要是linux、bsd）、webserver相關(highttp,apahe,php,tomcat,java。。。)、資料庫(mysql,oralce)、其它雜七八拉的東東。。。系統優化，高可靠性。。。這些只是加分項，不需必備，可以邊工作邊慢慢學，這些東西都不難。當然在運維中，有些是有分工偏重點不一樣。如可能有專門的運維dba
 3、系統、網路、安全等需要有所了解，至少知道其原理
 
 
 個人素質方面：
         1 溝通能力、團隊協作：運維工作跨部門、跨工種工作很多，需善於溝通、並且團隊協作能力要強；這應該是現代企業的基本素質要求了，不多說了。。。
         2 工作中需膽大心細  ：膽大才能創新、不走尋常路，特別對於運維這種新的工種，更需創新才能促進發展；心細，運維工程師是網站admin,最高線上許可權者，一不小心就會遺憾終生或打入十八層地獄。。。
         3 主動性、執行力、精力旺盛、抗壓能力強：由於IT行業的特性，變化快；往往計劃趕不上變化，運維工作就更突出了，比如國內各大公司伺服器往往是全國各地，哪裡便宜性價比高，就那往搬，進行大規模服務遷移（牽扯的伺服器成百上千台），這是一個非常頭痛的問題；往往時間非常緊迫，如限1周內完成，要命~~~，這種情況下，運維工程師的主動性及執行力就有很高的要求了：計劃、方案、服務無縫遷移、機器搬遷上架、環境準備、安全評估、性能評估、基建、各關聯部門扯皮。。。。。7X24小緊急事故響應等。
         4 其它就是一些基本素質了：頭腦要靈光、邏輯思維能力強、為人謙虛穩重、親和力、樂於助人、有大局觀
         5 最後一點，做網站運維需要有探索創新精神，通過創新型思維解決現實中的問題，因為這是一個處於幼年的職業（國外也一樣，但比國內起步早點），沒有成熟體系或方法論可以借鑒，只能靠大家自已摸索努力
 
 
 三、運維工程師的職責
 
 1、保證服務達到要求的線標準，如99.9%；保證線上穩定，如，網路/系統運維工程師對網路、系統穩定負責，那應用運維就需對線上應用的穩定負責。
 2、不斷的提升應用的可靠性與健壯性、性能優化、安全提升；這方面非常考驗主動性、和創新思維
 3、網站各層面實時狀態的監控、統計的覆蓋度；軟體、硬體、運行狀態，能監控的都需要監控統計，避免監控死角、並能實時了解應用的運轉情況。
 4、通過創新思維解決運維效率問題；目前各公司大部份運維主要工作還是依賴人工操作干預，需要儘可能的解放雙手
 5、運維知識的積累與沉澱、文檔的完備性，運維是一個經驗性非常強的崗位，好的經驗與陷阱都需積累下來，避免重複性范錯。
 6、成本控制；通過技術手段提升硬體承載、架構優化，如虛擬化技術，節省硬體開支。
 7、自動化運維；能對日常機械化工作進行提煉、設計並開發成工具、系統，能讓系統自動完成的盡量依靠系統；讓大家更多的時間用于思考、創新思維、做自已喜歡的事情。
 
 
 更新。。。10月7日
 
 四、運維職業的迷惘、現狀與發展前景
      應用運維不像其它崗位，如網路、系統、安全運維崗位及研發工程師、測試工程師等，有非常明確的職責定位、職業規劃、社會認同、比較有職業成就感；而應用運維工作可能給人的感覺是系統/應用哪方面都了解一些，但又都比上專職工程師更精通、感覺平時被關注度比較低（除非線上出現故障），慢慢的大家就會迷惘，對職業發展產生困惑,為什麼會有這種現象呢？ 除了職業本身特點外，主要還是因為對運維了解不深入、做得不深入導致、新職位還沒得到社會廣泛認知及認同；其實這個問題其它崗位也會出現，但我發現運維更典型，更容易出現這個問題；
 
 針對這個問題我談一下網站運維的現狀及發展前景（也在思考中，可能不太深入全面，也請大家斧正補充）
 
 運維現狀：
 1、處於剛起步的初級階段，各大公司有此專職，但重視或重要承度不高，可替代性強，工作職責也有所不同；小公司更多是由其它崗位來兼顧做這一塊工作，沒有專職，也不可能做得深入
 2、技術層次比較低；主要處於技術探索、積累階段，沒有型成體系化的理念、技術。
 3、體力勞動偏大；這個問題主要與第二點有關係，很多事情還是依靠人力進行，沒有完成好的提練，對於大規模集群沒有成熟的自動化管理方法，在此說明一下，大規模集群與運維工作是息息相關的如果只是百十來台機器，那就沒有運維太大的生存空間了
 4、優秀運維人才的極度缺乏；目前各大公司基本上都靠自已培養，這個現狀導致行業內運維人才的流動性非常低，非常多好的技術都局限在各大公司內部，如google 50萬台機器如果科學的管理？或者國內top 10 的一些經驗，這些經驗是非常有價值的東西並決定了一個公司的核心競爭力；這些問題進而導致業內先進運維技術的流通、貫通、與借簽，並最終將限制了運維發展。
 5、很多優秀的運維經驗都掌握在大公司手中；這不在於公司的技術實力，而在於大公司的技術規模、海量PV、硬體規模足夠大，如baidu可怕的流量、海量數據~~~~這些因素決定了他們遇到的問題都是其它中/小公司還沒有遇到的，或即將遇到。但大公司可能已有很好的解決方案或系統
 
 
 發展前景：
 1、從行業角度來看，隨著中國網際網路的高速發展（目前中國網民已躍升為全球第一）、網站規模越來越來大、架構越來越複雜；對專職網站運維工程師、網站架構師的要求會越來越急迫,特別是對有經驗的優秀運維人才需求量大，而且是越老越值錢；目前國內基本上都是選擇畢業生培養（限於大公司），培養成本高，而且沒有經驗人才加入會導致公司技術更新緩慢、影響公司的技術發展；當然，畢業生也有好處：白紙一張，可塑性強，比較認同並容易融入企業文化
 2、從個人角度，運維工程師技術含量及要求會越來越高，同時也是對公司應用、架構最了解最熟悉的人、越來越得到重視
 3、網站運維將成為一個融合多學科（網路、系統、開發、安全、應用架構、存儲等）的綜合性技術崗位，給大家提供一個很好的個人能力與技術廣度的發展空間
 4、運維工作的相關經驗將會變得非常重要，而且也將成為個人的核心競爭力，具備很好的各層面問題的解決能力及方案提供、全局思考能力等
 5、特長發控和興趣的培養；由於運維崗位所接觸的知識面非常廣闊，更容易培養或發揮出個人某些方面的特長或愛好，如內核、網路、開發、資料庫等方面，可以做得非常深入精通、成為這方面的專家
 6、如果真要以後不想做運維了，轉到其它崗位也比較容易，不會有太大的局限性。當然了，你得真正用心去做
 7、技術發展方向、網站/系統架構師
 
 續。。。。10.8
 
 五、運維關鍵技術點解剖（比較實際，現實中的案例，今天先想出這幾條，如大家有其它感覺興趣的，可以提出，我來解答）
 1、 大規模集群管理問題
     首先我們先要明確集群的概念，集群不是泛指各功能伺服器的總合，而是指為了達到某一目的或功能的伺服器、硬碟資源的整合（機器數大於兩台），對於應用來說它就是一個整體，目前常規集群可分為：高可用性集群（HA），負載均衡集群（如lvs），分散式儲、計算存儲集群（DFS，如google gfs ,yahoo hadoop），特定應用集群（某一特定功能伺服器組合、如db、cache層等），目前網際網路行業主要基於這四種類型；對於前兩種類似，如果業務簡單、應用上post操作比較少，可以簡單的採用四層交換機解決（如f5、foundly），達到服務高可用/負責均衡的作用，對於資源緊張的公司也有一些開源解決辦法如lvs+ha,非常靈活；對於后兩種，那就考驗公司技術實力及應用特點了，第三種DFS主要應用於海量數據應用上，如郵件、搜索等應用，特別是搜索要求就更高了，除了簡單海量存儲，還包括數據挖掘、用戶行為分析；如google、yahoo就能保存分析近一年的用戶記錄數據，而baidu應該少於30天、soguo就更少了。。。這些對於搜索準備性、及用戶體驗是至關重要的。
      接下來，我們再談談如何科學的管理集群，有以下關鍵幾點：
 I、監控
      主要包括故障監控和性能、流量、負載等狀態監控，這些監控關係到集群的健康運行，及潛在問題的及時發現與干預；
      a、服務故障、狀態監控：主要是對伺服器自身、上層應用、關聯服務數據交互監控；例如針對前端web server，我們就可以有很多種類型的監控，包括應用埠狀態監控，便於及時發現伺服器或應用本身是否crash、通過icmp包探測伺服器健康狀態，更上層可能還包括應用各頻道業務的監控，常用方法是採用面業特徵碼進行判斷，或對重點頁面進行簽名，以網站被黑篡改（報警、並自動恢復被篡改數據）。。。這些只是一部份，還有N多監控方式，依應用特點而定，還有一些問題需解決，如集群過大，如何高性能的進行監控也是一個現實問題。。。。。
      b、其它就是集群狀態類的監控或統計，為我們合理管理調優集群提供數據參考、包括服務瓶頸、性能問題、異常流量、攻擊等問題
 II、故障管理
      a、硬體故障問題；對於成百上千或上萬機器的N多集群，伺服器死機、硬體故障概率是非常大的，幾乎每時每刻都有服務硬體問題，死機、硬碟損壞、電源、內存、交換機。。。針對這種情況，我們在設計網站架構時需要充分考慮到這些問題，並將其視為常態；更多的依靠應用的冗餘機制來規避這種風險，但給系統工程師足夠寬裕的處理時間。（如google不是號稱同時死800台機器，服務不會受到任何影響嗎）；這就是考驗運維工程師及網站架構師功能的地方了，好的設計能達到google所描述自恢復能力，如gfs，糟糕的設計那就是一台伺服器的死機可能會造成大面積服務的連鎖故障反映，直接對用戶拒絕響應。
      b、應用故障問題；可能是某一bug被觸發、或某一性能閥值被超越、攻擊。。。情況不一而定，但重要的一點，是要有對這些問題的預防性措施，不能想當然，它不會出問題，如真出問題了，如何應對? 這需要運維工程師平時做足功夫，包括應急響應速度、故障處理的科學性、備用方案的有效等
 III、自動化
      自動化：簡而言之，就是將我們日常手動進行的一些工作通過工具，系統自動來完成，解放我們的雙手及枯燥的重複性勞動，例如：沒有工具前，我們安裝系統需要一台一台裸機安裝，如2000台，可能需要10人/10天，搞爛N張光碟，人力成本更大。。。而現在通過自動化工具，只需幾個簡單命令就能搞定、還有如機器人類程序，自動完成以往每天人工干預的工作，使其自動完成、彙報結果，並具備一定的專家系統能力，能做一些簡單的是/非判斷、優化選擇等。。。這些好處非常明顯不再多說。。。應該說，自動化運維是運維工程師職業化的一個追求，利私利公，雖然這是一個異常艱巨的任務：不斷變更的業務、不規範化的應用設計、開發模式、網路架構變更、IDC變更、規範變動等因素，都可能會對現有自動化系統產生影響，所以需要模塊化、介面化、變因參數化等。。。。。。因此，自動化相關工作，是運維工程師的核心重點工作之一，也是價值的體現
 
 10月13日更新。。。。
 
 2 大併發網站的設計
 
         網站架構設計中，非常重要的一個要素，就是確保架構的可擴展性、這是高併發網站的基石。往往，一個網站的大流量不是與生具來的，而是有一個積累過程~~最後變成巨無霸，包括google、yahoo這種全球流量大戶，而在這個成長過程中所積累的經驗才是最值得我們學習的，包括思考方式、問題解決、改進過程。沒有最好的架構設計方案，只有更好。。。，因此在此不會給大家一個終極方案。。。，在此介紹的這些經驗，更多的是讓大家真正掌握架構設計方法、理念、靈魂，並真正的能利用到實際中。為了讓大家更易理解，我在此主題討論中將會借用本版」jiang2798 「貼的"google架構、youtube架構"等經典案例和大家分析一下，再談談一些通用性原則及技巧
 
 高併發架構需滿足的一些因素、要點：
 I    負載均衡架構
     首先網站前端需要採用負載均衡群集解決用戶高併發的響應，目前常用方法包括 a、squid反向代理，這也是各大網站常用的方法，包括sohu、sina...；b、DNS輪循；c、采四層硬體設備，包括google、baidu使用這種方式。。。對於lvs，小頻道或不重要應用可以嘗試使用，對於大流量、實時性要求高的網站目前還不成熟。
 
 II   高性能中間件選擇、優化
     中間件選擇、優化非常重要，當服務流量大於一定承度時，性能的稍微提升，對於整體硬體成本控制、服務的整體性能提升都是非常可觀的。對於web server 目前常用的屬apache，但apache 多進程(線程池)架構有一些缺點，進程頻繁生成\註銷系統開銷大，特別當流量大時更是明顯，對於應用邏輯簡單的可以考慮lighttpd 採用單進程+epoll併發模式，效率高，但對多CPU支持有問題，但可採用啟多服務解決這個問題；如果由於應用架構原因必須使用apache，可考慮apache module 性能比普通CGI成倍提升。。。其它原則，包括各中間件各版本測試、包括性能、安全上的考良，找到平衡點，不要太關注某一點因素，導致整體架構上出現隱患，另外一點非常重要，那就中間件的參數優化，這些方面大家可以google、baidu上找找，比較多，但有個原則那就是需要根據伺服器實際資源情況進行優化，如httpd最大進程數設多大合適呢？有些朋友，就隨手來個2048，覺得這樣肯定不會再出現httpd由於進程閥值過低導致拒絕服務，但這有個隱患，因為生成進程，是需要硬體資源的，當進程數達到一定承度，可能伺服器內存會溢出，導致伺服器crash，特別是內存消耗量大的應用。。。這樣的案例很多，需謹記
 
 10.16 續。。。
 
 III  擴展性問題
      擴展性對於高速發展期間的網站非常重要，大家可以經常在網上看到某某網站的發展勵途，那簡直就是一部進化史，過程曲折而痛苦~~。因此成熟的經驗就非常重要了，擴展性可以從兩個方面來看：網路系統上的擴展性及應用本身的擴展性，首先在網路上需層次分明，盡量扁平化，全網冗餘不能存在故障點，盡量按業務類型進行劃分網路結構(pv大小、優先順序)防止互擾，重要的一點：網路設計中，簡單就是美~~，在不影響擴展性的前提下，不要搞得太複雜；網路硬體資源、機架位、IDC都需提前至少半年進行規劃，這些規劃的重要依據是公司業務發展的前景評估，這就體現公司的戰略眼光了，包括是否需要外地IDC（依用戶群體而定）。。。；另外，選一個好點的IDC是非常必要的，否則就得疲於IDC遷移了，北京地區好IDC還是不少的：皂君廟（有點老了。）、土城、聯通、酒仙橋、愛立信、互聯世紀、奧運官方機房數字北京據說馬上也能入駐了。。。當然了，有錢也能像google一樣自已搞個IDC，國內誰有這個實力?
      另一點就是應用本身的擴展性了，原則其實很簡單，應用設計時應盡量確保應用的層次化、採用高性能的中間件、邏輯複雜及大數據量交互的功能盡量做成獨立模塊\後台、cache層、資料庫分層（讀/寫操作分離），不要圖前期簡單直接將功能全部揉進前端CGI中，這很致命，隨時都可能會遇到性能瓶頸、而且毫無擴展性。。。
       當以上兩點很好的解決后，現在唯一的問題就是每半年根據業務的PV增漲、新業務發展，預購伺服器了。。。；當然了，對現有架構優化，性能提升才是根本解決之道，特別是現在全球經濟不景氣，大家都不好過，這就是運維工程師的責任了，優化再優化~~
 
 10.23 續。。。
 
 IV  應用設計、開發中的注意點
     架構層設計好后，應用層設計就是我們重點關注對象了，這也是一個項目成功的關鍵，好的設計主要體現在：性能(高併發承載能力)、可擴展性、可維護、安全性（數據完整性、應用穩定性、前端應用安全如SQL注入。。。）、模塊冗餘、負載均衡等等，技術點：線程池、epoll、TCP(長/短)連接的選擇、功能模塊的細化及後台化、模塊冗餘/負載均衡考慮(可擴展性)、高頻數據cache緩存、數據分層、應用單故障點的解決(數據唯一性問題)等。。。有兩點要注意：1、應用設計時要允分考慮伺服器、硬體設備甚基於IDC的不可靠性；也就是說我們在應用設計時需要考慮到應用運行過程中，隨時都可能會有1~2台伺服器或更多伺服器出現故障情況(網路故障、災難、攻擊、停電((整個IDC全掛))。。。)，如google GFS就是一個典型，我們不能將應用的穩定性寄託於硬體的穩定上，特別是門戶型公司大部份採用的都是X86普通機型，伺服器crash是家常便飯、隨時隨刻(當總量到一定量級時)，所以我們在做應用架構設計時需允分考慮這些問題發生時的對策，做到允分的冗餘/負載均衡（這兩點可統一），如多IDC間通過智能CDN的流控、單IDC應用模塊多節點冗餘/負載均衡等，即使某些應用由於特殊原因無法做到這點，也需允分考慮應急預案。。好的設計在這些突發情況下可以做到不用人工干預，當然難度也很大。。。記得前年李開復在北大演講時說過：google一個IDC同時故障800台機器，不會影響到任何應用的正常響應（有點懷疑，可能是他挑選的某類伺服器，呵呵）；2、大流量應用/模塊中能不使用資料庫就不要使用資料庫。