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

1 將業務拆分成多個微服務，提高業務之間的隔離性，增強系統面對高并發大流量時的穩定性。系統各個模塊的拆分，保證了各個模塊的穩定性，可以讓業務調用更全面，業務解耦更充分

2 系統可以橫向規模化發展，各個團隊之間的分工也更加明確。

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

本文將從幾個方面介紹微服務架構的原理

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

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

通過這樣的服務化，保證了各項服務的穩定運行

2常見的微服務架構和框架

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

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

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

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

3 云架構及其原理 3.1 注冊中心

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

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

3.2 假裝

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

3.3

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

3.4

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

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

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

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

3.5 祖爾

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

上面的情況簡直是不現實的。所以在一般的微服務架構中，一定要在里面設計一個網關，比如，ios，pc前端，微信小程序，H5等等，你不用關心后端幾百個服務，你懂的有一個網關，所有的請求都被處理了。到網關，網關會根據請求的一些特征，將請求轉發給后端的各個服務。

而且有了網關之后，還有很多好處，比如統一降級、限流、認證授權、安全等等。

總結

上述Cloud核心組件在微服務架構中的作用

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