Spring Cloud(零)《總有一偏概述告訴你SpringCloud是什麼》

前言介紹

爲了更好的實現領域驅動設計的落地，不只要在設計思路上作到領域職責清晰、系統邊界明確，還須要使用到Spring Boot、Spring Cloud框架服務體系來更好的構建微服務。後續部分章節將針對Spring Cloud的使用以及有益於構建微服務的知識技能作系列案例整理，以最終完成架構設計專題案例。網上難免有不少優秀的文章，但爲了系統的學習更須要事必躬親，親力親爲。

內容概述

Built directly on Spring Boot's innovative approach to enterprise Java, Spring Cloud simplifies distributed, microservice-style architecture by implementing proven patterns to bring resilience, reliability, and coordination to your microservices.

Spring Cloud 是一系列框架的有序集合。它利用 Spring Boot 的開發便利性巧妙地簡化了分佈式系統基礎設施的開發，如服務發現註冊、配置中心、消息總線、負載均衡、斷路器、數據監控等，均可以用 Spring Boot 的開發風格作到一鍵啓動和部署。Spring 並無重複製造輪子，它只是將目前各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，經過 Spring Boot 風格進行再封裝屏蔽掉了複雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分佈式系統開發工具包。

微服務與SpringCloud

微服務的概念源於Martin Fowler於2014年3月25日寫的一篇文章https://martinfowler.com/arti...

微服務架構模式（Microservices Architecture Pattern）的目的是將大型的、複雜的、長期運行的應用程序構建爲一組相互配合的服務，每一個服務均可以很容易得局部改良。 Micro 這個詞意味着每一個服務都應該足夠小，可是，這裏的小不能用代碼量來比較，而應該是從業務邏輯上比較 —— 符合 SRP(單一職責) 原則的才叫微服務。

設計模式六大原則

• 單一職責原則
• 里氏替換原則
• 依賴倒置原則
• 接口隔離原則
• 迪米特原則
• 開閉原則

關於微服務的一個形象表達：

X軸：運行多個負載均衡器以後的運行實例
Y軸：將應用進一步分解爲微服務（分庫）
Z軸：大數據量時，將服務分區（分表）

而Spring Cloud是Spring爲微服務架構思想作的一個一站式實現。從某種程度是能夠簡單的理解爲，微服務是一個概念、一個項目開發的架構思想。Spring Cloud 是微服務架構的一種 Java 實現。

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

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

使用微服務架構的好處

複雜度可控：在將應用分解的同時，規避了本來複雜度無止境的積累。每個微服務專一於單一功能，並經過定義良好的接口清晰表述服務邊界。因爲體積小、複雜度低，每一個微服務可由一個小規模開發團隊徹底掌控，易於保持高可維護性和開發效率。

獨立部署：因爲微服務具有獨立的運行進程，因此每一個微服務也能夠獨立部署。當某個微服務發生變動時無需編譯、部署整個應用。由微服務組成的應用至關於具有一系列可並行的發佈流程，使得發佈更加高效，同時下降對生產環境所形成的風險，最終縮短應用交付週期。

技術選型靈活：微服務架構下，技術選型是去中心化的。每一個團隊能夠根據自身服務的需求和行業發展的現狀，自由選擇最適合的技術棧。因爲每一個微服務相對簡單，故須要對技術棧進行升級時所面臨的風險就較低，甚至徹底重構一個微服務也是可行的。

容錯高：當某一組建發生故障時，在單一進程的傳統架構下，故障頗有可能在進程內擴散，造成應用全局性的不可用。在微服務架構下，故障會被隔離在單個服務中。若設計良好，其餘服務可經過重試、平穩退化等機制實現應用層面的容錯。

可擴展：每一個服務能夠各自進行 x 擴展和 z 擴展，並且，每一個服務能夠根據本身的須要部署到合適的硬件服務器上。當應用的不一樣組件在擴展需求上存在差別時，微服務架構便體現出其靈活性，由於每一個服務能夠根據實際需求獨立進行擴展。

Spring Cloud 技術總覽

• 服務治理：這是 Spring Cloud 的核心。目前 Spring Cloud 主要經過整合 Netflix 的相關產品來實現這方面的功能（Spring Cloud Netflix），包括用於服務註冊和發現的 Eureka，調用斷路器 Hystrix，調用端負載均衡 Ribbon，Rest 客戶端 Feign，智能服務路由 Zuul，用於監控數據收集和展現的 Spectator、Servo、Atlas，用於配置讀取的 Archaius 和提供 Controller 層 Reactive 封裝的 RxJava。除此以外，針對於服務的註冊和發現，除了 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 提供了集羣選主、分佈式鎖（暫未實現）、一次性令牌（暫未實現）等分佈式集羣須要的技術組件。

Eureka
Eureka 是 Netflix 開源的一款提供服務註冊和發現的產品，它提供了完整的 Service Registry 和 Service Discovery 實現。也是 Spring Cloud 體系中最重要最核心的組件之一。它將全部的能夠提供的服務都註冊到它這裏來管理，其它各調用者須要的時候去註冊中心獲取，而後再進行調用，避免了服務之間的直接調用，方便後續的水平擴展、故障轉移等。

Hystrix
在微服務架構中一般會有多個服務層調用，基礎服務的故障可能會致使級聯故障，進而形成整個系統不可用的狀況，這種現象被稱爲服務雪崩效應。服務雪崩效應是一種因 「服務提供者」 的不可用致使 「服務消費者」 的不可用，並將不可用逐漸放大的過程。

Hystrix Dashboard 和 Turbine
當熔斷髮生的時候須要迅速的響應來解決問題，避免故障進一步擴散，那麼對熔斷的監控就變得很是重要。熔斷的監控如今有兩款工具：Hystrix-dashboard 和 Turbine

