涩涩爱在线观看-涩涩www在线观看免费高清-涩色综合-涩色影院-国产成人精品视频免费-国产成人精品视频播放

為了解決大型網站面臨的高并發訪問、海量數據處理、高可靠運行等一系列問題與挑戰，大型互聯網公司在實踐中提出了許多解決方案，以實現網站高性能、高可用、易伸縮、可擴展、安全等各種技術架構目標。這些解決方案又被更多網站重復使用，從而逐漸形成大型網站架構模式。

分層

分層是企業應用系統中常見的一種架構模式，將系統在橫向維度上切分成幾個部分，每個部分負責一部分相對比較單一的職責，然后通過上層對下層的依賴和調用組成一個完整的系統。分層結構在計算機世界中無處不在，網絡的7層通信協議是一種分層結構；計算機硬件、操作系統、應用軟件也可以看作是一種分層結構。在大型網站架構中也采用分層結構，將網站軟件系統分為應用層、服務層、數據層。

                                                  網站分層架構

應用層：負責具體業務和視圖展示，如網站首頁及搜索輸入和結果展示

服務層：為應用層提供服務支持，如用戶管理服務，購物車服務等

數據層：提供數據存儲訪問服務，如數據庫、緩存、文件、搜索引擎等

通過分層，可以更好地將一個龐大的軟件系統切分成不同的部分，便于分工合作開發和維護；各層之間具有一定的獨立性，只要維持調用接口不變，各層可以根據具體問題獨立演化發展而不需要其他層必須做出相應調整。

但是分層架構也有一些挑戰，就是必須合理規劃層次邊界和接口，在開發過程中，嚴格遵循分層架構的約束，禁止跨層次的調用（應用層直接調用數據層）及逆向調用（數據層調用服務層，或者服務層調用應用層）。

在實踐中，大的分層結構內部還可以繼續分層，如應用層可以再細分為視圖層（美工負責）和業務邏輯層（工程師負責）；服務層也可以細分為數據接口層（適配各種輸入和輸出的數據格式）和邏輯處理層。分層架構是邏輯上的，在物理部署上，三層結構可以部署在同一個物理機器上，但是隨著網站業務的發展，必然需要對已經分層的模塊分離部署，即三層結構分別部署在不同的服務器上，使網站擁有更多的計算資源以應對越來越多的用戶訪問。所以雖然分層架構模式初的目的是規劃軟件清晰的邏輯結構便于開發維護，但在網站的發展過程中，分層結構對網站支持高并發向分布式方向發展至關重要。因此在網站規模還很小的時候就應該采用分層的架構，這樣將來網站做大時才能有更好地應對。

分割

如果說分層是將軟件在橫向方面進行切分，那么分割就是在縱向方面對軟件進行切分。

網站越大，功能越復雜，服務和數據處理的種類也越多，將這些不同的功能和服務分割開來，包裝成高內聚低耦合的模塊單元，一方面有助于軟件的開發和維護；另一方面，便于不同模塊的分布式部署，提高網站的并發處理能力和功能擴展能力。大型網站分割的粒度可能會很小。比如在應用層，將不同業務進行分割，例如將購物、論壇、搜索、廣告分割成不同的應用，由獨立的團隊負責，部署在不同的服務器上；在同一個應用內部，如果規模龐大業務復雜，會繼續進行分割，比如購物業務，可以進一步分割成機票酒店業務、3C業務，小商品業務等更細小的粒度。而即使在這個粒度上，還是可以繼續分割成首頁、搜索列表、商品詳情等模塊，這些模塊不管在邏輯上還是物理部署上，都可以是獨立的。同樣在服務層也可以根據需要將服務分割成合適的模塊。

分布式

對于大型網站，分層和分割的一個主要目的是為了切分后的模塊便于分布式部署，即將不同模塊部署在不同的服務器上，通過遠程調用協同工作。分布式意味著可以使用更多的計算機完成同樣的功能，計算機越多，CPU、內存、存儲資源也就越多，能夠處理的并發訪問和數據量就越大，進而能夠為更多的用戶提供服務。

但分布式在解決網站高并發問題的同時也帶來了其他問題。首先，分布式意味著服務調用必須通過網絡，這可能會對性能造成比較嚴重的影響；其次，服務器越多，服務器宕機的概率也就越大，一臺服務器宕機造成的服務不可用可能會導致很多應用不可訪問，使網站可用性降低；另外，數據在分布式的環境中保持數據一致性也非常困難，分布式事務也難以保證，這對網站業務正確性和業務流程有可能造成很大影響；分布式還導致網站依賴錯綜復雜，開發管理維護困難。因此分布式設計要根據具體情況量力而行，切莫為了分布式而分布式。在網站應用中，常用的分布式方案有以下幾種。

