大型網站技術架構（二）核心架構要素

一、概述

除了系統功能外，軟體架構還需關注性能、可用性、伸縮性、擴充性、安全這幾個架構要素。

1.1性能

衡量網站性能有一些列名額，總要的有：響應時間、TPS、系統性能計數器等。

網站性能優化的手段有很多，從使用者浏覽器到伺服器再到資料庫，影響到使用者請求的所有環節都可以進行性能優化。

1.浏覽器端：

①可以通過壓縮、合理布局頁面、減少cookie傳輸，減少http請求的方式減少請求的大小與數量，進而改善性能。

②采用緩存優化：浏覽器緩存、CDN加速和反向代理，加快請求響應速度。

2.應用伺服器端：

①緩存：本地緩存和分布式緩存

②異步：可采用消息隊列解耦削峰。

③叢集：多台應用伺服器組成一個叢集共同對外服務，提高整體處理能力，改善性能。

3.資料庫伺服器端：

關系型：緩存、索引、SQL優化等性能優化手段已經比較成熟。

Nosql：優化資料模型、存儲結構、伸縮特性等手段進行性能優化。

1.2可用性

網站宕掉、服務不可用對網站而言是重大事故。網站的高可用架構設計的主要目的就是保證伺服器硬體故障或者網站更新時服務依然可用、資料依然儲存并能夠通路。

1.網站高可用的主要手段是備援。

①對于應用伺服器：多台應用伺服器通過負載均衡裝置組成叢集對外提供服務。任何一台伺服器當機，隻需要将請求切換到其他伺服器即可（前提是應用伺服器不儲存會話資訊——無狀态，第三節詳細介紹）。

②對于存儲伺服器：由于其上存儲着資料，需要對資料進行實時備份，伺服器當機時，将資料通路轉移到可用的伺服器上，并進行資料恢複以保證繼續有伺服器當機時資料依然可用。

2.除了運作環境，網站的高可用還需要軟體開發過程的品質保證。通過發不驗證、自動化測試、自動化釋出、灰階釋出等手段減少故障、避免故障範圍擴大。

1.3伸縮性

所謂伸縮性是指不需要改變網站的軟硬體設計僅僅通過改變部署的伺服器數量就可以擴大或者縮小網站的服務處理能力。如：淘寶“雙十一”活動，通過不斷向叢集中加入伺服器的手段來緩解不斷上升的使用者并發通路壓力和不斷增長的資料存儲需求。活動結束後将這些伺服器下線以節約成本。

網站的伸縮性設計分為兩類：

1.根據功能進行實體分離實作伸縮。縱向分離（分層後分離）/橫向分離（業務功能分割後分離）然後部署。

2.單一功能通過叢集實作伸縮。

①應用層：

應用伺服器叢集——選擇合适的負載均衡裝置向叢集中不斷加伺服器。（前提：伺服器不儲存資料，即所有伺服器都是對等的）

②資料層：

分布式緩存叢集——加入新伺服器可能導緻緩存路由失效，故而改進緩存路由算法保證緩存資料的可通路性。

資料存儲伺服器叢集——包括關系資料庫和NoSQL資料庫伸縮性設計兩類：

》關系資料庫叢集——雖然支援資料複制、主從熱備等機制，但是很難做到大規模叢集的可伸縮性。是以其伸縮性必須在資料庫之外實作，通過路由分區等手段将部署有多個資料庫的伺服器組成一個叢集。

》Nosql伸縮性設計——對于大部分NoSQL産品，由于其先天為海量資料而生，伸縮性非常好，可以做到在較少運維參與的情況下實作叢集規模的線性伸縮

1.4擴充性

所謂擴充性是指，對現有系統影響最小的情況下，系統功能可持續擴充或提升的能力。不同于其他架構要素主要關注非功能需求，如何設計網站的架構使其能快速響應需求變化，是網站可擴充架構的主要目的。

設計網站可擴充架構的核心思想是子產品化，并在此基礎上，降低子產品間的耦合性，提高子產品的複用性。網站利用分層、分割解耦合，利用分布式部署的方式實體上分離耦合，将子產品分布式部署以後的聚合的方式主要包括消息隊列和分布式服務。故而，網站可擴充架構的主要手段是：事件驅動架構（通過在低耦合的子產品之間傳輸事件消息，保持子產品的松耦合，并借助事件消息的通信完成子產品間合作，典型的EDA就是生産者消費者模式）和分布式服務（将業務和可複用服務分離開來，通過分布式服務架構調用）。

1.利用分布式消息隊列實作子產品間通信，降低系統耦合性；

2.利用分布式服務打造可複用的業務平台

1.5安全

網站的安全架構就是保護網站不受惡意通路和攻擊，保護網站的重要資料不被竊取。

二、高性能

