在學習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： 管理任務作爲一次性的過程運行（使用腳本管理服務啓動和停止）