1.新。本書案例基於全新的Spring Boot 2.0及Spring Cloud Finchley.M2，深入淺出地講解了Spring Cloud。 2.實戰。跳脫純理論講述，案例貫穿全書，從0到1搭建微服務繫統，從1到0實現微服務拆分。讀者不僅能學到軟件開發技能，還能學到項目實戰經驗。 3.全。彌補市面上有關 Spring Cloud學習資料的不足，重新編寫整個教學案例，使讀者輕松脫離“Hello World”階段，實現對微服務的治理。

眾所周知，Spring Cloud 是開發微服務架構繫統的利器，企業對 Spring Cloud 方面的開發需求也非常旺盛。然而，雖然市面上介紹 Spring Cloud 的概念及基礎入門的書籍較多，但這些書籍中的案例往往隻是停留在簡單的“Hello World”級別，缺乏可真正用於實戰落地的指導。 本書與其他書籍不同，其中一個大的特色是真正從實戰角度出發，運用 Spring Cloud 技術來構建一個完整的微服務架構的繫統。本書介紹 Spring Cloud 的概念、產生的背景，以及圍繞 Spring Cloud 在開發微服務架構繫統過程中所面臨的問題時應當考慮的設計原則和解決方案。特別是在設計微服務架構繫統時所面臨的繫統分層、服務測試、服務拆分、服務通信、服務注冊、服務發現、服務消費、集中配置、日志管理、容器部署、安全防護、自動擴展等方面，給出了作者自己獨特的見解。本書不僅介紹了微服務架構繫統的原理、基礎理論，還以一個真實的天氣預報繫統實例為主線，集成市面上主流的實現技術框架，手把手地教讀者如何來應用這些技術，創建一個完整的微服務架構繫統。這樣讀者可以理論聯繫實踐，從而讓 Spring Cloud 真正地落地。 此外，本書不僅可以令讀者了解微服務架構繫統開發的完整流程，而且通過實戰結合技術點的歸納，令讀者知其然且知其所以然。本書所涉及的技術符合當前主流，並富有一定的前瞻性，可以有效提高讀者在市場中的核心競爭力。 本書主要面向以 Spring 為核心的 Java EE ，以及對 Spring Cloud 和微服務開發感興趣的讀者。

柳偉衛（英文名Way Lau），關注編程、繫統架構、性能優化。在大型IT公司擔任過項目經理、架構師、開發顧問等職位，具有多年軟件開發管理及繫統架構經驗。負責過多個省級、大型分布式繫統的設計與研發，參與了多個大型項目的微服務架構的技術改造，在實際工作中積累了大量的微服務架構經驗。是CSDN、開源中國、雲棲社區等技術社區專家。已出版專著《 Spring Boot企業級應用開發實戰》。

第I章 微服務概述

1.1 傳統軟件行業面臨的挑戰

1.2 常見分布式繫統架構

1.3 單塊架構如何進化為微服務架構

1.4 微服務架構的設計原則

1.5 如何設計微服務繫統

第2章 微服務的基石——Spring Boot

2.1 Spring Boot簡介

2.2 開啟一個Spring Boot項目

2.3 Hello World

2.4 如何搭建開發環境

2.5 Gradle與Maven的抉擇

第3章 Spring Boot 的主題

3.1 構建RESTful服務

3.2 Spring Boot的配置詳解

3.3 內嵌Servlet容器

3.4 實現安全機制

3.5 允許跨域訪問

3.6 消息通信

3.7 數據持久化

3.8 實現熱插撥

第4章 微服務的測試

4.1 測試概述

4.2 測試的類型和範圍

4.3 如何進行微服務的測試

第5章 微服務的協調者——Spring Cloud

5.1 Spring Cloud簡介

5.2 Spring Cloud入門配置

5.3 Spring Cloud的子項目介紹

第6章 服務拆分與業務建模

6.1 從一個天氣預報繫統講起

6.2 使用Redis提升應用的並發訪問能力

6.3 實現天氣數據的同步

6.4 給天氣預報一個“面子”

6.5 如何進行微服務的拆分

6.6 領域驅動設計與業務建模

第7章 天氣預報繫統的微服務架構設計與實現

7.1 天氣預報繫統的架構設計

7.2 天氣數據采集微服務的實現

7.3 天氣數據API微服務的實現

7.4 天氣預報微服務的實現

7.5 城市數據API微服務的實現

第8章 微服務的注冊與發現

8.1 服務發現的意義

8.2 如何集成Eureka Server

8.3 如何集成Eureka Client

8.4 實現服務的注冊與發現

第9章 微服務的消費

9.1 微服務的消費模式

9.2 常見微服務的消費者

9.3 使用Feign實現服務的消費者

9.4 實現服務的負載均衡及高可用

**0章 API 網關

10.1 API網關的意義

10.2 常見API網關的實現方式

10.3 如何集成Zuul

10.4 實現API網關

**1章 微服務的部署與發布

11.1 部署微服務將面臨的挑戰

11.2 持續交付與持續部署微服務

11.3 基於容器的部署與發布微服務

11.4 使用Docker來構建、運行、發布微服務

