針對入門新手的普及，有過大型網站技術架構牛人路過，別耽誤浪費了時間，閱讀之前，請確保有一定的網路基礎，熟練使用Linux，瀏覽大概需要3 5分鐘的時間，結尾有彩蛋。 目錄 "分散式" "微服務" "負載均衡集群" "高可用集群" "彈性雲" "故障轉移" "總結" 分散式 小馬正在經營一個線上購物網 ...
針對入門新手的普及，有過大型網站技術架構牛人路過，別耽誤浪費了時間，閱讀之前，請確保有一定的網路基礎，熟練使用Linux，瀏覽大概需要3-5分鐘的時間，結尾有彩蛋。
目錄
分散式
小馬正在經營一個線上購物網站，名叫TT貓，有商品管理、訂單管理、用戶管理、支付管理、購物車等等模塊，每個模塊部署到獨立的雲服務主機。
現在，程式員小明同學瀏覽TT貓，想買一款牛逼的cherry機械鍵盤來提升自己的工作效率。小明打開TT貓首頁、搜索商品、瀏覽詳情以及評論、添加購物車、下單、支付等等一系列操作。小明同學一氣呵成，流暢的完成了購物，當然也花費了不少銀子。
但是系統又是如何對這一系列操作，如下圖錯綜複雜的調用關係(自行忽略部分細節)。用戶看不見，模不著，整個下單過程卻行走在網路之間。
TT貓把所有功能模塊分佈部署在不同的地方，最終完成了用戶一系列的請求，這大概就是一個分散式系統吧。
微服務
博主認為微服務是一種架構，也是在分散式範疇之內的。多微才叫微？在分散式系統中，微服務更加強調單一職責、輕量級通信（HTTP）、獨立性並且進程隔離。
好了，沒什麼好說的了，實踐出真知，建議大家多多瞭解 spring-cloud相關微服務組件。
TT貓，每年都會搞一些活動，比如女生最愛的光棍節(雙11)，夜深人靜的時候會瞬間涌入大量用戶，指不定就會把某個服務打趴下。
這時候，問題來了用戶下單超時，或者直接500錯誤，如何去解決？
負載均衡集群
這種事情怎麼可以在如此重要的活動中出現，其實馬爸爸提前購買了多台伺服器，工程師們已分別把各個業務功能模塊複製部署了多份。
每個相同功能的模塊，它們構成了一個組，並以單一系統的模式加以管理。當妹子進行下單操作時，實際上是跟一個集群組發生關係，但系統會確保只跟其中一個發生了關係，具體跟誰，集群組有自己的調度演算法，不要擔心跟妹子發生不了關係。
舉個古代猥瑣而不淫蕩的例子吧，如果你生活在古代，年18，未婚，高富帥，急需解決個人生理問題。故，你來到了傳說中的青樓，咳咳，這個古代可以合法的。這時候老鴇或者大茶壺過來招呼你了，如果沒有特殊要求，你會被帶進一個屋裡，裡面有個風塵女子......
畫風一轉，有沒有閃瞎自己的程式員萬年鈦合金狗眼。你可以這麼理解，老鴇就是負載均衡器，內置調度演算法，風塵女子就是集組其中的一個。
好了，言歸正傳，省略號自行腦補，小伙伴們看到這裡可能會問了，平時生產環境中我們都用什麼做負載均衡器。
- 財大氣粗的用硬體F5
- 不差錢的使用DNS負載均衡
- 技術牛逼的用LVS
- 苦逼的創業型小公司只能使用Nginx
當然，負載均衡器不止以上幾種，有興趣的同學自行谷歌瞭解。
《論知行》篇中說：知其然知其所以然，簡單說下這幾種負載均衡器到底是如何行走於網路中的吧，學過網路的朋友大概都清楚七層網路模型。
首先一張圖，讓大家重溫一下大學基礎課程。
有沒有瞬間課堂書本的感覺，不過癮？再來一張TCP/IP五層模型。
在每一層都工作著不同的設備，比如財大氣粗，不差錢的國企使用的F5工作在4-7層，一般互聯網企業使用的LVS工作在傳輸層，使用最廣泛的Nginx工作在應用層。
最後來聊一下DNS負載均衡，雖然DNS最原始也是最簡單的方法，但是DNS負載均衡的控制權在功能變數名稱服務商手裡，NDS存在多級解決，緩存A記錄的問題，以及網站自身無法做更多的管理。這樣導致了一般中小公司很少使用。
當然，自身實力夠硬，DNS負載均衡也是個不錯的選擇。下圖是檢測TT貓功能變數名稱的A記錄得到的部分信息，僅供參考，自行領悟。
高可用集群
既然是集群，就不能夠出現單點故障，如果大家關註雲服務，可能會接觸到以下辭彙，“雙機熱備”，“兩地三中心”等等辭彙。
雙擊熱備是高可用的一種體現形式，如上圖所示，生產環境中我們存在兩個負載均衡節點，主節點處於激活狀態，另一個節點處於備用狀態，當主節點意外宕機，可以通過keepalived檢測並迅速切換到備用服務，保障業務正常運轉。
至於兩地三中心，下圖可能會讓大家理解的更加透徹，圖片源於網路。
彈性雲
小馬哥為了準備雙十一，購置了大量伺服器，但是活動一過，平時的用戶訪問量並不能滿足伺服器的接客能力，導致大量伺服器處於空窗期。
這還了得，不能閑著啊，精明的小馬哥一拍腦袋，組建了TT雲團隊。通過多年的努力開發了按量付費雲、彈性IP、共用帶寬等等產品為中小企業開源節流。
故障轉移
小明同學覺得這款鍵盤不錯，美滋滋的點擊購買按鈕，突然跳到了登陸頁面。
什麼鬼，褲子我都脫了，你就給我看這個？普通用戶可能不會覺得有什麼問題，重新登陸一次就是了。但是小明作為一隻嚴謹的程式猿，他想弄明白其中到底發生了什麼。
經過仔細的查閱資料分析，小明得出了以下結論：
發生以上故障，小明以為自己下單的那台服務掛機了，請求被分發到另一臺服務上，但為什麼會跳到登陸頁面呢？作為一名程式員，小明清楚的知道服務分為有狀態和無狀態的，儘管我們平時的HTTP請求是無狀態的，但是一般會通過cookie或者session來確定用戶狀態。
到這裡，各位看官應該明白到底是個什麼鬼了吧。就拿我們比較熟悉的Tomcat來說，我們的用戶信息一般存儲在session中，而session存儲在Tomcat記憶體中。瀏覽器通過cookie中的JSESSIONID來與伺服器進行認證。
然伺服器掛了，下單請求被分發到另一臺服務，自然小明再也找不到他的session了。
小明同學把問題反饋給了TT貓，小馬哥一看這還得了，集群都做了還差這點，於是趕緊叫工程師們拿出解決方案。
工程師最終提出了兩種方案：
- 伺服器用戶狀態複製(成本大，需要軟硬體支持，有延遲，存在失敗的風險)
- 統一存儲用戶狀態(我不說話，我就笑笑)
最終，工程師們採用第二種方案，使用Redis存儲用戶狀態數據。