分布式應用和服務：將分層和分割后的應用和服務模塊分布式部署，除了可以改善網站性能和并發性、加快開發和發布速度、減少數據庫連接資源消耗外；還可以使不同應用復用共同的服務，便于業務功能擴展。

分布式靜態資源：網站的靜態資源如JS，CSS，Logo圖片等資源獨立分布式部署，并采用獨立的域名，即人們常說的動靜分離。靜態資源分布式部署可以減輕應用服務器的負載壓力；通過使用獨立域名加快瀏覽器并發加載的速度；由負責用戶體驗的團隊進行開發維護有利于網站分工合作，使不同技術工種術業有專攻。

分布式數據和存儲：大型網站需要處理以P為單位的海量數據，單臺計算機無法提供如此大的存儲空間，這些數據需要分布式存儲。除了對傳統的關系數據庫進行分布式部署外，為網站應用而生的各種NoSQL產品幾乎都是分布式的。

分布式計算：嚴格說來，應用、服務、實時數據處理都是計算，網站除了要處理這些在線業務，還有很大一部分用戶沒有直觀感受的后臺業務要處理，包括搜索引擎的索引構建、數據倉庫的數據分析統計等。這些業務的計算規模非常龐大，目前網站普遍使用Hadoop及其MapReduce分布式計算框架進行此類批處理計算，其特點是移動計算而不是移動數據，將計算程序分發到數據所在的位置以加速計算和分布式計算。

此外，還有可以支持網站線上服務器配置實時更新的分布式配置；分布式環境下實現并發和協同的分布式鎖；支持云存儲的分布式文件系統等。

集群

使用分布式雖然已經將分層和分割后的模塊獨立部署，但是對于用戶訪問集中的模塊（比如網站的首頁），還需要將獨立部署的服務器集群化，即多臺服務器部署相同應用構成一個集群，通過負載均衡設備共同對外提供服務。

因為服務器集群有更多服務器提供相同服務，因此可以提供更好的并發特性，當有更多用戶訪問的時候，只需要向集群中加入新的機器即可。同時因為一個應用由多臺服務器提供，當某臺服務器發生故障時，負載均衡設備或者系統的失效轉移機制會將請求轉發到集群中其他服務器上，使服務器故障不影響用戶使用。所以在網站應用中，即使是訪問量很小的分布式應用和服務，也至少要部署兩臺服務器構成一個小的集群，目的就是提高系統的可用性。

緩存

緩存就是將數據存放在距離計算近的位置以加快處理速度。緩存是改善軟件性能的第一手段，現代CPU越來越快的一個重要因素就是使用了更多的緩存，在復雜的軟件設計中，緩存幾乎無處不在。大型網站架構設計在很多方面都使用了緩存設計。

CDN：即內容分發網絡，部署在距離終端用戶近的網絡服務商，用戶的網絡請求總是先到達他的網絡服務商那里，在這里緩存網站的一些靜態資源（較少變化的數據），可以就近以快速度返回給用戶，如視頻網站和門戶網站會將用戶訪問量大的熱點內容緩存在CDN。

反向代理：反向代理屬于網站前端架構的一部分，部署在網站的前端，當用戶請求到達網站的數據中心時，先訪問到的就是反向代理服務器，這里緩存網站的靜態資源，無需將請求繼續轉發給應用服務器就能返回給用戶。

本地緩存：在應用服務器本地緩存著熱點數據，應用程序可以在本機內存中直接訪問數據，而無需訪問數據庫。分布式緩存：大型網站的數據量非常龐大，即使只緩存一小部分，需要的內存空間也不是單機能承受的，所以除了本地緩存，還需要分布式緩存，將數據緩存在一個專門的分布式緩存集群中，應用程序通過網絡通信訪問緩存數據。使用緩存有兩個前提條件，一是數據訪問熱點不均衡，某些數據會被更頻繁的訪問，這些數據應該放在緩存中；二是數據在某個時間段內有效，不會很快過期，否則緩存的數據就會因已經失效而產生臟讀，影響結果的正確性。網站應用中，緩存除了可以加快數據訪問速度，還可以減輕后端應用和數據存儲的負載壓力，這一點對網站數據庫架構至關重要，網站數據庫幾乎都是按照有緩存的前提進行負載能力設計的。2.1.6 異步計算機軟件發展的一個重要目標和驅動力是降低軟件耦合性。事物之間直接關系越少，就越少被彼此影響，越可以獨立發展。大型網站架構中，系統解耦合的手段除了前面提到的分層、分割、分布等，還有一個重要手段是異步，業務之間的消息傳遞不是同步調用，而是將一個業務操作分成多個階段，每個階段之間通過共享數據的方式異步執行進行協作。在單一服務器內部可通過多線程共享內存隊列的方式實現異步，處在業務操作前面的線程將輸出寫入到隊列，后面的線程從隊列中讀取數據進行處理；在分布式系統中，多個服務器集群通過分布式消息隊列實現異步，分布式消息隊列可以看作內存隊列的分布式部署。異步架構是典型的生產者消費者模式，兩者不存在直接調用，只要保持數據結構不變，彼此功能實現可以隨意變化而不互相影響，這對網站擴展新功能非常便利。除此之外，使用異步消息隊列還有如下特性。