Hystrix-dashboard 是一款針對 Hystrix 進行實時監控的工具，經過 Hystrix Dashboard 咱們能夠直觀地看到各 Hystrix Command 的請求響應時間，請求成功率等數據。可是隻使用 Hystrix Dashboard 的話，你只能看到單個應用內的服務信息，這明顯不夠。咱們須要一個工具能讓咱們彙總系統內多個服務的數據並顯示到 Hystrix Dashboard 上，這個工具就是 Turbine.

Spring Cloud Config
隨着微服務不斷的增多，每一個微服務都有本身對應的配置文件。在研發過程當中有測試環境、UAT 環境、生產環境，所以每一個微服務又對應至少三個不一樣環境的配置文件。這麼多的配置文件，若是須要修改某個公共服務的配置信息，如：緩存、數據庫等，不免會產生混亂，這個時候就須要引入 Spring Cloud 另一個組件：Spring Cloud Config。

Spring Cloud Config 是一個解決分佈式系統的配置管理方案。它包含了 Client 和 Server 兩個部分，Server 提供配置文件的存儲、以接口的形式將配置文件的內容提供出去，Client 經過接口獲取數據、並依據此數據初始化本身的應用。

其實就是 Server 端將全部的配置文件服務化，須要配置文件的服務實例去 Config Server 獲取對應的數據。將全部的配置文件統一整理，避免了配置文件碎片化。配置中心 git 實例參考：配置中心 git 示例；

若是服務運行期間改變配置文件，服務是不會獲得最新的配置信息，須要解決這個問題就須要引入 Refresh。能夠在服務的運行期間從新加載配置文件，具體能夠參考這篇文章：配置中心 svn 示例和 refresh

當全部的配置文件都存儲在配置中心的時候，配置中心就成爲了一個很是重要的組件。若是配置中心出現問題將會致使災難性的後果，所以在生產中建議對配置中心作集羣，來支持配置中心高可用性。

Spring Cloud Bus
上面的 Refresh 方案雖然能夠解決單個微服務運行期間重載配置信息的問題，可是在真正的實踐生產中，可能會有 N 多的服務須要更新配置，若是每次依靠手動 Refresh 將是一個巨大的工做量，這時候 Spring Cloud 提出了另一個解決方案：Spring Cloud Bus

Spring Cloud Bus 經過輕量消息代理鏈接各個分佈的節點。這會用在廣播狀態的變化（例如配置變化）或者其它的消息指令中。Spring Cloud Bus 的一個核心思想是經過分佈式的啓動器對 Spring Boot 應用進行擴展，也能夠用來創建一個或多個應用之間的通訊頻道。目前惟一實現的方式是用 AMQP 消息代理做爲通道。

Spring Cloud Bus 是輕量級的通信組件，也能夠用在其它相似的場景中。有了 Spring Cloud Bus 以後，當咱們改變配置文件提交到版本庫中時，會自動的觸發對應實例的 Refresh，

Spring Cloud Zuul
在微服務架構模式下，後端服務的實例數通常是動態的，對於客戶端而言很難發現動態改變的服務實例的訪問地址信息。所以在基於微服務的項目中爲了簡化前端的調用邏輯，一般會引入 API Gateway 做爲輕量級網關，同時 API Gateway 中也會實現相關的認證邏輯從而簡化內部服務之間相互調用的複雜度。

Spring Cloud 體系中支持 API Gateway 落地的技術就是 Zuul。Spring Cloud Zuul 路由是微服務架構中不可或缺的一部分，提供動態路由，監控，彈性，安全等的邊緣服務。Zuul 是 Netflix 出品的一個基於 JVM 路由和服務端的負載均衡器。

它的具體做用就是服務轉發，接收並轉發全部內外部的客戶端調用。使用 Zuul 能夠做爲資源的統一訪問入口，同時也能夠在網關作一些權限校驗等相似的功能。

鏈路跟蹤
隨着服務的愈來愈多，對調用鏈的分析會愈來愈複雜，如服務之間的調用關係、某個請求對應的調用鏈、調用之間消費的時間等，對這些信息進行監控就成爲一個問題。在實際的使用中咱們須要監控服務和服務之間通信的各項指標，這些數據將是咱們改進系統架構的主要依據。所以分佈式的鏈路跟蹤就變的很是重要，Spring Cloud 也給出了具體的解決方案：Spring Cloud Sleuth 和 Zipkin

Spring Cloud Sleuth 爲服務之間調用提供鏈路追蹤。經過 Sleuth 能夠很清楚的瞭解到一個服務請求通過了哪些服務，每一個服務處理花費了多長時間。從而讓咱們能夠很方便的理清各微服務間的調用關係。

Zipkin 是 Twitter 的一個開源項目，容許開發者收集 Twitter 各個服務上的監控數據，並提供查詢接口

分佈式鏈路跟蹤須要 Sleuth+Zipkin 結合來實現

綜上總結

Spring Cloud 各個組件如何來配套使用：

從上圖能夠看出 Spring Cloud 各個組件相互配合，合做支持了一套完整的微服務架構。

• 其中 Eureka 負責服務的註冊與發現，很好將各服務鏈接起來
• Hystrix 負責監控服務之間的調用狀況，連續屢次失敗進行熔斷保護
• Hystrix dashboard，Turbine 負責監控 Hystrix 的熔斷狀況，並給予圖形化的展現
• Spring Cloud Config 提供了統一的配置中心服務
• 當配置文件發生變化的時候，Spring Cloud Bus 負責通知各服務去獲取最新的配置信息
• 全部對外的請求和服務，咱們都經過 Zuul 來進行轉發，起到 API 網關的做用
• 最後咱們使用 Sleuth+Zipkin 將全部的請求數據記錄下來，方便咱們進行後續分析

---