Spring Cloud整體核心架構只有一點：Rest服務，也就是說在整個Spring Cloud配置過程之中，所有的配置處理都是圍繞著Rest完成的，在這個Rest處理之中，一定要有兩個端：服務的提供者(Provider)、服務的消費者(Consumer)，所以對于整個Spring Cloud基礎的結構就如下所示。

SpringCloud基礎架構

既然Spring Cloud的核心是Restful結構，那么如果要想更好的去使用Rest這些微服務還需要考慮如下幾個問題。

1.所有的微服務地址一定會非常的多，所以為了統一管理這些地址信息，也為了可以及時的告訴用戶哪些服務不可用，所以應該準備一個分布式的注冊中心，并且該注冊中心應該支持有HA機制，為了高速并且方便進行所有服務的注冊操作，在Spring Cloud里面提供有一個Eureka的注冊中心。

微服務結構圖

2.對于整個的WEB端的構架(SpringBoot實現)可以輕松方便的進行WEB程序的編寫，而后利用Nginx或Apache實現負載均衡處理，但是你WEB端出現了負載均衡，那么業務端呢?應該也提供有多個業務端進行負載均衡。那么這個時候就需要將所有需要參與到負載均衡的業務端在Eureka之中進行注冊。

多業務端-負載均衡

在進行客戶端使用Rest架構調用的時候，往往都需要一個調用地址，即使現在使用了Eureka作為注冊中心，那么它也需要有一個明確的調用地址，可是所有的操作如果都利用調用地址的方式來處理，程序的開發者最方便應用的工具是接口，所以現在就希望可以將所有的Rest服務的內容以接口的方式出現調用，所以它又提供了一個Feign技術，利用此技術可以偽造接口實現。

Feign

3.在進行整體的微架構設計的時候由于牽扯的問題還是屬于RPC，所以必須考慮熔斷處理機制，實際上所有的熔斷就好比生活之中使用保險絲一樣，有了保險絲在一些設備出現了故障之后依然可以保護家庭的電器可以正常使用，如果說現在有若干的微服務，并且這些微服務之間可以相互調用，例如A微服務調用了B微服務，B微服務調用了C微服務。

如果在實際的項目設計過程之中沒有處理好熔斷機制，那么就會產生雪崩效應，所以為了防止這樣的問題出現，SpringCloud里面提供有一個Hystrix熔斷處理機制，以保證某一個微服務即使出現了問題之后依然可以正常使用。

Hystrix熔斷處理

4.在進行微服務訪問的時候還有一點是非常可怕的。

Zuul代理機制

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

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

Spring Cloud Config

在整體設計上Spring Cloud更好的實現了RPC的架構設計，而且使用Rest作為通訊的基礎，這一點是他的成功之處，由于大量的使用了netflix公司的產品技術，所以這些技術也有可靠的保證。