SpringCloud的相關架構簡單介紹

1、大的單體專案有多蛋疼

以前我們做單機系統的時候，所有的**都在乙個專案裡面，只是不同的模組按照包名來劃分的。我們以前做的乙個某省的教育專案，有學生資訊和就業系統、有高校培訓系統、有乙個人資系統等一共六個，4個小夥伴都在乙個**裡面進行開發，各個系統之間有一定的聯絡，但是大部分是不相關的，但管理頁面在一起。

那時候我們都在乙個專案裡面碼**，每次啟動好幾分鐘，還有就是包版本衝突問題，搞得真是蛋疼。大家經歷過大型的單體專案開發，相信你有體會的。

還有各系統的使用量也不一樣，有的比較大。比如學生資訊和就業系統，面向的是所有高校，特別是快畢業那段時間，每個學校會上報就業率等資訊，還有就是列印報到證呀什麼的。有的系統就使用比較少，比如人資、培訓系統使用的基本上就教育廳的一些員工，和部分老師，流量不大，勉強能扛得住。

2、模擬業務背景

大點的企業，比如做電商的，使用者幾十萬的，日活幾萬的，背後好幾十人上百人的團隊在支撐開發，單體系統就不太合適了。

比如現在有乙個下單買東西的需求，就需要訂單系統、庫存系統、倉庫系統和積分系統等來進行處理。如下圖：

訂單系統、庫存系統、倉儲和積分系統都是部署到不同的機器上的。

當使用者下單了，那麼訂單服務會進行通知庫存系統扣件庫存、通知倉儲系統發貨、通知積分系統累加積分的操作。

如果我們此時需要用到 spring cloud 來做乙個分布式架構的話，那麼我們需要什麼東西呢？每個東西都是幹嘛的呢？

3、如果使用 spring cloud 來實現，需要哪些元件？

3.1、eureka

首先，我們需要乙個註冊中心 eureka ，主要負責每個服務的註冊和發現。

每個微服務中都有乙個euraka client元件，專門負責將這個服務的服務id（serviceid）、ip、埠等資訊註冊到eureka server中。

euraka server是乙個註冊中心，該元件內部維護了乙個登錄檔，儲存了各個服務所在的機器ip和埠號等註冊資訊。

3.2、feign

其次每個服務還需要乙個遠端服務呼叫的元件 feign ，他主要負責與其他服務建立連線，構造請求，然後發起請求並呼叫其他服務來獲取資料。

3.3、ribbon

然後我們乙個服務可能會部署很多臺機器，那麼我們使用feign 去呼叫這個服務的時候，到底把請求傳送到哪台機器上去呢？此時我們就需要乙個元件來根據一定的策略來選擇一台機器。不管怎麼選的，總之得選一台機器給 feign 去呼叫就好了。

這個元件就是 ribbon，ribbon 主要負責就是負載均衡。ribbon 會定期去從eureka 註冊中心拉取註冊中心，快取到本地，每次發起遠端呼叫的時候，ribbon 就會從 eureka 登錄檔拉取下來的資料中挑選乙個機器讓 feign 來發起遠端呼叫。

3.4、zuul

我們這麼多的微服務，如果乙個服務乙個ip，使用方都需要進行呼叫的話，是不是得知道每乙個服務的ip位址才行呢？那得記住多少ip才行呀，多不好管理。

如果有乙個統一的位址(閘道器的位址)，然後根據不同的請求路徑來進行請求**，比如 /user/* 是**到使用者服務，/product/* 是轉向到商品服務等等。我使用的時候，只需要訪問同乙個ip（閘道器的ip位址），只是請求路徑不一樣，就行了。

spring cloud 也給我們提供了乙個元件，那就是 zuul ，他是乙個閘道器，就是負責網路的請求路由的。每個請求都經過這個閘道器，我們還可以做統一鑑權等等很多事情。

3.5、hystrix

還有乙個東西也得說一下，就是 hystrix，它是乙個錯誤隔離、熔斷以及降級的乙個框架。

在微服務的相互呼叫過程中，可能會出現被呼叫服務錯誤或者超時的情況，從而導致整個系統崩潰不可用，也就是我們常說的服務雪崩問題，hystrix 的存在就是為了解決這種問題的。

4、整體架構

我們按照以上使用到的這些元件，來往下單這個流程來套一下：

整個呼叫流程：

首先每個服務啟動的時候都需要往註冊中心進行註冊。

使用者先對閘道器發起下單請求，閘道器收到請求後發現是下單操作，根據請求路徑將請求路由到訂單系統，

訂單系統進行一系列操作，然後通過 feign 去呼叫庫存系統減庫存，通知倉儲服務發貨，呼叫積分系統加積分。

在發起呼叫之前，訂單系統還得通過ribbon 去註冊中心去拉取各系統的登錄檔資訊，並且按照一定的策略挑一台機器給 feign 來發起網路呼叫。