開篇必水

分散式系統比單機系統複雜得多，但經過多年的發展，業界已經有了豐富的分散式系統理論，也有了許多優秀的元件。在分散式系統理論裡，最近流行的微服務架構理論成了佼佼者，微服務的概念也成了當前分散式系統實現方案中的主流，顯然，微服務架構成了分散式系統的一種形式。優秀的分散式系統元件早期主要以國內阿里巴巴的Dubbo(現今已經被Apache歸納進入其孵化器）為主，後來從國外引入了Spring Boot和Spring Cloud，它們現在是微服務實現的主流方案。

為順應技術的發展趨勢，我對微服務進行了深入的學習和研究，並且於2018年創作出版了《深入淺出Spring Boot 2.x》。

 

為了更進一步地講解微服務，滿足當前企業搭建微服務系統的需要，我竭盡所能編寫了這本關於Spring Cloud的書。雖然Spring Cloud能夠有雙搭P微服務系統，但微服務系統只是分散式系統的一種形式，它並不能解決分散式系統的所有問題，例如，分散式快取、會話、資料庫及其事務等，都不能通過Spring Cloud來有效處理。但這些問題又是企業實施微服務系統時必須要面對的，甚至是一些企業的難點和痛點。因此，本書在詳細介紹Spring Cloud的基礎上，還會對常用的分散式技術進行講解，以滿足企業的需要。

 

內容安排

本書基於一線企業的實際應用需求，介紹Spring Cloud微服務和常用的分散式系統。整體來說，全書分為4個部分。

第一部分：概述和基礎（1~2章）

本部分將講解分散式和微服務的基礎知識和理念，並且簡單介紹本書需要用到的基礎知識。

第1章分散式和微服務概述

 

第2章技術基礎：為了更好地介紹Spring Cloud,這裡稍微介紹- .下Spring Boot和HTTP的REST風格。因為SpringCloud是以Spring Boot作為基石的，而各個服務系統又是通過REST風格的請求整合在-起的， 所以學習它們將有助於我們深入學習Spring Cloud。當然，如果你已經對它們很熟悉了，也可以跳過本章，直接學習第3章的內容。

 

第二部分：Spring Cloud微服務（3~12章）

介紹Spring Cloud的各類元件,這是微服務的核心內容。介紹的元件包括服務註冊和服務發現(Eureka)、服務呼叫(Ribbon 和OpenFeign)、斷路器(Hystix 和Resilience4j)、閘道器(Zuul和Gateway)、配置(Config)、 全鏈路追蹤(Sleuth)、 微服務的監控(Admin)等。

第3章服務治理——Eureka：,Pivotal團隊通過Spring Boot形式的封裝將Nettlix公司開發的分散式系統元件封裝了起來，其中就包括Eureka, Eureka是Spring Cloud的服務治理中心。在使用Spring Boot進行了二次封裝後，Bureka 的使用就顯得十分簡易了。Eureka 作為一個微服務的治理中心，它是一個服務應用，可以接收其他服務的註冊，也可以發現和治理服務例項。

 

第4章客戶端負載均衡——Ribbon：Spring Cloud Netflix Ribbon是一種客戶端負載均衡的元件，為了方便，在本書中都簡稱為Ribbon。在微服務架構中，我們依照業務將系統進行切分，但一個實際的業務往往需要多個微服務通過相互協作來完成，所以各種微服務之間存在服務呼叫。

 

第5章斷路器——Hystrix：Spring Cloud社群推薦開發者使用其他仍然活躍的開源專案，其中最推薦使用的是Resilience4J, 並且Spring Cloud社群也在加緊開發spring cloud-ircuitbreaker,來取代Hystrix。但這個專案還在開發中,並沒有釋出，加之當前不少企業也在使用Hystrix, 並且技術是相通的，所以這裡還是決定介紹一下 Hystrix。

 

第6章新斷路器——Resilience4j：Resilience4j是一個輕量級的、易於使用的容錯框架，它是受Netflix的Hystrix的啟發,基於Java8和函數語言程式設計設計的，所以在使用它的時候，可以看到大量的函數語言程式設計設計。它與Hystrix 相比有幾個不同點。

 

第7章宣告式呼叫——OpenFeign：本書從第3章到第6章，介紹了微服務的核心內容:服務治理、服務呼叫(Ribbon)和熔斷器(Hystrix和Resilience4j)。這些都是微服務的利器，只是從開發者的角度來說，和我們打交道最多的.是服務呼叫和熔斷器。服務呼叫使得多個微服務可以通過相互呼叫，為同一個業務服務。熔斷器則可以在很大的程度上保證服務呼叫。但是嚴格來講，Ribbon 使用REST請求方式編寫還是比較麻煩的，對於開發者也不算友好，因此在REST 請求方式的基礎上，一些開發者 又提供了介面宣告方式的呼叫，例如，我們本章要介紹的GitHub OpenFeign就是這樣的。

 

第8章舊API閘道器——Zuul：前面幾章，我們學習了服務註冊和發現(Eureka)， 通過它們，我們能夠順利地管理我們的服務;學習了服務之間的呼叫(Ribbon 和OpenFeign)，讓各個服務聯絡起來，通過共同協助來完企業業務邏輯;還學習了斷路器(Hystrix和Resilience4j)，它能儘可能地保護微服務之間的呼叫，通過熔斷的方式來避免服務依賴造成的雪崩。以上談到的這些都是Spring Cloud微服務的核心元件。本章開始讓我們學習微服務最後的一一個核心元件一API 閘道器。Netflix Zuul是-一個API閘道器，它的主要功能是提供閘道器服務。

第9章新閘道器——Spring CloudGateway：在第8章中，我們講述了舊閘道器Netlix Zuul,並且告知讀者，Zuul 1.x只是效能一-般的閘道器,加上Netlix Zuul 2.x版本經常不能如期釋出，所以新版的Spring Cloud不打算捆綁Zul了。新版的Spring Cloud提供了新的閘道器給開發者使用，這便是Spring Cloud Gateway。為了簡便，下 文在沒有特別指明的情況下，將簡稱它為Gateway。Gateway 並非是使用傳統的Jakarta EE的Servlet容器，它是採用響應式程式設計的方式進行開發的。在Gateway中，需要Spring Boot和Spring WebFlux提供的基於Netty的執行環境。

 

第10章配置——Spring Cloud Config：Spring Cloud Config (為了方便，在不產生歧義時，全書都簡稱為Config)是一個支援微服務和分散式集中化提供配置的專案。微服務架構中的例項可能會非常多，如果一個個地更新配置，運維成本會十分大。為了簡化配置的複雜性，一些開發者提出 了集中化管理配置的概念，也就是提供一個集中化的配置中心，讓我們可以統- -配置各個微服務例項。本章要講的Config 就是出於這個目的設計的。

 

第11章Spring Cloud Sleuth全鏈路追蹤：在前面的章節中，我們學習了Eureka 服務治理中心，通過它可以管理各個服務，使得它們能夠相互協作工作。但是隨著業務變得複雜，服務也會複雜起來，加上每-一個服 務都可以有多個例項，一旦發生 問題，將很難查詢問題的根源。為了解決這個問題，許多分散式開發者都開發了自己的鏈路監控元件,使得請求能夠追蹤到各個服務例項中,典型的如谷歌(Google)的Dapper、推特(Twitter)的Zipkin和阿里巴巴(Alibaba) 的EagleEye, 它們都是當前著名的鏈路追蹤元件。

 

第12章微服務的監控——Spring Boot Admin：在一個優秀的分散式系統中，監控服務例項，及時發現例項存在的問題是十分重要的。SpringBoot Admin就提供了這樣的功能，為了方便，在不引起歧義的情況下，下文將Spring Boot Admin簡稱為Admin。Admin 是一個監控平臺，它可以檢測各個Spring Boot應用，讓運維和開發人員及時發現各個服務例項存在的問題。Admin 是一個 基於Spring Boot Actuator 的控制檯，也就是它可以通過Spring Boot Actuator暴露的端點，來監測各個例項的執行狀況。Admin 的使用者介面(User Interface,UI)是採用AngularJs應用程式構建的。

 

第三部分：分散式技術（13~18章）

講解分散式的其他知識，包括分散式發號機、分散式資料庫、分散式快取、分散式會話和許可權等。

第13章生成唯一的ID——發號機制：在資料庫(請注意，在本章中，如果沒有特別說明，講到的資料庫就都是指關聯式資料庫，而不包含類似Redis這樣的非關聯式資料庫)中，主鍵往往是一條記錄的唯一標識，它具備唯- -性。 在單機的時候，只需要考慮單個資料庫的問題，相對簡單，但在分散式和微服務系統裡，就相對困難了，因為它涉及多臺機器之間的協作。那麼如何保證在分散式或者微服務的多個節點下生成唯一的ID, 如何讓ID具備- -定的可讀性呢? 這就需要一個發 號機制來控制了。如何實現發號機制，便是本章要討論的問題。

 

第14章分散式資料庫技術：在第1章我們談過，網際網路會員的增加和業務的複雜化，必然導致大資料的儲存，這時使用單機資料庫對資料儲存和訪問，就顯得捉襟見肘了。而劃分的方法在第1章也談過，主要是水平、垂直以及混合分法。對分散式和微服務來說，一種業務就可能有很多的資料，如交易，單資料庫也很有可能無法支撐，需要多個資料庫節點進行支援，這種需要將資料庫拆分為多節點進行儲存的技術，便是本章需要的論的分散式資料庫技術。為了更好地闡述分散式資料庫的知識，我們首先從分表、分庫和分割槽這樣的資料庫知識開始講述。不過本章我們還不會討論分散式事務的相關知識，這將會在下章進行討論。

 

第15章分散式資料庫事務：上一章中，我們討論了分散式資料庫的知識，主要是分片技術。這一章讓我們來討論分散式資料庫事務，我們知道在網際網路的世界中，有些資料對一致性的要求是十分苛刻的，如商品的庫存和使用者的賬戶資金，而這些卻極有可能分別儲存在不同的資料庫節點中，那麼如何在多個資料庫節點中保證這些資料的一致性，就是分散式資料庫事務要解決的問題。

 

第16章分散式快取——Redis：在當前網際網路中，快取系統一般由Redis來完成，所以後續我們會集中討論Redis， 就不再討論其他快取系統了。本書採用的是Redis的5.0.5版本，如果採用別的版本，在配置項上會有少量不同，不過也大同小異，不會有太大的問題。

 

第17章分散式會話：在分散式系統中，有多個伺服器節點，這些節點甚至是跨服務的，如果會話資訊只在一個節點上， 就需要- -定的機制來保證會話在多個服務節點之間能夠共享,方便是本章要討論的分散式會話。在分散式會話中，最重要的功能是安全驗證，因為不同的使用者會有不同的許可權。

 

第18章分散式系統許可權驗證：本章會講述分散式系統的許可權驗證。實際上，在分散式會話中談到的使用快取儲存會話(springsession-data-redis)，也能在一定程度 上支援分散式的許可權驗證，不過一切還 需要從最基礎的Spring Security開始講起。因為這裡涉及的內容較多，所以我還是新建了工程，且將其命名為chapter18，這樣就可以根據需要新增對應的模組了。

 

第四部分：微服務系統實踐（19~20章）

通過Apache Thrift 講解遠端過程呼叫(RPC)，並且講解在分散式中處理高併發的一些常用技巧，最後給出一個微服務例項。

第19章遠端過程呼叫：遠端過程呼叫(Remote Procedure Call, RPC)是-種服務呼叫的方式，它在許多企業中也得到了很多的應用。事實上，在微服務中，推薦我們使用的是REST風格的呼叫，而非RPC。那麼為什麼需要使用RPC?又如何使用呢?

 

第20章微服務設計和高併發實踐：以上幾章已經闡述了大部分搭建微服務的內容，本章主要講微服務實踐。在微服務中，要解決的大問題是高併發問題，這也是分散式中最受到關注的問題之一。

 

因為這份《spring cloud微服務和分散式系統實戰》和《深入淺出springboot2.0》內容實在太多，兩本書加起來一共971頁，沒有辦法給大家全部展示出來，需要獲取的小夥伴可以看這裡哦！