永無止境：網(wǎng)站的伸縮性架構

1. 所謂網(wǎng)站的伸縮性是指不需要改變網(wǎng)站的軟硬件設計，僅僅通過改變部署的服務器數(shù)量就可以擴大或者縮小網(wǎng)站的服務能力。

2. 網(wǎng)站架構的伸縮性設計：

? ? 1). 不同功能進行物理分離實現(xiàn)伸縮性：通過增加服務器提高網(wǎng)站處理能力，新增服務器總是從現(xiàn)有服務器中分離出部分功能和服務

? ? ? ? ?縱向分離(分層后分離)：將業(yè)務處理流程上不同部分分離部署，實現(xiàn)系統(tǒng)伸縮性。

? ? ? ? ?橫向分離(業(yè)務分割后分離)：將不同的業(yè)務模塊分離部署，實現(xiàn)系統(tǒng)伸縮性。橫向分離的粒度可以非常小，甚至可以一個關鍵網(wǎng)頁部署一個獨立服務。

? ? 2). 單一功能通過集群規(guī)模實現(xiàn)伸縮：使用集群，即將相同服務部署在多臺服務器上構成一個集群整體對外提供服務。

? ? ? ? ? 集群伸縮性又可以分為應用服務器集群伸縮性和數(shù)據(jù)服務集群伸縮性，而數(shù)據(jù)服務器集群又可分為緩存數(shù)據(jù)服務器集群和存儲數(shù)據(jù)服務器集群。

3. 應用服務器集群的伸縮性設計：應用服務器應該設計成無狀態(tài)的，即應用服務器不存儲請求上下文信息，如果將部署有相同應用的服務器組成一個集群，每次用戶請求都可以發(fā)送到集群中任意一臺服務器上去

? ? 處理，任何一臺服務器的處理結果都是相同的。

? ? 如果HTTP請求分發(fā)裝置可以感知或者可以配置集群的服務器數(shù)量，可以及時發(fā)現(xiàn)集群中新上線或下線的服務器，并能向新上線的服務器分發(fā)請求，停止向已下線的服務器分發(fā)請求，那么就實現(xiàn)了應用服務器集群的伸縮性。

? ? 負載均衡的幾種方式：

? ? 1). HTTP重定向負載：簡單，但需要兩次請求服務器才能完成一次訪問，性能差。可能會成為網(wǎng)站訪問的瓶頸，使用不多。

? ? 2). DNS域名解析負載均衡：這是利用DNS處理域名解析請求的同時進行負載均衡處理的一種方案。

? ? ? ? ?優(yōu)點：將負載均衡的工作轉交給DNS，同時許多DNS還支持基于地理位置的域名解析，即會將域名解析成舉例用戶地理最近的一份服務器地址。

? ? ? ? ?缺點：可能也會將域名解析到已經(jīng)下線的服務器，導致用戶訪問失敗。

? ? ? ? ?事實上，大型網(wǎng)站總是部分使用DNS域名解析，利用域名解析作為第一級負載均衡手段，即域名解析得到的一組服務器并不是實際提供Web服務的物理服務器，而是將同樣提供負載均衡服務的內(nèi)部服務器，

? ? ? ? ?這組內(nèi)部負載均衡服務器再次負載均衡，經(jīng)請求分發(fā)到真正的Web服務器。

? ? 3). 反向代理負載均衡：大多數(shù)反向代理同時提供負載均衡的功能，管理一組Web服務器，將請求根據(jù)負載均衡算法轉發(fā)到不同的Web服務器上。

? ? ? ? ?優(yōu)點：負載均衡和反向代理服務器功能集成在一起，部署簡單。

? ? ? ? ?缺點：反向代理是所有請求和響應的中轉站，其性能可能會成為瓶頸。

? ? 4). IP負載均衡：在網(wǎng)絡層通過修改請求目標地址進行負載均衡。

? ? 5). 數(shù)據(jù)鏈路層負載均衡：數(shù)據(jù)鏈路層負載均衡方式是指在通信協(xié)議的數(shù)據(jù)鏈路層修改mac地址進行負載均衡，又稱為三角傳輸模式，直接路由方式。

