永無止境：網站的伸縮性架構

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

2. 網站架構的伸縮性設計：

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

? ? ? ? ?縱向分離(分層后分離)：將業務處理流程上不同部分分離部署，實現系統伸縮性。

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

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

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

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

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

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

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

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

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

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

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

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

? ? ? ? ?這組內部負載均衡服務器再次負載均衡，經請求分發到真正的Web服務器。

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

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

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

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

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

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

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

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

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

5. 負載均衡算法：

? ? 負載均衡服務器的實現可以分成兩個部分：

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

? ? b. 將請求數據發送到該地址對應的Web服務器上

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

? ? a. 輪詢

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

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

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

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

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

7. 數據存儲服務器集群的伸縮性設計 ?

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

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

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

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

? ? ? ? ?分布式關系數據庫產品主要有開源的的Amoeba和Cobar。這兩個產品有相似的架構：

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

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

? ? ? ? ?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服務器可以看作是無狀態的應用服務器，因此其集群伸縮可以簡單實用負載均衡的手段實現。而MySQL中存儲著數據，要想保證集群擴容后數據一致負載均衡，必須做數據遷移，將集群中原來機器中的

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

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

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

?

?

隨需應變：網站的可擴展性架構

擴展性(Extensibility)：指對現有系統影響最小的情況下，系統功能可持續擴展或提升的能力

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

1. 構架可擴展的網站架構：開發低耦合系統是軟件設計的終極目標之一。

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

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

? ? 模塊，這些組件模塊以消息傳遞及依賴調用的方式聚合成一個完整系統。

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

2. 利用分布式消息隊列降低系統耦合性

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

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

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

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

? ? ? ? ?服務器集群中的其他的服務器發布消息。

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

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

? ? ? ? ?通信使用相關業務。

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

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

? ? ? ? ?對于大型網站，除了Web Service所提供的服務器注冊與發現，服務調用等標準功能，還需分布式服務框架能夠支持如下功能：

? ? ? ? ?a. 負載均衡

? ? ? ? ?b. 失效轉移

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

? ? ? ? ?d. 整合異構系統：不同語言的系統

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

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

? ? ? ? ?g. 實時監控

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

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

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

? ? ? ? ?配置自動調用本地或遠程實現。

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

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

? ? ? ? ?Dubbo的遠程服務通信模塊支持多種通信協議和數據序列化協議，使用NIO通信框架，具有較高的網絡通信性能。

4. 可擴展的數據結構：mongoDB ？

5. 利用開放平臺建設網站生態圈：

? ? 大型網站為了更好地服務自己的用戶，開發更多的增值業務，會把網站內部的服務封裝成一些調用接口開放出去，供外部的第三方開發者使用，這個提供開放接口的平臺被稱為開放平臺。第三方開發者利用

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

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

?

?

固若金湯：網站的安全架構

1. 道高一尺魔高一丈的網站應用攻擊與防御

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

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

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

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

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

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

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

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

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

? ? 2). 注入攻擊：

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

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

? ? 3). CSRF攻擊：

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

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

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

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

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

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

? ? ? ? ?b. HMTL注釋

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

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

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

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

? ? ? ? ?并且支持Nginx。

? ? 6). 網站安全漏洞掃描

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

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

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

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

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

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

? ? ? ? ?a. 把密匙和算法放在一個獨立的服務器上，甚至做成一個專用的硬件設施，對外提供加密和解密服務，應用系統調用這個服務，實現數據的加密。

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

3. 信息過濾與反垃圾：

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

? ? 2). 分類算法：

? ? 3). 黑名單

4. 電子商務風險控制：

? ? 1). 風險：

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

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

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

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

? ? 2). 風控：

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

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

?

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。