一、SpringCloud單架構
SpringCloud單架構其實就是我們之前使用的SpringBoot項目，這裏我們打開一個SpringBoot項目如下圖：
springcloud 我們會使用 Finchley 這個版本，而它對 springboot 的版本依賴是 2.0.3.RELEASE， 所以我們會用 2.0.3.RELEASE 這個版本的 springboot 來做。
運行以後如下圖：
表格裏面的數據是我們在service裏面添加的：
在正式項目中就是我們讀取數據庫裏面的內容。這裏手動編輯幾個數據舉例。
這個項目很簡單，就做兩件事： 1. 提供數據 2. 展示數據。 這就是一個典型的單體結構。
它把提供數據、展示數據這兩個服務放到了一起，這樣就會出現固有的弊端：
1. 如果要修改數據部分的代碼， 那麼必須把整個項目重新編譯打包部署。 雖然展示部分，什麼都沒變但是也會因爲重新部署而暫時不能使用，要部署完了，才能使用。
2. 如果提供數據部分出現了問題，比如有的開發人員改錯了，拋出了異常，會導致整個項目不能使用，展示數據部分也因此受到影響。
3. 性能瓶頸難以突破
4. 等等。。。
以上就是單體結構的問題，接下來，我們會把這個單體結構的項目，改造成爲springcloud 微服務分佈式架構，通過觀察和參與改造過程，就能夠掌握和理解 springcloud啦。
二、分佈式和集羣
要說springcloud 分佈式之前，先引入微服務概念。
1、微服務
簡單說，一個 springboot 就是一個 微服務，並且這個 springboot 做的事情很單純。 比如 product-service 這個項目，就可以拆成兩個微服務，分別是 數據微服務，和視圖微服務，其實就是倆 springboot, 只是各自做的事情都更單純~
2、服務註冊
那麼有了微服務，就存在如何管理這個微服務，以及這兩個微服務之間如何通信的問題，所以就要引入一個 微服務註冊中心概念，這個微服務註冊中心在 springcloud 裏就叫做 eureka server, 通過它把就可以把微服務註冊起來，以供將來調用。
3、服務訪問
在業務邏輯上， 視圖微服務 需要 數據微服務 的數據，所以就存在一個微服務訪問另一個微服務的需要。
而這倆微服務已經被註冊中心eureka管理起來了，所以 視圖微服務 就可以通過 註冊中心定位並訪問 數據微服務了。
4、分佈式的概念
系統改造到現在，就可以說是分佈式了~ 簡單說，原來是在一個 springboot裏就完成的事情，現在分佈在多個 springboot裏做，這就是初步具備 分佈式雛形了。
那麼分佈式有什麼好處呢？
4.1. 如果我要更新數據微服務，視圖微服務是不受影響的
4.2. 可以讓不同的團隊開發不同的微服務，他們之間只要約定好接口，彼此之間是低耦合的。
4.3. 如果視圖微服務掛了，數據微服務依然可以繼續使用
5、集羣的概念
原來數據微服務只有這一個springboot, 現在做同樣數據微服務的，有兩個 springboot, 他們提供的功能一模一樣，只是端口不一樣，這樣就形成了集羣。
那麼集羣有什麼好處呢？
1. 比起一個 springboot, 兩個springboot 可以分別部署在兩個不同的機器上，那麼理論上來說，能夠承受的負載就是 x 2. 這樣系統就具備通過橫向擴展而提高性能的機制。
2. 如果 8001 掛了，還有 8002 繼續提供微服務，這就叫做高可用 。
6、分佈式和集羣周邊服務
以上是很簡單的分佈式結構，圍繞這個結構，我們有時候還需要做如下事情：
6.1 微服務之間是如何彼此調用的？ sleuth 服務鏈路追蹤
6.2 如何在微服務間共享配置信息？配置服務 Config Server
6.3 如何讓配置信息在多個微服務之間自動刷新？ RabbitMQ 總線 Bus
6.4 如果數據微服務集羣都不能使用了， 視圖微服務如何去處理? 斷路器 Hystrix
6.5 視圖微服務的斷路器什麼時候開啓了？什麼時候關閉了？ 斷路器監控 Hystrix Dashboard
6.6 如果視圖微服務本身是個集羣，那麼如何進行對他們進行聚合監控？ 斷路器聚合監控 Turbine Hystrix Dashboard
6.7 如何不暴露微服務名稱，並提供服務？ Zuul 網關
在接下來的幾節博客裏面，我們將共同來解決這些問題，大家加油！