微服務架構(gòu)是業(yè)界非常流行的分布式服務治理方案，解決了原來多個服務之間通過rpc框架進行調(diào)用和通信的問題。是業(yè)務從單體架構(gòu)發(fā)展到集群架構(gòu)，再到配備多種服務的集群組織。它帶來的好處是

1 將業(yè)務拆分成多個微服務，提高業(yè)務之間的隔離性，增強系統(tǒng)面對高并發(fā)大流量時的穩(wěn)定性。系統(tǒng)各個模塊的拆分，保證了各個模塊的穩(wěn)定性，可以讓業(yè)務調(diào)用更全面，業(yè)務解耦更充分

2 系統(tǒng)可以橫向規(guī)?；l(fā)展，各個團隊之間的分工也更加明確。

當然：在微服務時代，我們面臨著很多需要解決的問題，比如：系統(tǒng)復雜度增加、服務依賴、服務性能監(jiān)控、全鏈路日志、容災、斷路器、限流等。

本文將從幾個方面介紹微服務架構(gòu)的原理

1 微服務原理 2 微服務框架介紹與選擇 云架構(gòu)及其原理 3.1 注冊中心 3.2 熔斷與限流 3.4.5 Zuul1 微服務原理

這里我們來看一個流程，以電商網(wǎng)站下單為例。原來的流程是創(chuàng)建訂單——調(diào)用庫存——加點——發(fā)貨。如果原本的邏輯是按照這個流程來的，如果中間任何一個環(huán)節(jié)出現(xiàn)問題，都可能導致用戶購買不成功。加入微服務開發(fā)之后，就是通過這一系列的邏輯來訂購服務-庫存服務-點服務

通過這樣的服務化，保證了各項服務的穩(wěn)定運行

2常見的微服務架構(gòu)和框架

微服務框架一般包括、、微服務本身等，現(xiàn)在比較流行的微服務框架有cloud和dubbo。cloud出自家族，提供一整套分布式服務治理方案，從注冊中心到微服務、監(jiān)控、限流等，阿里的dubbo只做服務治理。云端提供更多功能

由于dubbo是二進制傳輸，占用帶寬會少（基于netty等）是http協(xié)議傳輸，帶寬會比較多。同時，如果使用http協(xié)議（http+api），一般會使用JSON消息服務器運維外包，消耗會更大。http協(xié)議的通信真的會成為應用負載的瓶頸點嗎（云端不綁定http+JSON，如果有需要也可以使用高效的RPC和序列化協(xié)議作為替代）

dubbo的開發(fā)難度更大服務器運維外包，因為dubbo的jar包依賴（在代碼層面存在強依賴）是很多大型項目無法解決的問題。

dubbo的注冊中心可以選擇zk、redis等，注冊中心只能從體系結(jié)構(gòu)上使用或者自己開發(fā)簡單程序：.cloud程序結(jié)構(gòu)簡單，"+"=-cloud.dubbo相對復雜,url,,,,,, 從dubbo序列化的性能來看：dubbo的網(wǎng)絡開銷比cloud略小，但是可以通過壓縮、二進制、緩存、段降級等方式解決開發(fā)難度：神奇dubbo的坑是jar包依賴，開發(fā)階段難度極大，jar升級是個大問題，比較自由，但帶來的問題是不能“強行約束接口規(guī)范”，建議解決它以行政方式

3 云架構(gòu)及其原理 3.1 注冊中心

spring的注冊中心有兩者Eureka 和consul 以Euraka為例子  

Eureka Client：負責將這個服務的信息注冊到Eureka Server中  
Eureka Server：注冊中心，里面有一個注冊表，保存了各個服務所在的機器和端口號

3.2 假裝

原本微服務間的通信需要寫大段通信代碼，并且很有可能踩坑。通過feign可以很簡單的調(diào)用微服務。
![下單流程]( https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2018/11/7/166ebfff505b2a20~tplv-t2oaga2asx-image.image )

3.3

