大型網站技術架構03

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

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. 統計模型：智能統計，獲得交易風險分值。