大型網(wǎng)站技術(shù)架構(gòu):摘要與讀書筆記
作者丨xybaby?cnblogs.com/xybaby/p/8907880.html
花了幾個(gè)晚上看完了《大型網(wǎng)站技術(shù)架構(gòu)》這本書，個(gè)人感覺這本書的廣度還行，深度還有些欠缺（畢竟只有200頁(yè)左右）。但是作為一個(gè)缺乏大型網(wǎng)站技術(shù)的IT民工，看完一遍還是很有收獲的，至少對(duì)一個(gè)網(wǎng)站的技術(shù)演進(jìn)、需要解決的問題有了一個(gè)全面的認(rèn)識(shí)。文中也有一些作者個(gè)人的心得、感悟、總結(jié)，我覺得還是很中肯的。鏈接：https://book.douban.com/subject/25723064/在網(wǎng)上一搜，這本書的讀書筆記還是很多的，而我自己還是決定寫一篇讀書筆記，主要是為了避免自己忘得太快。筆記的內(nèi)容并不完全按照原書的內(nèi)容，主要記錄的是我自己感興趣的部分。一個(gè)網(wǎng)站的進(jìn)化史作者反復(fù)在文中提到一個(gè)觀點(diǎn)：大型網(wǎng)站是根據(jù)業(yè)務(wù)需求逐步演化而來(lái)的，而不是設(shè)計(jì)出來(lái)的。不得不承認(rèn)，互聯(lián)網(wǎng)行業(yè)發(fā)展到了今天，大魚吃小魚還是很普遍的，大公司的微創(chuàng)新能力分分鐘就能干死一個(gè)小的項(xiàng)目，所以小公司需要足夠快的發(fā)展，不停的快速迭代與試錯(cuò)。下面是是一個(gè)演化的過程，圖片來(lái)自網(wǎng)絡(luò)。
img在初始階段，訪問量并不大，所以應(yīng)用程序、數(shù)據(jù)庫(kù)、文件等所有的資源都在一臺(tái)服務(wù)器上。
img隨著業(yè)務(wù)的發(fā)展，就會(huì)發(fā)現(xiàn)一臺(tái)服務(wù)器抗不過來(lái)了，所以將應(yīng)用服務(wù)器與數(shù)據(jù)（文件、數(shù)據(jù)庫(kù)）服務(wù)器分離。三臺(tái)服務(wù)器對(duì)硬件資源的要求各不相同：應(yīng)用服務(wù)器需要更快的CPU，文件服務(wù)器需要更大的磁盤和帶寬，數(shù)據(jù)庫(kù)服務(wù)器需要更快速的磁盤和更大的內(nèi)存。分離之后，三個(gè)服務(wù)器各司其職，也方便針對(duì)性的優(yōu)化。
img“世界上沒有什么問題是加一級(jí)緩存解決不了的，如果有那就再加一級(jí)緩存”緩存的使用無(wú)處不在，緩存的根本目的是加快訪問速度。當(dāng)數(shù)據(jù)庫(kù)的訪問壓力過大的時(shí)候，就可以考慮使用緩存了。網(wǎng)站使用的緩存可以分為兩種: 緩存在應(yīng)用服務(wù)器上的本地緩存和緩存在專門的分布式緩存服務(wù)器上的遠(yuǎn)程緩存。
img
隨著業(yè)務(wù)的發(fā)展，單個(gè)應(yīng)用服務(wù)器一定會(huì)成為瓶頸，應(yīng)用服務(wù)器實(shí)現(xiàn)集群是網(wǎng)站可伸縮集群架構(gòu)設(shè)計(jì)中較為簡(jiǎn)單成熟的一種。后面也會(huì)提到，將應(yīng)用服務(wù)器設(shè)計(jì)為無(wú)狀態(tài)的（沒有需要保存的上下文信息），就可以通過增加機(jī)器，使用負(fù)載均衡來(lái)scale out。
img即使使用了緩存，但在緩存未命中、或者緩存服務(wù)時(shí)效的情況下，還是需要訪問數(shù)據(jù)庫(kù)，這個(gè)時(shí)候就需要數(shù)據(jù)庫(kù)的讀寫分離：主庫(kù)提供寫操作，從庫(kù)提供讀服務(wù)。注意，在上圖中增加了一個(gè)數(shù)據(jù)訪問模塊，可以對(duì)應(yīng)用層透明數(shù)據(jù)庫(kù)的主從分離信息。
imgCDN和反向代理其實(shí)都是緩存，區(qū)別在于CDN 部署在網(wǎng)絡(luò)提供商的機(jī)房；而反向代理則部署在網(wǎng)站的中心機(jī)房。使用CDN 和反向代理的目的都是盡旱返回?cái)?shù)據(jù)給用戶， 一方面加快用戶訪問速度，另一方面也減輕后端服務(wù)器的負(fù)載壓力。
img單個(gè)物理機(jī)的磁盤是有限的，單個(gè)關(guān)系數(shù)據(jù)庫(kù)的處理能力也是有上限的，所以需要分布式文件存儲(chǔ)與分布式數(shù)據(jù)庫(kù)。當(dāng)然，也需要”統(tǒng)一數(shù)據(jù)訪問模塊“，使得應(yīng)用層不用關(guān)心文件、數(shù)據(jù)的具體位置。值得一提的事，關(guān)系型數(shù)據(jù)庫(kù)自身并沒有很好的水平擴(kuò)展方案，因此一般都需要一個(gè)數(shù)據(jù)庫(kù)代理層，如cobar、mycat。
imgweb2.0的很多應(yīng)用并一定適合用關(guān)系數(shù)據(jù)庫(kù)存儲(chǔ)，更加靈活的NoSql能更加方便的解決一些問題，而且NoSQL天然就支持分布式。專門的搜索引擎在提供更優(yōu)質(zhì)服務(wù)的同時(shí)，也大大減輕了數(shù)據(jù)庫(kù)的壓力。
img將一個(gè)網(wǎng)站拆分成許多不同的應(yīng)用， 每個(gè)應(yīng)用獨(dú)立部署維護(hù)。應(yīng)用之間可以通過一個(gè)超鏈接建立關(guān)系(在首頁(yè)上的導(dǎo)航鏈接每個(gè)都指向不同的應(yīng)用地址) ，也可以通過消息隊(duì)列進(jìn)行數(shù)據(jù)分發(fā)， 當(dāng)然最多的還是通過訪問同一個(gè)數(shù)據(jù)存儲(chǔ)系統(tǒng)來(lái)構(gòu)成一個(gè)關(guān)聯(lián)的完整系統(tǒng)
img既然每一個(gè)應(yīng)用系統(tǒng)都需要執(zhí)行許多相同的業(yè)務(wù)操作， 比如用戶管理、商品管理等，那么可以將這些共用的業(yè)務(wù)提取出來(lái)，獨(dú)立部署。通過服務(wù)的分布式，各個(gè)應(yīng)用能更好的獨(dú)立發(fā)展，實(shí)現(xiàn)了從依賴模塊到依賴服務(wù)的過渡。將通用的公共服務(wù)獨(dú)立出來(lái)，也方便做服務(wù)管控，比如對(duì)各個(gè)應(yīng)用的服務(wù)請(qǐng)求進(jìn)行監(jiān)控，在高峰時(shí)期限制、關(guān)閉某些應(yīng)用的訪問等。大型網(wǎng)站架構(gòu)模式與核心要素這一部分是說大型網(wǎng)站需要解決的核心問題，以及解決這些問題的常規(guī)思路。
img上面描述了失效確認(rèn)的兩種方法：控制中心通過心跳檢測(cè)存儲(chǔ)服務(wù)器的存活性；應(yīng)用在訪問存儲(chǔ)服務(wù)失敗的時(shí)候通知控制中心檢測(cè)存儲(chǔ)服務(wù)存活性伸縮性（Scalability）網(wǎng)站的伸縮性是指不需要改變網(wǎng)站的軟硬件設(shè)計(jì)，僅僅通過改變部署的服務(wù)器數(shù)量就可以擴(kuò)大或者縮小網(wǎng)站的服務(wù)處理能力。
img服務(wù)治理框架的功能和特點(diǎn)：
花了幾個(gè)晚上看完了《大型網(wǎng)站技術(shù)架構(gòu)》這本書，個(gè)人感覺這本書的廣度還行，深度還有些欠缺（畢竟只有200頁(yè)左右）。但是作為一個(gè)缺乏大型網(wǎng)站技術(shù)的IT民工，看完一遍還是很有收獲的，至少對(duì)一個(gè)網(wǎng)站的技術(shù)演進(jìn)、需要解決的問題有了一個(gè)全面的認(rèn)識(shí)。文中也有一些作者個(gè)人的心得、感悟、總結(jié)，我覺得還是很中肯的。鏈接：https://book.douban.com/subject/25723064/在網(wǎng)上一搜，這本書的讀書筆記還是很多的，而我自己還是決定寫一篇讀書筆記，主要是為了避免自己忘得太快。筆記的內(nèi)容并不完全按照原書的內(nèi)容，主要記錄的是我自己感興趣的部分。一個(gè)網(wǎng)站的進(jìn)化史作者反復(fù)在文中提到一個(gè)觀點(diǎn)：大型網(wǎng)站是根據(jù)業(yè)務(wù)需求逐步演化而來(lái)的，而不是設(shè)計(jì)出來(lái)的。不得不承認(rèn)，互聯(lián)網(wǎng)行業(yè)發(fā)展到了今天，大魚吃小魚還是很普遍的，大公司的微創(chuàng)新能力分分鐘就能干死一個(gè)小的項(xiàng)目，所以小公司需要足夠快的發(fā)展，不停的快速迭代與試錯(cuò)。下面是是一個(gè)演化的過程，圖片來(lái)自網(wǎng)絡(luò)。
初始階段的網(wǎng)站架構(gòu)
img在初始階段，訪問量并不大，所以應(yīng)用程序、數(shù)據(jù)庫(kù)、文件等所有的資源都在一臺(tái)服務(wù)器上。應(yīng)用服務(wù)和數(shù)據(jù)服務(wù)分離
img隨著業(yè)務(wù)的發(fā)展，就會(huì)發(fā)現(xiàn)一臺(tái)服務(wù)器抗不過來(lái)了，所以將應(yīng)用服務(wù)器與數(shù)據(jù)（文件、數(shù)據(jù)庫(kù)）服務(wù)器分離。三臺(tái)服務(wù)器對(duì)硬件資源的要求各不相同：應(yīng)用服務(wù)器需要更快的CPU，文件服務(wù)器需要更大的磁盤和帶寬，數(shù)據(jù)庫(kù)服務(wù)器需要更快速的磁盤和更大的內(nèi)存。分離之后，三個(gè)服務(wù)器各司其職，也方便針對(duì)性的優(yōu)化。使用緩存改善網(wǎng)站性能
img“世界上沒有什么問題是加一級(jí)緩存解決不了的，如果有那就再加一級(jí)緩存”緩存的使用無(wú)處不在，緩存的根本目的是加快訪問速度。當(dāng)數(shù)據(jù)庫(kù)的訪問壓力過大的時(shí)候，就可以考慮使用緩存了。網(wǎng)站使用的緩存可以分為兩種: 緩存在應(yīng)用服務(wù)器上的本地緩存和緩存在專門的分布式緩存服務(wù)器上的遠(yuǎn)程緩存。使用應(yīng)用服務(wù)器集群改善網(wǎng)站的并發(fā)處理能力
img隨著業(yè)務(wù)的發(fā)展，單個(gè)應(yīng)用服務(wù)器一定會(huì)成為瓶頸，應(yīng)用服務(wù)器實(shí)現(xiàn)集群是網(wǎng)站可伸縮集群架構(gòu)設(shè)計(jì)中較為簡(jiǎn)單成熟的一種。后面也會(huì)提到，將應(yīng)用服務(wù)器設(shè)計(jì)為無(wú)狀態(tài)的（沒有需要保存的上下文信息），就可以通過增加機(jī)器，使用負(fù)載均衡來(lái)scale out。
數(shù)據(jù)庫(kù)讀寫分離
img即使使用了緩存，但在緩存未命中、或者緩存服務(wù)時(shí)效的情況下，還是需要訪問數(shù)據(jù)庫(kù)，這個(gè)時(shí)候就需要數(shù)據(jù)庫(kù)的讀寫分離：主庫(kù)提供寫操作，從庫(kù)提供讀服務(wù)。注意，在上圖中增加了一個(gè)數(shù)據(jù)訪問模塊，可以對(duì)應(yīng)用層透明數(shù)據(jù)庫(kù)的主從分離信息。使用反向代理和CDN 加速網(wǎng)站晌應(yīng)
imgCDN和反向代理其實(shí)都是緩存，區(qū)別在于CDN 部署在網(wǎng)絡(luò)提供商的機(jī)房；而反向代理則部署在網(wǎng)站的中心機(jī)房。使用CDN 和反向代理的目的都是盡旱返回?cái)?shù)據(jù)給用戶， 一方面加快用戶訪問速度，另一方面也減輕后端服務(wù)器的負(fù)載壓力。使用分布式文件系統(tǒng)和分布式數(shù)據(jù)庫(kù)系統(tǒng)
img單個(gè)物理機(jī)的磁盤是有限的，單個(gè)關(guān)系數(shù)據(jù)庫(kù)的處理能力也是有上限的，所以需要分布式文件存儲(chǔ)與分布式數(shù)據(jù)庫(kù)。當(dāng)然，也需要”統(tǒng)一數(shù)據(jù)訪問模塊“，使得應(yīng)用層不用關(guān)心文件、數(shù)據(jù)的具體位置。值得一提的事，關(guān)系型數(shù)據(jù)庫(kù)自身并沒有很好的水平擴(kuò)展方案，因此一般都需要一個(gè)數(shù)據(jù)庫(kù)代理層，如cobar、mycat。使用NoSQL 和搜索引擎
imgweb2.0的很多應(yīng)用并一定適合用關(guān)系數(shù)據(jù)庫(kù)存儲(chǔ)，更加靈活的NoSql能更加方便的解決一些問題，而且NoSQL天然就支持分布式。專門的搜索引擎在提供更優(yōu)質(zhì)服務(wù)的同時(shí)，也大大減輕了數(shù)據(jù)庫(kù)的壓力。業(yè)務(wù)拆分
img將一個(gè)網(wǎng)站拆分成許多不同的應(yīng)用， 每個(gè)應(yīng)用獨(dú)立部署維護(hù)。應(yīng)用之間可以通過一個(gè)超鏈接建立關(guān)系(在首頁(yè)上的導(dǎo)航鏈接每個(gè)都指向不同的應(yīng)用地址) ，也可以通過消息隊(duì)列進(jìn)行數(shù)據(jù)分發(fā)， 當(dāng)然最多的還是通過訪問同一個(gè)數(shù)據(jù)存儲(chǔ)系統(tǒng)來(lái)構(gòu)成一個(gè)關(guān)聯(lián)的完整系統(tǒng)分布式服務(wù)
img既然每一個(gè)應(yīng)用系統(tǒng)都需要執(zhí)行許多相同的業(yè)務(wù)操作， 比如用戶管理、商品管理等，那么可以將這些共用的業(yè)務(wù)提取出來(lái)，獨(dú)立部署。通過服務(wù)的分布式，各個(gè)應(yīng)用能更好的獨(dú)立發(fā)展，實(shí)現(xiàn)了從依賴模塊到依賴服務(wù)的過渡。將通用的公共服務(wù)獨(dú)立出來(lái)，也方便做服務(wù)管控，比如對(duì)各個(gè)應(yīng)用的服務(wù)請(qǐng)求進(jìn)行監(jiān)控，在高峰時(shí)期限制、關(guān)閉某些應(yīng)用的訪問等。大型網(wǎng)站架構(gòu)模式與核心要素這一部分是說大型網(wǎng)站需要解決的核心問題，以及解決這些問題的常規(guī)思路。核心要素
五個(gè)要點(diǎn)：性能，可用性，伸縮性，擴(kuò)展性，安全作者指出，很多時(shí)候大家都混淆了伸縮性（Scalability）與擴(kuò)展性（Extensibility）。我以前也是把Scalability稱之為擴(kuò)展性，不過想想，在我們講代碼質(zhì)量的時(shí)候，擴(kuò)展性也是指Extensibility，以后還是直接說這兩個(gè)英文單詞好了。這幾點(diǎn)后面會(huì)詳細(xì)介紹。網(wǎng)站架構(gòu)模式
對(duì)模式的定義，書中描述得很好：" 每一個(gè)模式描述了一個(gè)在我們周圍不斷重復(fù)發(fā)生的問題及該問題解決方案的核心。這樣， 你就能一次又一次地使用該方案而不必做重復(fù)工作" 。模式的關(guān)鍵在于模式的可重復(fù)性， 問題與場(chǎng)景的可重復(fù)性帶來(lái)解決方案的可重復(fù)使用。用我自己的話來(lái)說，模式就是套路。這些模式，都是為了達(dá)成上面提到的核心要素。那么，有哪些模式呢分層
分層是企業(yè)應(yīng)用系統(tǒng)中最常見的一種架構(gòu)模式，將系統(tǒng)在橫向維度上切分成幾個(gè)部分，每個(gè)部分負(fù)責(zé)一部分相對(duì)比較單一的職責(zé)， 然后通過上層對(duì)下層的依賴和調(diào)用組成一個(gè)完整的系統(tǒng)。在大型網(wǎng)站架構(gòu)中也采用分層結(jié)構(gòu)，將網(wǎng)主占軟件系統(tǒng)分為應(yīng)用層、服務(wù)層、數(shù)據(jù)層。分層的好處在于：解耦合，獨(dú)立發(fā)展，伸縮性，可擴(kuò)展性。上面網(wǎng)站的進(jìn)化史也凸出了分層的重要性。但是分層架構(gòu)也有一些挑戰(zhàn)， 就是必須合理規(guī)劃層次邊界和接口，在開發(fā)過程中，嚴(yán)格遵循分層架構(gòu)的約束， 禁止跨層次的調(diào)用( 應(yīng)用層直接調(diào)用數(shù)據(jù)層)及逆向調(diào)用(數(shù)據(jù)層調(diào)用服務(wù)層， 或者服務(wù)層調(diào)用應(yīng)用層)。分割
分層強(qiáng)調(diào)的是橫向切分，而分割是縱向切分， 上面網(wǎng)站進(jìn)化史部分的業(yè)務(wù)拆分就包含了分割。分割的目標(biāo)是高內(nèi)聚、低耦合的模塊單元分布式
分層和分割的一個(gè)主要目的是分布式部署，但分布式也有自己的問題：網(wǎng)絡(luò)通信帶來(lái)的性能問題，可用性，一致性與分布式事務(wù)，系統(tǒng)維護(hù)管理復(fù)雜度。集群
一個(gè)機(jī)器解決不了的問題，就用幾個(gè)機(jī)器來(lái)解決，當(dāng)服務(wù)無(wú)狀態(tài)的時(shí)候，通過往集群增加機(jī)器就能解決大部分問題。對(duì)應(yīng)網(wǎng)站進(jìn)化史中“使用應(yīng)用服務(wù)器集群改善網(wǎng)站的并發(fā)處理能力”緩存
緩存就是將數(shù)據(jù)存放在距離計(jì)算最近的位置以加快處理速度，同時(shí)大大減輕了數(shù)據(jù)提供者的壓力大型網(wǎng)站架構(gòu)設(shè)計(jì)在很多方面都使用了緩存設(shè)計(jì)：CDN、反向代理、本地緩存、分布式緩存異步
異步是解耦合的一個(gè)重要手段，常見的生產(chǎn)者-消費(fèi)者模型就是一個(gè)異步模式。出了解耦合，異步還能提高系統(tǒng)可用性、加快響應(yīng)速度、流量削峰冗余
冗余是系統(tǒng)可用性的重要保障，也是數(shù)據(jù)可靠性的重要手段自動(dòng)化
凡人總是會(huì)出這樣那樣的錯(cuò)誤，能自動(dòng)話的就要自動(dòng)化。自動(dòng)化大大解放了程序員、運(yùn)維人員的生產(chǎn)力！發(fā)布過程自動(dòng)化、自動(dòng)化代碼管理、自動(dòng)化測(cè)試、自動(dòng)化安全檢測(cè)、自動(dòng)化部署、自動(dòng)化監(jiān)控、自動(dòng)化報(bào)警、自動(dòng)化失效轉(zhuǎn)移、自動(dòng)化失效恢復(fù)、自動(dòng)化降級(jí)。性能奧運(yùn)精神：更快、更高、更強(qiáng)技術(shù)人員對(duì)于性能的追求是無(wú)止境的。性能，站在不同的角度，衡量指標(biāo)是不一樣的：- 用戶視角：響應(yīng)時(shí)間，優(yōu)化手段：（瀏覽器優(yōu)化，頁(yè)面布局，壓縮文件，http長(zhǎng)鏈接），CND，反向代理
- 開發(fā)人員視角：系統(tǒng)延遲、吞吐量、穩(wěn)定性。優(yōu)化手段：緩存，異步，集群，代碼優(yōu)化
- 運(yùn)維視角：基礎(chǔ)設(shè)施性能 資源利用率。優(yōu)化手段：定制骨干網(wǎng)絡(luò)、定制服務(wù)器，虛擬化
系統(tǒng)吞吐量和系統(tǒng)并發(fā)數(shù)， 以及響應(yīng)時(shí)間的關(guān)系可以形象地理解為高速公路的通行狀況: 吞吐量是每天通過收費(fèi)站的車輛數(shù)目(可以換算成收費(fèi)站收取的高速費(fèi)) ， 并發(fā)數(shù)是高速公路上的正在行駛的車輛數(shù)目，響應(yīng)時(shí)間是車速。車輛很少時(shí)， 車速很快， 但是收到的高速費(fèi)也相應(yīng)較少; 隨著高速公路上車輛數(shù)目的增多，車速略受影響，但是收到的高速費(fèi)增加很快; 隨著車輛的繼續(xù)增加，車速變得越來(lái)越慢，高速公路越來(lái)越堵，收費(fèi)不增反降; 如果車流量繼續(xù)增加，超過某個(gè)極限后，任何偶然因素都會(huì)導(dǎo)致高速全部癱瘓， 車走不動(dòng)，費(fèi)當(dāng)然也收不著，而高速公路成了停車場(chǎng)(資源耗盡)。
web前端性能優(yōu)化
瀏覽器優(yōu)化：減少http請(qǐng)求，瀏覽器緩存，壓縮。CDN優(yōu)化，反應(yīng)代理應(yīng)用服務(wù)器性能優(yōu)化
四招：緩存、集群、異步、代碼優(yōu)化緩存
首先自然是緩存網(wǎng)站性能優(yōu)化第一定律: 優(yōu)先考慮使用緩存優(yōu)化性能。使用緩存，需要考慮的是緩存置換與一致性問題，其中緩存一致性問題也是分布式系統(tǒng)中需要解決的一個(gè)問題，主要的解決方法有租期和版本號(hào)。并不是所有的場(chǎng)合都適合緩存，如頻繁修改的數(shù)據(jù)、沒有熱點(diǎn)訪問的數(shù)據(jù)。緩存的可用性：理論上不能完全依靠，但事實(shí)上盡可能高可用，否則數(shù)據(jù)庫(kù)宕機(jī)導(dǎo)致系統(tǒng)不可用。因此緩存服務(wù)器也要納入監(jiān)控，盡量高可用。緩存穿透：如果因?yàn)椴磺‘?dāng)?shù)臉I(yè)務(wù)、或者惡意攻擊持續(xù)高并發(fā)地請(qǐng)求某個(gè)不存在的數(shù)據(jù)，由于緩存沒有保存該數(shù)據(jù)， 所有的請(qǐng)求都會(huì)落到數(shù)據(jù)庫(kù)上，會(huì)對(duì)數(shù)據(jù)庫(kù)造成很大壓力，甚至崩橫。一個(gè)簡(jiǎn)單的對(duì)策是將不存在的數(shù)據(jù)也緩存起來(lái)(其value 值為null )。
代碼優(yōu)化
- 多線程
- 為什么要使用多線程，IO阻塞 與 多核CPU
- 理想的load 是：即沒有進(jìn)程（線程）等待，也沒有CPU空閑
- 啟動(dòng)線程數(shù)= [任務(wù)執(zhí)行時(shí)間/ (任務(wù)執(zhí)行時(shí)間-10 等待時(shí)間)J xCPU 內(nèi)核數(shù)
- 資源復(fù)用
- 這個(gè)很常見，各種池（pool）：線程池、連接池
應(yīng)用層高可用
位于應(yīng)用層的服務(wù)器通常為了應(yīng)對(duì)高并發(fā)的訪問請(qǐng)求，會(huì)通過負(fù)載均衡設(shè)備將一組服務(wù)器組成一個(gè)集群共同對(duì)外提供服務(wù)，當(dāng)負(fù)載均衡設(shè)備通過心跳檢測(cè)等手段監(jiān)控到某臺(tái)應(yīng)用服務(wù)器不可用時(shí)，就將其從集群列表中剔除，并將請(qǐng)求分發(fā)到集群中其他可用的服務(wù)器上，使整個(gè)集群保持可用，從而實(shí)現(xiàn)應(yīng)用高可用。應(yīng)用層的高可用很容易，因?yàn)閼?yīng)用服務(wù)器很多時(shí)候是無(wú)狀態(tài)的。但是也有時(shí)候需要有維護(hù)的數(shù)據(jù)，如session，這樣就不能將一個(gè)請(qǐng)求路由到任意的應(yīng)用服務(wù)器。要解決session的問題，有以下幾種方法：- session綁定：利用負(fù)載均衡的源地址Hash 算法實(shí)現(xiàn)，負(fù)載均衡服務(wù)器總是將來(lái)源于同一IP 的請(qǐng)求分發(fā)到同一臺(tái)服務(wù)器上
- 用cookie記錄session：Cookie是存放在客戶端（瀏覽器）的，在每次訪問的時(shí)候帶上cookie里面的信息即可
- 專門的session服務(wù)器：將應(yīng)用服務(wù)器的狀態(tài)分離， 分為無(wú)狀態(tài)的應(yīng)用服務(wù)器和有狀態(tài)的Session。簡(jiǎn)單的方法是利用分布式緩存、數(shù)據(jù)庫(kù)（redis）來(lái)實(shí)現(xiàn)Session服務(wù)器的功能
服務(wù)層的高可用
服務(wù)層的高可用也是利用集群，不過需要借助分布式服務(wù)調(diào)用框架。服務(wù)層的服務(wù)器被應(yīng)用層通過分布式服務(wù)調(diào)用框架訪問，分布式服務(wù)調(diào)用框架會(huì)在應(yīng)用層客戶端程序中實(shí)現(xiàn)軟件負(fù)載均衡， 并通過服務(wù)注冊(cè)中心對(duì)提供服務(wù)的服務(wù)器進(jìn)行心跳檢測(cè)，發(fā)現(xiàn)有服務(wù)不可用，立即通知客戶端程序修改服務(wù)訪問列表，剔除不可用的服務(wù)器。為了保證服務(wù)層的高可用，可以采用以下策略：- 分層管理
- 超時(shí)設(shè)置
- 異步調(diào)用
- 服務(wù)降級(jí)，包括：拒絕服務(wù)，高峰時(shí)段，拒絕低優(yōu)先級(jí)應(yīng)用的訪問；關(guān)閉服務(wù)，關(guān)閉某些不重要的功能
- 冪等性設(shè)計(jì)，方便失敗時(shí)重試
數(shù)據(jù)層的高可用
包括分布式文件系統(tǒng)與分布式數(shù)據(jù)庫(kù)，核心都是冗余加失效轉(zhuǎn)移。冗余（復(fù)制集、replica）需要解決的核心問題是一致性問題失效轉(zhuǎn)移操作由三部分組成: 失效確認(rèn)、訪問轉(zhuǎn)移、數(shù)據(jù)恢復(fù)。img上面描述了失效確認(rèn)的兩種方法：控制中心通過心跳檢測(cè)存儲(chǔ)服務(wù)器的存活性；應(yīng)用在訪問存儲(chǔ)服務(wù)失敗的時(shí)候通知控制中心檢測(cè)存儲(chǔ)服務(wù)存活性伸縮性（Scalability）網(wǎng)站的伸縮性是指不需要改變網(wǎng)站的軟硬件設(shè)計(jì)，僅僅通過改變部署的服務(wù)器數(shù)量就可以擴(kuò)大或者縮小網(wǎng)站的服務(wù)處理能力。應(yīng)用層的伸縮性
將應(yīng)用層設(shè)計(jì)成無(wú)狀態(tài)，即可利用集群 + 負(fù)載均衡來(lái)解決伸縮性問題。關(guān)于負(fù)載均衡，我之前也寫過一篇文章《關(guān)于負(fù)載均衡的一切：總結(jié)與思考》（http://www.cnblogs.com/xybaby/p/7867735.html）介紹。緩存的伸縮性
首先，緩存是有狀態(tài)的，分布式緩存服務(wù)器集群中不同服務(wù)器中緩存的數(shù)據(jù)各不相同，緩存訪問請(qǐng)求不可以在緩存服務(wù)器集群中的任意一臺(tái)處理，必須先找到緩存有需要數(shù)據(jù)的服務(wù)器，然后才能訪問。如果緩存訪問被路由到了沒有緩存相關(guān)數(shù)據(jù)的服務(wù)器，那么該訪問請(qǐng)求就會(huì)落地到數(shù)據(jù)庫(kù)，增加數(shù)據(jù)庫(kù)的壓力。因此，必須讓新上線的緩存服務(wù)器對(duì)整個(gè)分布式緩存集群影響最小，即緩存命中率越高越好。在這個(gè)場(chǎng)景下，最好的負(fù)載均衡算法就是一致性hash數(shù)據(jù)層的伸縮性
關(guān)系型數(shù)據(jù)庫(kù)，依賴于分布式數(shù)據(jù)庫(kù)代理。而NoSQL數(shù)據(jù)庫(kù)產(chǎn)品都放棄了關(guān)系數(shù)據(jù)庫(kù)的兩大重要基礎(chǔ): 以關(guān)系代數(shù)為基礎(chǔ)的結(jié)構(gòu)化查詢語(yǔ)言( SQL ) 和事務(wù)一致性保證( AClD )。而強(qiáng)化其他一些大型網(wǎng)站更關(guān)注的特性: 高可用性和可伸縮性。伸縮性總結(jié)：一個(gè)具有良好伸縮性架構(gòu)設(shè)計(jì)的網(wǎng)站，其設(shè)計(jì)總是走在業(yè)務(wù)發(fā)展的前面， 在業(yè)務(wù)需要處理更多訪問和服務(wù)之前，就已經(jīng)做好充足準(zhǔn)備， 當(dāng)業(yè)務(wù)需要時(shí)， 只需要購(gòu)買或者租用服務(wù)器簡(jiǎn)單部署實(shí)施就可以。可擴(kuò)展性（Extensibility）設(shè)計(jì)網(wǎng)站可擴(kuò)展架構(gòu)的核心思想是模塊化， 并在此基礎(chǔ)之上， 降低模塊間的耦合性，提高模塊的復(fù)用性。主要有分布式消息隊(duì)列和分布式服務(wù)。分布式消息隊(duì)列通過消息對(duì)象分解系統(tǒng)耦合性， 不同子系統(tǒng)處理同一個(gè)消息。分布式服務(wù)則通過接口分解系統(tǒng)輯合性， 不同子系統(tǒng)通過相同的接口描述進(jìn)行服務(wù)調(diào)用。分布式服務(wù)
縱向拆分：將一個(gè)大應(yīng)用拆分為多個(gè)小應(yīng)用， 如果新增業(yè)務(wù)較為獨(dú)立， 那么就直接將其設(shè)計(jì)部署為一個(gè)獨(dú)立的Web 應(yīng)用系統(tǒng)。橫向拆分: 將復(fù)用的業(yè)務(wù)拆分出來(lái)， 獨(dú)立部署為分布式服務(wù)， 新增業(yè)務(wù)只需要調(diào)用這些分布式服務(wù)， 不需要依賴具體的模塊代碼，即可快速搭建一個(gè)應(yīng)用系統(tǒng)， 而模塊內(nèi)業(yè)務(wù)邏輯變化的時(shí)候， 只要接口保持一致就不會(huì)影響業(yè)務(wù)程序和其他模塊。分布式服務(wù)依賴于分布式服務(wù)治理框架分布式服務(wù)治理框架
這一塊兒接觸甚少，還需要花點(diǎn)時(shí)間專門學(xué)習(xí)學(xué)習(xí)。img服務(wù)治理框架的功能和特點(diǎn)：- 服務(wù)注冊(cè)與發(fā)現(xiàn)
- 服務(wù)調(diào)用
- 負(fù)載均衡
- 失效轉(zhuǎn)移：分布式服務(wù)框架支持服務(wù)提供者的失效轉(zhuǎn)移機(jī)制， 當(dāng)某個(gè)服務(wù)實(shí)例不可用， 就將訪問切換到其他服務(wù)實(shí)例上，以實(shí)現(xiàn)服務(wù)整體高可用。
- 高效遠(yuǎn)程通信
- 整合異構(gòu)系統(tǒng)
- 對(duì)應(yīng)用最小侵入
- 版本管理：分布式服務(wù)框架需要支持服務(wù)多版本發(fā)布， 服務(wù)提供者先升級(jí)接口發(fā)布新版本的服務(wù)， 并同時(shí)提供舊版本的服務(wù)供請(qǐng)求者調(diào)用， 當(dāng)請(qǐng)求者調(diào)用接口升級(jí)后才可以關(guān)閉舊版本服務(wù)。
- 實(shí)時(shí)監(jiān)控
評(píng)論
圖片
表情