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

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

2 系統(tǒng)可以橫向規(guī)模化發(fā)展，各個團(tuán)隊(duì)之間的分工也更加明確。

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

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

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

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

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

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

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

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

dubbo的開發(fā)難度更大服務(wù)器運(yùn)維外包，因?yàn)閐ubbo的jar包依賴（在代碼層面存在強(qiáng)依賴）是很多大型項(xiàng)目無法解決的問題。

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

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

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

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

3.2 假裝

原本微服務(wù)間的通信需要寫大段通信代碼，并且很有可能踩坑。通過feign可以很簡單的調(diào)用微服務(wù)。
![下單流程]( 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)用微服務(wù)，但是某個微服務(wù)部署在多臺服務(wù)器上，這個時間需要挑選一臺進(jìn)行訪問。而ribbon就是這個挑選機(jī)制。   
Ribbon的負(fù)載均衡默認(rèn)使用的最經(jīng)典的Round Robin輪詢算法，按照順序一圈圈輪訓(xùn)  
它與feign和注冊中心的關(guān)系如下圖

3.4

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

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

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

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

3.5 祖爾

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

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

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

總結(jié)

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

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