Spring Cloud整體核心架構：Rest服務，在Spring Cloud配置過程中，都是遵循Rest風格規范，在Rest處理中，必不可少兩個對象端：服務的提供者（provider）和服務消費者（consumer）

所以整個Spring Cloud的基礎結構如下所示：

?

?

既然Spring Cloud的核心是Restful架構，那么如果想更好的去使用微服務好需要考慮這些問題：

1、所有的微服務的地址可能非常多，為了統一管理這些地址，也為了能夠即時告訴用戶哪些服務不可用用，為此必不可少一個分布式注冊中心，并且注冊中心支持HA機制（High Availability），為了高效且方便的服務注冊，Spring Cloud使用Eureka服務注冊中心。

?

2、對于整個的WEB端的架構（Spring Boot實現），可以進行輕松方便的WEB程序編寫，而后利用Nginx或Apache實現負載均衡，這是WEB端端的負載均衡，那么業務端呢？應該也提供多個業務端進行負載均衡，這時將所有需要參與到負載均衡的業務端在Eureka之中進行注冊。

?

在進行客戶端使用Rest架構調用的時候，都需要有一個調用地址，即使使用了Eureka作為注冊中心，也需要有一個明確的調用地址，但是所有的操作都利用訪問地址的方式來調用。程序的開發者最方便的應用工具是接口，更好的方式是將所有的Rest服務的內容以接口的方式調用，所以它有提供了feign技術，利用feign可以偽造接口。

3、在進行整體微服務架構設計的時候由于牽扯到的問題還是屬于RPC，所以不可避免考慮到熔斷處理機制，所謂上的熔斷就好比用電安全之中的保險絲，假設現在有若干個微服務，并且這些微服務之間允許相互調用，例如，A服務調用B服務、B服務又調用了C服務。

?

如果實際開發中沒有設計好熔斷處理機制，那么就會出現雪崩效應，所以為了防止這樣的災難問題出現，Spring Cloud里面提供有Hystrix熔斷處理機制，以保證某一個微服務出現問題之后依然可以正常提供服務信息，但是這個返回的服務信息可能已經不是期望的結果，而是服務故障的信息，讓調用方知道該服務出現，避免擴大更大范圍的影響。

?

?

?

?

4、在進行微服務訪問的時候還有一點是非常可怕的，客戶端調用Rest微服務時需要知道所有微服務的名稱信息，如果服務多名稱也會多，操作起來非常麻煩，同時增加日后維護成本。

?

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

?

5、在Spring Boot里面突出“零配置”的概念，原則上不再使用任何配置文件，但是事實上沒有完全實現，因為在整體的設計里面，依然會提供application.yml等配置文件，那么在微服務創建之中，一定有成百上千個微服務，于是這些配置文件的管理就成為問題，維護起來就不是件容易的事了。

為了解決這樣的問題，Spring Cloud的設計中提供一個SpringCloudConfig的程序組件，利用這個組件就可以直接基于Git或SVN來進行配置文件的管理。

?

由此可見，在整體設計上SpringCloud更好的實現了RPC的架構設計，而且使用了Rest作為通信的基礎，這是它無與倫比之處，同時大量使用了Netflix公司的產品實踐技術，所以這些技術也有可靠保證。

作者： xiaogao

出處： http://www.cnblogs.com/tocode/

關于作者：專注Java Web，網絡爬蟲，請多多賜教！

本文版權歸作者和博客園共有，歡迎轉載，但務必注明出處，且在文章頁面明顯位置給出, 原文鏈接 如有問題請咨詢。

轉載于:https://www.cnblogs.com/tocode/p/8996964.html

總結

以上是生活随笔為你收集整理的Spring Cloud 微服务入门（二）--Spring Cloud 架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。