最近學習到了SpringBoot整合SpringCloud那一塊，由於沒有學習過SpringCloud相關的知識，所以這篇博客開個荒，慢慢記錄一下之後的SpringCloud的學習之路。這一篇博客就簡單介紹一些五大常用小組件的用途和概念。
慣例閒扯:
大家或許會經常把Dubbo和SpringCloud來進行比較，但其實它們兩還是會有所不同。之前我也瞭解過Dubbo，它主要是解決RPC(遠程調用)那一塊的問題，確實它的出現極大地解決了服務多了之後，調用關係繁雜的情況。而SpringCloud則是一個分佈式的整體解決方案。竟然都叫整體解決方案了,那它應該還會解決其他可能出現的情況。
以下摘自官方：
Spring Cloud 爲開發者提供了在分佈式系統（配置管理，服務發現，熔斷，路由，微代理，控制總線，一次性token，全局瑣，leader選舉，分佈式session，集羣狀態）中快速構建的工具，使用Spring Cloud的開發者可以快速的啓動服務或構建應用、同時能夠快速和雲平臺資源進行對接。
SpringCloud爲我們提供許多組件，來針對可能出現的應用場景，以下用大白話的視角來看看常用的五個小組件。
五大常用小組件:
- 服務發現——Netflix Eureka: 這個組件就是分佈式系統裏面的"註冊中心"，和Dubbo中的Zookeeper作用相似。服務提供者註冊服務至Eureka上，其他服務消費者可以去訂閱它。
- 客服端負載均衡——Netflix Ribbon： 該組件負責各節點間的負載均衡，往往分佈式集羣中各節點關係"錯中複雜",有時該節點服務壓力已經很大，新的請求進不來，那新的請求只能去別的功能相同的節點，而Ribbon就是負責調配這一工作的。
- 斷路器——Netflix Hystrix： 在現實的分佈式開發中，往往會碰到一個情況，我們瀏覽器的請求先調用a節點，而a節點又去調用b，b調用c…也是"錯中複雜"。那麼假設一直調用到最後，調用到z節點(誇張點)，發現出現錯誤了，那瀏覽器只能一直等待很長時間，等z節點一直響應到a節點，瀏覽器才能收到錯誤信息。如果有Hystrix的話，當出現錯誤時，馬上先返回錯誤信息給瀏覽器，這樣用戶也不用花那麼多時間去等待。
- 服務網關——Netflix Zuul: 我們可以設置一個網關，每次節點調用結束後，先經過網關篩選，再返回。打個比喻，現在疫情期間，我們出門的話，也要量體溫，如果這時你發燒了，那麼就會被攔下來，然後你該去醫院進行進一步的檢查。而Zuul就是這個作用。
- 分佈式配置——Spring Cloud Config: 偷個小懶，顧名思義嘿嘿嘿。
以後會不定時的用大白話的方式分享SpringCloud的相關知識。大佬們有什麼意見的話，歡迎來指正哦。