? ? ? ? ?使用三角傳輸模式的鏈路層負載均衡是目前大型網(wǎng)站使用最廣泛的一種負載手段。在Linux平臺最好的鏈路層負載均衡開源產(chǎn)品時LVS(Linux Virtual Server).

4. 一般對負載均衡的使用是隨著網(wǎng)站規(guī)模的提升根據(jù)不同的階段來使用不同的技術。具體的應用需求還得具體分析，如果是中小型的Web應用，比如日PV小于1000萬，用Nginx就完全可以了；如果機器不少，可以用DNS輪詢，

? ? LVS所耗費的機器還是比較多的；大型網(wǎng)站或重要的服務，且服務器比較多時，可以考慮用LVS。

? ? 參考：http://www.ha97.com/5646.html

5. 負載均衡算法：

? ? 負載均衡服務器的實現(xiàn)可以分成兩個部分：

? ? a. 根據(jù)負載均衡算法和Web服務器列表計算得到集群中的一臺Web服務器地址

? ? b. 將請求數(shù)據(jù)發(fā)送到該地址對應的Web服務器上

? ? 具體的輪詢算法有一下幾種：

? ? a. 輪詢

? ? b. 加權輪詢：根據(jù)應用服務器硬件性能的情況，在輪詢的基礎上，按照配置的權重將請求分發(fā)到每個服務器，高性能的服務器能分配更多的請求。

? ? c. 隨機：請求被隨機分配到各個應用服務器，在許多場合下，這種方案都很簡單實用，因為好的隨機數(shù)本身就很均衡。即使應用服務器硬件配置不同，也可以使用加權隨機算法。

? ? d. 最少連接：記錄每個應用服務器長在處理的連接數(shù)(請求數(shù))，將新到的請求分發(fā)到最少連接的服務器上，應該說，這是最符合負載均衡定義的算法。同樣，最少連接算法也可以實現(xiàn)加權最少連接。

? ? e. 源地址散列：根據(jù)請求來源的IP地址進行Hash計算，得到應用服務器，這樣來自同一個IP地址的請求總是在同一個服務器地址上，該請求的上下文信息可以存儲在這臺服務器上，在一個會話周期內(nèi)重復使用，從而實現(xiàn)會話粘滯。

6. 分布式緩存集群的伸縮性設計

7. 數(shù)據(jù)存儲服務器集群的伸縮性設計 ?

? ? 1). 關系型數(shù)據(jù)庫集群的伸縮性設計：

? ? ? ? ?a. 主從讀寫分離

? ? ? ? ?b. 數(shù)據(jù)分庫，這種方式的制約條件時跨庫表不能進行Join操作

? ? ? ? ?在大型網(wǎng)站的實際應用中，即使進行了分庫和主從復制，對一些單表數(shù)據(jù)仍然很大的表，還需要進行分片，將一張表拆開分別存儲在多個數(shù)據(jù)庫中。目前網(wǎng)站在線業(yè)務應用中比較成熟的支持數(shù)據(jù)分片的

? ? ? ? ?分布式關系數(shù)據(jù)庫產(chǎn)品主要有開源的的Amoeba和Cobar。這兩個產(chǎn)品有相似的架構：

? ? ? ? ?Cobar是一個分布式關系數(shù)據(jù)庫訪問代理，介于應用服務器和數(shù)據(jù)庫服務器之間。應用程序通過JDBC驅動訪問Cobar集群，Cobar服務器根據(jù)SQL和分庫規(guī)則分解SQL，分發(fā)到MYSQL集群不同的數(shù)據(jù)庫實例上執(zhí)行(每

? ? ? ? ?個MySQL實例都部署為主從結構，保證數(shù)據(jù)高可用)，執(zhí)行完將結果返回至SQL執(zhí)行模塊，通過結果合并模塊將兩個返回值合并成一個結果集，最終返回給應用程序，完成分布式數(shù)據(jù)庫的一次訪問。

