如何正確使用 Spring Cloud？【下】

4. Spring Cloud 微服務全家桶有哪些？

除了經常使用組件以外，Spring Cloud 還集成了微服務全家桶，開箱即用：

• 服務註冊發現類，包括：Eureka、Consul、Zookeeper、Etcd 等。服務註冊：每一個微服務組件都向註冊中心登記本身提供的服務，包括服務的主機、端口號、版本號、通信協議等信息。註冊中心按照服務類型分類組織服務清單，同時以心跳檢測的方式監測清單中服務是否可用，若不可用須要從服務清單中剔除，以達到排除故障服務的效果。服務發現：在服務治理框架下，服務間的調用再也不經過具體的實例地址來實現，而是經過服務名發起請求調用實現。服務調用方經過服務名從註冊中心的服務清單中獲取服務實例的列表清單，經過指定的負載均衡策略取出一個服務實例位置來進行服務調用。

• 服務調用框架類，包括：Ribbon、Feign 等。客戶端負載均衡，將負載均衡邏輯集成到消費方，消費方從註冊中心獲知服務有哪些實例可用，而後再按照某種策略從這些地址中選擇一個服務實例進行訪問。

• 服務容錯組件類，包括：Hystrix 等。服務熔斷：某個目標服務不可用或大量訪問超時，系統將斷開該服務的調用，對後續的調用請求，系統再也不繼續轉發至此服務，直接返回失敗應答，從而快速地釋放資源；若是目標服務狀況好轉，則恢復調用。服務降級：在應急屏蔽或服務熔斷狀況下，直接返回本地缺省的應答。

• 統一配置中心類，包括：Spring Cloud Config、Spring Cloud Bus 等。在服務構建階段，配合構建流水線，爲服務軟件包或鏡像提供配置；在服務運維階段，動態調整服務配置，知足運維的靈活性需求；在服務開發階段，提供配置API將配置外置化，供其餘系統調用。

• 服務網關代理類，包括：Zuul、Spring Cloud Gateway 等。主要提供服務路由功能，即接收消費方的全部請求，按照某種策略將請求轉發至服務提供方。同時，在服務網關中完成一系列橫切面的功能，例如：權限校驗、請求計量、流量控制、服務質量、請求管理、響應管理、版本管理等。

• 調用鏈路監測類，包括：Spring Cloud Sleuth，封裝了 Dapper、Zipkin 和 HTrace 等。微服務架構下組件的數量衆多，一個業務請求可能須要調用多個服務，調用的複雜性決定了錯誤和異常難以定位。咱們須要知道每一個請求到底有哪些服務參與，調用順序是怎麼樣的，從而清楚每一個調用步驟，出現問題也能很快定位。

一般咱們會採用 Eureka 做爲服務註冊中心，實現服務註冊與發現；經過 Ribbon 和 Feign 實現服務的消費以及客戶端負載均衡；經過 Spring Cloud Config 實現應用不一樣環境的外部化配置以及版本管理。爲了讓服務集羣更爲健壯，藉助 Hystrix 的融斷機制來避免微服務架構中個別服務出現異常時引發故障蔓延和雪崩。服務網關 Zuul 爲微服務架構門戶，將權限控制、計量計費等較重的非業務邏輯內容遷移到服務路由層面，使得服務集羣主體可以具有更高的可複用性和可測試性。

5. Spring Cloud 如何融合 DevOps？

接下來，咱們來了解一下 Spring Cloud 在與 DevOps 融合方面能夠作哪些事情，它是如何讓應用持續交付更加快捷的？咱們都知道，DevOps 打造了一套持續交付的流程，包括：開發、編譯、測試、發佈、運營等節點。如何讓應用更順暢地經過上述各個節點呢？Spring Cloud 能夠在每一個研發節點上作一些配合和優化：

• 開發環節，咱們你們應該都試用過 Spring Initializer 建立過 Spring Boot 項目工程，除此以外咱們還能夠藉助 Maven Archetype 來快速生成項目工程。Archetype 是 Maven 工程的模板工具包，一個 Archetype 定義了某種類型項目的基本骨架，藉助它儘量快地給用戶提供示例工程。
• 測試環節，微服務一般對外提供 RESTful API，供各類類型客戶端調用，而以往咱們須要藉助文檔來記錄這些 API 信息，以便其餘人員查閱和測試。若是 API 發生了改變，那咱們就須要同步更新文檔，這會下降持續交付的效率，而 Swagger 能夠幫咱們自動生成 API 在線文檔，與代碼實現保持同步。在此基礎上，咱們還能夠對 API 進行自動化測試。經過 Spring Boot 集成 Swagger，讓接口測試變得更加自動化。
• 發佈環節，使用 Spring Boot 開發的項目，能夠嵌入應用服務器 Jetty、Tomcat 等，最適合發佈成 Docker 鏡像。咱們能夠提供製做鏡像的 Dockerfile 模板，再也不使用 Docker Maven 插件，而是在當前項目的根目錄下新建一個 Dockerfile 文件，代碼編寫完了以後，用戶只須要修改一些參數，直接手動執行命令將應用打成鏡像，這樣就不用深刻學習容器相關技術了。
• 運營環節，咱們能夠接入統一配置中心、日誌雲、全鏈路追蹤等平臺，方便問題的定位解決。

