屌的一批，阿里P8推荐的Spring Cloud实战笔记

Spring Cloud 前世今生

Spring Cloud体系由Spring 在2015年年初推出，至今已经五年多，其子项目在不断增加与完善，其所包含的功能点已经基本满足整个微服务体系的需求。加上Spring本身强大的技术后盾和活跃的技术社区氛围，Spring Cloud已经形成了一股势不可挡的力量，迅速扩张、覆盖至整个互联网技术公司。尝试调研使用并在生产环境落地Spring Cloud的互联网公司越来越多，Netflix公司也在不断迭代与完善其组件，源源不断地供给Spring Cloud更新的源泉。

Spring Cloud问世之前各大互联网公司都有自己的服务框架，大多数是在参考业内的基础上自主研发，导致各个公司重复造轮子，浪费了资源并降低了效率，一旦开发人员更替有很大可能停止维护又重新造个轮子。技术人员在更换工作的时候要重新熟悉新公司的整个技术体系，带来的成本也很高，像很多年前SSH一统江湖的时候每个公司都是SSH,在技术层面形成了大一统之势。利用SpringCloud，无技术体系切换的学习成本，由Apache、Spring等开源组织维护技术框架，互联网公司可以更多专注于自身公司的业务层面。

今天给大家分享一份《极简Spring Cloud实战》本书精巧实用、快速入门，资深Spring Cloud践行者经验集结，组件应用与原理分析结合，并以综合案例融合微服务和DevOps实践

如何阅读本书

本书分为三篇，共14章内容。

基础服务篇(第1~9章)：本篇内容是实践微服务必备的知识点和技能，需要重点学习。

任务与消息篇(第10~13章)：主要介绍消息处理以及任务流依赖处理方面的组件的使用及其实现原理。

微服务实战篇(第14章)：本篇是基于Spring Cloud、Docker、OAuth2构建微服务的一个完整案例。

第一篇　基础服务篇

本篇将为读者介绍微服务架构的演进过程,带领读者了解什么是微服务，为什么需要微服务,以及微服务与Spring Cloud之间是什么关系,为什么要选择Spring Cloud来实现微服务而不是市面上现存的其他解决方案。了解之后,相信读者会有自己的答案。

第1章微服务与Spring Cloud：第1章对微服务演进历程以及Spring Cloud 的全貌进行了提纲挈领的介绍，以期读者有全局性认知，使后面的学习不会碎片化。

第2章服务发现: Eureka：Eureka是 Netflix开源的一款提供服务注册和发现的产品，提供了完整的服务注册和服务发现实现，也是Spring Cloud体系中最重要、最核心的组件之一。通俗讲，Eureka就是一个服务中心，将所有可以提供的服务都注册到它这里来管理，其他各调用者需要的时候去注册中心获取，然后服务调用方再向服务提供方发起调用，避免了服务之间的直接调用,方便后续的水平扩展、故障转移等。

第3章　配置中心：Config：Spring Could Config是一个提供了分布式配置管理功能的Spring Cloud子项目。在以往的单体应用中往往是代码与配置文件放在一个应用包中，但是随着系统的体量越来越大,我们会将系统分成多个服务，对于这么多服务的配置管理以及热生效等方面的支持将会越来越麻烦。Spring Cloud Config 完美解决了这些问题。

第4章　客户端负载均衡：Ribbon：Ribbon是一个基于HTTP和TCP客户端的负载均衡器。它可以在客户端配置ribbonServerList(服务端列表)，然后轮询请求以实现负载均衡。它在联合Eureka使用时,ribbonServerList 会被
DiscoveryEnabledNIWSServerList重写，扩展成从Eureka注册中心获取服务端列表。同时它会用NIWSDiscoveryPing来取代IPing，它将职责委托给Eureka来确定服务端是否已经启动。

第5章　RESTful客户端：Feign：在实际开发过程中，尽管Eureka的注册发现和Ribbon的客户端负载均衡很强大，但是我们不可能每次都对URL进行远程调用，像拼参数这种事情会让每个开发人员痛苦不堪，而Feign将会解决这些问题。Feign是一个Web服务的客户端框架，它让 Web服务的客户端开发变得更容易。只需要使用Feign创建一个接口加上一个注解就行了。在使用Feign时，Spring Cloud还可以整合Ribbon和Eureka，为HTTP客户端提供负载均衡的能力。