2.1Web前端優化

1.浏覽器通路優化

①減少http請求——具體手段包括合并CSS、合并JS、合并圖檔等。

②CSS放在頁面最上面、JS放在頁面最下面——因為浏覽器會在下載下傳全部CSS後便對整個頁面渲染，在加載完JS後立即執行。

③啟用壓縮——在服務端對檔案進行壓縮，浏覽器端解壓縮，有效減少通信傳輸的資料量（會對伺服器和浏覽器産生一定壓力）。

④減少cookie傳輸——減少cookie中傳輸的資料量；靜态資源的通路如CSS、JS等，發送cookie沒意義，考慮使用獨立域名通路。

⑤使用浏覽器緩存——通過HTTP頭中的Cache-Control和Expires屬性設定緩存，時間可以使數天甚至幾個月。更新緩存時采用逐量更新的方法，以免使用者浏覽器突然大量緩存失效。

2.CDN加速

本質仍是緩存，而且将資料緩存在離使用者最近的地方，使使用者以最快速度擷取資料。CDN一般緩存的是靜态資源，如：圖檔、檔案、CSS、Script腳本、靜态網頁等。

CDN部署在網絡營運商的機房，這些營運商又是終端使用者的網絡提供服務商，是以使用者請求第一跳到達了CDN伺服器，CDN緩存着請求的資料就直接傳回給浏覽器，以最短路徑傳回響應。

3.反向代理

》是什麼？

傳統代理伺服器位于浏覽器一側，代理浏覽器将http請求發送到網際網路上，反向代理伺服器位于網站機房一側，代理Web伺服器接受Http請求。

》怎麼樣？

①代理伺服器通過配置緩存加速Web請求，當使用者第一次通路靜态内容時，靜态内容就被緩存在反向代理伺服器上了。事實上，有些網站會把動态内容也緩存在代理伺服器上。當這些動态内容有變化時，通過内部通知機制通知反向代理緩存失效，反向代理會重新加載最新的動态内容再次緩存起來。

②除了通過緩存提升性能外，反向代理還可以實作負載均衡功能，通過負載均衡建構的應用叢集提高系統的總體處理能力。

③反向代理伺服器相當于在Web伺服器和可能的網絡攻擊之間建立了一個屏障，有一定的安全功能。

2.2應用伺服器性能優化

緩存、異步、叢集、代碼優化

2.3存儲性能優化

1.資料庫

關系型：緩存、索引、SQL優化等性能優化手段已經比較成熟。

Nosql：優化資料模型、存儲結構、伸縮特性等手段進行性能優化。

2.磁盤媒體

在網站應用中，海量資料讀寫對磁盤通路造成巨大壓力，磁盤的可用性和容錯性也至關重要

①機械硬碟和固态硬碟

》由于每次通路都要移動磁頭臂，機械硬碟有快速順序讀寫，慢速随機讀寫的通路特性。

》固态硬碟資料存儲在可持久記憶的矽晶體上，有更好的随機通路特性。

②存儲結構。B+樹和LSM樹

詳細内容： https://blog.csdn.net/u013928917/article/details/75912045 B+樹和LSM比較

③RAID和HDFS

》RAID（廉價磁盤備援陣列）主要目标是實作資料在多塊磁盤上并發讀寫和資料備份。

》RAID技術在傳統關系資料庫及檔案系統中應用比較廣泛，在大型網站比較喜歡使用的NoSQL以及分布式檔案系統中，RAID技術遭到冷落。HDFS（Hadoop分布式檔案系統）：系統在整個存儲及叢集的多态伺服器上進行資料讀寫和備份，可以看做在伺服器叢集規模上實作了類似RAID的功能，是以不需要磁盤RAID。

①HDFS以塊為機關管理檔案内容，一個檔案被分割成若幹個Block，當程式寫檔案時，每寫完一個Block，HDFS就會自動複制到另外兩台機器上，保證Block有三個副本。相當于實作了RAID1的資料複制功能。

②對檔案進行處理計算時，通過MapReduce并發計算任務架構，可以啟動多個計算子任務，同時讀取多個Block，并發處理，相當于實作了RAID0的并發通路功能。

》HDFS架構

1、Client：就是用戶端。
檔案切分。檔案上傳 HDFS 的時候，Client 将檔案切分成 一個一個的Block，然後進行存儲。
與 NameNode 互動，擷取檔案的位置資訊。
與 DataNode 互動，讀取或者寫入資料。
2、NameNode：就是 master，它是一個主管、管理者。
管理 HDFS 的名稱空間
管理資料塊（Block）映射資訊
配置副本政策
處理用戶端讀寫請求。
3、DataNode：就是Slave。NameNode 下達指令，DataNode 執行實際的操作。
存儲實際的資料塊。
執行資料塊的讀/寫操作。
4、Secondary NameNode：并非 NameNode 的熱備。當NameNode 挂掉的時候，它并不能馬上替換 NameNode 并提供服務。
輔助 NameNode，分擔其工作量。	
定期合并 fsimage和fsedits，并推送給NameNode。
在緊急情況下，可輔助恢複 NameNode。
           

