嗨~
我是水文小墨~ 今天來水一水我理解的微服務，一說到微服務，很多小夥伴想到的是 啊~ 我知道 就是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.路由管理
我們在上面篇幅說的服務的呼叫都是服務之間的呼叫，屬於後臺服務端部分，假設前端有一個請求，涉及到了三個服務，那前端是不是需要傳送三次請求訪問不同的主機呢？這樣設計的系統呼叫太複雜了。對前端人員來說太不友好了
那麼我們是不是可以通過一種封裝的方式，將整個的服務部分封裝起來，對外暴露一個連線地址，所有的連線都來連線這個地址，進來之後再用特定的規則去判斷你要訪問的是哪個服務？
像這樣：
當我們將後端的服務部分封裝起來之後，對前端只暴露一個介面，這樣前端只需要去訪問我這個介面就可以了，而且，有了這個介面，在後端，我們可以對前端發過來的請求進行過濾，這個介面是不是就相當於我們後端服務的一個訪問門面呀？
這種方式類似於設計模式中的 門面模式 不管我後端寫的多爛，我給你一個好看的門面，我就是完美的~