什么是微服務架構
微服務是系統架構上的一種設計風格， 它的主旨是將一個原本獨立的系統拆分成多個小型服務，這些小型服務都在各自獨立的進程中運行，服務之間通過基于HTTP的RESTful API進行通信協作。 被拆分成的每一個小型服務都圍繞著系統中的某一項或一些耦合度較高的業務功能進行構建， 并且每個服務都維護著自身的數據存儲、 業務開發、自動化測試案例以及獨立部署機制。 由千有了輕量級的通信協作基礎， 所以這些微服務可以使用不同的語言來編寫。
微服務與單體系統的區別
在傳統的項目中我們通常將需求分為三個主要部分： 數據庫、 服務端處理、 前端展現。 在業務發展初期， 由于所有的業務邏輯在一個應用中， 開發、 測試、 部署都還比較容易且方便。 但是， 隨著企業的發展， 系統為了應對不同的業務需求會不斷為該單體項目增加不同的業務模塊； 同時隨著移動端設備的進步， 前端展現模塊已經不僅僅局限于Web的形式， 這對千系統后端向前端的支持需要更多的接口模塊。 單體應用由千面對的業務需求更為寬泛， 不斷擴大的需求會使得單體應用變得越來越臃腫。 單體應用的問題就逐漸凸顯出來， 由于單體系統部署在一個進程內， 往往我們修改了一個很小的功能， 為了部署上線會影響其他功能的運行。 并且， 單體應用中的這些功能模塊的使用場景、 并發量、 消耗的資源類型都各有不同， 對于資源的利用又互相影響， 這樣使得我們對各個業務模塊的系統容量很難給出較為準確的評估。 所以， 單體系統在初期雖然可以非常方便地進行開發和使用，但是隨著系統的發展， 維護成本會變得越來越大， 且難以控制。
?為了解決單體系統變得龐大脯腫之后產生的難以維護的問題， 微服務架構誕生了并被大家所關注。 我們將系統中的不同功能模塊拆分成多個不同的服務， 這些服務都能夠獨立部署和擴展。 由于每個服務都運行在自己的進程內， 在部署上有穩固的邊界， 這樣每個服務的更新都不會影響其他服務的運行。 同時， 由千是獨立部署的， 我們可以更準確地為每個服務評估性能容量， 通過配合服務間的協作流程也可以更容易地發現系統的瓶頸位置，以及給出較為準確的系統級性能容量評估。
為什么選擇Spring Cloud
簡單來說，服務化的核心就是將傳統的一站式應用根據業務拆分成一個一個的服務，而微服務在這個基礎上要更徹底地去耦合(不再共享DB、KV，去掉重量級ESB)，并且強調DevOps和快速演化。這就要求我們必須采用與一站式時代、泛SOA時代不同的技術棧，而Spring Cloud就是其中的佼佼者。
DevOps是英文Development和Operations的合體，他要求開發、測試、運維進行一體化的合作，進行更小、更頻繁、更自動化的應用發布，以及圍繞應用架構來構建基礎設施的架構。這就要求應用充分的內聚，也方便運維和管理。這個理念與微服務理念不謀而合。
接下來我們從服務化架構演進的角度來看看為什么Spring Cloud更適應微服務架構。點擊這里查看Spring系列教程集合。
從使用nginx說起
最初的服務化解決方案是給提供相同服務提供一個統一的域名，然后服務調用者向這個域名發送HTTP請求，由Nginx負責請求的分發和跳轉。
這種架構存在很多問題：
Nginx作為中間層，在配置文件中耦合了服務調用的邏輯，這削弱了微服務的完整性，也使得Nginx在一定程度上變成了一個重量級的ESB。
服務的信息分散在各個系統，無法統一管理和維護。每一次的服務調用都是一次嘗試，服務消費者并不知道有哪些實例在給他們提供服務。這不符合DevOps的理念。
無法直觀的看到服務提供者和服務消費者當前的運行狀況和通信頻率。這也不符合DevOps的理念。
消費者的失敗重發，負載均衡等都沒有統一策略，這加大了開發每個服務的難度，不利于快速演化。
為了解決上面的問題，我們需要一個現成的中心組件對服務進行整合，將每個服務的信息匯總，包括服務的組件名稱、地址、數量等。服務的調用方在請求某項服務時首先通過中心組件獲取提供這項服務的實例的信息(IP、端口等)，再通過默認或自定義的策略選擇該服務的某一提供者直接進行訪問。所以，我們引入了Dubbo。
基于Dubbo實現微服務
Dubbo是阿里開源的一個SOA服務治理解決方案，文檔豐富，在國內的使用度非常高。
使用Dubbo構建的微服務，已經可以比較好地解決上面提到的問題：
- 調用中間層變成了可選組件，消費者可以直接訪問服務提供者。
- 服務信息被集中到Registry中，形成了服務治理的中心組件。
- 通過Monitor監控系統，可以直觀地展示服務調用的統計信息。
- Consumer可以進行負載均衡、服務降級的選擇。
但是對于微服務架構而言，Dubbo也并不是十全十美的：
?Registry嚴重依賴第三方組件(zookeeper或者redis)，當這些組件出現問題時，服務調用很快就會中斷。
?Dubbo只支持RPC調用。使得服務提供方與調用方在代碼上產生了強依賴，服務提供者需要不斷將包含公共代碼的jar包打包出來供消費者使用。一旦打包出現問題，就會導致服務調用出錯。
最為重要的是，Dubbo現在已經重新維護了，對于技術發展的新需求，需要由開發者自行拓展升級。這對于很多想要采用微服務架構的中小軟件組織，顯然是相當合適的。
Github社區上有一個DUBBO的升級版，叫DUBBOX，提供了更高效的RPC序列化方式和REST調用方式。但是該項目也基本停止維護了。
新的選擇 Spring Cloud
作為新一代的服務框架，Spring Cloud提出的口號是開發“面向云環境的應用程序”，它為微服務架構提供了更加全面的技術支持。
Spring Cloud與DUBBO對比：
| 微服務需要的功能 | Dubbo | Spring Cloud |
|---|---|---|
| 服務注冊和發現 | Zookeeper | Eureka |
| 服務調用方式 | RPC | Restful Api |
| 斷路器 | 有 | 有 |
| 負載均衡 | 有 | 有 |
| 服務路由和過濾 | 有 | 有 |
| 分布式配置 | 無 | 有 |
| 分布式鎖 | 無 | 計劃開發 |
| 集群選主 | 無 | 有 |
| 分布式消息 | 無 | 有 |
?Spring Cloud拋棄了Dubbo的RPC通信，采用的是基于HTTP的REST方式。嚴格來說，這兩種方式各有優劣。雖然從一定程度上來說，后者犧牲了服務調用的性能，但也避免了上面提到的原生RPC帶來的問題。而且REST相比RPC更為靈活，服務提供方和調用方的依賴只依靠一紙契約，不存在代碼級別的強依賴，這在強調快速演化的微服務環境下，顯得更加合適。
Eureka相比于zookeeper，更加適合于服務發現的場景。
很明顯，Spring Cloud的功能比Dubbo更加強大，涵蓋面更廣，而且作為Spring的拳頭項目，它也能夠與Spring Framework、Spring Boot、Spring Data、Spring Batch等其他Spring項目完美融合，這些對于微服務而言是至關重要的。前面提到，微服務背后一個重要的理念就是持續集成、快速交付，而在服務內部使用一個統一的技術框架，顯然比把分散的技術組合到一起更有效率。更重要的是，相比于Dubbo，它是一個正在持續維護的、社區更加火熱的開源項目，這就保證使用它構建的系統，可以持續地得到開源力量的支持。
Spring Cloud簡介
?Spring Cloud是一個基千Spring Boot實現的微服務架構開發 工具。 它為微服務架構中涉及的 配置管理、 服務治理、 斷路器、 智能路由、 微代理、 控制總線、 全局鎖、 決策競選、分布式會話和集群狀態管理等操作提供了一種簡單的開發方式。
Spring Cloud包含了多個子項目(針對分布式系統中涉及的多個不同開源產品，還可能會新增)， 如下所述。
Spring Cloud Config: 配置管理工具， 支持使用Git存儲 配置內容， 可以使用它實現應用配置的外部化存儲， 并支持客戶端配置信息刷新、 加密／解密配置內容 等。
- Spring Cloud Netflix: 核心 組件， 對多個Netflix OSS開源套件進行整合。
- Eureka: 服務治理組件， 包含服務注冊中心、 服務注冊與發現機制的實現。
- Hystrix: 容錯管理組件，實現斷路器模式， 幫助服務依賴中出現的延遲和為故障提供強大的容錯能力。
- Ribbon: 客戶端負載均衡的服務調用組件。
- Feign: 基于伈bbon 和 Hystrix 的聲明式服務調用組件。
- Zuul: 網關組件， 提供智能路由、 訪問過濾等功能。
- Archaius: 外部化配置組件。
- Spring Cloud Bus: 事件、 消息總線， 用于傳播集群中的狀態變化或事件， 以觸發后續的處理， 比如用來動態刷新配置等。
- Spring Cloud Cluster: 針對 ZooKeeper、 Redis、 Hazelcast、 Consul 的選舉算法和通用狀態模式的實現。
- Spring Cloud Cloudfoundry: 與 Pivotal Cloudfoundry 的整合支持。
- Spring Cloud Consul: 服務發現與配置管理工具。
- Spring Cloud Stream: 通過 Redis、 Rabbit 或者 Kafka 實現的消費微服務， 可以通過簡單的聲明式模型來發送和接收消息。
Spring Cloud AWS: 用千簡化整合 Amazon Web Service 的組件。 - Spring Cloud Security: 安全工具包， 提供在 Zuul 代理中對 0Auth2 客戶端請求的中繼器。
- Spring Cloud Sleuth: Spring Cloud 應用的分布式跟蹤實現， 可以完美整合 Zip虹n。
- Spring Cloud ZooKeeper: 基于 ZooKeeper 的服務發現與配置管理組件。
- Spring Cloud Starters: Spring Cloud 的基礎組件， 它是基于 Spring Boot 風格項目的基礎依賴模塊。
- Spring Cloud CLI: 用于在 Groovy 中快速創建 Spring Cloud 應用的 Spring Boot CLI插件。
- ......
)