拓展閱讀：

https://www.cnblogs.com/codeOfLife/p/5375120.html 初步掌握HDFS的架構及原理

三、高可用性

網站的可用性描述網站可有效通路的特性。

典型的分層模型是三層：應用層、服務層、資料層。關閉服務或者伺服器當機時對于各層産生的影響不同，高可用的解決方案差異也很大。

初此之外，還可通過一系列軟體品質保證手段保證線上系統的可用性：網站釋出、自動化測試、預釋出驗證、灰階釋出等。

3.1 應用層：

應用層主要處理網站的業務邏輯，典型特點是無狀态性，多個服務執行個體之間完全對等。可以通過負載均衡裝置将一組伺服器組成一個叢集共同對外服務。

當負載均衡裝置通過心跳檢測等手段監控到某台應用伺服器不可用時，就将其在叢集清單中移除，并将請求分發到其他可用的伺服器上，進而實作高可用。

注：

①應用伺服器叢集的Session管理，一般是将應用伺服器的狀态分離——無狀态的應用程式和有狀态的session伺服器（獨立部署，統一管理session）。該種方式可用性高、伸縮性好、性能也不錯（cookie管理：大小限制存儲的資訊量，傳輸cookie影響性能）。

②對于有狀态的session伺服器，一種比較簡單的方法是利用分布式緩存、資料庫等，在這些産品的基礎上進行包裝，使其符合Session的存儲和通路要求。如果業務場景對Session管理比較高，則需開發專門的Session服務管理平台。

3.2服務層

與應用層類似，通過叢集方式實作高可用，隻是這些伺服器被應用層通過分布式服務調用架構通路（第五節詳細介紹）。分布式服務調用架構會在應用層用戶端程式中實作負載均衡，并通過注冊中心對提供服務的伺服器進行心跳檢測，發現服務不可用，立即通知用戶端程式修改服務通路清單，剔除不可用伺服器。

除負載均衡外，還有以下幾點高可用的服務政策：

①分級管理。

根據功能需要劃分不同優先級，核心應用和服務使用更好的硬體——高優先級服務部署在不同實體機上。

同時也應注意有必要的隔離，避免故障連鎖。

②逾時設定。

伺服器當機、線程死鎖等原因，可能導緻服務端的調用失去響應，同時還占用應用程式資源，不利于及時将通路請求轉移到正常伺服器上。

設定逾時時間，逾時通訊架構抛出異常，失效轉移。

③異步調用。

隔離：避免一個服務失敗導緻整個應用請求失敗的情況。

④服務降級。

網站通路高峰期，為了保證核心功能正常使用，需要對服務降級。降級有兩種手段：拒絕服務和關閉服務。

》拒絕服務：拒絕低優先級應用的排程。 ——避免“要死大家一起死”。

》關閉服務：關閉部分不重要的服務。如“雙十一”關閉評價服務。

⑤幂等性設計。

應用排程失敗後，會将請求發送給其他伺服器。但是這個失敗可能是因為網絡故障沒收到響應或其他原因導緻的“失敗”，這時候重複調用服務，可能會出現問題（如支付）。

服務重複調用無法避免，應用層也不關心服務是否真的失敗，是以必須在服務層保證重複調用和調用一次産生的結果相同，即服務具有幂等性。

個人了解
除了叢集失效轉移之外，可用性還有如下思想提高可用性：分級管理、隔離、快速失敗、幂等性。
           

3.3資料層

分析：由于資料存儲伺服器上儲存的資料不同，當某台伺服器當機後，資料通路請求不能任意切換到叢集中的其他機器上。

手段：資料備份和失效轉移機制

1.資料備份：保證資料有多個副本，任意副本失效都不會導緻資料永久丢失，進而實作資料完全的持久化。

資料備份包括資料熱備和資料冷備。

》冷備：資料複制到存儲媒體上并實體存檔保管

》熱備：熱備分為兩種：異步熱備和同步熱備

①異步熱備：多份資料本寫入操作異步完成。應用程式收到資料服務系統的寫操縱成功響應時，隻寫成了一份（主），存儲系統會異步地寫入其他副本（從）。

注：關系資料庫的主從同步機制，寫操作之通路主資料庫，讀操作隻通路從資料庫，實作了讀寫分離

②同步熱備：多份資料副本的寫入操作同時完成。存儲伺服器完全對等，無主從之分。一般等待所有存儲伺服器都傳回操作成功的響應後，再通知應用程式寫操作成功。

