一、爲什麼會有spring-cloud。隨着現代互聯網的發展，以前很多傳統的單體項目將不再滿足於現在的互聯網需求，而這個時候就誕生了另外一種說法，微服務。簡單理解就是將軟件應用程序獨立部署的服務的一中特殊方式。微服務架構是一種分佈式架構，可以安裝業務單元，功能單元進行服務的劃分。它有自己化運維、容錯、快速演進等特點，它可以解決傳統項目的弊病，並且可以滿足越來越複雜的業務關係。
二、單體架構和分佈式架構的優缺點。
1）單體架構：
以MVC架構模式爲例，我們在傳統項目中基本都是採用這種方式。通過MVC（表示層、業務邏輯層、數據訪問層）的架構基本能夠所有應用程序。
缺點：
隨着業務複雜性增加，代碼量增加。代碼的可讀性、可維護性和可擴展性就會下降。
隨着用戶數量增加，併發數增加。單體項目的併發就會存在瓶頸。
測試難度增加。
爲了解決上面的一些問題傳統的方式：
通過nginx進行反向代理，做負載均衡，運用程序，多臺部署。
MySQL設置主從，通過讀寫分理來改善併發能力。
通過加入緩存，提高讀取效率。
但是這種方式還是會存在很大問題：
單體項目代碼的可讀性、可維護性和可擴展性還是不能提升。
隨着海量用戶增加，數據庫將成爲瓶頸。
交付能力越來越弱。新老人員維護代碼的成本過高，代碼修改添加成本太高。
2）分佈式架構
微服務特點：
按業務劃分爲一個獨立單元，即獨立的服務。
服務通過http協議通訊。
自動化部署。
可以介於不同語言之間。
可以用不同的存儲技術。
服務集中化管理。
是一個分佈式系統。
優勢：
通過把龐大的業務關係拆分成各個曉得單元，服務之間明確界限，增加了代碼的可讀性和可擴展性。
由於微服務系統是分佈式系統，在業務擴展上面有很強的能力。另外併發能力，可以通過集羣方式得以處理。
通過http協議傳輸數據，服務之間完全解耦。這使得服務之間可以通過不同語言開發。
如果存在部分架構調整，那麼單體工程絕對是抓破頭皮的存在。
微服務在進行更新或者戎機的情況下，不會影響其他服務。
在CAP理論中使用AP架構，及有具有高可用和分區容錯的特點。
缺點：
複雜度高。由於是分佈式系統，所以部署複雜、學習成本上升、網路問題、服務依賴、測試都會變得更加複雜。
分佈式事務。CAP理論（即同時滿足一致性(Consistency)、可用性(Availability)、分區容錯(Partition tolerance)）。三者不可兼得，又由於P是基本要求所以，只能在CA中做取捨。微服務一般採用AP架構，那麼問題就在一致性上面即分佈式事務。一般採用兩階段提交方式解決。即第一階段service-acount發起一個分佈式事務，交給事務協調器TC管理。TC向所有參與事務的節點發起準備操作。第二階段，如果準備成功，則發出提交命令，如果存在一個節點失敗，則全部回滾。如果由於網絡原因導致提交阻塞，會影響整個系統運行。所以儘量減少分佈式事務的發生。
服務劃分。業務拆分的界限主要是不是很明確，所以在劃定上面一般根據業務的可獨立和可更新進行劃分。可以參考領域驅動設計進行劃分。
服務部署。由於服務的數量和複雜度，還要考慮先後順序等，所以導致了服務部署難的問題。目前採用的方式可以有docker編排，devops理念等
三、spring-cloud簡介
1）微服務應該具備的功能
微服務具有以下特點：
按業務劃分，代碼量小，易於維護。
每個微服務有自己的獨立組件。
通信採用http或者其他方式，具有容錯能力。
一套服務治理方案，服務之間不耦合。
單個服務能夠集羣化，並且具有負載能力。
有一個完整的安全機制。
有鏈路追蹤能力。
有一套完整的實時日誌系統。
微服務具有以下功能：
服務的註冊和發現。
服務的負載均衡。
服務的容錯。（熔斷器機制）
服務的網關。
服務配置的統一管理。
鏈路追蹤。
實時日誌。
2）簡介
spring-cloud是基於spring-boot的。spring-boot是一種全新的web框架，他的特點是簡化開發和部署過程。簡化了spring的配置和依賴管理。spring-cloud是通過包裝其他技術框架來實現的，提供了一些常用組件：服務註冊與發現、配置中心、熔斷器、智能路由、微代理、控制總線、全局鎖、分佈式會話等。
常用組件：
服務註冊與發現組件：Eureka |
熔斷組件：Hystrix |
| =====> Spring Cloud Netflix
負載均衡組件：Ribbon |
路由網關組件：Zuul |
Spring Cloud Config：配置文件統一管理功能，一般配合spring cloud bus（消息總線）使用
Spring Cloud Security：安全管理，一般配合spring security oauth2使用
Spring Cloud Sleuth：分佈式鏈路追蹤組件
Spring Cloud Stream：數據流操作包
其他組件：
Feign：聲明式遠程調度組件。
Archaius：配置管理API組件。
Spring Cloud Data Flow：大數據操作組件。
Spring Cloud Consul：另一個服務註冊與發現組件。
Spring Cloud Zookeeper：服務註冊與發現組件。
Spring Cloud CLI：可以讓用戶以命令形式快速運行和搭建容器。
Spring Cloud Task：任務調度和管理。
四、上面介紹了Spring Cloud，下面看一下阿里的Dubbo。
Dubbo是阿里開源的一個分佈式服務架構，致力於高性能和透明化的RPC調用，以及SOA的服務治理方案。
1）RPC遠程調用：以NIO爲基礎實現的Netty框架的使用。
2）集羣容錯：提供了基於接口方法的遠程調用功能，並顯示負載均衡、失敗容錯等功能。
3）服務發現與發現：集成Zookeeper。
4）Dubbo架構流程：
服務提供者向服務中心註冊服務。
服務消費者訂閱服務。
服務消費者發現服務。
服務消費者遠程調度服務提供者進行服務消費，在調度過程中使用了負載均衡、失敗容錯等功能。
服務消費者和提供者，在內存中記錄調用次數，並定時發送監控中心。
特點：
連通性：服務之間均爲長連接。
健壯性：監控中心宕機不影響其他服務。
伸縮性：動態增減註冊中心和服務數量。
升級性：服務集羣升級，不會對現有框架造成壓力。
五、Spring Cloud和Dubbo對比
目前Dubbo已經完全開源，捐給apache了，更新的狀態不是很頻繁。Dubbo使用tcp的協議，從效率上來說，比Spring Cloud的Restful的接口風格更快。Dubbo更好基於xml配置，Spring Cloud更多基於註解進行配置。上手層度上來說，Dubbo上手更加容易，Spring Cloud和Spring Boot的相關文檔全都是英文且量大，所以學習成本上來說，Dubbo更好。但是從解耦上來說，Spring Cloud採用http通信，所以在解耦上面做的更好。開發效率和部署效率上來說，Spring Cloud做的更加完善和高效。
六、容器集羣管理Spring Cloud和Kubernetes對比
總結：
Spring Cloud採用Java編寫，在集成上面會更加實用。
Spring Cloud 有大量的類庫。
Spring Cloud 更多關注功能點。
Kubernetes支持跨語言。
Kubernetes提供微服務功能外，還支持環境、資源限制、管理應用程序聲明週期等功能。
Kubernetes面向DevOps人員。
Kubernetes學習成本高，比較新的平臺。
七、上面主要是介紹Spring Cloud的相關知識，下面詳細介紹各個功能。
1）Spring-Cloud之構架微服務準備-1
八、在此說明本博客參考《深入理解Spring Cloud與微服務構建》一書進行編寫，如果存在侵權問題，請聯繫博主。