如何正確使用 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？【上】請添加鏈接描述