SpringCloud基礎瞭解
SpringCloud背景和基礎知識
隨着技術的慢慢發展，單一的應用很難滿足目前用戶的需求的。例如現在最簡單的商場應用，用戶下單後，需要創建訂單服務，再創建庫存服務、快遞服務、如果有可能還會有會員積分服務。所以目前單一的應用去做這些事情很困難，能夠完成，但是中間要花費大量的時間和精力去處理服務之間的協調和通信問題。SpringCloud就應用而生，和SpringBoot的產生一樣，也是輕量級，讓開發人員更加專注的開發業務代碼，而不是和業務無關的代碼。由此可見，這也是目前主流工具的開發方向。
想要了解SpringCloud需要先了解SpringBoot，因爲都是Spring的全家桶，所以SpringCloud是基於SpringBoot的。關於SpringBoot的介紹這裏就不再累述了，很多文檔包括我也寫了一些。其實在我看來，因爲這些腳手架的原因，現在開發人員甚至不用關注底層原理，直接就可以開發。所以SpringBoot只要會大致寫一個HelloWorld，就可以看關於SpringCloud的文檔了。但是一旦底層出現一些問題，這些人又完全沒有方法。短期看，Spring對於編程的發展有一定的好處，但是長遠看，會使得編程人員往更高級的語言發展（但是Java本身就是高級語言啊）或者後來的編程人員越來越原理這裏底層原理。無論哪種都不是很好的結果。（說多了，開始吧）
SpringCloud的核心組件
-
服務發現——Netflix Eureka。通過這個組件可以將服務註冊到Eureka服務端中，服務端則將所有的服務的機器和端口號記錄下來。當調用服務時，向註冊中心查詢註冊表即可。
-
客服端負載均衡——Netflix Ribbon。這個組件是爲了提供客戶側的軟件負載均衡算法。Ribbon的負載均衡默認使用的最經典的Round Robin輪詢算法。
-
HTTP客戶端——OpenFeign。簡化調用服務時的工作，將複雜的請求簡化爲配置，使用動態代理來構造出需要請求的服務地址，最後發起請求和解析請求。
-
斷路器——Netflix Hystrix。爲了避免雪崩現象，使用Hystrix來解決這個問題。Hystrix是隔離、熔斷以及降級的一個框架。當某個服務掛掉後，Hystrix首先熔斷，在一定時間後直接返回，但是不能直接返回，需要降級，把這個錯誤或者異常記錄，在服務恢復後繼續執行。
-
服務網關——Netflix Zuul。各個服務因爲請求地址不同，前端做分離是不現實的，所以採用路由的形式，將前端的請求統一從路由過，再由路由轉發給對應的服務。
記在後面的話
其實把上面的看完就可以理解這些組件設計的目的了，總的來說，SpringCloud的組件雖然都是輕量級的，但是普通的應用拆分服務的很少，所以還是有一定體量的纔會上微服務，所以保證這些服務和應用正常工作就顯得格外重要，各個組件也是爲了保證這一點。作爲碼農，瞭解各個模塊和組件的作用非常重要，要比一個demo重要的多。後面我也會慢慢的搭建一個簡單的SpringCloud框架。
就這樣吧，結束。