? ? ? ? ?select * from users where userid in (12,22,23) ?可以被拆分為：select * from users where userid in (12,22) 和 ?select * from users where userid in (23) ? ? ? ? ? ? ?

? ? ? ? ?那么Cobar如何做集群的伸縮性呢？

? ? ? ? ?Cobar的伸縮有兩種：Cobar服務集群的伸縮和MySQL服務集群的伸縮。

? ? ? ? ?Cobar服務器可以看作是無狀態(tài)的應用服務器，因此其集群伸縮可以簡單實用負載均衡的手段實現(xiàn)。而MySQL中存儲著數(shù)據(jù)，要想保證集群擴容后數(shù)據(jù)一致負載均衡，必須做數(shù)據(jù)遷移，將集群中原來機器中的

? ? ? ? ?數(shù)據(jù)遷移到新添加的機器中。實踐中，Cobar利用了MySQL的數(shù)據(jù)同步功能進行數(shù)據(jù)遷移，數(shù)據(jù)同步不是以數(shù)據(jù)為單位，而是以Schema為單位。

? ? 2). NoSQL數(shù)據(jù)庫的伸縮性設計：NoSQL，主要指非關系的、分布式的數(shù)據(jù)庫設計模式。也有許多專家將NoSQL解讀為Not Only SQL ,表示NoSQL這是關系數(shù)據(jù)庫的補充，而不是替代方案。一般而言，NoSQL數(shù)據(jù)庫

? ? ? ? ? 都放棄了關系數(shù)據(jù)庫的兩大重要基礎：以關系代數(shù)為基礎的結構化查詢語言(SQL)和事務一致性保證(ACID)。而強化其他一些大型網(wǎng)站更關注的特性：高可用性和可伸縮性。

?

?

隨需應變：網(wǎng)站的可擴展性架構

擴展性(Extensibility)：指對現(xiàn)有系統(tǒng)影響最小的情況下，系統(tǒng)功能可持續(xù)擴展或提升的能力

伸縮性(Scalability)：指系統(tǒng)通過增加(減少)自身資源規(guī)模的方式強化(減少)自己計算處理事務的能力。

1. 構架可擴展的網(wǎng)站架構：開發(fā)低耦合系統(tǒng)是軟件設計的終極目標之一。

? ? 軟件架構師最大的價值不在于掌握多少先進的技術，而在于將具有將一個大系統(tǒng)分成N個耦合的子模塊的能力，這些子模塊包含橫向的業(yè)務模塊，也包括縱向的基礎技術模塊。

? ? 設計網(wǎng)站可擴展架構的核心思想是模塊化，并在此基礎上，降低模塊間的耦合性，提高模塊的復用性。分層和分割也是模塊化設計的重要手段，利用分層和分割的方式將軟件分割為若干個低耦合的獨立的組件

? ? 模塊，這些組件模塊以消息傳遞及依賴調(diào)用的方式聚合成一個完整系統(tǒng)。

? ? 模塊分布式部署以后具體聚合方式主要有分布式消息隊列和分布式服務。

2. 利用分布式消息隊列降低系統(tǒng)耦合性

? ? 1). 事件驅動架構：通過在低耦合的模塊之間傳輸事件消息，以保持模塊的松散耦合，并借助事件消息的通信完成模塊間的合作。消息發(fā)布-訂閱的模式。

? ? 2). 分布式消息隊列：隊列是一種先進先出的數(shù)據(jù)結構，分布式消息隊列可以看作將這種數(shù)據(jù)結構部署到獨立的服務器上，應用程序可以通過遠程訪問接口使用分布式消息隊列，進行消息存儲操作，進而實現(xiàn)分布式異步調(diào)用。

? ? ? ? ?開源的分布式消息隊列有很多，比較有名的是ActiveMQ等。伸縮性(分布式)，可用性(如果隊列已滿，會將消息寫入磁盤，消息推送模塊在將內(nèi)存隊列消息處理完成以后，將磁盤內(nèi)容添加到內(nèi)存隊列繼續(xù)處理)

