㈠ 什麼是分布式感謝分享,百度能搜到的概念性的東西就不要貼了 java開發的web網站怎麼實現分布式
我看了網路後的理解是：
集群：集群是同一個任務，由許多台伺服器通過負載均衡來完成。
分布式：一個任務，拆分為多個子任務，由不同的伺服器完成各自的結果並匯總。
比如有二十個算術題，集群負載均衡概念是讓10個人每個人分1個或2個題，有的人學習很好，可能就給他分3道題，有的人學習差，就只給他分1個題。注意每個人分到的這些題都是完整的一道或多道題並沒有拆分。把學習能力理解為伺服器的處理能力就可以了。
有一個算術題，分布式的概念是，把這個題分成幾個小問題，分給一堆人，這堆人每個人解決自己的小問題。
分布式利用集群概念是指：首先布置一層分布式網路，例如A節點處理乘法問題，B節點處理加法問題。那麼A節點伺服器或許會接收到大量的計算請求。例如例子中的現在有20個乘法題，那麼A節點可以採用集群方式，把這20個乘法題負載均衡的方式分給同在A節點的其他伺服器。這里有個點就是，A節點可以是一台伺服器，也可是多台伺服器。當是多台伺服器處理同類請求的時候，顯然就是分布式中某個節點利用了集群概念了。
這只是我自己的理解，如果不是的話還請路過大神指正。。。
關於你說的問題，我挑個我會的吧。運行同一個web程序，我認為這是集群概念而非分布式概念，如果每個節點運行一個web程序的一部分，例如A運行 數學計算 程序的 加法部分。B運行乘法部分，我認為這才算分布式概念。運行同一個web程序，顯然可以同時接受大量請求，然後負載均衡給每一台伺服器完整運行咯。
就我知道的，Dubbo框架就是一個分布式框架，也可以實現集群負載均衡。
㈡ websphere 分布式計算和架構是怎麼實現的
介紹
分布式計算簡單來說，是把一個大計算任務拆分成多個小計算任務分布到若乾颱機器上去計算，然後再進行結果匯總。 目的在於分析計算海量的數據，從雷達監測的海量歷史信號中分析異常信號(外星文明)，淘寶雙十一實時計算各地區的消費習慣等。
海量計算最開始的方案是提高單機計算性能，如大型機，後來由於數據的爆發式增長、單機性能卻跟不上，才有分布式計算這種妥協方案。 因為計算一旦拆分，問題會變得非常復雜，像一致性、數據完整、通信、容災、任務調度等問題也都來了。
舉個例子，產品要求從資料庫中100G的用戶購買數據，分析出各地域的消費習慣金額等。 如果沒什麼時間要求，程序員小明就寫個對應的業務處理服務程序，部署到伺服器上，讓它慢慢跑就是了，小明預計10個小時能處理完。 後面產品嫌太慢，讓小明想辦法加快到3個小時。
平常開發中類似的需求也很多，總結出來就是，數據量大、單機計算慢。 如果上Hadoop、storm之類成本較高、而且有點大才小用。 當然讓老闆買更好的伺服器配置也是一種辦法。
利用分片演算法
小明作為一個有追求有理想的程序員，決定用介於單機計算和成熟計算框架的過度解決方案，這樣成本和需求都能滿足了。 分布式計算的核心在於計算任務拆分，如果數據能以水平拆分的方式，分布到5台機器上，每台機器只計算自身的1/5數據，這樣即能在3小時內完成產品需求了。
如上所述，小明需要把這些數據按照一定維度進行劃分。 按需求來看以用戶ID劃分最好，由於用戶之間沒有狀態上的關聯，所以也不需要事務性及二次迭代計算。 小明用簡單的hash取模對id進行劃分。
f(memberid) % 5 = ServerN
這樣程序可以分別部署到5台機器上，然後程序按照配置只取對應余數的用戶id，計算出結果並入庫。 這種方式多機之間毫無關聯，不需要進行通信，可以避免很多問題。 機器上的程序本身也不具備分布式的特性，它和單機一樣，只計算自身獲取到的數據即可，所以如果某台機器上程序崩潰的話，處理方式和單機一樣，比如記錄下處理進度，下次從當前進度繼續進行後續計算。
利用消息隊列
使用分片方式相對比較簡單，但有如下不足之處。
它不具有負載均衡的能力，如果某台機器配置稍好點，它可能最先計算完，然後空閑等待著。也有可能是某些用戶行為數據比較少，導致計算比較快完成。
還有一個弊端就是每台機器上需要手動更改對應的配置， 這樣的話多台機器上的程序不是完全一樣的，這樣可以用遠程配置動態修改的辦法來解決。
小明這種方式引入了個第三方，消息隊列。 小明先用一個單獨的程序把用戶信息推送到消息隊列里去，然後各台機器分別取消費這個隊列。 於是就有了3個角色：
推送消息的，簡稱Master。
消息隊列，這里以Rabbitmq為例。
各個處理程序，簡稱Worker或Slave都行。
雖然僅僅引入了個第三方，但它已經具備了分布式計算的很多特性。
計算任務分發。 Master把需要計算的用戶數據，不斷的推送消息隊列。
程序一致性。 Worker訂閱相同的消息隊列即可，無需更改程序代碼。
任意擴容。 由於程序完全一樣，意味著如果想要加快速度，重復部署一份程序到新機器即可。 當然這是理論上的，實際當中會受限於消息隊列、資料庫存儲等。
容災性。 如果5台中某一台程序掛了也不影響，利用Rabbitmq的消息確認機制，機器崩潰時正在計算的那一條數據會在超時，在其他節點上進行消費處理。
Hadoop簡介
Hadoop介紹已經相當多了，這里簡述下比如:」Hadoop是一套海量數據計算存儲的基礎平台架構」，分析下這句話。
其中計算指的是MapRece，這是做分布式計算用的。
存儲指的是HDFS，基於此上層的有HBase、Hive，用來做數據存儲用的。
平台，指可以給多個用戶使用，比如小明有一計算需求，他只需要按照對應的介面編寫業務邏輯即可，然後把程序以包的形式發布到平台上，平台進行分配調度計算等。 而上面小明的分布式計算設計只能給自己使用，如果另外有小華要使用就需要重新寫一份，然後單獨部署，申請機器等。Hadoop最大的優勢之一就在於提供了一套這樣的完整解決方案。
下面找了介紹Hadoop的概覽圖，跟小明的設計做對比下:
圖中「大數據計算任務」 對應小明的100G用戶數據的計算任務。
」任務劃分「 對應Master和消息隊列。
「子任務」 對應Worker的業務邏輯。
」結果合並「 對應把每個worker的計算結果入庫。
「計算結果」 對應入庫的用戶消費習慣數據。
PS：為了方便描述，把小明設計的分布式計算，叫做小和尚。
MapRece
由於MapRece計算輸入和輸出都是基於HDFS文件，所以大多數公司的做法是把mysql或sqlserver的數據導入到HDFS，計算完後再導出到常規的資料庫中，這是MapRece不夠靈活的地方之一。 MapRece優勢在於提供了比較簡單的分布式計算編程模型，使開發此類程序變得非常簡單，像之前的MPI編程就相當復雜。
狹隘的來講，MapRece是把計算任務給規范化了，它可以等同於小和尚中Worker的業務邏輯部分。 MapRece把業務邏輯給拆分成2個大部分，Map和Rece，可以先在Map部分把任務計算一半後，扔給Rece部分繼續後面的計算。 當然在Map部分把計算任務全做完也是可以的。 關於Maprece實現細節部分不多解釋，有興趣的同學可以查相關資料或看下樓主之前的C#模擬實現的博客【探索C#之微型MapRece】。
如果把小明產品經理的需求放到Hadoop來做，其處理流程大致如下：
把100G數據導入到HDFS
按照Maprece的介面編寫處理邏輯，分Map、Rece兩部分。
把程序包提交到Maprece平台上，存儲在HDFS里。
平台中有個叫Jobtracker進程的角色進行分發任務。 這個類似小和尚的Master負載調度管理。
如果有5台機器進行計算的話，就會提前運行5個叫TaskTracker的slave進程。 這類似小和尚worker的分離版，平台把程序和業務邏輯進行分離了， 簡單來說就是在機器上運行個獨立進程，它能動態載入、執行jar或dll的業務邏輯代碼。
Jobtracker把任務分發到TaskTracker後，TaskTracker把開始動態載入jar包，創建個獨立進程執行Map部分，然後把結果寫入到HDFS上。
如果有Rece部分，TaskTracker會創建個獨立進程把Map輸出的HDFS文件，通過RPC方式遠程拉取到本地，拉取成功後，Rece開始計算後續任務。
Rece再把結果寫入到HDFS中
從HDFS中把結果導出。
這樣一看好像是把簡單的計算任務給復雜化了，其實如果只有幾台計算任務的話，使用Maprece確實是殺雞用牛刀了。 如果有TB、PB級別的數據、跑在成百上千台計算節點上，Maprece的優勢才會體現出來。 其計算框架圖架構如下：
離線計算
通常稱Maprece及小和尚這種計算為離線計算，因為它對已經持久化的文件數據進行計算，不能實時響應。 還有個原因就是它的處理速度比較慢，它的輸入和輸出源都是基於HDFS設計，如果數據不是一開始就寫入到HDFS上，就會涉及到數據導入導出，這部分相對耗費時間。 而且它的數據流動是基於文件系統的，Map部分輸出的數據不是直接傳送到Rece部分，而是先寫入HDFS再進行傳送。
處理速度慢也是Maprece的不足之處，促使了後面實時計算的誕生。
另外個缺點是Maprece的計算任務流比較單一，它只有Map、Rece兩部分。 簡單的可以只寫一部分邏輯來解決，如果想拆分成多個部分，如邏輯A、邏輯B、邏輯C等， 而且一部分計算邏輯依賴上一次計算結果的話，MapRece處理起來就比較困難了。 像storm框架解決此類問題的方案，也稱為流式計算，下一章繼續補充。
㈢ 如何開發web分布式工作流管理系統
一、背景資料
基於知識管理的辦公自動化系統簡介
（一）第三代辦公自動化系統的理念
第三代辦公自動化系統以知識管理為核心。網路時代的辦公已經不再是簡單
的文件處理，不再是行政事務了，其目的在於達到整個企業的最終目標，這就需
要依靠先進的管理思想和方法。知識管理是一種系統，是幫助企業發現知道什麼、
如何定位擁有專門知識的人、如何傳遞這些知識及如何有效利用知識的系統，它
意味著能夠在恰當的時間，將正確的知識傳給正確的人，幫助他們採取正確的行
動，避免重復錯誤和重復工作，幫助企業提供整體業務水平的提高。
知識管理是企業信息集成的一個必然趨勢，應該說是一種自然的演進過程，
它將會滲透於信息系統建設的方方面面，在信息建設中得到融合與體現。先進的
組織管理模式與知識管理之間是相輔相成的關系，先進的管理模式革命，必然引
發知識管理的新浪潮；知識管理的實施，將會進一步推動先進管理思想在企業中
的滲透。
1．把知識管理融入BPR(業務流程重組)
知識管理只有與業務流程緊密相連，才能獲得成功。將知識創造與發布同企
業的業務流程相結合，不僅可以節省大量開支，更重要的是能夠產生巨大的價值，
通過知識管理實現對業務流程中無序的知識進行系統化管理，實現知識共享和再
利用，從而提高業務水平和效率。
2．改造企業文化
知識管理的成功首先取決於鼓勵信息共享的企業文化。改造傳統的企業文化、
建立有利於知識共享的新型企業文化，是企業能夠在知識經濟時代不斷發展的關
鍵因素。
3．通過知識管理提高企業的核心能力-建立學習型企業
所謂學習型企業，是指通過不斷的學習來改企業自身、提高企業競爭力的企
業，善於不斷地學習是它的本質特徵。這里所說的學習並不僅僅是單純的看書、
辦學習班，而是包括了企業在系統研究項目和產品開發、營銷、技術支持過程中
學習，它強調全員學習、全程學習和團隊學習。全員學習，從決策層、管理層到
具體操作層都要全身心地投入學習；全程學習，任何企業的運作都包括准備、計
劃、推行3 個階段，把學習融入企業運作的所有階段；團隊學習，不僅重視個人
學習和個人智力的開發，更重視團隊學習和群體智力的開發。
（二）第三代OA 的架構
第三代OA 的底層是企業的基本信息支撐環境，它包括MRPII、MIS 系統對企
業內部各種層次生產經營管理過程的信息化支撐，以及對企業外部Internet 的信
息獲取。三類系統的相互作用體現了Intranet 的思想，通過設計與實現優秀的
Internet 信息獲取工具，可以有效地利用外部的有用信息為企業內部的經營管理
過程服務，幫助企業更好地把握來自市場的機遇與挑戰。
- 27 -
第二層是企業多維知識倉庫，存在於底層企業信息支撐環境中的企業信息資
源是龐雜而海量的，需要在數據挖掘與模式提取的工具支持下，發掘其中有價值
的模式與知識，進行緊密而科學的組織，這是支持知識管理系統實現的有利依據。
知識管理的目的就在於更好地支持各個層次企業員工的工作流過程，包括：
(1) 員工與企業知識倉庫之間的個人知識挖掘與融合過程，用於完成員工不
斷根據個人需求在知識倉庫中的映射與知識提取，以及員工個人知識不斷融合進
入企業整個知識倉庫的過程；
(2) 員工之間的知識流轉與共享過程，提供了不同知識映射集合之間共享與
交叉的可能，同時也提供了無法進入企業知識倉庫中的非結構化個人頭腦知識的
交流與互動的機會，從而可能引發新的知識的產生；
(3) 個人知識支持的工作過程與信息回饋過程，是在個人知識平台支持下指
導實現員工的工作過程，以及工作結果的信息回饋過程。充分利用這一過程，可
以及時地收集知識利用的反饋信息，為閉環知識管理系統的完善與控制提供了必
要基礎。
基於企業多維知識倉庫還可以通過進一步的知識支持與決策分析過程建立面
向決策的企業決策支持系統，也就是圖中的第三層。通過建立決策模型與先進系
統理論的應用，支持企業決策者高層次的管理決策過程，從根本上決定與引導企
業的發展演變過程。
在上述分析中，我們看到知識在企業內部的縱向提取過程、員工與知識系統
的發散性融合作用、企業員工工作環境中員工知識的相互交叉作用、相增相長，
以及員工知識在企業信息管理中的循環更新過程，這正是知識管理系統的邏輯實
現模型。
幾種不同的應用解決方案類型：
(1)工作組通信：在工作組的成員間提高信息交換的效率，如電子郵件、在線
日歷等。
(2)企業級通信：跨越企業內部門間的界限，提供全企業的復雜的信息傳遞系
統。
(3)企業間通信：企業間郵件、EDI、電子化文檔交換(例如基於Web 發布文檔)。
(4)工作組協作：利用在線討論組和共享資源，發揮工作組中每個人的技能達
到共同探索和集體決策。
(5)企業級知識管理：跨越企業內部門間的界限，更好地利用企業內的各類智
力資源，避免企業內各種寶貴的經驗和專長埋沒於個人或某個部門內部。將這些
智力資源與企業的工作環境相集成，形成可以指導員工的實際工作和學習培訓的
「知識」。
(6)電子社區開發：跨越企業間的界限，在某些方面具有共同利益的實體形成
虛擬的電子化共同空間，利用該空間為各個參與者服務，例如在線交換創意和分
布式的學習工具。
(7)工作組級流程創新：將工作組內部的信息流和知識流應用於工作流程中，
以創造新的或改進現有的工作方式和流程(例如銷售自動化)。
(8)企業級流程創新：打破部門間的界限，在企業內重新協調工作流程，以實
- 28 -
現減少停頓時間、避免冗餘和相互抵觸的目標和激勵機制。例如很多企業在改造
「從概念到市場」的產品製造流程，使其更加有效和迅速。
(9)價值鏈創新：將企業級的流程創新擴展到企業之間，從企業所處的社會和
經濟價值鏈入手，改造企業間的工作流程，為所有的企業帶來收益。
我們可以看出知識管理以網路通訊作為支撐基礎，以協作和協調作為實現知
識管理的技術手段。而協作和協調正是第三代OA 的基本技術和優勢。
㈣ Java Web如何實現分布式 將網站分成多個功能點在多台伺服器上發布！
Apache+Tomcat整合
Tomcat可以做在多個伺服器場，至於怎麼組合看你自己了
可以把不同的模塊放在不同的Tomcat中，也可以把Apache+Tomcat中的Tomcat做成集群模式
㈤ web程序分布式怎麼實現
這個是由中間件的集群實現的,,,tomcat,weblogic等..這些中間件能夠自動處理當前的會話信息,後端中間件自動從節點1切換到節點2,,但用戶的當前數據不會丟失..
㈥ 請問分布式架構主要有哪幾種
分布式架構CORBA (Common Object Request Broker Architecture) 是在1992年由OMG(Open Management Group) 組織提出的。那時的分布式應用環境都採用Client/Server架構，CORBA的應用很大程度的提高了分布式應用軟體的開發效率。 當時的另一種分布式系統開發工具是Microsoft的DCOM(Distributed Common Object Model)。Microsoft為了使在Windows平台上開發的各種應用軟體產品的功能能夠在運行時(Runtime)相互調用(比如在Microsoft Word中直接編輯Excel文件)，實現了OLE(Linked and Embedded Object)技術，後來這個技術衍生為COM(Common Object Model)。 瑭錦-TANJURD表示隨著Internet的普及和網路服務(Web Services)的廣泛應用, Browser/Server架構的模式逐漸體現出它的優勢。於是，Sun公司在其Java技術的基礎上推出了應用於B/S架構的J2EE的開發和應用平台;Microsoft也在其DCOM技術的基礎上推出了主要面向B/S應用的.NET開發和應用平台。
㈦ 分布式Web伺服器架構
最開始，由於某些想法，於是在互聯網上搭建了一個網站，這個時候甚至有可能主機都是租借的，但由於這篇文章我們只關注架構的演變歷程，因此就假設這個時候已經是託管了一台主機，並且有一定的帶寬了，這個時候由於網站具備了一定的特色，吸引了部分人訪問，逐漸你發現系統的壓力越來越高，響應速度越來越慢，而這個時候比較明顯的是資料庫和應用互相影響，應用出問題了，資料庫也很容易出現問題，而資料庫出問題的時候，應用也容易出問題，於是進入了第一步演變階段：將應用和資料庫從物理上分離，變成了兩台機器，這個時候技術上沒有什麼新的要求，但你發現確實起到效果了，系統又恢復到以前的響應速度了，並且支撐住了更高的流量，並且不會因為資料庫和應用形成互相的影響。
這一步架構演變對技術上的知識體系基本沒有要求。
架構演變第二步：增加頁面緩存
好景不長，隨著訪問的人越來越多，你發現響應速度又開始變慢了，查找原因，發現是訪問資料庫的操作太多，導致數據連接競爭激烈，所以響應變慢，但資料庫連接又不能開太多，否則資料庫機器壓力會很高，因此考慮採用緩存機制來減少資料庫連接資源的競爭和對資料庫讀的壓力，這個時候首先也許會選擇採用squid 等類似的機制來將系統中相對靜態的頁面（例如一兩天才會有更新的頁面）進行緩存（當然，也可以採用將頁面靜態化的方案），這樣程序上可以不做修改，就能夠很好的減少對webserver的壓力以及減少資料庫連接資源的競爭，OK，於是開始採用squid來做相對靜態的頁面的緩存。
前端頁面緩存技術，例如squid，如想用好的話還得深入掌握下squid的實現方式以及緩存的失效演算法等。
架構演變第三步：增加頁面片段緩存
增加了squid做緩存後，整體系統的速度確實是提升了，webserver的壓力也開始下降了，但隨著訪問量的增加，發現系統又開始變的有些慢了，在嘗到了squid之類的動態緩存帶來的好處後，開始想能不能讓現在那些動態頁面里相對靜態的部分也緩存起來呢，因此考慮採用類似ESI之類的頁面片段緩存策略，OK，於是開始採用ESI來做動態頁面中相對靜態的片段部分的緩存。
這一步涉及到了這些知識體系：
頁面片段緩存技術，例如ESI等，想用好的話同樣需要掌握ESI的實現方式等；
架構演變第四步：數據緩存
在採用ESI之類的技術再次提高了系統的緩存效果後，系統的壓力確實進一步降低了，但同樣，隨著訪問量的增加，系統還是開始變慢，經過查找，可能會發現系統中存在一些重復獲取數據信息的地方，像獲取用戶信息等，這個時候開始考慮是不是可以將這些數據信息也緩存起來呢，於是將這些數據緩存到本地內存，改變完畢後，完全符合預期，系統的響應速度又恢復了，資料庫的壓力也再度降低了不少。
這一步涉及到了這些知識體系：
緩存技術，包括像Map數據結構、緩存演算法、所選用的框架本身的實現機制等。
架構演變第五步： 增加webserver
好景不長，發現隨著系統訪問量的再度增加，webserver機器的壓力在高峰期會上升到比較高，這個時候開始考慮增加一台webserver，這也是為了同時解決可用性的問題，避免單台的webserver down機的話就沒法使用了，在做了這些考慮後，決定增加一台webserver，增加一台webserver時，會碰到一些問題，典型的有：
1、如何讓訪問分配到這兩台機器上，這個時候通常會考慮的方案是Apache自帶的負載均衡方案，或LVS這類的軟體負載均衡方案；
2、如何保持狀態信息的同步，例如用戶session等，這個時候會考慮的方案有寫入資料庫、寫入存儲、cookie或同步session信息等機制等；
3、如何保持數據緩存信息的同步，例如之前緩存的用戶數據等，這個時候通常會考慮的機制有緩存同步或分布式緩存；
4、如何讓上傳文件這些類似的功能繼續正常，這個時候通常會考慮的機制是使用共享文件系統或存儲等；
在解決了這些問題後，終於是把webserver增加為了兩台，系統終於是又恢復到了以往的速度。
這一步涉及到了這些知識體系：
負載均衡技術（包括但不限於硬體負載均衡、軟體負載均衡、負載演算法、linux轉發協議、所選用的技術的實現細節等）、主備技術（包括但不限於 ARP欺騙、linux heart-beat等）、狀態信息或緩存同步技術（包括但不限於Cookie技術、UDP協議、狀態信息廣播、所選用的緩存同步技術的實現細節等）、共享文件技術（包括但不限於NFS等）、存儲技術（包括但不限於存儲設備等）。
架構演變第六步：分庫
享受了一段時間的系統訪問量高速增長的幸福後，發現系統又開始變慢了，這次又是什麼狀況呢，經過查找，發現資料庫寫入、更新的這些操作的部分資料庫連接的資源競爭非常激烈，導致了系統變慢，這下怎麼辦呢，此時可選的方案有資料庫集群和分庫策略，集群方面像有些資料庫支持的並不是很好，因此分庫會成為比較普遍的策略，分庫也就意味著要對原有程序進行修改，一通修改實現分庫後，不錯，目標達到了，系統恢復甚至速度比以前還快了。
這一步涉及到了這些知識體系：
這一步更多的是需要從業務上做合理的劃分，以實現分庫，具體技術細節上沒有其他的要求；
但同時隨著數據量的增大和分庫的進行，在資料庫的設計、調優以及維護上需要做的更好，因此對這些方面的技術還是提出了很高的要求的。
架構演變第七步：分表、DAL和分布式緩存
隨著系統的不斷運行，數據量開始大幅度增長，這個時候發現分庫後查詢仍然會有些慢，於是按照分庫的思想開始做分表的工作，當然，這不可避免的會需要對程序進行一些修改，也許在這個時候就會發現應用自己要關心分庫分表的規則等，還是有些復雜的，於是萌生能否增加一個通用的框架來實現分庫分表的數據訪問，這個在ebay的架構中對應的就是DAL，這個演變的過程相對而言需要花費較長的時間，當然，也有可能這個通用的框架會等到分表做完後才開始做，同時，在這個階段可能會發現之前的緩存同步方案出現問題，因為數據量太大，導致現在不太可能將緩存存在本地，然後同步的方式，需要採用分布式緩存方案了，於是，又是一通考察和折磨，終於是將大量的數據緩存轉移到分布式緩存上了。
這一步涉及到了這些知識體系：
分表更多的同樣是業務上的劃分，技術上涉及到的會有動態hash演算法、consistent hash演算法等；
DAL涉及到比較多的復雜技術，例如資料庫連接的管理（超時、異常）、資料庫操作的控制（超時、異常）、分庫分表規則的封裝等；
架構演變第八步：增加更多的webserver
在做完分庫分表這些工作後，資料庫上的壓力已經降到比較低了，又開始過著每天看著訪問量暴增的幸福生活了，突然有一天，發現系統的訪問又開始有變慢的趨勢了，這個時候首先查看資料庫，壓力一切正常，之後查看webserver，發現apache阻塞了很多的請求，而應用伺服器對每個請求也是比較快的，看來是請求數太高導致需要排隊等待，響應速度變慢，這還好辦，一般來說，這個時候也會有些錢了，於是添加一些webserver伺服器，在這個添加 webserver伺服器的過程，有可能會出現幾種挑戰：
1、Apache的軟負載或LVS軟負載等無法承擔巨大的web訪問量（請求連接數、網路流量等）的調度了，這個時候如果經費允許的話，會採取的方案是購買硬體負載，例如F5、Netsclar、Athelon之類的，如經費不允許的話，會採取的方案是將應用從邏輯上做一定的分類，然後分散到不同的軟負載集群中；
2、原有的一些狀態信息同步、文件共享等方案可能會出現瓶頸，需要進行改進，也許這個時候會根據情況編寫符合網站業務需求的分布式文件系統等；
在做完這些工作後，開始進入一個看似完美的無限伸縮的時代，當網站流量增加時，應對的解決方案就是不斷的添加webserver。
這一步涉及到了這些知識體系：
到了這一步，隨著機器數的不斷增長、數據量的不斷增長和對系統可用性的要求越來越高，這個時候要求對所採用的技術都要有更為深入的理解，並需要根據網站的需求來做更加定製性質的產品。
架構演變第九步：數據讀寫分離和廉價存儲方案
突然有一天，發現這個完美的時代也要結束了，資料庫的噩夢又一次出現在眼前了，由於添加的webserver太多了，導致資料庫連接的資源還是不夠用，而這個時候又已經分庫分表了，開始分析資料庫的壓力狀況，可能會發現資料庫的讀寫比很高，這個時候通常會想到數據讀寫分離的方案，當然，這個方案要實現並不容易，另外，可能會發現一些數據存儲在資料庫上有些浪費，或者說過於佔用資料庫資源，因此在這個階段可能會形成的架構演變是實現數據讀寫分離，同時編寫一些更為廉價的存儲方案，例如BigTable這種。
這一步涉及到了這些知識體系：
數據讀寫分離要求對資料庫的復制、standby等策略有深入的掌握和理解，同時會要求具備自行實現的技術；
廉價存儲方案要求對OS的文件存儲有深入的掌握和理解，同時要求對採用的語言在文件這塊的實現有深入的掌握。
架構演變第十步：進入大型分布式應用時代和廉價伺服器群夢想時代
經過上面這個漫長而痛苦的過程，終於是再度迎來了完美的時代，不斷的增加webserver就可以支撐越來越高的訪問量了，對於大型網站而言，人氣的重要毋庸置疑，隨著人氣的越來越高，各種各樣的功能需求也開始爆發性的增長，這個時候突然發現，原來部署在webserver上的那個web應用已經非常龐大了，當多個團隊都開始對其進行改動時，可真是相當的不方便，復用性也相當糟糕，基本是每個團隊都做了或多或少重復的事情，而且部署和維護也是相當的麻煩，因為龐大的應用包在N台機器上復制、啟動都需要耗費不少的時間，出問題的時候也不是很好查，另外一個更糟糕的狀況是很有可能會出現某個應用上的bug就導致了全站都不可用，還有其他的像調優不好操作（因為機器上部署的應用什麼都要做，根本就無法進行針對性的調優）等因素，根據這樣的分析，開始痛下決心，將系統根據職責進行拆分，於是一個大型的分布式應用就誕生了，通常，這個步驟需要耗費相當長的時間，因為會碰到很多的挑戰：
1、拆成分布式後需要提供一個高性能、穩定的通信框架，並且需要支持多種不同的通信和遠程調用方式；
2、將一個龐大的應用拆分需要耗費很長的時間，需要進行業務的整理和系統依賴關系的控制等；
3、如何運維（依賴管理、運行狀況管理、錯誤追蹤、調優、監控和報警等）好這個龐大的分布式應用。
經過這一步，差不多系統的架構進入相對穩定的階段，同時也能開始採用大量的廉價機器來支撐著巨大的訪問量和數據量，結合這套架構以及這么多次演變過程吸取的經驗來採用其他各種各樣的方法來支撐著越來越高的訪問量。
這一步涉及到了這些知識體系：
這一步涉及的知識體系非常的多，要求對通信、遠程調用、消息機制等有深入的理解和掌握，要求的都是從理論、硬體級、操作系統級以及所採用的語言的實現都有清楚的理解。
運維這塊涉及的知識體系也非常的多，多數情況下需要掌握分布式並行計算、報表、監控技術以及規則策略等等。
說起來確實不怎麼費力，整個網站架構的經典演變過程都和上面比較的類似，當然，每步採取的方案，演變的步驟有可能有不同，另外，由於網站的業務不同，會有不同的專業技術的需求，這篇blog更多的是從架構的角度來講解演變的過程，當然，其中還有很多的技術也未在此提及，像資料庫集群、數據挖掘、搜索等，但在真實的演變過程中還會藉助像提升硬體配置、網路環境、改造操作系統、CDN鏡像等來支撐更大的流量，因此在真實的發展過程中還會有很多的不同，另外一個大型網站要做到的遠遠不僅僅上面這些，還有像安全、運維、運營、服務、存儲等，要做好一個大型的網站真的很不容易