小墨學習記--微服務

碼不夠的張小黑發表於2020-08-24

嗨~

我是水文小墨~ 今天來水一水我理解的微服務,一說到微服務,很多小夥伴想到的是 啊~ 我知道 就是Spring cloud嘛~ 那我們就基於Java的spring cloud框架來聊一下。

spring cloud似乎就是為微服務而生的 那什麼是微服務呢?接下來,小墨以小墨可以理解的角度帶您去看一下微服務~

小墨理解的微服務是將很多的模組摘出來,形成可以獨立執行的專案(服務),專案(服務)進行單獨部署之後,再次開發類似的專案時,可以直接呼叫這些服務來快速開發。縮短專案工期。

spring cloud是在sping boot的基礎上把很多的三方框架以元件的形式,按照公司名將三方框架整合到spring中。

他們之間似乎沒有特別的聯絡,考慮一下,將服務單獨部署之後會出現什麼問題呢?

服務執行期間,肯定不會在同一個上下文中,那如果A服務要呼叫B服務的方法是不是就成了一個問題?

spring cloud就是通過中介軟體的形式,將這些服務聯絡起來,對這些服務進行管理與監控!

 

1.服務發現與呼叫

不在同一個上下文中,我們怎麼建立服務之間的聯絡?TCP協議嘛~

你可能會說,不對呀,服務間的呼叫是通過Rest的方式呼叫的呀,沒錯,spring框架有Rest的使用工具類,但是,Rest是通過HTTP協議的進行服務呼叫的,HTTP協議底層封裝的是TCP協議。

這樣服務之間的呼叫問題解決了,但是有沒有問題呢?

在開發環境中,一個服務有可能依賴很多服務裡面的方法,服務都是單獨部署的,我們有可能會不知道有哪些服務,或者某一臺機器的ip地址換了,我們之前的連線就連不上了,這樣互相呼叫是不是會出現一團糟的情況?像這樣,8這臺機器IP換了,所有呼叫這個服務的服務就都連不上了。

我們可不可以有一箇中間人來去管理他們呢?就像租房子的時候,我們找不到房源,可以求助於掌握了大量房源的房產經紀人(中介)一樣。像這樣

這樣,房產經紀人維護著每個房子的地址,我們就能很方便的找到合適的房子了,這其實也是設計模式中 中介者模式的實現思路~

Spring cloud 就用Eureka這個服務發現與註冊的元件充當房產經紀人的角色來維護服務地址,他是核心的元件之一。

2.服務降級與熔斷

當我們的服務多了之後,服務之間的呼叫是會出現鏈條狀甚至是網狀的結構,像這樣

 

假設當服務③掛掉之後,服務②在呼叫③的過程中一直得不到回應,就每隔一段時間去訪問一下③服務,時間長了之後服務②就因為記憶體的原因,也掛掉了,同理所有呼叫服務2的服務也就會掛掉,最後整個微服務專案就因為服務③掛掉了,這是很危險的一種情況。

 為了避免這種情況,就出現了服務降級和熔斷的解決方案。

服務降級可以有兩種方式,一種是服務③中的某個方法出錯了,在服務③中對這個方法進行降級。另一種是當服務③連線不通時,在服務②中對服務③降級。

降級是指,當服務不能返回正常資料時,我們給呼叫的服務回覆一個友好的錯誤資訊,保證呼叫的服務不會出錯。其中一種方式是如果被呼叫的方法出錯的話,我們把這個跳轉到另外一個返回錯誤資訊的方法裡面。

熔斷指的是:當服務在一定時間內的錯誤數達到一定的量級之後,將整個被呼叫的服務關閉掉,之後過一段時間以後,將服務設定為半開狀態,如果半開狀態下的服務請求能通過的話,就開啟服務,否則繼續關閉服務。

在spring cloud中我們是通過Hystrix元件來實現服務降級和熔斷的。

3.路由管理

我們在上面篇幅說的服務的呼叫都是服務之間的呼叫,屬於後臺服務端部分,假設前端有一個請求,涉及到了三個服務,那前端是不是需要傳送三次請求訪問不同的主機呢?這樣設計的系統呼叫太複雜了。對前端人員來說太不友好了

那麼我們是不是可以通過一種封裝的方式,將整個的服務部分封裝起來,對外暴露一個連線地址,所有的連線都來連線這個地址,進來之後再用特定的規則去判斷你要訪問的是哪個服務?

像這樣:

當我們將後端的服務部分封裝起來之後,對前端只暴露一個介面,這樣前端只需要去訪問我這個介面就可以了,而且,有了這個介面,在後端,我們可以對前端發過來的請求進行過濾,這個介面是不是就相當於我們後端服務的一個訪問門面呀?

這種方式類似於設計模式中的 門面模式 不管我後端寫的多爛,我給你一個好看的門面,我就是完美的~

 

相關文章