? ? ? ? ?為了避免消息隊列宕機造成消息丟失，會將消息成功發(fā)送到消息隊列的消息存儲在消息生產(chǎn)者服務器，等消息真正被消息消費者服務器處理后才刪除消息。在消息隊列服務器宕機后，生產(chǎn)者服務器會選擇分布式消息隊列

? ? ? ? ?服務器集群中的其他的服務器發(fā)布消息。

3. 利用分布式服務打造可復用的業(yè)務平臺：如果說分布式消息隊列通過消息對象分解系統(tǒng)耦合性，不同子系統(tǒng)處理同一個消息；那么分布式服務則通過接口分解系統(tǒng)耦合性，不同子系統(tǒng)通過相同的接口描述進行服務調(diào)用。

? ? 1). Web Service與企業(yè)級分布式服務：服務提供者通過WSDL向注冊中心描述自身提供的服務接口屬性，注冊中心使用UDDI發(fā)布服務提供者提供的服務，服務請求者從注冊中心檢索到服務信息后，通過SOAP和服務

? ? ? ? ?通信使用相關業(yè)務。

? ? ? ? ?缺點：臃腫的注冊和發(fā)現(xiàn)機制，低效的XML序列化手段，開銷相對較高的HTTP遠程通信，復雜的部署與維護手段

? ? 2). 大型網(wǎng)站分布式服務的需求與特定：

? ? ? ? ?對于大型網(wǎng)站，除了Web Service所提供的服務器注冊與發(fā)現(xiàn)，服務調(diào)用等標準功能，還需分布式服務框架能夠支持如下功能：

? ? ? ? ?a. 負載均衡

? ? ? ? ?b. 失效轉移

? ? ? ? ?c. 高效的遠程通信

? ? ? ? ?d. 整合異構系統(tǒng)：不同語言的系統(tǒng)

? ? ? ? ?e. 對應用侵入最少

? ? ? ? ?f. 版本控制：分布式框架需要支持服務多版本發(fā)布，服務提供者先升級接口發(fā)布新版本的服務，并同時提供舊版本的服務供請求者調(diào)用，當請求者調(diào)用接口升級后才可以關閉舊版本服務。

? ? ? ? ?g. 實時監(jiān)控

? ? 3). 分布式服務框架設計：

? ? ? ? ?以阿里巴巴分布式開源框架Dubbo為例，分析其架構設計：

? ? ? ? ?服務消費者程序通過服務接口使用服務，而服務接口通過代理加載具體服務，具體服務可以是本地的代碼模塊，也可以是遠程服務，因此對應用較少侵入：應用程序只需要調(diào)用服務接口，服務框架根據(jù)

? ? ? ? ?配置自動調(diào)用本地或遠程實現(xiàn)。

? ? ? ? ?服務架構客戶端模塊通過服務注冊中心加載服務提供者列表(服務提供者啟動后自動向服務注冊中心注冊自己可提供的服務接口列表)，查找需要的服務接口，并根據(jù)配置的負載均衡策略將服務請求發(fā)送

? ? ? ? ?到某臺服務提供者服務器。如果服務調(diào)用失敗，客戶端模塊會自動從服務提供者列表選擇一個可提供同樣服務的另一臺服務器重新請求服務，實現(xiàn)服務的自動失效轉移，保證服務高可用性。

? ? ? ? ?Dubbo的遠程服務通信模塊支持多種通信協(xié)議和數(shù)據(jù)序列化協(xié)議，使用NIO通信框架，具有較高的網(wǎng)絡通信性能。

4. 可擴展的數(shù)據(jù)結構：mongoDB ？

5. 利用開放平臺建設網(wǎng)站生態(tài)圈：

? ? 大型網(wǎng)站為了更好地服務自己的用戶，開發(fā)更多的增值業(yè)務，會把網(wǎng)站內(nèi)部的服務封裝成一些調(diào)用接口開放出去，供外部的第三方開發(fā)者使用，這個提供開放接口的平臺被稱為開放平臺。第三方開發(fā)者利用

