互聯網架構主要解決的問題
- 高併發
- 海量數據
什麼是分佈式
從上圖可以看出，要想實現分佈式，必須解決兩個問題：
- 任務分解
- 結點通信
分佈式和集羣的關係
分佈式：一個業務拆分爲多個子業務，部署在不同的服務器上
集羣：同一個業務，部署在多個服務器上
注意：如果將多個子系統部署在同一服務器上，在網絡層面來講，就不能稱爲分佈式
發展歷史
計算機的發展歷史
- 1946年情人節第一臺電子數字計算機，在美國賓夕法尼亞大學誕生，可以進行每秒五千次的加法運算，由美國人莫克利發明
- 1964年，大型機 IBM SYSTEM/360 被髮明，具有超強的計算能力和可靠性。當時通常用於金融、政府。大型主機的出現，引領了軟件朝集中式發展
- 大型主機後，計算機共有兩條發展趨勢：
- x86 CPU 朝個人PC機發展
- RISC CPU 朝小型機發展
大型機時代，軟件往集中式發展，成爲當時軟件架構的主流。
分佈式架構的發展歷史
- PC機的性能不斷提升，給分佈式提供了條件
- 企業開始去 IOE 運動： IBM小型機、Oracle、EMC存儲設備
- 2013年5月17日，最後一臺IBM小型機下線
淘寶大約在08年開始去IOE，將其架構替換爲: PC機、MySql、SSD硬盤和Fusion-IO
架構演變
單機計算機的架構->分佈式計算機架構
馮諾依曼模型：運算器、控制器、存儲器、輸入設備、輸出設備
計算機架構也可以映射爲分佈式架構：
- 存儲器：數據庫、緩存
- 運算器：業務員邏輯、程序
- 控制器：硬負載、軟負載
- 輸入設備/輸出設備：用戶界面
- 數據流/指令流/控制流：RPC調用、消息
分佈式架構演變過程
一個公司的架構在一開始一定不是最完美的，也沒有一開始就具備高性能、高併發、高可用、安全性等特性，而是隨着用戶量的增加、業務功能的擴展逐步演變過來的，慢慢的完善的
第一階段 單應用架構
描述：網站初期，在一臺服務器上運行所有的軟件，搭建過程效率極高
第二階段 應用服務器與數據服務器分離
隨着負載的提高，單機服務器性能已經無法滿足網站的運行，此時可以對將應用服務器與數據服務器分離，既提高了負載能力，又提高了系統的容災能力
描述：應用服務器與數據服務器完全分離，相互不影響，大大減少網站宕機的風險
第三階段 應用服務器集羣
隨着訪問量的不斷增加，單臺應用服務器不再能滿足我們的需求，可以通過增加應用服務器的方式對用戶請求進行分流，從而提升系統的負載能力
發展到上面的架構，各種問題也就出現：
- 用戶請求如何轉發到具體的應用服務器上
- 如果每次訪問到服務器不同，如何維護session信息，如何進行session共享
負載問題解決：
- 硬件負載均衡器，F5，完善，可以解決session共享的問題，但是比較昂貴
- 軟負載均衡
Session跨域共享問題解決：
- session sticky， 保證請求落在同一臺服務器上
- session replication， session複製，早期常用的解決方案，每臺服務器上都保存session，會造成session網絡同步開銷，佔用空間更大
- session集中存儲，存儲在DB或者緩存（redis）中
- cookie ，無需在服務器上保存會話信息，將會話信息保存在cookie中，一般時access_token(userid/token/timstamp)，access_token需要進行ip驗證，防止access_token被截獲，造成安全問題
爲了解決上述問題，架構就變成了如下：
第四階段 數據服務器讀寫分離
如何提高數據庫的性能？如果單純的部署兩臺數據庫，然後負載到不同的數據庫上，一定會造成數據不一致的情況，又因爲網站中百分之八十大都是讀請求，所以我們可以考慮對數據庫進行讀寫分離。
上面的架構引入了兩個新的問題？
- 如何進行讀寫分離？答：mysql提供了master/slave模式
- 應用層如何對數據源選擇？答：使用第三方數據庫中間件，比如mycat
第五階段 引入搜索引擎
用戶頻繁的搜索導致度數據庫壓力繼續增大，使用 sql like搜索效率極低，此時開始引入搜索引擎集羣，搜索操作都會經過搜索引擎，大大減緩了讀庫的壓力。
問題：搜索引擎索引數據如何同步，是實時增量同步？還是定時全量同步？
第六階段 引入緩存技術，減緩數據庫壓力
第七階段 數據庫水平/垂直拆分
用戶多，隨着數據量的增大，數據庫的瓶頸又重新展現出來，此時可以對數據庫進行水平拆分和垂直拆分。
- 垂直拆分：將數據庫不同業務數據拆分到不同的數據庫中
- 水平拆分：將同一表中數據拆分到兩個甚至更多的數據庫中，水平拆分的原因是某些業務數據量已經達到了單個數據庫的瓶頸，這時可以採取將表拆分到多個數據庫中
第八階段 應用拆分
當業務越來越大，應用服務器壓力越來越大時，工程規模也越來越大，我們可以考慮應用拆分，將業務拆分爲多個子系統
上述應用拆分後，雖然進行了模塊拆分，但是如果要在交易信息中查詢用戶信息，並不是通過調用用戶模塊的功能實現的，而實直接在內部使用sql查詢用戶信息，所以每個系統都會有查詢用戶的sql，如果用戶表結構發生變化，所有子系統都會進行修改，所以需要對用戶進行服務抽離：
