讀書筆記之《大型分佈式網站架構設計與實踐》

    分佈式系統的設計，涉及通訊協議、遠程調用、服務治理、系統安全、存儲、搜索、監控、穩定性保障、性能優化、數據分析、數據挖掘等各個領域。這本書做者結合淘寶網的實際工做經歷，重點介紹大型分佈式系統的架構設計。寫的時間比較早了，知識點相對來講全面，可是不夠深刻，架構思想仍是很值得學習的。

1、面向服務的體系架構(SOA)

本章主要介紹和解決下面問題：
HTTP協議的工做方式與HTTP網絡協議棧的結構？
如何實現基於HTTP協議和TCP協議的RPC調用，它們之間有何差異，分別適用何種場景？
如何實現服務的動態註冊和路由，以及軟負載均衡的實現？

一、基於TCP協議的RPC（TCP傳輸層）

    RPC即遠程過程調用。單臺服務器的處理能力受硬件成本的限制，不可能無限制地提高。RPC將原來的本地調用轉變爲調用遠端的服務器上的方法，給系統的處理能力和吞吐量帶來了近似於無限提高的可能。RPC的實現包括客戶端和服務端，即服務的調用方和服務的提供方。服務調用方發送RPC請求到服務提供方，服務提供方根據調用方提供的參數執行請求方法，將執行結果返回給調用方，一次RPC調用完成。
    服務調用者的規模發展到必定階段，對服務提供方的壓力也日益增長，那麼服務就須要擴容。隨着服務提供者的增長和業務的發展，不一樣的服務之間須要進行分組，以隔離不一樣的業務，這樣，就須要考慮服務的路由和負載均衡的問題。若是服務提供者爲一個集羣，那麼服務消費者經過獲取服務提供者的分組信息和地址信息進行路由，根據相應的負載均衡策略，選取其中一臺進行調用。

    無論哪一種類型的數據，最終都須要轉換成二進制流在網絡上進行傳輸。數據的發送方須要將對象轉換成爲二進制流(對象的序列化)，才能在網絡上進行傳輸。數據的接收方須要將二進制流再恢復成對象(對象的反序列化)。

二、基於HTTP協議的RPC(HTTP應用層)

    HTTP超文本傳輸協議，屬於應用層協議，構建在TCP和IP協議之上，處於TCP/IP體系架構中的頂端。