提高系統可用性。消費者服務器發生故障，數據會在消息隊列服務器中存儲堆積，生產者服務器可以繼續處理業務請求，系統整體表現無故障。消費者服務器恢復正常后，繼續處理消息隊列中的數據。加快網站響應速度。處在業務處理前端的生產者服務器在處理完業務請求后，將數據寫入消息隊列，不需要等待消費者服務器處理就可以返回，響應延遲減少。消除并發訪問高峰。用戶訪問網站是隨機的，存在訪問高峰和低谷，即使網站按照一般訪問高峰進行規劃和部署，也依然會出現突發事件，比如購物網站的促銷活動，微博上的熱點事件，都會造成網站并發訪問突然增大，這可能會造成整個網站負載過重，響應延遲，嚴重時甚至會出現服務宕機的情況。使用消息隊列將突然增加的訪問請求數據放入消息隊列中，等待消費者服務器依次處理，就不會對整個網站負載造成太大壓力。

但需要注意的是，使用異步方式處理業務可能會對用戶體驗、業務流程造成影響，需要網站產品設計方面的支持。2.1.7 冗余網站需要7724小時連續運行，但是服務器隨時可能出現故障，特別是服務器規模比較大時，出現某臺服務器宕機是必然事件。要想保證在服務器宕機的情況下網站依然可以繼續服務，不丟失數據，就需要一定程度的服務器冗余運行，數據冗余備份，這樣當某臺服務器宕機時，可以將其上的服務和數據訪問轉移到其他機器上。訪問和負載很小的服務也必須部署至少兩臺服務器構成一個集群，其目的就是通過冗余實現服務高可用。數據庫除了定期備份，存檔保存，實現冷備份外，為了保證在線業務高可用，還需要對數據庫進行主從分離，實時同步實現熱備份。為了抵御地震、海嘯等不可抗力導致的網站完全癱瘓，某些大型網站會對整個數據中心進行備份，全球范圍內部署災備數據中心。網站程序和數據實時同步到多個災備數據中心。2.1.8 自動化在無人值守的情況下網站可以正常運行，一切都可以自動化是網站的理想狀態。目前大型網站的自動化架構設計主要集中在發布運維方面。發布對網站都是頭等大事，許多網站故障出在發布環節，網站工程師經常加班也是因為發布不順利。通過減少人為干預，使發布過程自動化可有效減少故障。發布過程包括諸多環節。自動化代碼管理，代碼版本控制、代碼分支創建合并等過程自動化，開發工程師只要提交自己參與開發的產品代號，系統就會自動為其創建開發分支，后期會自動進行代碼合并；自動化測試，代碼開發完成，提交測試后，系統自動將代碼部署到測試環境，啟動自動化測試用例進行測試，向相關人員發送測試報告，向系統反饋測試結果；自動化安全檢測，安全檢測工具通過對代碼進行靜態安全掃描及部署到安全測試環境進行安全攻擊測試，評估其安全性；后進行自動化部署，將工程代碼自動部署到線上生產環境。此外，網站在運行過程中可能會遇到各種問題：服務器宕機、程序Bug、存儲空間不足、突然爆發的訪問高峰。網站需要對線上生產環境進行自動化監控，對服務器進行心跳檢測，并監控其各項性能指標和應用程序的關鍵數據指標。如果發現異常、超出預設的閾值，就進行自動化報警，向相關人員發送報警信息，警告故障可能會發生。在檢測到故障發生后，系統會進行自動化失效轉移，將失效的服務器從集群中隔離出去，不再處理系統中的應用請求。待故障消除后，系統進行自動化失效恢復，重新啟動服務，同步數據保證數據的一致性。在網站遇到訪問高峰，超出網站大處理能力時，為了保證整個網站的安全可用，還會進行自動化降級，通過拒絕部分請求及關閉部分不重要的服務將系統負載降至一個安全的水平，必要時，還需要自動化分配資源，將空閑資源分配給重要的服務，擴大其部署規模。2.1.9 安全互聯網的開放特性使得其從誕生起就面對巨大的安全挑戰，網站在安全架構方面也積累了許多模式：通過密碼和手機校驗碼進行身份認證；登錄、交易等操作需要對網絡通信進行加密，網站服務器上存儲的敏感數據如用戶信息等也進行加密處理；為了防止機器人程序濫用網絡資源攻擊網站，網站使用驗證碼進行識別；對于常見的用于攻擊網站的XSS攻擊、SQL注入、進行編碼轉換等相應處理；對于垃圾信息、敏感信息進行過濾；對交易轉賬等重要操作根據交易模式和交易信息進行風險控制。