收藏本站

電腦請使用 Ctrl + D 加入最愛
手機請使用 收藏
關閉

小編的世界 優質文選 主機

阿裏P8結合企業真實需求講解微服務(分布式)系統開發進階筆記


字體大小:
2020年10月16日 -
:        
 

為了更進一步地講解微服務,滿足當前企業搭建微服務系統的需要,我竭盡所能編寫了這本關於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頁,沒有辦法給大家全部展示出來,需要獲取的小夥伴可以直接轉發+關注後私信(學習)即可免費獲取!

  大家在看    
我國網絡受美國“根服務器”限制,一旦對方關閉,會

我國網絡受美國“根服務器”限制,一旦對方關閉,會

《MIR4(傳奇4)》免費開放 服務器登陸問題遭

《MIR4(傳奇4)》免費開放 服務器登陸問題遭

聯想 戴爾 華為 浪潮全系列 服務器 存儲 工作

聯想 戴爾 華為 浪潮全系列 服務器 存儲 工作

11.11什麼值得買?有顏又能打的PowerEd

11.11什麼值得買?有顏又能打的PowerEd

1U GPU Server 服務器 新一代 GP

1U GPU Server 服務器 新一代 GP

永劫無間服務器炸了,玩家大罵rnm退錢

永劫無間服務器炸了,玩家大罵rnm退錢

服務器崩潰!LOL手遊由於太過火爆,將禁止加速器

服務器崩潰!LOL手遊由於太過火爆,將禁止加速器

數據庫存儲服務器怎樣購買?看完以下五點再做決定

數據庫存儲服務器怎樣購買?看完以下五點再做決定

非常鑒定室|《你是我的榮耀》更新讓服務器崩了!這

非常鑒定室|《你是我的榮耀》更新讓服務器崩了!這

美國心虛啥?對服務器發動攻擊,企圖破壞調查德堡實

美國心虛啥?對服務器發動攻擊,企圖破壞調查德堡實