Spring Cloud技術分析

       現現在微服務架構十分流行，而採用微服務構建系統也會帶來更清晰的業務劃分和可擴展性。同時，支持微服務的技術棧也是多種多樣的，本系列文章主要介紹這些技術中的翹楚——Spring Cloud。這是序篇，主要講述咱們爲何選擇Spring Cloud和它的技術概覽。

1、爲何微服務架構須要Spring Cloud

       簡單來講，服務化的核心就是將傳統的一站式應用根據業務拆分紅一個一個的服務，而微服務在這個基礎上要更完全地去耦合（再也不共享DB、KV，去掉重量級ESB），而且強調DevOps和快速演化。這就要求咱們必須採用與一站式時代、泛SOA時代不一樣的技術棧，而Spring Cloud就是其中的佼佼者。

       DevOps是英文Development和Operations的合體，他要求開發、測試、運維進行一體化的合做，進行更小、更頻繁、更自動化的應用發佈，以及圍繞應用架構來構建基礎設施的架構。這就要求應用充分的內聚，也方便運維和管理。這個理念與微服務理念不謀而合。

       接下來咱們從服務化架構演進的角度來看看爲何Spring Cloud更適應微服務架構。

       1.1 從使用nginx提及

         最初的服務化解決方案是給提供相同服務提供一個統一的域名，而後服務調用者向這個域名發送HTTP請求，由Nginx負責請求的分發和跳轉。

這種架構存在不少問題:

• Nginx做爲中間層，在配置文件中耦合了服務調用的邏輯，這削弱了微服務的完整性，也使得Nginx在必定程度上變成了一個重量級的ESB。
• 服務的信息分散在各個系統，沒法統一管理和維護。每一次的服務調用都是一次嘗試，服務消費者並不知道有哪些實例在給他們提供服務。這不符合DevOps的理念。
• 沒法直觀的看到服務提供者和服務消費者當前的運行情況和通訊頻率。這也不符合DevOps的理念。
• 消費者的失敗重發，負載均衡等都沒有統一策略，這加大了開發每一個服務的難度，不利於快速演化。

爲了解決上面的問題，咱們須要一個現成的中心組件對服務進行整合，將每一個服務的信息彙總，包括服務的組件名稱、地址、數量等。服務的調用方在請求某項服務時首先經過中心組件獲取提供這項服務的實例的信息（IP、端口等），再經過默認或自定義的策略選擇該服務的某一提供者直接進行訪問。因此，咱們引入了Dubbo。

1.2 基於Dubbo實現微服務

       Dubbo是阿里開源的一個SOA服務治理解決方案，文檔豐富，在國內的使用度很是高。

       使用Dubbo構建的微服務，已經能夠比較好地解決上面提到的問題：

• 調用中間層變成了可選組件，消費者能夠直接訪問服務提供者。

• 服務信息被集中到Registry中，造成了服務治理的中心組件。

• 經過Monitor監控系統，能夠直觀地展現服務調用的統計信息。

• Consumer能夠進行負載均衡、服務降級的選擇。

可是對於微服務架構而言，Dubbo也並非十全十美的：

• Registry嚴重依賴第三方組件（zookeeper或者redis），當這些組件出現問題時，服務調用很快就會中斷。

• DUBBO只支持RPC調用。使得服務提供方與調用方在代碼上產生了強依賴，服務提供者須要不斷將包含公共代碼的jar包打包出來供消費者使用。一旦打包出現問題，就會致使服務調用出錯。

• 最爲重要的是，DUBBO如今已經中止維護了，對於技術發展的新需求，須要由開發者自行拓展升級。這對於不少想要採用微服務架構的中小軟件組織，顯然是不太合適的。

    1.3 新的選擇——Spring Cloud

     做爲新一代的服務框架，Spring Cloud提出的口號是開發「面向雲環境的應用程序」，它爲微服務架構提供了更加全面的技術支持。

     結合咱們一開始提到的微服務的訴求，咱們把Spring Cloud與DUBBO進行一番對比：

