微服務是架構設計方式，分佈式是系統部署方式程序員
概念
微服務web
簡單來講微服務就是很小的服務，小到一個服務只對應一個單一的功能，只作一件事。這個服務能夠單獨部署運行，服務之間能夠經過RPC來相互交互，每一個微服務都是由獨立的小團隊開發，測試，部署，上線，負責它的整個生命週期。算法
微服務架構瀏覽器
在作架構設計的時候，先作邏輯架構，再作物理架構，當你拿到需求後，估算過最大用戶量和併發量後，計算單個應用服務器可否知足需求，若是用戶量只有幾百人的小應用，單體應用就能搞定，即全部應用部署在一個應用服務器裏，若是是很大用戶量，且某些功能會被頻繁訪問，或者某些功能計算量很大，建議將應用拆解爲多個子系統，各自負責各自功能，這就是微服務架構。緩存
分佈式服務器
分佈式服務顧名思義服務是分散部署在不一樣的機器上，一個服務可能負責幾個功能，是一種面向SOA架構的，服務之間也是經過rpc來交互或者是webservice來交互的。cookie
邏輯架構設計完後就該作物理架構設計，系統應用部署在超過一臺服務器或虛擬機上，且各分開部署的部分彼此經過各類通信協議交互信息，就可算做分佈式部署，生產環境下的微服務確定是分佈式部署的，分佈式部署的應用不必定是微服務架構的，好比集羣部署，它是把相同應用複製到不一樣服務器上，可是邏輯功能上仍是單體應用。
微服務相比分佈式服務來講，它的粒度更小，服務之間耦合度更低，因爲每一個微服務都由獨立的小團隊負責，所以它敏捷性更高，分佈式服務最後都會向微服務架構演化，這是一種趨勢， 不過服務微服務化後帶來的挑戰也是顯而易見的，例如服務粒度小，數量大，後期運維將會很難.
網絡
示例講解
分佈式session
小馬正在經營一個在線購物網站，名叫TT貓，有商品管理、訂單管理、用戶管理、支付管理、購物車等模塊，每一個模塊部署到獨立的雲服務主機。架構
如今，程序員小明同窗瀏覽TT貓，想買一款牛逼的cherry機械鍵盤來提高本身的工做效率。因而他打開TT貓首頁、搜索商品、瀏覽詳情以及評論、添加購物車、下單、支付等一系列操做。小明同窗一鼓作氣，流暢地完成了購物，固然也花費了很多銀子。
但系統又是如何進行這一系列操做，以下圖錯綜複雜的調用關係(自行忽略部分細節)。用戶看不見、摸不着，但整個下單過程卻行走在網絡之間。
集羣
TT貓，每一年都會搞一些活動，好比女生最愛的光棍節(雙11)，夜深人靜的時候會瞬間涌入大量用戶，指不定就會把某個服務打趴下。
這時候，問題來了用戶下單超時，或者直接500錯誤，如何去解決?
負載均衡集羣
這種事情怎麼能夠在如此重要的活動中出現?其實馬爸爸提早購買了多臺服務器，工程師們已分別把各個業務功能模塊複製部署了多份。
每一個相同功能的模塊，它們構成了一個組，並以單一系統的模式加以管理。當妹子進行下單操做時，其實是跟一個集羣組發生關係，但系統會確保只跟其中一個發生了關係，具體跟誰，集羣組有本身的調度算法，不要擔憂跟妹子發生不了關係。
高可用集羣
既然是集羣，就不可以出現單點故障，若是你們關注雲服務，可能會接觸到如下詞彙，「雙機熱備」，「兩地三中心」等等詞彙。
雙機熱備是高可用的一種體現形式，如上圖所示，生產環境中咱們存在兩個負載均衡節點，主節點處於激活狀態，另外一個節點處於備用狀態，當主節點意外宕機，能夠經過keepalived檢測並迅速切換到備用服務，保障業務正常運轉。
至於兩地三中心，下圖可能會讓你們理解得更加透徹，圖片源於網絡。
擴展：負載均衡
負載均衡器
生產環境中咱們都用什麼作負載均衡器?
財大氣粗的用硬件F5
不差錢的使用DNS負載均衡
技術牛逼的用LVS
苦逼的創業型小公司只能使用Nginx
固然，負載均衡器不止以上幾種，有興趣的同窗自行谷歌瞭解。
七層網絡模型：
TCP/IP五層模型
DNS負載均衡
DNS負載均衡的控制權在域名服務商手裏，NDS存在多級解析，緩存A記錄的問題，以及網站自身沒法作更多的管理。這樣致使了通常中小公司不多使用。
自身實力夠硬，DNS負載均衡也是個不錯的選擇。下圖是檢測TT貓域名的A記錄獲得的部分信息，僅供參考。
彈性雲
小馬哥爲了準備雙十一，購置了大量服務器，但活動一過，平時的用戶訪問量並不能知足服務器的接客能力，致使大量服務器處於空窗期。
這還了得，不能閒着啊，精明的小馬哥一拍腦殼，組建了TT雲團隊。經過多年的努力開發了按量付費雲、彈性IP、共享帶寬等等產品爲中小企業開源節流。
ps:雲計算相關概念（基礎設施（infrastructure）、平臺（platform）和軟件（software））
故障轉移
小明同窗以爲這款鍵盤不錯，美滋滋的點擊購買按鈕，忽然跳到了登錄頁面。
什麼鬼，褲子我都脫了，你就給我看這個?普通用戶可能不會以爲有什麼問題，從新登錄一次就是了。但小明做爲一隻嚴謹的程序猿，他想弄明白其中到底發生了什麼。
通過仔細的查閱資料分析，小明得出瞭如下結論：
發生以上故障，小明覺得本身下單的那臺服務掛機了，請求被分發到另外一臺服務上，但爲何會跳到登錄頁面呢?做爲一名程序員，小明清楚的知道服務分爲有狀態和無狀態的，儘管咱們平時的HTTP請求是無狀態的，可是通常會經過cookie或者session來肯定用戶狀態。
到這裏，各位看官應該明白究竟是個什麼鬼了吧。就拿咱們比較熟悉的Tomcat來講，咱們的用戶信息通常存儲在session中，而session存儲在Tomcat內存中。瀏覽器經過cookie中的JSESSIONID來與服務器進行認證。
然而服務器掛了，下單請求被分發到另外一臺服務，天然小明再也找不到他的session了。
小明同窗把問題反饋給了TT貓，小馬哥一看這還得了，集羣都作了還差這點，因而趕忙叫工程師們拿出解決方案。
工程師最終提出了兩種方案：
服務器用戶狀態複製(成本大，須要軟硬件支持，有延遲，存在失敗的風險)
統一存儲用戶狀態(我不說話，我就笑笑)
最終，工程師們採用第二種方案，使用Redis存儲用戶狀態數據。
TT貓的負載均衡實現：參考下面文章相關部分
參考文章