共計 2869 個字符，預計需要花費 8 分鐘才能閱讀完成。
這篇文章給大家分享的是有關 Spring Cloud 的示例分析的內容。丸趣 TV 小編覺得挺實用的，因此分享給大家做個參考，一起跟隨丸趣 TV 小編過來看看吧。
1 Spring Cloud 概述 1.1 傳統的應用 1.1.1 單體應用
在此之前，筆者所在公司開發 Java 程序，大都使用 Struts、Spring、Hibernate（MyBatis）等技術框架，每一個項目都會發布一個單體應用。例如開發一個進銷存系統，將會開發一個 war 包部署到 Tomcat 中，每一次需要開發新的模塊或添加新功能時，都會在原來的基礎上不斷的添加。若干年后，這個 war 包不斷的膨脹，程序員在進行調試時，服務器也可能需要啟動半天，維護這個系統的效率極為低下。這樣一個 war 包，涵蓋了庫存、銷售、會員、報表等模塊，如圖 1 -1。
圖 1 -1 單體應用
這樣的單體應用隱患非常多，任何的一個 bug，都有可能導致整個系統宕機。筆者印象最深刻的是，曾經有一客戶在高峰期，導出一張銷售明細報表（數據量較大），最終造成整個系統癱瘓，前臺的銷售人員無法售賣。維護這樣一個系統，不僅效率極低，而且充滿風險，項目組的各個成員惶惶不可終日，我們需要本質上的改變。
1.1.2 架構演進
針對以上的單體應用的問題，我們參考 SOA 架構，將各個模塊劃分獨立的服務模塊（war），并且使用了數據庫的讀寫分離，架構如圖 1 -2。
圖 1 -2 架構演進
各個模塊之間會存在相互調用的依賴關系，例如銷售模塊會調用會員模塊的接口，為了減少各個模塊之間的耦合，我們加入了企業服務總線（ESB），各模塊與 ESB 之間的架構如圖 1 - 3 所示。
圖 1 -3 ESB
加入 ESB 后，各個模塊將服務發布到 ESB 中，它們與 ESB 之間使用 SOAP 協議進行通信。圖 1 - 2 與圖 1 - 3 的架構實現后，整個系統的性能有了明顯的提升，各個模塊的耦合度也降低了。運行了一段日子后，又出現了新的問題，由于銷售終端數量的增多，銷售模塊明顯超過其承受能力，為了保證銷售前端的正常運行，我們使用了 Nginx 做負載均衡，請見圖 1 -4。
圖 1 -4 使用 Nginx
隨著銷售模塊的增多，帶來了許多問題，例如管理這些模塊，對于運維工程師來說，是一項艱巨的任務，一旦銷售模塊有所修改，他們將通宵達旦進行升級。另外，企業服務總線也有可能成為性能的瓶頸，雖然目前仍未出現該問題，但我們需要未雨綢繆。
1.1.3 架構要求
從前面的架構演進可知，應用中的每一個點，都有可能成為系統的問題點。隨著互聯網應用的普及，在大數據、高并發的環境下，我們的系統架構需要面對更為嚴苛的挑戰，我們需要一套新的架構，它起碼能滿足以下要求：
? 高性能：這是應用程序的基本要求。
? 獨立性：其中一個模塊出現 bug 或者其他問題，不可以影響其他模塊或者整個應用。
? 容易擴展：應用中的每一個節點，都可以根據實際需要進行擴展。
? 便于管理：對于各個模塊的資源，可以輕松進行管理、升級，減少維護成本。
? 狀態監控與警報：對整個應用程序進行監控，當某一個節點出現問題時，能及時發出警報。
為了能解決遇到的問題、達到以上的架構要求，我們開始研究 Spring Cloud。
1.2 微服務與 Spring Cloud1.2.1 什么是微服務
微服務一詞來源 Martin Fowler 的“Microservices”一文，微服務是一種架構風格，將單體應用劃分為小型的服務單元，微服務之間使用 HTTP 的 API 進行資源訪問與操作。
在對單體應用的劃分上，微服務與前面的 SOA 架構有點類似，但是 SOA 架構側重于將每個單體應用的服務集成到 ESB 上，而微服務做得更加徹底，強調將整個模塊變成服務組件，微服務對模塊的劃分粒度可能會更細。以我們前面的銷售、會員模塊為例，在 SOA 架構中，只需要將相應的服務發布到 ESB 容器就可以了，而在微服務架構中，這兩個模塊本身，將會變為一個或多個的服務組件。SOA 架構與微服務架構，請見圖 1 - 5 與圖 1 -6。
圖 1 -5 SOA 架構
圖 1 -6 微服務架構
在微服務的架構上，Martin Fowler 的文章肯定了 Netflix 的貢獻，接下來，我們了解一下 Netflix OSS。
1.2.2 關于 Netflix OSS
Netflix 是一個互聯網影片提供商，在幾年前，Netflix 公司成立了自己的開源中心，名稱為 Netflix Open Source Software Center，簡稱 Netflix OSS。這個開源組織專注于大數據、云計算方面的技術，提供了多個開源框架，這些框架包括大數據工具、構建工具、基于云平臺的服務工具等。Netflix 所提供的這些框架，很好的遵循微服務所推崇的理念，實現了去中心化的服務管理、服務容錯等機制。
1.2.3 Spring Cloud 與 Netflix
Spring Cloud 并不是一個具體的框架，大家可以把它理解為一個工具箱，它提供的各類工具，可以幫助我們快速的構建分布式系統。
Spring Cloud 的各個項目基于 Spring Boot，將 Netflix 的多個框架進行封裝，并且通過自動配置的方式將這些框架綁定到 Spring 的環境中，從而簡化了這些框架的使用。由于 Spring Boot 的簡便，使得我們在使用 Spring Cloud 時，很容易的將 Netflix 各個框架整合進我們的項目中。Spring Cloud 下的“Spring Cloud Netflix”模塊，主要封裝了 Netflix 的以下項目：
? Eureka：基于 REST 服務的分布式中間件，主要用于服務管理。
? Hystrix：容錯框架，通過添加延遲閥值以及容錯的邏輯，來幫助我們控制分布式系統間組件的交互。
? Feign：一個 REST 客戶端，目的是為了簡化 Web Service 客戶端的開發
? Ribbon：負載均衡框架，在微服務集群中為各個客戶端的通信提供支持，它主要實現中間層應用程序的負載均衡
? Zuul：為微服務集群提供過代理、過濾、路由等功能。
1.2.4 Spring Cloud 的主要模塊
除了 Spring Cloud Netflix 模塊外，Spring Cloud 還包括以下幾個重要的模塊：
? Spring Cloud Config：為分布式系統提供了配置服務器和配置客戶端，通過對它們的配置，可以很好的管理集群中的配置文件。
? Spring Cloud Sleuth：服務跟蹤框架，可以與 Zipkin、Apache HTrace 和 ELK 等數據分析、服務跟蹤系統進行整合，為服務跟蹤、解決問題提供了便利。
? Spring Cloud Stream：用于構建消息驅動微服務的框架，該框架在 Spring Boot 的基礎上，整合了“Spring Integration”來連接消息代理中間件。
? Spring Cloud Bus：連接 RabbitMQ、Kafka 等消息代理的集群消息總線。
感謝各位的閱讀！關于“Spring Cloud 的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！