? ? 這個開放的接口開發(fā)應用程序或網(wǎng)站，為更多的用戶提供價值。網(wǎng)站、用戶、第三方開發(fā)者互相依賴，形成一個網(wǎng)站的生態(tài)圈。

? ? 開放平臺的架構設計：API接口，協(xié)議轉換，安全，審計，路由，流程

?

?

固若金湯：網(wǎng)站的安全架構

1. 道高一尺魔高一丈的網(wǎng)站應用攻擊與防御

? ? 1). XSS攻擊：XSS攻擊即跨站點腳本攻擊(Cross Site Script)，指黑客通過篡改網(wǎng)頁，注入惡意HTML腳本，在用戶瀏覽網(wǎng)頁時，控制用戶瀏覽器惡意操作的一種攻擊方式。

? ? ? ? ?常見的XSS攻擊類型有兩種：

? ? ? ? ?a. 反射型：攻擊者誘使用戶點擊一個嵌入惡意腳本的鏈接，達到攻擊的目的。

? ? ? ? ?b. 持久性XSS攻擊：黑客提交含有惡意腳本的請求，保存在被攻擊的Web站點的數(shù)據(jù)庫中，用戶瀏覽網(wǎng)頁時，惡意腳本被包含在正常頁面，達到攻擊的目的。此攻擊經(jīng)常使用在論壇，博客等Web應用中。

? ? ? ? ?防止XSS攻擊的手段主要有如下兩種：

? ? ? ? ?a. 消毒：XSS攻擊者一般都是通過在請求中嵌入惡意腳本達到攻擊的目的，這些腳本是一般用戶不使用的，如果進行過濾和消毒處理，即對某些html危險字符轉義，如">"轉義為"&gt"等，就可以防止大部分攻擊。

? ? ? ? ? ? ? ? ? ? ?為了避免對不必要的內(nèi)容錯誤轉義，如"3<5"中的"<"需要進行文本匹配后的轉義，如"<img src"這樣的上下問中的"<"才轉義。事實上消毒幾乎是所有網(wǎng)站必備的XSS防攻擊手段。

? ? ? ? ?b. HttpOnly：即瀏覽器禁止頁面JS訪問帶有HttpOnly屬性的Cookie。HttpOnly并不是直接對抗XSS攻擊的，而是通過防止XSS攻擊者竊取Cookie。對于敏感信息的Cookie，如用戶認證信息等。可以通過對該

? ? ? ? ? ? ?Cookie添加HttpOnly屬性，避免被攻擊腳本竊取。

? ? 2). 注入攻擊：

? ? ? ? ?SQL注入需要攻擊者對表結構有所了解，獲取表結構的方法有一下集中：開源(開源網(wǎng)站搭建，別人也可能知道代碼)，錯誤回顯(根據(jù)錯誤信息，猜到代碼結構)，盲注(根據(jù)頁面變化，猜測SQL結構，難度較大)

? ? ? ? ?防SQK注入攻擊：消毒(通過正則表達式匹配，過濾請求數(shù)據(jù)中可能注入的SQL)，參數(shù)綁定(使用預編譯手段，綁定參數(shù)是最好的防SQL注入方法)

? ? 3). CSRF攻擊：

? ? ? ? ?CSRF(Cross Site Request Forgery，跨站點請求偽造)，攻擊者通過跨站點請求，以合法用戶身份進行非法操作，如轉賬交易、發(fā)表評論等。CSRF的主要手法是利用跨站點其請求，在用戶不知情的情況下，

? ? ? ? ?以用戶身份偽造請求。其核心是利用了瀏覽器的Cookie或服務器Session策略，盜取用戶身份。

? ? ? ? ?相應的，CSRF的防御手段主要是識別請求者身份。主要有一下幾種方法：

? ? ? ? ?表單Token，驗證碼(用戶體驗較差)，Referer check(HTTP請求頭的Referer域記錄著請求來源，可通過檢查請求來源驗證其是否合法。如防圖片盜用)

