三分鐘讀懂TT貓分佈式、微服務和集羣之路

針對新手入門的普及，有過大型網站技術架構牛人路過，別耽誤浪費了時間，閱讀以前，請確保有必定的網絡基礎，熟練使用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存儲用戶狀態數據。

知識補充

最近接觸並使用了阿里雲的負載均衡SLB ，大致瞭解了一下TT貓的負載均衡實現，如下架構實現源於TT貓。

負載均衡採用集羣部署，可實現會話同步，以消除服務器單點故障，提高冗餘，保證服務的穩定性。阿里雲當前提供四層（TCP協議和UDP協議）和七層（HTTP和HTTPS協議）的負載均衡服務。

• 四層採用開源軟件LVS（Linux Virtual Server）+ keepalived的方式實現負載均衡。

• 七層採用Tengine實現負載均衡。

以下圖所示，各個地域的四層負載均衡其實是由多臺LVS機器部署成一個LVS集羣來運行的。採用集羣部署模式極大地保證了異常狀況下負載均衡服務的可用性、穩定性與可擴展性。

LVS集羣內的每臺LVS都會進行會話，經過組播報文同步到該集羣內的其它LVS機器上，從而實現LVS集羣內各臺機器間的會話同步。以下圖所示，當客戶端向服務端傳輸三個數據包後，在LVS1上創建的會話A開始同步到其它LVS機器上。圖中實線表示現有的鏈接，圖中虛線表示當LVS1出現故障或進行維護時，這部分流量會走到一臺能夠正常運行的機器LVS2上。於是負載均衡集羣支持熱升級，而且在機器故障和集羣維護時最大程度對用戶透明，不影響用戶業務。

總結


若是您對這篇總結感興趣請 回覆

感謝小編厚愛和各位博友的推薦，這篇文章包括配圖也是花了近一下午的時間才搞定的，因爲自身認知的侷限性，可能有些地方並不能知足各位看官，還請見諒。

之後TT貓系列會以更加通俗易懂的風格展現給你們，感謝，同時我也不該該"騙"你們，後面的總結回覆也是本身抖了個小機靈，然而博客園把彈出層屏蔽了。

三分鐘深刻TT貓之故障轉移：http://www.cnblogs.com/smallSevens/p/7535139.html