通過feign調(diào)用微服務，但是某個微服務部署在多臺服務器上，這個時間需要挑選一臺進行訪問。而ribbon就是這個挑選機制。   
Ribbon的負載均衡默認使用的最經(jīng)典的Round Robin輪詢算法，按照順序一圈圈輪訓  
它與feign和注冊中心的關(guān)系如下圖

3.4

一個系統(tǒng)中有很多微服務和很多組件。這么多服務互相調(diào)用，如果不做保護，如果一個服務失敗，就會引起連鎖反應，導致其他服務也掛掉。比如點服務掛了，那么訂單服務的所有線程都會卡在請求點服務，所有線程都無法工作，導致訂單服務瞬間掛掉，訂單的所有請求別人的服務會卡住，無法響應。

會有很多小線程池。比如訂單服務請求庫存服務是一個線程池，請求存儲服務是一個線程池，請求點服務是一個線程池。線程池中的每個線程僅用于請求該服務。如果紅利服務宕機，只會影響請求紅利服務的線程池，對其他服務的調(diào)用仍然有效。

：但是如果信用服務都掛了，為什么每次調(diào)用都要卡幾秒？是否有意義？當然不是！所以我們只需要直接融合點服務即可。比如你在5分鐘內(nèi)請求積分服務，它會直接返回。不要去網(wǎng)絡請求卡了幾秒。這個過程就是所謂的斷路器！

降級：每次調(diào)用積分服務，都會在數(shù)據(jù)庫中記錄一條信息，說你給某個用戶加了多少積分，因為積分服務宕機了，所以加不成功！這樣，當積分服務恢復后，你就可以根據(jù)這些記錄手動加分了。

3.5 祖爾

Zuul，又稱微服務網(wǎng)關(guān)。該組件負責網(wǎng)絡路由。不懂網(wǎng)絡路由？好吧，我告訴你，如果沒有 Zuul，你的日常工作會怎樣？假設(shè)你后臺部署了上百個服務，現(xiàn)在有個前端小哥，人家的請求直接從瀏覽器發(fā)出來。比如：如果有人要請求一個庫存服務，你還讓他們記住這個服務的名字是-嗎？部署在 5 臺機器上？就算人家愿意記住這個，你有后臺上百個服務的名稱和地址嗎？難不成別人要了一個，就得記住一個？要這么玩，真是友誼之舟，說來就翻！

上面的情況簡直是不現(xiàn)實的。所以在一般的微服務架構(gòu)中，一定要在里面設(shè)計一個網(wǎng)關(guān)，比如，ios，pc前端，微信小程序，H5等等，你不用關(guān)心后端幾百個服務，你懂的有一個網(wǎng)關(guān)，所有的請求都被處理了。到網(wǎng)關(guān)，網(wǎng)關(guān)會根據(jù)請求的一些特征，將請求轉(zhuǎn)發(fā)給后端的各個服務。

而且有了網(wǎng)關(guān)之后，還有很多好處，比如統(tǒng)一降級、限流、認證授權(quán)、安全等等。

總結(jié)

上述Cloud核心組件在微服務架構(gòu)中的作用

：Eureka：各個服務啟動時，Eureka Client都會將服務注冊到Eureka
Server，并且Eureka Client還可以反過來從Eureka Server拉取注冊表，從而知道其他服務在哪里Ribbon：服務間發(fā)起請求的時候，基于Ribbon做負載均衡，從一個服務的多臺機器中選擇一臺
Feign：基于Feign的動態(tài)代理機制，根據(jù)注解和選擇的機器，拼接請求URL地址，發(fā)起請求
Hystrix：發(fā)起請求是通過Hystrix的線程池來走的，不同的服務走不同的線程池，實現(xiàn)了不同服務調(diào)用的隔離，避免了服務雪崩的問題
Zuul：如果前端、移動端要調(diào)用后端系統(tǒng)，統(tǒng)一從Zuul網(wǎng)關(guān)進入，由Zuul網(wǎng)關(guān)轉(zhuǎn)發(fā)請求給對應的服務