産品特色

編輯推薦

（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企業級應用開發實戰》。

內頁插圖

目錄

目錄
第1章 微服務概述
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 實現服務的負載均衡及高可用
第10章 API 網關
10.1 API網關的意義
10.2 常見API網關的實現方式
10.3 如何集成Zuul
10.4 實現API網關
第11章 微服務的部署與發布
11.1 部署微服務將麵臨的挑戰
11.2 持續交付與持續部署微服務
11.3 基於容器的部署與發布微服務
11.4 使用Docker來構建、運行、發布微服務
第12章 微服務的日誌與監控
12.1 微服務日誌管理將麵臨的挑戰
12.2 日誌集中化的意義
12.3 常見日誌集中化的實現方式
12.4 Elastic Stack實現日誌集中化
第13章 微服務的集中化配置
13.1 為什麼需要集中化配置
13.2 使用Config實現的配置中心
第14章 微服務的高級主題——自動擴展
14.1 自動擴展的定義
14.2 自動擴展的意義
14.3 自動擴展的常見模式
14.4 如何實現微服務的自動擴展
第15章 微服務的高級主題——熔斷機製
15.1 什麼是服務的熔斷機製
15.2 熔斷的意義
15.3 熔斷與降級的區彆
15.4 如何集成Hystrix
15.5 實現微服務的熔斷機製
第16章 微服務的高級主題——分布式消息總綫
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 通過。

書質量不錯，用得上，好好學習一下

希望下次能用紙盒子包裝一下，

還行吧，不知道為什麼不用maven部署 感覺gradle用的少 可能我跟不上潮流

快速入門的選擇，給團隊新人看最好瞭。

還行，。。。。。。。。。。。。。

買瞭好多書，很劃算哦！好評！！！

書本有的有薄膜封麵，有的沒有，有點奇怪，不過內容還是值得一看

我不是排斥袋子，

不錯的書，雖然還沒看完，但是網上推薦都不錯，看瞭一些，確實如此。