Ⅰ 如何讀懂Web服務的系統架構圖
大數據數量龐大，格式多樣化。大量數據由家庭、製造工廠和辦公場所的各種設備、互聯網事務交易、社交網路的活動、自動化感測器、移動設備以及科研儀器等生成。它的爆炸式增長已超出了傳統IT基礎架構的處理能力，給企業和社會帶來嚴峻的數據管理問題。因此必須開發新的數據架構，圍繞「數據收集、數據管理、數據分析、知識形成、智慧行動」的全過程，開發使用這些數據，釋放出更多數據的隱藏價值。
一、大數據建設思路
1）數據的獲得
四、總結
基於分布式技術構建的大數據平台能夠有效降低數據存儲成本，提升數據分析處理效率，並具備海量數據、高並發場景的支撐能力，可大幅縮短數據查詢響應時間，滿足企業各上層應用的數據需求。
Ⅱ 基於Web的計算是什麼意思
這是一種基於網路應用的架構類型.
以前應用較多的是C/S模式,即客戶機/伺服器模式,這是一種胖客戶端形式,伺服器端存儲數據,客戶端發送請求,完成大部分的運算.
現在應用較多的是B/S模式,即瀏覽器/伺服器模式,這是一種瘦客戶端模式.客戶端發送請求,運算處理在伺服器進行,然後將結果返回給客戶端.這就是基於WEB計算的主要方式.
Ⅲ 分布式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鏡像等來支撐更大的流量，因此在真實的發展過程中還會有很多的不同，另外一個大型網站要做到的遠遠不僅僅上面這些，還有像安全、運維、運營、服務、存儲等，要做好一個大型的網站真的很不容易
Ⅳ 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技術架構的重要組成包括哪些
不知道你問的是不是這樣的：提供一種統一的、面向組件的編程模型。
Web Service的體系結構描述了三個角色（服務提供者、服務請求者、服務代理者）以及三個操作（發布、查找、綁定）。
Web主要技術特徵：在傳輸層和網路層採用TCP/IP協議，預設斷口的80；在應用層採用HTTP協議，使用HTML文檔實現信息交互；基本上運行在C/S模式下。
Ⅵ Web應用框架的架構
基於請求的框架較早出現，它用以描述一個web應用程序結構的概念和傳統的靜態Internet站點一樣，是將其機制擴展到動態內容的延伸。對一個提供HTML和圖片等靜態內容的網站，網路另一端的瀏覽器發出以URI形式指定的資源的請求，Web伺服器解讀請求，檢查該資源是否存在於本地，如果是則返回該靜態內容，否則通知瀏覽器沒有找到。Web應用升級到動態內容領域後，這個模型只需要做一點修改。那就是web伺服器收到一個URL請求（相較於靜態情況下的資源，動態情況下更接近於對一種服務的請求和調用）後，判斷該請求的類型，如果是靜態資源，則照上面所述處理；如果是動態內容，則通過某種機制（CGI、調用常駐內存的模塊、遞送給另一個進程如Java容器）運行該動態內容對應的程序，最後由程序給出響應，返回瀏覽器。在這樣一個直接與web底層機制交流的模型中，伺服器端程序要收集客戶端籍get或post方式提交的數據，轉換，校驗，然後以這些數據作為輸入運行業務邏輯後生成動態的內容（包括HTML、JavaScript、CSS、圖片等）。
基於組件的框架採取了另一種思路，它把長久以來軟體開發應用的組件思想引入到web開發。伺服器返回的原本文檔形式的網頁被視為由一個個可獨立工作、重復使用的組件構成。每個組件都能接受用戶的輸入，負責自己的顯示。上面提到的伺服器端程序所做的數據收集、轉換、校驗的工作都被下放給各個組件。現代web框架基本上都採用了模型、視圖、控制器相分離的MVC架構，基於請求和基於組件兩種類型大都會有一個控制器將用戶的請求分派給負責業務邏輯的模型，運算的結果再以某個視圖表現出來，所以兩大分類框架的區別主要在視圖部分，基於請求的框架仍然把視圖也就是網頁看作是一個文檔整體，程序員要用HTML、Javascript和CSS這些底層的代碼來寫「文檔」，而基於組件的框架則把視圖看作由積木一樣的構件拼成，積木的顯示不用程序員操心（當然它們也是由另一些程序員開發出來的），只要設置好它綁定的數據和調整它的屬性，把他們大大從編寫HTML、Javascript和CSS這些界面的工作中解放出來。 基於請求的和基於組件的兩種框架各有優劣。雖然一眼看上去後者有很大的吸引力，普通的web開發人員只要使用專門的公司或開源組織提供的組件就可以輕松開發出好用漂亮的界面，但是有幾種因素綜合起來不利於這種理想中的方案。要編寫一個沒有潛在問題的、跨瀏覽器的、顯示美觀並且有足夠靈活性可以調整的伺服器端組件是需要高水平的技能、豐富的經驗和較多時間的，即使付出這些成本，也不能完全避免使用者失望的情況。
綜合來看，基於請求的框架要程序員自己動手的地方比較多，但也因此可以更精細地控制HTML、CSS和Javascript這些最終決定應用程序界面的代碼，特別是如果要在界面上有創新，嘗試新的視覺效果和用戶操作，必然選擇基於請求的框架。基於組件的框架可以提高開發界面的效率，前提是選用的組件質量優秀。
Ⅶ web前端和後端是不是指B/S架構
可以這么說。bs架構就是：B=瀏覽器，S伺服器。
關於前端和後端的解釋（針對於工作崗位）
前端 在大部分企業就是做瀏覽器端展現相關的工作，會用到html,css,js,ps,ai等等，總之就是和界面相關的東西。
而「後端」的主要工作室程序開發、數據處理了，比如：php，asp，mysql，mssql。主要實現功能上的東西，如用戶登錄驗證、圖片上傳處理，等等。
Ⅷ 簡述WEB系統的架構原理
這個話題太大了。
一般來說，WEB系統，主要是指後端，前端就是各種瀏覽器了。
那麼簡單來講，只要是能與瀏覽器通過網路交互的系統，都可以算是WEB系統。最簡潔的就是用NODEJS寫一個echo,就是客戶端發什麼內容，就回什麼內容。
而在實際應用中，WEB系統的架構，一般有這么幾個部分：負載均衡、授權驗證（可選）、靜態內容服務、動態內容服務（業務邏輯）、資料庫、運維後台。
1）負載均衡是為了改善用戶體驗、充分利用伺服器資源，主要功能是將新的請求轉發到不那麼忙的伺服器進行處理。
2）授權驗證，是在對瀏覽器發起的請求進行授權校驗，如果不是合法的請求，就予以拒絕或者重定向至登錄頁面。
3）靜態內容服務，是指圖片、CSS等不會根據不同用戶而變化的靜態內容，將其直接返回給用戶。因為不需要進行邏輯判斷，性能主要取決於I/O讀寫，響應可以非常快。超大型網站，也會把一部分動態內容，例如對訪問量大的新聞頁，做靜態處理，以提升響應速度。靜態內容服務的典型是CDN。
4）動態內容服務，是根據用戶請求的不同，而進行響應的業務邏輯處理。比如對用戶數據的CRUD(增刪查改）。這是絕大多數WEB系統的核心所在，一般會調用資料庫和數據緩存。具體實現會根據業務需要而變化，也可以變得非常復雜。
5）資料庫，是數據所在，既有經典的關系型傳統資料庫系統，也有為了提升訪問性能、減輕的內存資料庫。
6）運維後台，是為了方便監控運行狀態、升級維護系統，不直接參與對外服務。
先寫這么多吧。有具體的問題了，可以再問。