前言

本文是以微服务与分布式开发结合的独特视角，展现来自一线开发者的实战经验总结，希望大家能够仔细品读，把握其中的真谛，不断地提高自己的技术深度和广度，才能在企业中更好的生存下来！

本文就给大家分享SpringCloud微服务和分布式系统实践的全部技术知识，总共有527页、20章的内容，因为内容实在是太多了，文中不能一一给大家体现出来，所以只能把部分知识点拿出来给大家介绍，每章都有更加细化的内容！

主要讲解内容

第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自定义发号机制

第14章分布式数据库技术；在第1章我们谈过，互联网会员的增加和业务的复杂化，必然导致大数据的存储，这时使用单机数据库对数据存储和访问，就显得捉襟见肘了。而划分的方法在第1章也谈过，主要是水平、垂直以及混合分法。对分布式和徼服务来说，一种业务就可能有很多的数据，如交易，单数据库也很有可能无法支撑，需要多个数据库节点进行支持，这种需要将数据库拆分为多节点进行存储的技术，便是本章需要讨论的分布式数据库技术。为了更好地阐述分布式数据库的知识，我们首先从分表、分库和分区这样的数据库知识开始讲述。不过本章我们还不会讨论分布式事务的相关知识，这将会在下章进行讨论。

14.1基础知识
14.2开发环境搭建
14.3分片算法
14.4分片中间件ShardingSphere

第15章分布式数据库事务；上一章中，我们讨论了分布式数据库的知识，主要是分片技术。这一章我们来讨论分布式数据库事务，我们知道在互联网的世界中，有些数据对一致性的要求是十分苛刻的，如商品的库存和用户的账户资金，而这些却极有可能分别存储在不同的数据库节点中，那么如何在多个数据库节点中保证这些数据的一致性,就是分布式数据库事务要解决的问题。

分布式数据库事务比单机数据库事务要复杂得多，它涉及多个数据库节点之间的协作。在第1章中，我讲过BASE理论，在分布式数据库中，存在强一致性和弱一致性。所谓强一致性是指任何多个后续线程或者其他节点的访问都会返回最新值。弱一致性是指当用户对数据完成更新操作后，并不保证在后续线程或者其他节点马上访问到最新值，它只是通过某种方法来保证最后的一致性。强一致性的好处是，对于开发者来说比较友好，数据始终可以读取到最新值，但这种方式需要复杂的协议，并且需要牺牲很多的性能。弱一致性，对于开发者来说相对没有那么友好，无法保证读取的值是最新的，但是不需要引入复杂的协议，也不需要牺牲很多的性能。事实上，在发生一定的不一致的情况下，我们可以采取多种方式进行补救，用户的快速体验，往往比保证强一致性重要，所以在当今互联网的开发中，弱一致性占据了主导地位。而从微服务的角度来说，强一致性是不符合微服务的设计理念的，这些都会在本章进行讲解。

15.1强─致性事务
15.2弱—致性事务
15.3分布式事务应用的实践理论

第16章分布式缓存——Redis；

16.1 Redis的高可用
16.2使用─致性哈希(ShardedJedis)
16.3分布式缓存实践

第17章分布式会话；会话(session)是指客户端和服务器之间的交互过程中，由服务器端分配的一片内存空间，它用于存储客户端和服务端交互的数据，例如，典型的电商网站的购物车。这片内存空间是由对应的客户端和服务器共享的，它可以存储那些需要暂存的和常用的数据，以便后续快速方便地读出。在会话机制中，为了使浏览器和服务器能够对应起来，会使用一个字符串进行关联，例如，Tomcat中的sessionId。在单体系统中，因为服务器实例只有一个，所以只需要将用户的数据存入到自己的内存中就可以反复读出了。在分布式系统中，有多个服务器节点，这些节点甚至是跨服务的，如果会话信息只在一个节点上，就需要一定的机制来保证会话在多个服务节点之间能够共享，这便是本章要讨论的分布式会话。在分布式会话中，最重要的功能是安全验证，因为不同的用户会有不同的权限。

17.1分布式会话的几种方式
17.2黏性会话
17.3服务器会话复制
17.4使用缓存(spring-session-data-redis)
17.5持久化到数据库

第18章分布式系统权限验证；在计算机系统中，权限往往也是很重要的一个部分。在单体系统中，权限往往很容易控制，但是在分布式系统中，则不然。因为在单体系统中往往只有一个节点，只要解决单点就可以了。但是分布式系统是多节点协作，不能一个节点验证通过后，另外一个节点却没有验证通过，所以本章将会讲述分布式系统的权限验证。实际上，在分布式会话中谈到的使用缓存存储会话(spring-session-data-redis)，也能在一定程度上支持分布式的权限验证，不过一切还需要从最基础的 Spring Security开始讲起。因为这里涉及的内容较多，所以我还是新建了工程，且将其命名为chapter18，这样就可以根据需要新增对应的模块了。