==
主要讲解内容
======
第1章分布式和微服务概述;
-
1.1互联网系统的特征
-
1.2分布式系统概述
-
1.3分布式系统的设计原则
-
1.4微服务架构
-
1.5 Spring Cloud
-
1.6微服务系统样例简介
**第2章技术基础;**为了更好地介绍Spring Cloud,这里稍微介绍一下Spring Boot和HTTP的REST风格。因为SpringCloud是以Spring Boot作为基石的,而各个服务系统又是通过REST风格的请求集成在一起的,所以学习它们将有助于我们深入学习Spring Cloud。当然,如果你已经对它们很熟悉了,也可以跳过本章,直接学习第3章的内容。
-
2.1 Spring Boot
-
2.2 REST风格简介
**第3章服务治理———Eureka;**Eureka是Spring Cloud的服务治理中心。在使用Spring Boot进行了二次封装后,Eureka的使用就显得十分简易了。Eureka作为一个微服务的治理中心,它是一个服务应用,可以接收其他服务的注册,也可以发现和治理服务实例。
-
3.1服务治理中心
-
3.2 Eureka治理机制
-
3.3 Eureka配置
**第4章客户端负载均衡——Ribbon;**Spring Cloud Netflix Ribbon是一种客户端负载均衡的组件,为了方便,在本文中都简称为Ribbon。在微服务架构中,我们依照业务将系统进行切分,但一个实际的业务往往需要多个微服务通过相互协作来完成,所以各种微服务之间存在服务调用。
在Spring Cloud中,提供的服务调用是Ribbon和 OpenFeign。Ribbon是Netflix公司开发的组件,Spring Cloud通过二次封装使得它更加简单易用。OpenFeign实际也是基于Ribbon来实现的。
微服务之间的调用往往被称为“客户端负载均衡”,这是因为在 Eureka 的机制中,任何微服务都是Eureka的“客户端”。通过第3章的学习,可以知道一个微服务可以存在多个实例,在进行服务调用的时候需要选取具体实例进行调用,这就需要通过具体的负载均衡算法来实现了。正如我们第3章的例子,产品微服务可能会调用资金微服务,但是资金微服务下面又分为多个实例,如何获取资金微服务下的多个实例是服务实例清单获取和维护的功能,而如何选取具体的服务实例就是负载均衡的功能了。
-
4.1负载均衡概述
-
4.2初识Ribbon
-
4.3Ribbon负载均衡器和策略
-
4.4 Ribbon服务实例清单维护
-
4.5自定义Ribbon客户端
-
4.6 Ribbon使用实践
**第5章断路器———Hystrix;**Spring Cloud Netflix Hystrix是一种断路器组件,在本书中,如果没有特殊说明,就将其简称为Hystrix。其实在写本章之前,我一直很犹豫要不要写Hystrix,因为 Netflix开源的限流组件Hystrix已经在其GitHub主页上宣布不再开发新功能了,只基于现有的功能进行维护。因此 Spring Cloud社区推荐开发者使用其他仍然活跃的开源项目,其中最推荐使用的是 Resilience4J,并且Spring Cloud社区也在加紧开发spring-cloud-circuitbreaker,来取代Hystrix。但这个项目还在开发中,并没有发布,加之当前不少企业也在使用Hystrix,并且技术是相通的,所以这里还是决定介绍一下Hystrix。
-
5.1概述
-
5.2入门实例
-
5.3 Hystrix工作原理
-
5.4 Hystrix实践
-
5.5仪表盘
-
5.6 Hystrix属性配置
**第6章新断路器———Resilience4j;**Resilience4j是一个轻量级的、易于使用的容错框架,它是受Netflix 的Hystrix 的启发,基于Java8和函数式编程设计的,所以在使用它的时候,可以看到大量的函数式编程设计。
-
6.1断路器(CircuitBreaker)
-
6.2限速器(RateLimiter)
-
6.3舱壁隔离(Bulkhead)
-
6.4重试器(Retry)
-
6.5缓爱存(Cache)
-
6.6时间限制器(TimeLimiter)
-
6.7组件混用
-
6.8使用Spring Boot 2的配置方式
**第7章声明式调用———OpenFeign;**本文从第3章到第6章,介绍了微服务的核心内容:服务治理、服务调用(Ribbon)和熔断器(Hystrix和Resilience4j)。这些都是微服务的利器,只是从开发者的角度来说,和我们打交道最多的是服务调用和熔断器。服务调用使得多个微服务可以通过相互调用,为同一个业务服务。熔断器则可以在很大的程度上保证服务调用。但是严格来讲,Ribbon使用REST 请求方式编写还是比较麻烦的,对于开发者也不算友好,因此在 REST请求方式的基础上,一些开发者又提供了接口声明方式的调用,例如,我们本章要介绍的GitHub OpenFeign就是这样的。
-
7.1 OpenFeign的使用
-
7.2配置Hystrix
-
7.3使用Resilience4j调用OpenFeign接口
**第8章旧API网关———Zuul;**前面几章,我们学习了服务注册和发现(Eureka),通过它们,我们能够顺利地管理我们的服务;学习了服务之间的调用(Ribbon和 OpenFeign),让各个服务联系起来,通过共同协助来完企业业务逻辑;还学习了断路器(Hystrix和Resilience4j),它能尽可能地保护微服务之间的调用,通过熔断的方式来避兔服务依赖造成的雪崩。以上谈到的这些都是Spring Cloud微服务的核心组件。
本章开始让我们学习微服务最后的一个核心组件~—API网关。Netflix Zuul是一个API网关,它的主要功能是提供网关服务。
-
8.1什么是网关
-
8.2 Zuul入门实例
-
8.3Zuul原理-过滤器
-
8.4限流
-
8.5动态路由
-
8.6灰度发布(金丝雀发布)
-
8.7使用Hystrix容断
**第9章新网关——Spring CloudGateway;**在第8章中,我们讲述了旧网关Netflix Zuul,并且告知读者,Zuul 1.x只是性能一般的网关,加上Netflix Zul 2.x版本经常不能如期发布,所以新版的Spring Cloud不打算捆绑Zuul了。新版的Spring Cloud 提供了新的网关给开发者使用,这便是Spring Cloud Gateway。为了简便,下文在没有特别指明的情况下,将简称它为Gateway。Gateway 并非是使用传统的JakartaEE的Servlet容器,它是采用响应式编程的方式进行开发的。在Gateway中,需要Spring Boot和Spring WebFlux提供的基于Netty的运行环境。
-
9.1认识Gateway
-
9.2断言(Predicate)
-
9.3过滤器(Filter)概述
-
9.4内置过滤器工厂
-
9.5自定义过滤器
-
9.6 Gateway知识补充
**第10章配置———Spring Cloud Config;**Spring Cloud Config(为了方便,在不产生歧义时,全书都简称为Config)是一个支持微服务和分布式集中化提供配置的项目。微服务架构中的实例可能会非常多,如果一个个地更新配置,运维成本会十分大。为了简化配置的复杂性,一些开发者提出了集中化管理配置的概念,也就是提供一个集中化的配置中心,让我们可以统一配置各个微服务实例。本章要讲的 Config就是出于这个目的而设计的。
-
10.1入门实例—使用Git仓库
-
10.2使用其他方式实现配置
-
10.3服务端的使用详解
**第11章Spring Cloud Sleuth全链路追踪;**在前面的章节中,我们学习了Eureka 服务治理中心,通过它可以管理各个服务,使得它们能够相互协作工作。但是随着业务变得复杂,服务也会复杂起来,加上每一个服务都可以有多个实例,一旦发生问题,将很难查找问题的根源。为了解决这个问题,许多分布式开发者都开发了自己的链路监控组件,使得请求能够追踪到各个服务实例中,典型的如谷歌(Google)的Dapper、推特(Twitter)的Zipkin和阿里巴巴(Alibaba)的EagleEye,它们都是当前著名的链路追踪组件。
-
11.1链路追踪的基本概念
-
11.2 Spring Cloud Sleuth和Zipkin
-
11.3实例
-
11.4持久化
**第12章微服务的监控——Spring Boot Admin;**在一个优秀的分布式系统中,监控服务实例,及时发现实例存在的问题是十分重要的。SpringBoot Admin就提供了这样的功能,为了方便,在不引起歧义的情况下,下文将Spring Boot Admin简称为Admin。Admin是一个监控平台,它可以检测各个Spring Boot应用,让运维和开发人员及时发现各个服务实例存在的问题。Admin是一个基于Spring Boot Actuator的控制台,也就是它可以通过Spring Boot Actuator暴露的端点,来监测各个实例的运行状况。Admin的用户界面(USser Interface,UI)是采用AngularJs应用程序构建的。
-
12.1本章实例简介
-
12.2 URL注册方式
-
12.3服务发现注册方式
-
12.4使用Spring Security保护Admin服务端
**第13章生成唯—的ID——发号机制;**在数据库(请注意,在本章中,如果没有特别说明,讲到的数据库就都是指关系数据库,而不包含类似Redis这样的非关系数据库)中,主键往往是一条记录的唯一标识,它具备唯一性。在单机的时候,只需要考虑单个数据库的问题,相对简单,但在分布式和微服务系统里,就相对困难了,因为它涉及多台机器之间的协作。那么如何保证在分布式或者微服务的多个节点下生成唯一的ID,如何让ID具备一定的可读性呢﹖这就需要一个发号机制来控制了。如何实现发号机制,便是本章要讨论的问题。
-
13.1生成ID的常见办法
-
13.2自定义发号机制
最后
分享一些系统的面试题,大家可以拿去刷一刷,准备面试涨薪。
这些面试题相对应的技术点:
- JVM
- MySQL
- Mybatis
- MongoDB
- Redis
- Spring
- Spring boot
- Spring cloud
- Kafka
- RabbitMQ
- Nginx
- …
大类就是:
- Java基础
- 数据结构与算法
- 并发编程
- 数据库
- 设计模式
- 微服务
- 消息中间件
786)]
[外链图片转存中…(img-HYHjNsXL-1714673960786)]
[外链图片转存中…(img-4TRMHzLH-1714673960786)]
[外链图片转存中…(img-rnlSqCjX-1714673960787)]
[外链图片转存中…(img-3fgeWr0Q-1714673960787)]
[外链图片转存中…(img-ZgNTHKFb-1714673960788)]
[外链图片转存中…(img-pgyg6hv8-1714673960788)]
[外链图片转存中…(img-X36bZlbD-1714673960789)]