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

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

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

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

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

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

這里我們來看一個(gè)流程，以電商網(wǎng)站下單為例。原來的流程是創(chuàng)建訂單——調(diào)用庫(kù)存——加點(diǎn)——發(fā)貨。如果原本的邏輯是按照這個(gè)流程來的，如果中間任何一個(gè)環(huán)節(jié)出現(xiàn)問題，都可能導(dǎo)致用戶購(gòu)買不成功。加入微服務(wù)開發(fā)之后，就是通過這一系列的邏輯來訂購(gòu)服務(wù)-庫(kù)存服務(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ù)治理方案，從注冊(cè)中心到微服務(wù)、監(jiān)控、限流等，阿里的dubbo只做服務(wù)治理。云端提供更多功能

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

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

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

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

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

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

3.2 假裝

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

3.4

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

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

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

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

3.5 祖爾

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

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

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

總結(jié)

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

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