Ⅰ web程序分布式怎麼實現
這個是由中間件的集群實現的,,,tomcat,weblogic等..這些中間件能夠自動處理當前的會話信息,後端中間件自動從節點1切換到節點2,,但用戶的當前數據不會丟失..
Ⅱ 分布式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鏡像等來支撐更大的流量，因此在真實的發展過程中還會有很多的不同，另外一個大型網站要做到的遠遠不僅僅上面這些，還有像安全、運維、運營、服務、存儲等，要做好一個大型的網站真的很不容易
Ⅲ Java Web如何實現分布式 將網站分成多個功能點在多台伺服器上發布！
Apache+Tomcat整合
Tomcat可以做在多個伺服器場，至於怎麼組合看你自己了
可以把不同的模塊放在不同的Tomcat中，也可以把Apache+Tomcat中的Tomcat做成集群模式
Ⅳ 請問web項目的分布式布署，就是多台伺服器布署嗎 與伺服器集群有何區別
java後端程序放到多台伺服器，前端訪問數據時由nignx運用演算法隨機一個伺服器上的java後端
Ⅳ 什麼是 javaweb 分布式
分布式系統（distributed system）是建立在網路之上的軟體系統。正是因為軟體的特性，所以分布式系統具有高度的內聚性和透明性。因此，網路和分布式系統之間的區別更多的在於高層軟體（特別是操作系統），而不是硬體
Ⅵ 如何區分分布式web和非分布式web系統，試說明兩者的可能的應用場合
1.這個涉及到的范圍太廣，從整體設計上來說，你需要有個成熟穩定的架構，可以借鑒現有的，比如淘寶商城等，其次資料庫的設計、服務端架構的設計、編程語言的選擇、系統安全性、服務端的負載均衡等，都需要你了解，有些部分甚至需要熟練掌握。
2.web管理系統的概念也很大，尤其涉及到分布式，牽涉到的方方面面，都非常考驗項目經理和架構師的功力，如果個人開發的話，個人建議你還是找個現有的項目參考（目前個人的某些項目由於企業的原因無法公開，只能你自己找了）。
3.具體細節的問題，像數據同步，網路訪問安全機制等更需要注意，最好你能跟業內的專業人士做深入交流。
Ⅶ 為什麼將WEB服務視為一個分布式多媒體信息系統
分布式軟體系統(Distributed Software Systems)是支持分布式處理的軟體系統,是在由通信網路互聯的多處理機體系結構上執行任務的系統。它包括分布式操作系統、分布式程序設計語言及其編譯(解釋)系統、分布式文件系統和分布式資料庫系統等。
分布式操作系統負責管理分布式處理系統資源和控制分布式程序運行。它和集中式操作系統的區別在於資源管理、進程通信和系統結構等方面。
分布式程序設計語言用於編寫運行於分布式計算機系統上的分布式程序。一個分布式程序由若干個可以獨立執行的程序模塊組成,它們分布於一個分布式處理系統的多台計算機上被同時執行。它與集中式的程序設計語言相比有三個特點：分布性、通信性和穩健性。
Ⅷ 分布式web應用集群，應用部署是怎麼全部部署的
1）比方說我先在有5台伺服器，想做一個集群，是不是意味著我要把應用程序在5台伺服器上分別部署？如果這樣的話，session能使先共享嗎？
根據中間件不同部署方式也不同。tomcat下面就要分別部署了，weblogic支持分別部署，也支持統一部署（兩種方式各有優缺點，推薦分別部署）。
中間件基本上都支持session共享復制，不過實現方式可能有點區別（有的是基於容器，有的是基於memcache等等）。可參考之前的問題（關於jboss的）：
Ⅸ 如何開發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 的基本技術和優勢。
Ⅹ 如何搭建分布式web伺服器
太簡單了，所有文件共享，session共享或者改寫，然後外邊就可以簡單的套一層負載均衡了
負載均衡後端web伺服器數量就可以隨意調整了