6. Spring Cloud 如何適配雲基礎設施？

剛纔咱們已經詳細介紹了 Spring Cloud 在開發框架、服務集成和融合 DevOps 等方面的內容，接下來咱們看看 Spring Cloud 在適配雲平臺方面能夠作哪些事情。一般爲了讓各類雲計算技術棧對應用開發者透明，下降應用上雲的難度，咱們須要適配虛擬機、容器等不一樣類型的雲基礎設施。

虛擬機是物理機的抽象，包括操做系統、內存和存儲等，在製做 VM 鏡像的時候能夠按需安裝軟件，例如：WEB服務器和數據庫等，這些軟件也會出如今以該鏡像啓動的虛擬機中，VM 與它所在的主機，以及主機上其餘 VM 相互隔離。容器在系統中只須要代碼運行庫環境所需的空間便可，同一個操做系統上的容器共享主機內核。因爲實現原理不一樣，運行虛擬機和容器時所需的資源也不一樣。虛擬機本質上是一個完整的計算機，比容器須要更多的資源，而容器只是操做系統的一部分。通常容器集羣資源密集度較低，所以在單個服務器上運行多容器要比在單個服務器上運行多VM更適合。

那咱們的應用適合部署在哪一種基礎設施上呢？一般公共應用適合採用虛擬機部署，例如：消息隊列、註冊中心、數據庫等等，這類應用對運行資源要求比較高，自己沒有太多個組件構成；業務應用適合採用容器部署，咱們能夠將業務應用拆解成大量職責單一的微服務組件，每一個組件對資源要求相對肯定，並且在不一樣訪問量下須要彈性伸縮。

所以，咱們 DevOps 系統須要抽象出操做不一樣基礎設施的管理接口，基於這些管理接口實現應用生命週期管理、服務治理等功能，這塊能夠借鑑國外廠商指定了一個雲應用管理標準 CAMP（Cloud Application Management for Platform），它定義了應用構建、運行、管理、監控和更新等API，以及資源模型和交互協議等。ßß

7. Spring Cloud 填空式應用開發模式

在單個微服務構建上，Spring 已經從展現層、領域層和數據源層給咱們提供了豐富的組件，咱們只須要關注業務邏輯代碼的編寫；在服務集成上，Spring Cloud 已經提供了微服務全家桶，咱們只須要引用這些服務，不須要自行搭建這些公共服務；在對接 DevOps 和 雲基礎設施上，咱們能夠作一些優化和適配。在它的支持下，咱們能夠更加輕鬆地擁抱微服務、DevOps 和雲計算，更好地應對新技術挑戰。遵循分工協做的理念，Spring Cloud 給咱們提供了一種填空式的開發模式，在這種開發模式下，咱們只須要聚焦業務和用戶，從而以更快地迭代速度打磨出優秀的產品。

8. 總結

Spring 家族變得愈來愈龐大，包括 Spring Framework、Spring Boot、Spring Cloud 等，若是咱們對它沒有一個全局的認知，那咱們很容易迷失在技術細節當中，也用很差這款產品。本文是做者參與公司微服務框架研發過程當中積累的經驗認知，能夠做爲 Spring Cloud 知識體系的索引，後續能夠根據它深刻學習某個特性。

本文主要價值是幫助你們梳理出 Spring Cloud 相關的知識框架，也就是咱們常說的全局視角或者上帝視角。有了這個框架以後，咱們能夠根據本身的須要按圖索驥找相關節點的資料來研究學習，不至於陷入細節找不到方向。固然，考慮到咱們每一個人的工做學習狀況不一樣，平時遇到的問題也不一樣，本文內容沒法覆蓋全部人遇到的問題，歡迎你們留言提問，也歡迎關注「 IT老兵哥 」交流互動，謝謝！

本系列其餘文章索引以下：

• 如何正確使用 Spring Cloud？【上】請添加連接描述