web瀏覽器和web服務器之間的一次HTTP請求與響應過程，須要完成的步驟以下(例如：http://www.google.com:80/index.html)：
(1)瀏覽器端根據所使用的HTTP協議，解析出url對應的域名 -> www.google.com
(2)經過DNS域名解析，查詢出該域名對應的IP地址 -> 74.125.31.147
(3)經過url解析出對應的端口號(若是是80端口，默承認以省略) -> 80
(4)瀏覽器發起並創建到74.125.31.147的80端口的鏈接
(5)瀏覽器向服務器發送get請求
(6)服務器響應瀏覽器的請求，瀏覽器讀取響應，渲染網頁
(7)瀏覽器關閉與服務器的鏈接

基於TCP協議實現的RPC，因爲位於協議棧的下層，可以更靈活的對協議字段進行定製、減小網路傳輸字節數等，可是較難實現跨平臺的調用。
基於HTTP協議的RPC實現可使用JSON或者XML格式的響應數據，通用，跨平臺。可是HTTP是上層協議，發送同等內容的信息，使用HTTP傳輸所佔用的字節數比使用TCP協議傳輸所佔用的字節數更多，那麼在同等網絡環境下，經過HTTP協議傳輸相同內容，效率要低於TCP協議。固然，有其餘方式縮小這一差距。

三、服務的路由和負載均衡

    服務消費者經過服務名稱，在衆多服務中找到要調用的服務的地址列表，稱爲服務的路由；對於負載較高的服務來講，每每對應着多臺服務器組成的集羣，那麼請求到來時，爲了將請求均衡地分配到後端服務器，負載均衡程序將從服務對應的地址列表中，經過相應的負載均衡算法和規則，選取一臺服務器進行訪問，這個過程稱爲服務的負載均衡。

當服務愈來愈多，規模愈來愈大，對應的機器數量也愈來愈大，一旦服務路由或者負載均衡服務器宕機，依賴它的全部服務均將失效。那麼就須要一個可以動態註冊和獲取服務信息的地方，來統一管理服務名稱和其對應的服務器列表信息，稱之爲服務配置中心。當服務器宕機或者下線時，相應的機器須要可以動態地從服務配置中內心面移除，而且通知相應的消費者。

(1)負載均衡算法

<>輪詢法：將請求按照順序輪流的分配到後端服務器上，它均衡地對待後端每一臺服務器，而不關心服務器實際的鏈接數和當前的系統負載。

<>隨機法：經過系統隨機函數，根據後端服務器列表的大小值來隨機選取其中一臺進行訪問。

<>源地址哈希法：獲取客戶端訪問的IP地址值，經過哈希函數計算獲得一個數值，用該數值對服務器列表的大小進行取模運算，獲得的結果即是要訪問的服務器的序號。

<>加權輪詢法：給配置高、負載低的機器配置更高的權重，讓其處理更多的請求，而配置低、負載高的機器，給其分配較低的權重，下降其系統負載。請求順序的且按照權重分配給後端。

<>加權隨機法：根據後端服務器不一樣的配置和負載狀況，配置不一樣的權重。按照權重來隨機選取服務器，而不是按照順序。

<>最小鏈接數法：因爲後端服務器的配置不盡相同，對於請求的處理有快又慢，根據後端服務器當前的鏈接狀況，動態的選取其中當前積壓鏈接數最少的一臺服務器來處理當前請求，儘量地提升後端服務器的利用率，將負載合理的分流到每一臺服務器。

四、HTTP服務網關

    網關接收外部的各類HTTP請求，完成相應的權限和安全校驗，當校驗經過後，根據傳入的服務名稱，到服務配置中心找到相應的服務名稱節點。網關能夠很好的解決安全問題，也能夠經過服務名稱進行服務的路由和負載均衡調度，使得不一樣的平臺之間可以很好地複用公共的業務邏輯。

2、分佈式系統基礎設施

    分佈式系統基礎設施：分佈式緩存系統、持久化存儲、分佈式消息系統、搜索引擎、CDN系統、負載均衡系統、運維自動化系統、實時計算系統、分佈式文件系統、日誌收集系統、監控系統、數倉系統等。

一、分佈式緩存

這一小節講的memcache，略過吧。

二、持久化緩存

(1)Mysql擴展

業務拆分 -> 隨着業務的發展，單個庫的訪問量愈來愈大，對業務進行拆分，每一塊業務使用單獨的數據庫存儲。這樣訪問不一樣的業務就訪問到了不一樣的數據庫，提升了吞吐能力。

複製策略 -> 業務繼續發展，訪問量繼續加大，拆分後的每一個庫壓力愈來愈大，可使用MySQL的複製策略來對系統擴展。經過複製策略，能夠將一臺MySQL數據庫服務器中的數據複製到其餘MySQL數據庫服務器上，當各臺數據庫服務器上包含相同數據時，訪問MySQL集羣中任意一臺服務器，都能取到相同的數據。要實現數據庫的複製，須要開啓Master服務器端的Binary log，複製的過程實際上就是Slave從master獲取binary log，而後再在本地鏡像的執行日誌中記錄的操做。因爲複製過程是異步的，所以Master和Slave之間數據可能存在延遲的現象，
此時只可以保證數據最終一致性。

分庫與分表 -> 採用Master-Slave複製模式的MySQL架構，只可以對數據庫的讀進行擴展，而對數據庫的寫入操做仍是集中於Master上，且單個Master掛載的Slave不可能無限多。對於訪問頻繁且數據量巨大的單表來講，分表。分表可以解決單表數據量過大帶來的查詢效率降低的問題，可是沒法給數據庫的併發處理能力帶來質的提高。面對高併發的讀寫訪問，當數據庫Master服務器沒法承載寫操做壓力時，擴展Slave服務器就沒啥意義了。所以，須要對數據庫進行拆分，提升數據庫寫入能力，即分庫。

數據庫通過業務拆分及分庫分表後，查詢性能和併發處理能力提升了，但會帶來其餘問題。例如：本來跨表的事務上升爲分佈式事務，記錄被切分到不一樣的庫和不一樣的表中，難以進行多表關聯查詢。分庫分表之後，若是須要對系統進一步擴容，講很是不方便，須要從新進行數據遷移。

(2)HBase

略過

(3)Redis

略過，推薦看《Redis開發與運維》

三、消息系統

消息能夠做爲應用間通訊的一種方式，消息被保存在隊列中，直到被接收者取出，消息發送者不須要同步等待消息接收者的響應，消息的異步接收下降了系統集成的耦合度，提高了分佈式系統協做的效率。當系統處於峯值壓力時，分佈式消息隊列還可以做爲緩衝，削峯填谷。書中介紹的ActiveMQ，這裏略過，後面專門分析實際項目中用的RocketMQ。

四、垂直化搜索引擎

垂直化的搜索引擎主要針對企業內部的自有數據檢索，不像Google、Baidu那樣的搜索引擎平臺，採用網絡爬蟲對全網數據進行抓取，從而
創建索引並提供給用戶進行檢索。在分佈式系統中，垂直化的搜索引擎可以知足用戶對全文檢索、模糊匹配的需求，解決數據庫like查詢效率低下的問題，又可以解決分佈式環境下，因爲採用分庫分表或者NoSQL數據庫，致使沒法進行多表關聯或者進行復雜查詢的問題。

(1)Lucene

倒排索引：也稱反向索引，它將文檔中的詞做爲關鍵字，創建詞與文檔的映射關係，能夠根據詞快速獲取包含這個詞的文檔列表。
分詞：也稱爲切詞，將句子或者段落進行切割，從中提取出包含固定語義的詞。

(2)Solr

略過。

3、互聯網安全架構

安全、密碼學內容，跳過。

4、系統穩定性

一、在線日誌分析

cat：顯示文本文件內容，若是日誌文件比較大，不要用cat命令。
more：相似cat，不過會以一頁一頁的形式顯示，更方便使用者逐頁閱讀。
less：比more更豐富，支持內容查找，高亮顯示。
tail：查看文件的最後幾行，後面 -n參數後面跟數字表示顯示文件的最後幾行， -f 參數表示讓tail不退出，而且持續地顯示文件新增長的行。
head：與tail相似，顯示文件開頭的幾行。
grep：查找文件中符合條件的字符串，找到符合的，會把該行打印出來。
find：查找文件路徑，好比 find /home -name a.log 在/home路徑下查找文件名爲a.log的文件。

二、集羣監控

三、流量控制

分清核心鏈路和非核心鏈路，系統出現問題或者故障時，及時進行服務降級，避免因非核心依賴致使的故障傳導，影響當前服務的穩定性。

四、性能優化

性能優化涉及前端優化、服務端優化、操做系統優化、數據庫查詢優化、JVM調優等。

五、Java應用故障的排查

5、數據分析

本章主要都是一些日誌收集框架和大數據處理框架的介紹，沒啥乾貨，略了吧。

至此，完結。