**2章 微服務的日志與監控

12.1 微服務日志管理將面臨的挑戰

12.2 日志集中化的意義

12.3 常見日志集中化的實現方式

12.4 Elastic Stack實現日志集中化

**3章 微服務的集中化配置

13.1 為什麼需要集中化配置

13.2 使用Config實現的配置中心

**4章 微服務的高題——自動擴展

14.1 自動擴展的定義

14.2 自動擴展的意義

14.3 自動擴展的常見模式

14.4 如何實現微服務的自動擴展

**5章 微服務的題——熔斷機制

15.1 什麼是服務的熔斷機制

15.2 熔斷的意義

15.3 熔斷與降級的區別

15.4 如何集成Hystrix

15.5 實現微服務的熔斷機制

**6章 微服務的**主題——分布式消息總線

16.1 消息總線的定義

16.2 Spring Cloud Bus設計原理

16.3 如何集成Bus

16.4 實現配置信息的自動*新



附錄A：本書所涉及的技術及相關版本

參考文獻

\"1.2 常見分布式繫統架構 復雜的大型軟件繫統，傾向於使用分布式繫統架構。就像 Warren Buffett 有個關於投資的名言，就是“不要把雞蛋放在一個籃子裡”。對於繫統而言也是如此。廠商的機器不可能保證永遠不壞，也無法保證黑客不會來對繫統搞破壞，*為關鍵的是，我們無法保證自己的程序不會出現Bug。問題無法避免，錯誤也不可避免。我們隻能把雞蛋分散到不同的籃子裡，來減少“一鍋端”的風險。這就是需要分布式繫統的一個重要原因。使用分布式繫統的另外一個理由是可擴展性。畢竟任何主機（哪怕是小型機、**計算機）都會有性能的極限。而分布式繫統可以通過不斷擴張主機的數量以實現橫向水平性能的擴展。本章將會介紹市面上常見的分布式繫統架構，並對這些架構做優缺點的比較。本章大部分內容源自筆者的另一本書《分布式繫統常用技術及案例分析》1，有興趣的讀者也可以作為參考。
1.2.1 分布式對像體繫 在基於對像的分布式繫統中，對像的概念在分布式實現中起著極其關鍵的作用。從原理上來講，所有的一切都被作為對像抽像出來，而客戶端將以調用對像的方式來獲得服務和資源。分布式對像之所以成為重要的範型，是因為它相對比較容易地把分布的特性隱藏在對像接口後面。此外，因為對像實際上可以是任何事務，所以它也是構建繫統的強大範型。面向對像技術於20 世紀80 年代開始用於開發分布式繫統。同樣，在達到高度分布式透明性的同時，通過遠程服務器宿主獨立對像的理念構成了開發新一代分布式繫統的穩固的基礎。在分布式對像體繫架構中，比較有代表性的技術有 DCOM、CORBA 及 RMI。
1. DCOM（COM+） 1992 年4 月，微軟發布 Windows 3.1 ，包括一種被稱為 OLE（Object Linking and Embedding）的機制。這允許一個程序動態鏈接其他庫來支持其他功能，如將一個電子表格嵌入 Word 文檔。OLE演變成了 COM （Component Object Model）。一個 COM 對像是一個二進制文件。使用 COM 服務的程序來訪問標準化接口的 COM 對像，而不是其內部結構。COM 對像用全局**標識符（GUID）來命名，用類的 ID 來識別對像的類。可以有多種方法來創建一個 COM 對像，如 CoGetInstance-FromFile。COM 庫在繫統注冊表中查找相應的二進制代碼（一個 DLL 或可執行文件）來創建對像，並給調用者返回一個接口指針。COM 的著眼點是在同一臺計算機上不同應用程序之間的通信需求。
DCOM（Distributed Component Object Model）是 COM 的擴展，它支持不同的兩臺機器上組件間的通信，而且無論它們是運行在局域網、廣域網，還是 Internet 上。借助 DCOM 的應用程序將能夠進行任意空間分布。DCOM 於1996 年在 Windows NT 4.0 中引入，後來*名為 COM+。由於DCOM 是為了支持訪問遠程 COM 對像，需要創建一個對像的過程，此時需要提供服務器的網絡名及類 ID。微軟提供了一些機制來實現這一點。*透明的方式是遠程計算機的名稱固定在注冊表（或DCOM 類存儲）裡，與特定類 ID 相關聯。采用這種方式之後，應用程序便不知道它正在訪問一個遠程對像，並且可以使用與訪問本地 COM 對像相同的接口指針。另外，應用程序也可指定一個機器名作為參數。
由於 DCOM 是 COM 這個組件技術的無縫升級，所以能夠從現有的有關 COM 的知識中獲益，以前在 COM 中開發的應用程序、組件、工具都可以移入分布式的環境中。DCOM 將屏蔽底層網絡協議的細節，你隻需要集中精力於應用。
DCOM *大的缺點是，這是微軟**的解決辦法，但在跨防火牆方面的工作做得不是很好（大多數RPC 繫統也有類似的問題），因為防火牆必須允許某些端口來讓 ORPC 和 DCOM 通過。
\"