微服務是一種架構，也是在分布式範疇之内的。多微才叫微?在分布式系統中，微服務更加強調單一職責、輕量級通信(HTTP)、獨立性并且進程隔離。好了，沒什麼好說的了，實踐出真知，建議大家多多了解 Spring-Cloud相關微服務組件。

一、分布式

小馬正在經營一個在線購物網站，名叫TT貓，有商品管理、訂單管理、用戶管理、支付管理、購物車等模塊，每個模塊部署到獨立的雲服務主機。

現在，程序員小明同學浏覽TT貓，想買一款牛逼的cherry機械鍵盤來提升自己的工作效率。于是他打開TT貓首頁、搜索商品、浏覽詳情以及評論、添加購物車、下單、支付等一系列操作。小明同學一氣呵成，流暢地完成了購物，當然也花費了不少銀子。

但系統又是如何進行這一系列操作，如下圖錯綜複雜的調用關系(自行忽略部分細節)。用戶看不見、摸不着，但整個下單過程卻行走在網絡之間。

圖 1 分布式釋義

TT貓把所有功能模塊分布部署在不同的地方，最終完成了用戶一系列的請求，這大概就是一個分布式系統吧。

二、微服務

博主認為微服務是一種架構，也是在分布式範疇之内的。多微才叫微?在分布式系統中，微服務更加強調單一職責、輕量級通信(HTTP)、獨立性并且進程隔離。好了，沒什麼好說的了，實踐出真知，建議大家多多了解 Spring-Cloud相關微服務組件。

TT貓，每年都會搞一些活動，比如女生最愛的光棍節(雙11)，夜深人靜的時候會瞬間湧入大量用戶，指不定就會把某個服務打趴下。

這時候，問題來了用戶下單超時，或者直接500錯誤，如何去解決?

圖2 TT貓罷工

三、負載均衡集群

這種事情怎麼可以在如此重要的活動中出現?其實馬爸爸提前購買了多台服務器，工程師們已分别把各個業務功能模塊複制部署了多份。

每個相同功能的模塊，它們構成了一個組，并以單一系統的模式加以管理。當妹子進行下單操作時，實際上是跟一個集群組發生關系，但系統會确保隻跟其中一個發生了關系，具體跟誰，集群組有自己的調度算法，不要擔心跟妹子發生不了關系。

圖3 負載均衡調度

舉個古代猥瑣而不淫蕩的例子吧，如果你生活在古代，年18，未婚，高富帥，急需解決個人生理問題。故，你來到了傳說中的風月場，咳咳，這個古代可是合法的。這時候老鸨或者大茶壺過來招呼你了，如果沒有特殊要求，你會被帶進一個屋裡，裡面有個風塵女子......

畫風一轉，有沒有閃瞎自己的程序員萬年钛合金狗眼。你可以這麼理解，老鸨就是負載均衡器，内置調度算法，風塵女子就是集組其中的一個。

圖4 花好月圓

好了，言歸正傳，省略号自行腦補，小夥伴們看到這裡可能會問了，平時生産環境中我們都用什麼做負載均衡器?

财大氣粗的用硬件F5

财大氣粗的用硬件F5

不差錢的使用DNS負載均衡

技術牛逼的用LVS

苦逼的創業型小公司隻能使用Nginx

當然，負載均衡器不止以上幾種，有興趣的同學自行谷歌了解。

《論知行》篇中說：知其然知其所以然，簡單說下這幾種負載均衡器到底是如何行走于網絡中的吧，學過網絡的朋友大概都清楚七層網絡模型。

首先一張圖，讓大家重溫一下大學基礎課程。

首先一張圖，讓大家重溫一下大學基礎課程。

有沒有瞬間課堂書本的感覺，不過瘾?再來一張TCP/IP五層模型。

在每一層都工作着不同的設備，比如财大氣粗，不差錢的國企使用的F5工作在4-7層，一般互聯網企業使用的LVS工作在傳輸層，使用最廣泛的Nginx工作在應用層。

圖5

最後來聊一下DNS負載均衡，雖然DNS最原始也是最簡單的方法，但是DNS負載均衡的控制權在域名服務商手裡，NDS存在多級解析，緩存A記錄的問題，以及網站自身無法做更多的管理。這樣導緻了一般中小公司很少使用。

當然，自身實力夠硬，DNS負載均衡也是個不錯的選擇。下圖是檢測TT貓域名的A記錄得到的部分信息，僅供參考，自行領悟。

圖7

四、高可用集群

圖 高可用集群

既然是集群，就不能夠出現單點故障，如果大家關注雲服務，可能會接觸到以下詞彙，“雙機熱備”，“兩地三中心”等等詞彙。

雙機熱備是高可用的一種體現形式，如上圖所示，生産環境中我們存在兩個負載均衡節點，主節點處于激活狀态，另一個節點處于備用狀态，當主節點意外宕機，可以通過keepalived檢測并迅速切換到備用服務，保障業務正常運轉。至于兩地三中心，下圖可能會讓大家理解得更加透徹，圖片源于網絡。

圖8

五、彈性雲

小馬哥為了準備雙十一，購置了大量服務器，但活動一過，平時的用戶訪問量并不能滿足服務器的接客能力，導緻大量服務器處于空窗期。

這還了得，不能閑着啊，精明的小馬哥一拍腦袋，組建了TT雲團隊。通過多年的努力開發了按量付費雲、彈性IP、共享帶寬等等産品為中小企業開源節流。

六、故障轉移

圖9 故障轉移

小明同學覺得這款鍵盤不錯，美滋滋的點擊購買按鈕，突然跳到了登陸頁面。

圖10

什麼鬼，褲子我都脫了，你就給我看這個?普通用戶可能不會覺得有什麼問題，重新登陸一次就是了。但小明作為一隻嚴謹的程序猿，他想弄明白其中到底發生了什麼。

經過仔細的查閱資料分析，小明得出了以下結論：

發生以上故障，小明以為自己下單的那台服務挂機了，請求被分發到另一台服務上，但為什麼會跳到登陸頁面呢?作為一名程序員，小明清楚的知道服務分為有狀态和無狀态的，盡管我們平時的HTTP請求是無狀态的，但是一般會通過cookie或者session來确定用戶狀态。

到這裡，各位看官應該明白到底是個什麼鬼了吧。就拿我們比較熟悉的Tomcat來說，我們的用戶信息一般存儲在session中，而session存儲在Tomcat内存中。浏覽器通過cookie中的JSESSIONID來與服務器進行認證。

然而服務器挂了，下單請求被分發到另一台服務，自然小明再也找不到他的session了。

小明同學把問題反饋給了TT貓，小馬哥一看這還得了，集群都做了還差這點，于是趕緊叫工程師們拿出解決方案。

工程師最終提出了兩種方案：

服務器用戶狀态複制(成本大，需要軟硬件支持，有延遲，存在失敗的風險)

統一存儲用戶狀态(我不說話，我就笑笑)

圖11

最終，工程師們采用第二種方案，使用Redis存儲用戶狀态數據。

知識補充

最近接觸并使用了阿裡雲的負載均衡SLB ，大體了解了一下TT貓的負載均衡實現，以下架構實現源于TT貓。

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

四層采用開源軟件LVS(Linux Virtual Server) keepalived的方式實現負載均衡。

七層采用Tengine實現負載均衡。

圖12

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

圖13

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

圖14