第6章　熔断器：Hystrix：微服务架构中，一般存在着很多服务单元。这样就有可能某个单元因为网络原因或自身问题而出现故障或延迟，导致调用方的对外服务也出现延迟。如果此时调用方的请求不断增加，时间一长就会由于等待故障方响应而形成任务积压，最终导致调用方自身服务的瘫痪。为了解决这种问题，便出现了断路器(或称熔断器，Circuit Breaker)模式。

第7章　路由网关：Zuul：Spring Cloud体系中支持API Gateway落地的技术就是Zuul。Spring Cloud Zuul路由是微服务架构中不可或缺的一部分，提供动态路由、监控、弹性和安全等边缘服务。

第8章　网关新选择：Gateway：Spring Cloud Gateway是Spring官方基于Spring 5.0、Spring Boot 2.0和 Project Reactor等技术开发的网关，Spring Cloud Gateway旨在为微服务架构提供一种简单而有效的统一的API路由管理方式。Spring Cloud Gateway作为Spring Cloud生态系中的网关，目标是替代Netflix Zuul。其不仅提供统一的路由方式，并且基于Filter链的方式提供了网关基本的功能,例如安全、监控/埋点和限流等。

第9章　调用链追踪：Spring Cloud Sleuth：主要介绍了Spring Cloud中注册中心的其他实现和快速调试、开发脚手架。

第10章　加密管理：Vault：通常项目中敏感配置信息一般需要进行加密处理，比如数据库密码等，但Spring Boot内置不提供加密支持，不能加密配置文件信息。HashiCorp Vault则可以解决这个问题，它提供集中管理密文和保护敏感数据的服务，而Spring Cloud Vault作为HashiCorp Vault的客户端，支持访问HashiCorp Vault内存储的数据，避免了在Spring Boot程序中存储敏感数据，为该场景提供了解决方案。它允许应用程序以透明的方式访问存储在Vault实例中的密文。比如API令牌、SSL证书和口令。它还可以负责处理用户的访问控制，具有撤销令牌、审计功能,跟踪用户等功能。

第11章　公共子项目：Spring Boot CLI是Spring Boot提供的一个命令行工具，它可以提供快速运行SpringBoot程序的功能，并支持插件功能，当我们为Spring Boot CLI安装上Spring Cloud插件时，它提供的命令行操作也可以用于Spring Cloud。我们可以支持Spring Cloud Config客户端对配置信息的加解密处理，甚至可以直接通过CLI在命令行上运行诸如Eureka、Zipkin、Config Server等服务。它为我们日常开发中调试搭建环境测试等场景提供了极大的便利。

第二篇　任务与消息篇

上一篇全面介绍了Spring Cloud生态中偏重于服务调用、服务治理、服务监控等方面的各个组件,接下来将进入一个新篇。这一篇将介绍Spring Cloud生态中有关消息总线、任务广播、批处理等方面的各个组件，同样非常实用。

第12章　消息驱动：Spring Cloud Stream：在企业级应用中处理非同步场景、消息通知、应用间解耦等场景经常会使用到消息中间件。我们可能已经使用过或者听过一些市面上常用的消息中间件，如ActiveMQ,RabbitMQ、MetaQ、kafka、 Redis 中的消息队列功能等。Spring Cloud Stream是一个构建消息驱动微服务的框架，基于Spring Integration并利用Spring Boot提供了自动配置，支持发布–订阅模型、消费者分组、数据分片等功能，提供极为方便的消息中间件使用体验。

第13章　消息总线：Spring Cloud Bus：Spring Cloud Bus通过轻量级消息代理连接各个分布的节点，以广播状态的变化(如配置变化)或者其他的消息指令。Spring Cloud Bus的一个核心思想是通过分布式的启动器对Spring Boot应用进行扩展，也可以用来建立多个应用之间的通信频道。目前唯一实现的方式是用AMQP消息代理作为通道队列，目前常用的有Kafka和RabbitMQ。