在學習SpringCloud前先了解以下概念問題：

SpringCloud是做什麼的？
從官網上找到答案：

Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state). Coordination of distributed systems leads to boiler plate patterns, and using Spring Cloud developers can quickly stand up services and applications that implement those patterns. They will work well in any distributed environment, including the developer’s own laptop, bare metal data centres, and managed platforms such as Cloud Foundry.
英語不好，簡單翻譯就是：
Spring Cloud為開發者提供了快速構建分散式系統中的一些通用模式（例如配置管理，服務發現，斷路器，智慧路由，微代理，控制匯流排，一次性令牌，全域性鎖，領導選舉，分散式 會話，群集狀態）。 分散式系統的協調導致了樣板模式， 使用Spring Cloud開發人員可以快速地支援實現這些模式的服務和應用程式。 他們將在任何的分散式環境中正常工作，包括開發人員自己的膝上型電腦，裸機資料中心，以及Cloud Foundry等託管平臺。

什麼是微服務?

簡單來說微服務是系統架構上的一種設計風格，它的主旨是把原本獨立的服務拆分成多個小型服務，這些個小型服務在自己獨立的程序下執行，各個服務之間通過HTTP的RESTFUL API進行通訊協作。被拆分的每一個小型服務都圍繞著系統中的某一項或一些耦合度高的業務功能進行構建，並且每個服務都維護著自身的資料儲存、業務開發、自動化測試案例以及獨立的部署機制。由於有了輕量級的通訊協作基礎，所以這些微服務可以使用不同的語言來編寫。
知道了微服務，那個微服務和獨立的單體系統有什麼區別呢？
在以往傳統的系統架構中，我們針對一個複雜的業務需求通常使用物件或者業務型別來構造這個單體專案。在專案中我們通常將業務需求分為三個部分：前端展現，後端處理，資料庫。在業務發展初期，將所有的業務放在一個應用裡進行開發，部署，測試還是很容易實現的。但是，隨著業務發展，需求增加，我們會在這個專案專案上不斷的增加不同的業務模組，提供更多的介面模組。在這種情況下單體應用的問題就逐漸的體現出來了：由於單體應用是一個程序，我們修改一個很小的功能，為了部署上線總會影響其他功能的正常執行。並且單體應用中這些功能模組的使用場景、併發量，消耗的資源都各個不同，對於資源的利用又相互影響，這樣使我們對各個業務的系統容量很難給出較準的評估。所以，單體應用，時間越長，業務發展越大，維護的成本就會越大，並且越來越難以控制。
為了解決單體應用變的龐大臃腫而導致的難以維護等問題，微服務架構誕生並被大家關注。
我們將系統中不同功能模組才分成多個不同的服務，這些服務都能夠獨立的部署執行和擴充套件。由於每個服務都在自己的程序內，在部署上有穩固的邊界，這樣每個服務的更新都不會影響其他的服務正常執行，並且由於是獨立部署的，我們可以更精準的為每個服務評估效能容量，通過配合服務間的協作流程可以更容易的發現系統的瓶頸所在，以及給出較為準確的系統級效能容量。

如何實施微服務

對於單體應用的實施我們都非常瞭解了，也很簡單。但是一旦單體應用被拆分成多個服務，那麼久會引起許多單體應用不會出現的問題：

• 運維的新挑戰：在微服務架構中，運維人員需要維護的程序數量會大大增加，對這些程序編排和組織不是一件容易的事。運維過程需要更多的自動化。對運維人員所具備的技能要求也大大提高。
• 介面的一致性：雖然我們拆分了服務，但是業務邏輯上的依賴並不會消除，只是從一個單體應用中的程式碼依賴變成了服務之間的通訊依賴。而當我們對原有介面進行一些修改，那麼互動也需要協調這樣的改變來進行釋出，以保障介面的正確呼叫。所以我們需要更完善介面和版本管理，或者嚴格的遵守開閉原則。
• 分散式的複雜性：
  由於拆分後各個微服務都是獨立執行在各自的程序中，他們只能通過通訊來進行協同工作，所以分散式環境問題都微服務架構系統設計時需要考慮的重要因素，比如：網路延遲，分散式事物，非同步訊息等一系列問題。

微服務的九大特性

• 服務元件化
• 按業務組織團隊
• 做“產品”的態度
• 智慧端點和啞管道
• 列表內容
• 去中心化自理
• 去中心化管理資料
• 基礎設施自動化
• 容錯設計
• 演進式設計