2.失效轉移：保證當一個資料副本不可通路時，可以快速切換到通路資料的其他副本。

失效轉移操作分為三個步驟：失效确認，通路轉移，資料恢複

①失效确認。确認伺服器是否當機手段有兩種：心跳檢測和程式通路失敗報告。

對于後者，程式通路失敗後，有必要再進行心跳檢測确認。畢竟失效轉移代價太高，若誤判代價太大。

②通路轉移

對等，則轉移到其他對等伺服器上；不對等，需要重新計算路由選擇存儲伺服器。

③資料恢複

伺服器當機後，資料存儲的副本數目減少，必須将副本的數目恢複到系統設定的值。防止再有伺服器當機時，無法通路轉移

高可用分布式存儲設計思路：

1.瞬時故障：

失效确認。瞬時故障短暫時間内即可自行恢複，遇到後隻需要多次重試請求，就可以重新連接配接到伺服器。

2.臨時故障：

發現故障不是瞬時故障，采用臨時伺服器進行寫操作，故障修複了，将臨時伺服器寫入的資料遷移到修複好的伺服器中。

讀操作，隻選擇正常狀态下的伺服器讀資料。

3.永久故障：

讀操作，隻選擇正常狀态下的伺服器讀資料。

寫操作，首先同時寫入正常伺服器和臨時伺服器；發覺故障為永久故障而非臨時故障，則新資料同時寫入正常伺服器和代替故障伺服器的新伺服器，然後正常伺服器的資料也要複制到新伺服器中，同時，删除臨時伺服器寫入的資料。

四、伸縮性

4.1概述

1.伸縮性分兩類：①根據功能進行實體分離（不同的伺服器部署不同的服務）實作伸縮。②單一功能通過叢集實作伸縮（多台伺服器部署相同的服務，提供相同的功能）

個人了解：
第二條，叢集是實作伸縮性的手段不用多說。
第一條擴充還是伸縮？兩者都是吧。
①聯想原始網站是應用程式、資料庫、檔案等部署在同一台機器上，後來分離部署，獲得跟高cpu，高大記憶體，是通過增加/減少裝置數量來擴大/縮小伺服器的處理能力，故而可以了解為伸縮性。
②而分割分布式部署，解耦同樣是助于提高擴充性的。
第一條比較簡單，是以伸縮性主要還是研究第二條。伸縮性可以簡單了解為多台伺服器提供相同的功能。  是以我認為“伸縮性>叢集=多台伺服器提供相同的功能/服務”。本節接下來的内容都是讨論第二條的。
           

2.叢集伸縮性可分為①應用程式伺服器叢集伸縮性和②資料伺服器叢集伸縮性（緩存資料伺服器叢集+存儲資料伺服器叢集）

3.叢集對于資料狀态管理的不同，技術實作也不同

①無狀态：負載均衡算法定位清單中進行資料處理的伺服器+借助負載均衡伺服器實作将請求資料發送到對應的web伺服器上

②有狀态：在無狀态基礎上還要考慮狀态變化。具體情況具體分析。

4.2負載均衡

1.負載均衡

》目标：負載均衡伺服器作為請求分發裝置，可以感覺或者可以配置叢集的伺服器數量，可以及時發現叢集中新上線或下線的伺服器，并能向新上線的服務分發請求，停止向已下線的伺服器分發請求。

》過程：将使用者請求按照某種規則分發到叢集的不同伺服器上。由于任何一台伺服器處理結果都是相同的（無狀态前提下），是以當某台伺服器故障後，負載均衡伺服器會将該伺服器上的請求分發到其他伺服器上代替處理。

》好處：實作網站的伸縮性，同時改善網站的可用性。

2.實作負載均衡的基礎技術包括以下幾種：

①HTTP重定向負載均衡—— HTTP重定向伺服器作為負載均衡伺服器

②DNS域名伺服器負載均衡——DNS伺服器處理域名解析請求的同時進行負載均衡處理

個人了解：
實際使用往往将域名解析作為第一級負載均衡手段，真實處理請求的web伺服器由第一級處理的結果（提供負載均衡的内部伺服器）再次負載均衡定位得到。
這麼使用的原因是：當叢集中某台伺服器下線時，若采用多級域名解析作為負載均衡的手段，容易出現響應延遲（下線的伺服器A可能被多級DNS緩存，及時修改了DNS的A記錄，生效也需要一定時間）。故而隻采用第一級DNS，然後再通過内部的負載均衡伺服器處理。
           

③反向代理伺服器負載均衡—— 和反向代理伺服器功能內建在一起

注：由于Web伺服器不直接對外提供通路，是以Web伺服器不需要使用外部IP位址，而反向代理伺服器則需要配置雙網卡和内部外部兩套IP位址。

