More  

收藏本站

電腦請使用 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頁,沒有辦法給大家全部展示出來,需要獲取的小夥伴可以直接轉發+關注後私信(學習)即可免費獲取!