為什麼選擇SpringCloud?
微服務很火，那麼一個微服務架構我們需要考慮很多問題，比如服務治理（dubbo/dubbox等）、分散式配置管理（Disconf/Diamond等）、批量任務、服務跟蹤等等，當我們搜尋微服務架構的實施方案是會發現，大部分的是分享的主要以理論和一些粗輪廓框架為主，針對於上面的問題整合了來自不同公司或者組織的很多開源框架，並加入自身業務的優化，所以找不到一個完全相同的架構方案。
前面分析過微服務的優點和缺點，這些缺點通常是這些框架出現的源頭，都是為了解決或者彌補業務拆分後所引起的諸多問題來設計出的方案。當我們準備實施一個微服務架構的時候，為了避免前輩們踩過的坑，我們不得不在這些核心問題上選擇不同的框架，那麼選擇又如此之多，這必然會導致技術選型初期需要花費大量精力來進行調研、分析、實踐。
SpringCloud的出現可以說是對微服務架構的巨大支援和強力的技術後盾。我們不用再像以前一樣針對某個問題來選擇相應的架構來解決。SpringCloud是一個綜合性解決微服務架構的框架，整合了諸多被廣泛實踐和證明過的框架作為實施的基礎部件，又在該體系基礎上建立一些非常優秀的邊緣元件。

SpringCloud簡介

SpringCloud簡單來說就是一個分散式系統開發工具包，基於SpringBoot簡化了配置管理、服務發現、斷路器、路由、微代理、事件匯流排、全域性鎖、決策競選、分散式會話等

Spring Cloud組成

Spring Cloud的子專案，大致可分成兩類：
一類是對現有成熟框架”Spring Boot化”的封裝和抽象，也是數量最多的專案；
二類是開發了一部分分散式系統的基礎設施的實現，如Spring Cloud Stream扮演的就是kafka, ActiveMQ這樣的角色。

SpringCloud子專案及介紹

Spring Cloud Config： 配置管理開發工具包，可以讓你把配置放到遠端伺服器，目前支援本地儲存、Git以 及Subversion。
Spring Cloud Bus： 事件、訊息匯流排，用於在叢集（例如，配置變化事件）中傳播狀態變化，可與Spring Cloud Config聯合實現熱部署。
Spring Cloud Netflix： 針對多種Netflix元件提供的開發工具包，其中包括Eureka、Hystrix、Zuul、Archaius等。
Netflix Eureka： 雲端負載均衡，一個基於 REST 的服務，用於定位服務，以實現雲端的負載均衡和中間層伺服器的故障轉移。
Netflix Hystrix： 容錯管理工具，旨在通過控制服務和第三方庫的節點,從而對延遲和故障提供更強大的容錯能力。
Netflix Zuul： 邊緣服務工具，是提供動態路由，監控，彈性，安全等的邊緣服務。
Netflix Archaius： 配置管理API，包含一系列配置管理API，提供動態型別化屬性、執行緒安全配置操作、輪詢框架、回撥機制等功能。
Spring Cloud for Cloud Foundry： 通過Oauth2協議繫結服務到CloudFoundry，CloudFoundry是VMware推出的開源PaaS雲平臺。
Spring Cloud Sleuth： 日誌收集工具包，封裝了Dapper,Zipkin和HTrace操作。
Spring Cloud Data Flow： 大資料操作工具，通過命令列方式操作資料流。
Spring Cloud Security： 安全工具包，為你的應用程式新增安全控制，主要是指OAuth2。
Spring Cloud Consul： 封裝了Consul操作，consul是一個服務發現與配置工具，與Docker容器可以無縫整合。
Spring Cloud Zookeeper： 操作Zookeeper的工具包，用於使用zookeeper方式的服務註冊和發現。
Spring Cloud Stream： 資料流操作開發包，封裝了與Redis,Rabbit、Kafka等傳送接收訊息。
Spring Cloud CLI： 基於 Spring Boot CLI，可以讓你以命令列方式快速建立雲元件。

SpringCloud開發要素

Codebase： 從一個程式碼庫部署到多個環境
Dependencies： 使用顯式的宣告隔離依賴，即模組單獨執行，並可以顯式管理依賴
Config： 在系統外部儲存配置資訊
Backing Services： 把支援性服務看做是資源，支援性服務包括資料庫、訊息佇列、緩衝伺服器等
Build, release, run： 嚴格的劃分編譯、構建、執行階段，每個階段由工具進行管理
Processes： 應用作為無狀態執行
Port binding： 經由埠繫結匯出服務，優先選擇 HTTP API 作為通用的整合框架
Concurrency： 併發性使用水平擴充套件實現，對於web就是水平擴充套件web應用實現
Disposability： 服務可處置性，任何服務可以隨意終止或啟動
Dev/prod parity： 開發和生產環境保持高度一致，一鍵式部署
Logs： 將日誌看做是事件流來管理，所有參與的服務均使用該方式處理日誌
Admin processes： 管理任務作為一次性的過程執行（使用指令碼管理服務啟動和停止）