④IP負載均衡 ——在網絡層通過修改目标位址進行負載均衡

⑤資料鍊路層負載均衡——在資料鍊路層修改Mac位址進行負載均衡。

拓展閱讀：負載均衡技術實作

https://www.cnblogs.com/yeyublog/p/6438373.html

https://blog.csdn.net/mengdonghui123456/article/details/53981976

4.3負載均衡算法

1.目标：根據負載均衡算法和Web伺服器清單計算得到叢集中一台Web伺服器的位址

2.負載均衡算法通常有

①輪詢

②權重輪詢

③随機

④最少連接配接

⑤源位址散列（hash）

4.4伺服器叢集伸縮性設計

1.應用程式伺服器叢集

應用伺服器應該設計為無狀态的（應用伺服器不存儲上下文資訊。）

負載均衡+負載均衡算法

2.分布式緩存伺服器叢集

》分布式緩存之于叢集的特性：分布式緩存伺服器叢集中不同伺服器中緩存的資料各不相同，故而，緩存通路請求必須先找到緩存有需要資料的伺服器，然後才能通路。而新上線的緩存伺服器沒有緩存任何資料，而已下線的緩存伺服器還緩存着許多熱點資料。

》主要目标：新加入緩存伺服器後使得整個緩存伺服器叢集中已經緩存的資料盡可能還被通路到。

》問題分析解決：

①問題：分布式緩存擴容的時候，事情會變得很棘手。簡單的路由算法可以使用餘數Hash算法，擴容時，伺服器規模越大，不能命中的機率越大。

②解決方案：雖然可以在網站通路少時擴容伺服器叢集、進行緩存預熱，仍是治标不治本。必須改進路由算法，目前比較流行的是使用一緻性hash算法。

》分布式緩存的一緻性Hash算法

核心思想：

①節點構成環，降低影響（隻影響了新節點加入位置周圍兩節點間的命中率）。然而在原始環上增加一個節點會打亂原始環中節點間緩存資料量/負載壓力的比例。

②進一步改進：需要依靠增加虛拟層，每個節點虛拟化為多個節點分布在環中，一定程度上削弱增加節點帶來的打亂原始負載/緩存資料量比例的影響。

注：一台伺服器虛拟為多少個虛拟伺服器節點合适呢？太多會影響性能，太少又會導緻負載不平衡。一般來說，經驗值是150

拓展閱讀：

https://www.cnblogs.com/lpfuture/p/5796398.html 一緻性雜湊演算法原理

3.資料存儲伺服器叢集

》緩存叢集之于資料存儲伺服器叢集

緩存的目的是加快讀取速度，減輕存儲伺服器壓力，緩存丢失還可從資料庫等存儲伺服器上擷取。

故而，資料存儲伺服器叢集對資料的持久型和可用性提出了更高的要求，緩存伺服器叢集伸縮性不能直接适用于資料庫等存儲伺服器。

》重點任務：叢集伸縮的同時，需要保證資料的可靠存儲，任何情況下都保證資料的可用性和正确性

①關系資料庫叢集的伸縮性設計

基本的：資料庫主從分離讀寫，主從複制，資料一緻。

資料分庫：不同業務的資料表部署在不用的資料庫叢集上，類似于業務分割。

資料分片：将一些很大的表單資料（如淘寶的商品資料庫），進行分片，将一張表拆分開分别存儲在多個資料庫中。

個人體會：
	以上内容進一步說明伸縮性=增加/減少伺服器處理業務>增加/減少功能一緻伺服器處理業務.
	另外，“功能一緻”這個詞也要看層面，資料分庫、資料分片雖然細分，功能不一緻，但是整體功能都是存儲資料又是一緻。是以這些伺服器都叫做“關系資料庫”叢集。故而叢集這個詞很模糊，怎樣才是功能一緻？
	業務功能一緻還是不一緻勿論，叢集的判斷重點看是否是一組伺服器，因為“功能一緻”細分可能不一緻，大方面有可能是一緻的。或許這就是“有狀态”的特點吧。
	“分布式部署”這個詞應該同時包含伸縮性和擴充性兩個語義：①從大方面講，分布式都是同一個功能（分布式緩存伺服器，都是用來存緩存的），可以算這一組是叢集。②細粒度來講，分布式部署的是分層/分割得到的功能有别的各個子產品，從這個角度來講，是解耦，利于系統擴充。
           

以支援分片的分布式資料庫産品Cobar為例，觀察它如何實作伸縮，同時保證資料存儲的正确性與可用性。

對比思考：

》與直接分片對比，使用cobar的好處？ cobar叢集