? ? 4). 其他攻擊和漏洞

? ? ? ? ?a. Error Code：錯誤回顯。防御手段也很簡單：通過配置Web服務器參數(shù)，跳轉500頁面(HTTP響應碼500表示服務器內(nèi)部錯誤)到專門錯誤頁面即可，Web引用常用的MVC框架也有這功能。

? ? ? ? ?b. HMTL注釋

? ? ? ? ?c. 文件上傳：控制文件上傳類型

? ? ? ? ?d. 路徑遍歷：攻擊者在請求的URL中使用相對路徑，遍歷系統(tǒng)未開放地目錄和文件。防御方法主要是將JS、CSS等資源文件部署在獨立服務器、使用獨立域名，其他文件不使用靜態(tài)URL訪問，動態(tài)參數(shù)不包含文件路徑信息。

? ? 5). Web應用防火墻：

? ? ? ? ?ModSecurity是一個開源的Web應用防火墻，探測攻擊并保護Web應用程序，既可以嵌入到Web應用服務器中，也可以作為一個獨立的應用程序啟動。ModSecurity最早只是Apache的一個模塊，現(xiàn)在應有Java等多個版本，

? ? ? ? ?并且支持Nginx。

? ? 6). 網(wǎng)站安全漏洞掃描

2. 信息加密技術及密匙安全管理

? ? 1). 單向散列加密：將加密后的內(nèi)容保存到數(shù)據(jù)庫。用戶使用時，拿用戶的輸入信息加密后比較是否相同。常用算法:MD5,SHA等。

? ? 2). 對稱加密：指加密和解密使用的密匙是同一個密匙。 ? 優(yōu)點：算法簡單，加密效率高，系統(tǒng)開銷小，適合對大量數(shù)據(jù)加密。 ? ? 缺點：遠程通信的情況下如何安全交換密匙是一個難題，如果密匙丟失，會導致信息泄露。

? ? ? ? ? ? ? ? ? ? ? ? 常用算法：DES算法，RC算法等。

? ? 3). 非對稱加密：對外界公開的，被稱為公鑰，另一個只有所有者知道，被稱為私匙。用公鑰加密的信息必須用私匙才能解開，用私匙加密的信息只有公鑰才能解開。

? ? 4). 密匙的安全管理：

? ? ? ? ?a. 把密匙和算法放在一個獨立的服務器上，甚至做成一個專用的硬件設施，對外提供加密和解密服務，應用系統(tǒng)調(diào)用這個服務，實現(xiàn)數(shù)據(jù)的加密。

? ? ? ? ?b. 將加密算法放到應用系統(tǒng)中，密匙放到獨立服務器中，為了提高密匙的安全性，實際存儲事，密匙被切分成數(shù)片，加密后分別保存在不同的存儲介質(zhì)中，兼顧安全性的同時又改善了性能。

3. 信息過濾與反垃圾：

? ? 1). 文本匹配：Trie算法，構造多級hash表進行文本匹配。

? ? 2). 分類算法：

? ? 3). 黑名單

4. 電子商務風險控制：

? ? 1). 風險：

? ? ? ? ?a. 賬戶風險：包括賬戶被盜用，惡意注冊賬戶等

? ? ? ? ?b. 買家風險：惡意下單，黃牛利用促銷搶購，良品拒收等

? ? ? ? ?c. 賣家風險：欺詐行為，虛假發(fā)貨等

? ? ? ? ?d. 交易風險：信用卡盜刷，支付欺詐，洗錢套現(xiàn)等

? ? 2). 風控：

? ? ? ? ?a. 規(guī)則引擎：當交易的某些指標滿足一定條件時，就會被認為具有高風險的欺詐可能性。

? ? ? ? ?b. 統(tǒng)計模型：智能統(tǒng)計，得到交易風險分值。? ? ??

?

轉載于:https://www.cnblogs.com/Jtianlin/p/5136340.html

總結

以上是生活随笔為你收集整理的大型网站技术架构03的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。