既然SpringCloud的核心是Restful結構，那麽如果要想更好的去使用Rest這些微服務還需要考慮如下幾個問題。
1、所有的微服務地址壹定會非常的多，所以為了統壹管理這些地址信息，也為了可以及時的告訴用戶哪些服務不可用，所以應該準備壹個分布式的註冊中心，並且該註冊中心應該支持有HA機制，為了高速並且方便進行所有服務的註冊操作，在SpringCloud裏面提供有壹個Eureka的註冊中心。
對於整個的WEB端的構架（SpringBoot實現）可以輕松方便的進行WEB程序的編寫，而後利用Nginx或Apache實現負載均衡處理，但是妳WEB端出現了負載均衡，那麽業務端呢？應該也提供有多個業務端進行負載均衡。那麽這個時候就需要將所有需要參與到負載均衡的業務端在Eureka之中進行註冊。
在進行客戶端使用Rest架構調用的時候，往往都需要壹個調用地址，即使現在使用了Eureka作為註冊中心，那麽它也需要有壹個明確的調用地址，可是所有的操作如果都利用調用地址的方式來處理，程序的開發者最方便應用的工具是接口，所以現在就希望可以將所有的Rest服務的內容以接口的方式出現調用，所以它又提供了壹個Feign技術，利用此技術可以偽造接口實現。
在進行整體的微架構設計的時候由於牽扯的問題還是屬於RPC，所以必須考慮熔斷處理機制，實際上所有的熔斷就好比生活之中使用保險絲壹樣，有了保險絲在壹些設備出現了故障之後依然可以保護家庭的電器可以正常使用，如果說現在有若幹的微服務，並且這些微服務之間可以相互調用，例如A微服務調用了B微服務，B微服務調用了C微服務。
如果在實際的項目設計過程之中沒有處理好熔斷機制，那麽就會產生雪崩效應，所以為了防止這樣的問題出現，SpringCloud裏面提供有壹個Hystrix熔斷處理機制，以保證某壹個微服務即使出現了問題之後依然可以正常使用。
通過Zuul的代理用戶只需要知道指定的路由的路徑就可以訪問指定的微服務的信息，這樣更好的提現了java中的“key=value”的設計思想，而且所有的微服務通過zuul進行代理之後也更加合理的進行名稱隱藏。
在SpringBoot學習的時候壹直強調過壹個問題：在SpringBoot裏面強調的是壹個“零配置”的概念，本質在於不需要配置任何的配置文件，但是事實上這壹點並沒有完全的實現，因為在整個在整體的實際裏面，依然會提供有application.yml配置文件，那麽如果在微服務的創建之中，那麽壹定會有成百上千個微服務的信息出現，於是這些配置文件的管理就成為了問題。例如：現在妳突然有壹天妳的主機要進行機房的變更，所有的服務的IP地址都可能發生改變，這樣對於程序的維護是非常不方便的，為了解決這樣的問題，在SpringCloud設計的時候提供有壹個SpringCloudConfig的程序組件，利用這個組件就可以直接基於GIT或者SVN來進行配置文件的管理。
在整體設計上SpringCloud更好的實現了RPC的架構設計，而且使用Rest作為通訊的基礎，這壹點是他的成功之處，由於大量的使用了netflix公司的產品技術，所以這些技術也有可靠的保證。