Cobar 伺服器可以看作是無狀态的應用伺服器，是以可以直接使用負載均衡手段實作叢集伸縮。而 MySQL 伺服器中存儲着資料，是以我們要做資料遷移（把叢集中原有的伺服器中的資料遷移到新的伺服器），才能保證擴容後資料一緻負載均衡。

》與緩存資料庫叢集采取的伸縮性設計方法相比，該方法如何保證了資料存儲的正确性和可用性？

可以利用一緻性 Hash 算法進行資料遷移，盡量使得要遷移的資料最少。實踐中，Cobar 伺服器利用 MySQL 的資料同步功能進行資料遷移。遷移是以 Schema 為機關。

拓展閱讀：

https://blog.csdn.net/hxpjava1/article/details/60468263 阿裡開源Mysql分布式中間件：Cobar

②Nosql資料庫叢集的伸縮性設計

》為了應對大型網站遇到關系資料庫難以克服的缺陷——糟糕的海量資料處理能力及僵硬的設計限制，NoSql被提出彌補關系資料庫的不足。

》Nosql：非關系的、分布式的資料庫設計模式。放棄了關系資料庫的兩大重要基礎：結構化查詢和事務一緻性保證。更關注網站的高可用性和伸縮性。

》Apache Hbase應用最廣泛的Nosql産品之一

拓展閱讀：https://www.cnblogs.com/caiyisen/p/7424177.html HBase核心知識點總結

五、擴充性

伸縮性主要依靠将系統子產品解耦、分布式部署，然後将各子產品聚合的形式實作。子產品分布式部署以後聚合方式主要有：消息隊列和分布式服務。

5.1分布式消息隊列

1.消息隊列

①工作模式：消息隊列利用釋出——訂閱模式工作。消息發送者發送資訊，一個/多個消息接收者訂閱消息。消息發送者在對消息進行處理并送到分布式消息隊列後，消息接收者從分布式隊列擷取該消息後繼續進行處理。

②特點：

消息發送者和消息接收者無直接耦合，消息發送者不需等待消息接收者處理完即可傳回，有更好的響應延遲；

網站通路高峰時，消息可以暫存于消息隊列，等待接收者根據其負載能力控制處理速度，減輕資料庫等後端存儲的壓力。

2.分布式消息隊列架構原理

過程

①消息生産者應用程式通過遠端通路交界口将資訊推送給消息隊列伺服器，消息隊列伺服器将消息寫入本地記憶體後立即傳回成功響應給生産者。

②消息隊列伺服器根據訂閱清單查找訂閱該消息的消費者應用程式，将隊列中的消息按照FIFO原則，通過遠端通信接口發送給消費者程序。

分析：

①伸縮性：

消息隊列伺服器上資料可看作被即時處理的，類似于無狀态伺服器。伸縮性設計隻需将新伺服器加入分布式消息隊列叢集，并通知生産者伺服器更改消息隊列伺服器清單即可。

②可用性：

》為了避免消費者程序處理緩慢，造成消息隊列伺服器記憶體不足問題：如果記憶體已滿，可寫入到磁盤；消息推送子產品處理完記憶體隊列的消息後，将磁盤内容加載到記憶體隊列繼續處理。

》為了避免消息隊列伺服器當機造成資訊丢失：将消息成功發送到消息隊列的資訊存儲在生産者伺服器，等消息真正被消費者伺服器處理後才删除資訊；在消息隊列伺服器當機後，生産者伺服器會選擇叢集中其他伺服器釋出消息。

5 .2分布式服務打造可複用的業務平台

1.背景及解決思想

問題：巨無霸系統将會帶來編譯部署困難、代碼分支管理困難、資料庫連接配接耗盡等問題。

解決方式：通過拆分，将子產品獨立部署，降低系統耦合。拆分分為縱向拆分和橫向拆分。

》縱向拆分：梳理業務，将一個大應用拆分為多個小應用，如果新增業務比較獨立，那就将其設計部署為一個獨立的Web應用系統。

》橫向拆分：将複用的業務拆分開來，獨立部署為分布式服務，新增業務隻需調用這些分布式服務，不需要依賴具體的子產品代碼。

縱向拆分較簡單，而橫向拆分不但需要識别可複用的業務、設計服務接口、規範服務依賴關系，還需要完善的分布式服務管理架構。

2.分布式服務架構的架構原理

》分布式服務通過接口分解系統耦合性，不同子系統通過相同的接口描述進行服務調用。

分布式服務架構一般需要支援負載均衡、失效轉移、高效的遠端通信、整合異構系統、對應用最少侵入等特性。

》阿裡巴巴分布式開源架構Dubbo

①服務消費者程式通過服務接口使用服務，而服務接口通過代理加載具體服務，具體服務可以是本地的代碼子產品，也可以是遠端的服務，是以對應用較少侵入：應用程式隻需要調用服務接口，服務架構根據配置自動調用本地或遠端實作。

