springClound的一些概念總結

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來進行配置檔案的管理。