微服務須要的功能	Dubbo	Spring Cloud
服務註冊和發現	Zookeeper	Eureka
服務調用方式	RPC	RESTful API
斷路器	有	有
負載均衡	有	有
服務路由和過濾	有	有
分佈式配置	無	有
分佈式鎖	無	計劃開發
集羣選主	無	有
分佈式消息	無	有

 

        Spring Cloud拋棄了Dubbo的RPC通訊，採用的是基於HTTP的REST方式。嚴格來講，這兩種方式各有優劣。雖然從必定程度上來講，後者犧牲了服務調用的性能，但也避免了上面提到的原生RPC帶來的問題。並且REST相比RPC更爲靈活，服務提供方和調用方的依賴只依靠一紙契約，不存在代碼級別的強依賴，這在強調快速演化的微服務環境下，顯得更加合適。

       很明顯，Spring Cloud的功能比DUBBO更增強大，涵蓋面更廣，並且做爲Spring的拳頭項目，它也可以與Spring Framework、Spring Boot、Spring Data、Spring Batch等其餘Spring項目完美融合，這些對於微服務而言是相當重要的。前面提到，微服務背後一個重要的理念就是持續集成、快速交付，而在服務內部使用一個統一的技術框架，顯然比把分散的技術組合到一塊兒更有效率。更重要的是，相比於Dubbo，它是一個正在持續維護的、社區更加火熱的開源項目，這就保證使用它構建的系統，能夠持續地獲得開源力量的支持。

2、Spring Cloud技術概覽

• 服務治理：這是Spring Cloud的核心。目前Spring Cloud主要經過整合Netflix的相關產品來實現這方面的功能（Spring Cloud Netflix），包括用於服務註冊和發現的Eureka，調用斷路器Hystrix，調用端負載均衡Ribbon，Rest客戶端Feign，智能服務路由Zuul，用於監控數據收集和展現的Spectator、Servo、Atlas，用於配置讀取的Archaius和提供Controller層Reactive封裝的RxJava。除此以外，針對

Feign和RxJava並非Netiflix的產品，可是被整合到了Spring Cloud Netflix中。

---

對於服務的註冊和發現，除了Eureka，Spring Cloud也整合了Consul和Zookeeper做爲備選，可是由於這兩個方案在CAP理論上都遵循CP而不是AP（下一篇會詳細介紹這點），因此官方並無推薦使用。

• 分佈式鏈路監控：Spring Cloud Sleuth提供了全自動、可配置的數據埋點，以收集微服務調用鏈路上的性能數據，併發送給Zipkin進行存儲、統計和展現。

• 消息組件：Spring Cloud Stream對於分佈式消息的各類需求進行了抽象，包括髮布訂閱、分組消費、消息分片等功能，實現了微服務之間的異步通訊。Spring Cloud Stream也集成了第三方的RabbitMQ和Apache Kafka做爲消息隊列的實現。而Spring Cloud Bus基於Spring Cloud Stream，主要提供了服務間的事件通訊（好比刷新配置）。

• 配置中心：基於Spring Cloud Netflix和Spring Cloud Bus，Spring又提供了Spring Cloud Config，實現了配置集中管理、動態刷新的配置中心概念。配置經過Git或者簡單文件來存儲，支持加解密。

• 安全控制：Spring Cloud Security基於OAUTH2這個開放網絡的安全標準，提供了微服務環境下的單點登陸、資源受權、令牌管理等功能。

• 命令行工具：Spring Cloud Cli提供了以命令行和腳本的方式來管理微服務及Spring Cloud組件的方式。

• 集羣工具：Spring Cloud Cluster提供了集羣選主、分佈式鎖（暫未實現）、一次性令牌（暫未實現）等分佈式集羣須要的技術組件。

後續章節咱們會詳細介紹咱們實際使用到的Spring Cloud組件。

 

 原文連接：http://tech.lede.com/2017/03/15/rd/server/SpringCloud0/