②服務架構伺服器端：服務提供者啟動後自動向服務注冊中心注冊自己提供的服務接口清單。

③服務架構用戶端：服務架構用戶端通過服務注冊中心加載服務提供者清單，查找需要的服務接口，并根據配置的負載均衡政策将服務調用請求發送到某台服務提供者伺服器（如果服務調用失敗，用戶端子產品會自動從服務提供者清單中，選擇一個可提供相同服務的另一台伺服器重新請求服務，實作服務的自動失效轉移）。

④Dubbo遠端服務通信子產品支援多種通信協定和資料序列化協定，使用NIO通信架構，具有較高的網絡通信性能。

3.更進一步，利用開放平台建設網站生态圈

網站必須提供更多的增值服務才能賺錢，開放平台是内部和外部的接口，外部需要面對衆多第三方開發者、對内需要面對網站内諸多業務服務。開放平台架構設計一般包括：

①OpenAPI、協定轉換（提供給第三方，并将其輸入轉換為内部可識别的形式）；

②安全、審計（完成身份識别、權限監控、計費等功能）；

③路由、流程（将開放平台的通路路由到具體的内部服務，将原來離散的服務組織成一個隐藏服務細節上下文相關的新服務）。

5.3其他——可擴充資料結構

》問題：關系型資料庫表結構帶來資料結構僵硬，難以面對需求變更的挑戰，盡管使用備援字段應對仍不理想。

》解決方案：Nosql資料庫使用列族設計就是一個解決方案，建立表的時候，隻需要指定列族名字，具體字段可以在寫入時再指定。通過這種方式，資料表可包含數百萬字段，使得應用程式資料結構可以擴充。

六、安全

6.1網站應用攻擊和防禦

1.XSS攻擊

XSS（跨站點腳本攻擊），指黑客通過篡改網頁注入惡意HTML腳本，在使用者浏覽網頁時，控制浏覽器進行惡意操作的一種攻擊方式。攻擊類型包括：反射型和持久型。

①反射型XSS攻擊：攻擊者誘使使用者點選一個嵌入式惡意腳本連結，攻擊者可以采用XSS攻擊偷取使用者cookie、密碼等重要資料。

②持久型/存儲型XSS攻擊：黑客送出含有惡意腳本的請求，儲存到被攻擊Web站點的資料庫中，使用者浏覽網頁時，惡意腳本會被包含在正常頁面中，達到攻擊的目的。此種攻擊經常使用在論壇、部落格等Web應用中。

應對政策：

①消毒：XSS攻擊一般都是通過在請求中嵌入惡意腳本達到攻擊目的，這些腳本一般使用者輸入不會使用，如果進行過濾和消毒處理（即對html危險字元轉義，如“>”轉義為“&gt”），就可以防止大部分攻擊。

②HttpOnly：因為浏覽器禁止頁面JavaScript通路帶有HttpOnly屬性的cookie。是以可以通過對該Cookie添加HttpOnly屬性的方式，防止XSS攻擊者竊取Cookie。

2.注入攻擊

注入攻擊主要有兩種形式：SQL注入和OS注入攻擊。

注入攻擊是應用違背了“資料與代碼分離原則”導緻的結果。隻需要牢記“資料與代碼分離原則”，在“拼湊”發生的地方進行安全檢查。就能避免此類問題。

防禦方式：采用預編譯手段進行參數綁定、消毒（通過正規表達式過濾請求資料中可能注入的SQL）。

3.其他攻擊和漏洞

》CSRF攻擊：跨站點請求僞造 。即利用跨站請求，在使用者不知道的情況下，以使用者身份僞造請求。 https://www.cnblogs.com/wangyuyu/p/3388169.html

防禦手段主要是識别請求者身份：

①驗證碼（請求送出時，需要使用者輸入驗證碼）

②表單Token（在請求中增加随機數的方法組織攻擊者獲得請求參數）

③Referer check（Http請求頭的referer域記錄着請求拉遠）

》漏洞：

①Error Code錯誤回顯—— 異常堆棧資訊直接輸出到用戶端浏覽器。

②HTML注釋——開發人員在PHP、JSP等伺服器頁面程式使用HTML注釋文法進行注釋，這些注釋會顯示在用戶端浏覽器。

③檔案上傳——上傳某些可執行檔案獲得服務端指令執行能力，進而為所欲為。最有效防禦方式是設定白名單，隻允許上傳可靠的檔案類型。

④路徑周遊——攻擊者在請求的URL中使用相對路徑，周遊系統未開放的目錄和檔案。防禦方式：JS、CSS等資源檔案部署在獨立伺服器上、使用獨立域名；其他檔案不使用靜态URL通路；動态參數不包含檔案路徑資訊。

6.2加密

