springClound的一些概念總結

版權聲明：本文爲博主原創文章，未經博主允許不得轉載。 https://blog.csdn.net/lyh147406/article/details/79938138

springClound框架總結


SpringClound整體核心架構只有一點：Rest服務，也就是說在整個SpringCloud配置過程之中，所有的配置處理都是圍繞着Rest完成的，在這個Rest處理之中，一定要有兩個端：服務的提供者（Provider）、服務的消費者（Consumer），
既然SpringCloud的核心是Restful結構，那麼如果要想更好的去使用Rest這些微服務還需要考慮如下幾個問題。
1、所有的微服務地址一定會非常的多，所以爲了統一管理這些地址信息，也爲了可以及時的告訴用戶哪些服務不可用，所以應該準備一個分佈式的註冊中心，並且該註冊中心應該支持有HA機制，爲了高速並且方便進行所有服務的註冊操作，在SpringCloud裏面提供有一個Eureka的註冊中心。




2、對於整個的WEB端的構架（SpringBoot實現）可以輕鬆方便的進行WEB程序的編寫，而後利用Nginx或Apache實現負載均衡處理，但是你WEB端出現了負載均衡，那麼業務端呢？應該也提供有多個業務端進行負載均衡。那麼這個時候就需要將所有需要參與到負載均衡的業務端在Eureka之中進行註冊。
在進行客戶端使用Rest架構調用的時候，往往都需要一個調用地址，即使現在使用了Eureka作爲註冊中心，那麼它也需要有一個明確的調用地址，可是所有的操作如果都利用調用地址的方式來處理，程序的開發者最方便應用的工具是接口，所以現在就希望可以將所有的Rest服務的內容以接口的方式出現調用，所以它又提供了一個Feign技術，利用此技術可以僞造接口實現。




3、在進行整體的微架構設計的時候由於牽扯的問題還是屬於RPC，所以必須考慮熔斷處理機制，實際上所有的熔斷就好比生活之中使用保險絲一樣，有了保險絲在一些設備出現了故障之後依然可以保護家庭的電器可以正常使用，如果說現在有若干的微服務，並且這些微服務之間可以相互調用，例如A微服務調用了B微服務，B微服務調用了C微服務。
如果在實際的項目設計過程之中沒有處理好熔斷機制，那麼就會產生雪崩效應，所以爲了防止這樣的問題出現，SpringCloud裏面提供有一個Hystrix熔斷處理機制，以保證某一個微服務即使出現了問題之後依然可以正常使用。




4、通過Zuul的代理用戶只需要知道指定的路由的路徑就可以訪問指定的微服務的信息，這樣更好的提現了java中的“key=value”的設計思想，而且所有的微服務通過zuul進行代理之後也更加合理的進行名稱隱藏。




5、學習SpringBoot的時候：在SpringBoot裏面強調的是一個“零配置”的概念，本質在於不需要配置任何的配置文件，但是事實上這一點並沒有完全的實現，因爲在整個在整體的實際裏面，依然會提供有application.yml配置文件，那麼如果在微服務的創建之中，那麼一定會有成百上千個微服務的信息出現，於是這些配置文件的管理就成爲了問題。例如：現在你突然有一天你的主機要進行機房的變更，所有的服務的IP地址都可能發生改變，這樣對於程序的維護是非常不方便的，爲了解決這樣的問題，在SpringCloud設計的時候提供有一個SpringCloudConfig的程序組件，利用這個組件就可以直接基於GIT或者SVN來進行配置文件的管理。