為了保護網站敏感資料，需要對其進行加密處理。資訊加密技術可分為三類：單項散列加密、對稱加密、非對稱加密。

1.單項散列加密。

》通過不同輸入長度的資訊進行散列計算，得到固定長度的輸出。散列計算的過程是單向的，且輸入的任何微小變化都會導緻輸出的完全不同。

》應用場景：密碼加密儲存。

》破解：通過彩虹表（人們常用密碼和對應的密文關系表）等手段進行猜測式破解。

》為了加強單項散列計算安全性，還會給雜湊演算法加點鹽（加密的密鑰）。常用的單項雜湊演算法包括：MD5、SHA等。

2.對稱加密。

》所謂對稱加密是指加密和解密使用的密鑰是同一個密鑰（或者可以互相推算）。傳統也是最常用的加密手段，适用于絕大多數加密的場合。

》應用場景：資訊需要安全交換或存儲的場合，如cookie加密、通信加密等。

》常用的加密算法有DES算法、RC算法等。

3.非對稱加密。

》加密和解密的密鑰不是同一個密鑰，其中一個對外界公開（公鑰），另一個隻有所有者知道（私鑰）。二者加密的資訊隻有對方才能解開。

》應用場景：資訊安全傳輸、數字簽名等場合。

》過程描述：

①資訊發送者A通過公開管道獲得資訊接受者B的公鑰，對送出資訊進行加密，然後通過非安全傳輸通道将密文發送給B，B得到密文後，用自己的私鑰進行解密。即使密文資訊在傳輸過程中遭到竊取，竊取者沒有解密密鑰也無法還原明文。

②數字簽名過程則相反，簽名者用自己的私鑰對資訊進行加密，然後發送給對方，接收方用簽名者的公鑰進行解密，獲得原始明文資訊，由于私鑰隻有簽名者擁有，資訊不可抵賴，具有簽名的性質。

》常用算法有RSA算法等。

》如果有人偷換公鑰為自己的公鑰，冒充資訊接受者與資訊發送者（以下稱使用者）進行通信，怎樣驗證公鑰的身份？——數字證書。

CA（證書中心）可以将（XX公鑰及其所有者等）資訊利用CA自身的私鑰進行加密，使用者可以通過CA提供的公鑰進行解密，進而驗證XX公鑰的身份。

4.非對稱加密和非對稱加密混合使用

實際應用中，往往采取兩種加密混合使用的方式：先使用非對稱加密對對稱密鑰進行安全傳輸，然後使用對稱加密技術進行資訊加解密與交換。

而有時，對同一個資料兩次使用非對稱加密可以同時實作資訊安全傳輸與數字簽名的目的。

拓展閱讀：

https://www.cnblogs.com/zfxJava/p/5295957.html 數字簽名、數字證書、對稱加密算法、非對稱加密算法、單向加密（雜湊演算法）

密鑰本身是以明文方式儲存的，從前述的幾種加密技術中可以看出，資訊的安全是靠密鑰保證的，密鑰安全性極為重要。

密鑰安全管理方式：

①：把密鑰和算法放在一個獨立的伺服器上，對外提供加密解密服務，供應用系統調用。專人維護、遠端調用 ，成本較高，系統開銷較大。

②：加解密算法放在應用系統中，密鑰放在獨立伺服器中，實際存儲時，密鑰被分片儲存在不同媒體上。兼顧性能與安全。

6.3資訊過濾

1.文本比對——主要解決敏感詞過濾問題。怎樣查找敏感詞？正規表達式比對效率極差，一般采用Trie算法和構造多級Hash表進行文本比對。

2.分類算法——識别垃圾資訊、資訊自動分類。比較實用的分類算法是貝葉斯分類算法。

3.黑名單——用于資訊去重、垃圾郵件識别。可以通過Hash表實作黑名單，黑名單清單非常大時，可以用布隆過濾器（通過一個二級制清單和一組随機數映射函數實作）代替Hash表。

拓展閱讀：

https://www.cnblogs.com/xujian2014/p/5614724.html 字典樹(Trie樹)實作與應用

https://www.jianshu.com/p/2104d11ee0a2 布隆過濾器的原理、使用場景和注意事項

6.4風險控制

電子商務存在賬戶盜用、賣家惡意占用庫存、不良賣家惡意欺詐（如虛假發貨）等風險。風控技術手段主要有規則引擎和統計模型

1.規則引擎：設定風控業務規則，通過使用指定的規則對比交易請求與曆史資料評估風險，高風險則進行人工稽核，否則正常交易。

2.統計模型：為了應對規則增加帶來的規則沖突、難以維護問題，訓練統計模型（分類算法或更複雜的及其學習算法隻能統計）。實際使用：采集交易資訊作為模型的輸入，借助訓練的模型，得到交易的風險分值。