Thinkingcao的专栏

SpringCloud从入门到精通系列教程，持续更新中......................

一、什么是负载均衡？负载均衡可以想象为将所有请求先聚在一起，然后根据负载均衡算法分发请求达到合理分配请求，将服务器处理请求的效率达到最大化，为微服务集群分担请求，降低系统的压力。负载均衡算法：1、随机，通过随机选择服务进行执行，一般这种方式使用较少;2、轮训，负载均衡默认实现方式，请求来之后排队处理;3、加权轮训，通过对服务器性能的分型，给高配置，低负载的服务器分配更高的权重，均衡各个服务器的压力;4、地址Hash，通过客户端请求的地址的HASH值取模映射进行服务器调度。5、最小链接数;即使

一、前言在Ribbon组件中，一共提供了7种负载均衡策略规则，默认使用轮训规则RoundRobinRule：最低并发策略BestAvailableRule： 选择最小请求数可用过滤策略（AvailabilityFilteringRule）： 过滤掉连接失败的服务节点，并且过滤掉高并发的服务节点，然后从健康的服务节点中，使用轮询策略选出一个节点返回。随机策略 RandomRule ： 随机选择一个server轮询策略 RoundRobinRule： 轮询选择server（Ribbon

一、背景在之前对Spring Cloud微服务系列组件进行了一个系统的学习，并且在前面的一些微服务组件学习过程中，总结了一些学习心得以及对于在学习这些微服务组件后的一些个人理解；恰好最近公司有个规模较大的项目，需要考虑到上微服务架构，所以我就主动申请了挑战一下这个新技术。二、面对技术选型的挑战大家都知道，在Spring Cloud经历过几个大版本的发布后，变得愈来愈成熟，而其中的大部分组件是由国外著名的Netflix的流媒体播放公司开源贡献的，在后续的更新中，Netflix公司提出了一些组件相继停更。

一. 前言在开发SpringCloud项目架构的项目时，服务与服务之间的调用通过Feign客户端实现，在做一个从Feign客户端到service服务端的POST请求时，Feign客户端为服务消费者觉得，service服务端为服务提供者角色，提供者角色中service服务端Controller类中方法测试正常，但却在Feign客户端返回时报错，大致异常如下：Caused by: java.io.IOException: Incomplete output stream at sun.net.www

前言在SpringCloud微服务架构的项目中，服务之间的调用是通过Feign客户端实现。默认情况下在使用Feign客户端时，Feign 调用远程服务存在Header请求头参数丢失问题，例如一个订单服务Order和一个商品服务Product，调用关系为： 用户下单调用订单服务，订单库创建一笔订单，同时商品服务扣减库存数量；在订单服务通过Feign调用商品服务中扣减库存的接口时，由于Feign是一个伪HTTP客户端，这时相当于重新生成一个HTTP请求，会出现请求头Header参数丢失问题，那么下面给大家介绍

在使用SpringCloud及SpringBoot搭建项目框架之前，都需要去了解二者之间版本的兼容对应关系，关于SpringBoot和SpringCloud官方版本号的命名规则很是好奇，想要一探究竟，那么显而易见，SpringBoot的版本号是通过数字来命名的，SpringCloud则是通过希腊英文字母的方式，在发布的版本时是以伦敦地铁站作为版本命名，并按地铁站名称的首字母A-Z依次命名。

为什么放弃Dubbo 使用SpringCloud？相同点：SpringCloud 和Dubbo可以实现RPC远程调用框架，可以实现服务治理。不同点:SpringCloud是一套目前比较网站微服务框架了，整合了分布式常用解决方案遇到了问题注册中心Eureka、负载均衡器Ribbon ，客户端调用工具Rest和Feign，分布式配置中心Config，服务保护Hystrix，网...

1.使用Feign调用接口分为两层，Ribbon的调用和Hystrix的调用，所以Ribbon的超时时间和Hystrix的超时时间的结合就是Feign的超时时间。2.一般情况下 都是 Ribbon 的超时时间（<）Hystrix的超时时间（因为涉及到Ribbon 的重试机制），如果Ribbon 的超时时间大于Hystrix的超时时间，对于Ribbon 的重试是没有意义的（Hystrix超时熔断了，Ribbon 无法重试）。

一. 背景在微服务项目中，我的服务消费使用的是Feign客户端，在调用服务提供者的时候报超时异常了，异常如下：com.netflix.hystrix.exception.HystrixRuntimeException: RemoteCardImgHandleFeign#getVehicleLicenseInfos(CardInfosVi) timed-out and fallback fail...

一、前言在搭建SpringCloud项目环境架构的时候，Springboot版本与SpringCloud版本对应关系很重要，如果版本不对应，常见的会遇见项目启动不起来，怪异的会是项目出现一些诡异的问题。Release train Spring Boot compatibilitySpring Cloud Release TrainSpring Boot VersionHo...

一、问题在一次项目架构中，使用SpringCloud微服务架构，其中将Alibaba-Cloud配置SpringCloud组件使用，服务发现和配置中心使用的是阿里巴巴开源的组件nacos，nacos-server部署在linux下的centos7.0环境上，每个服务启动时都会去连接nacos-server端，在nacos-server部署在Linux环境下时，由于网络限制的原因，框架bug就产生...

一、背景随着互联网的蔓延，各种传统项目(单体应用)已经不能够满足当前各种复杂的场景需求，都逐渐向分布式服务、微服务做转换，如今分布式、微服务已经普遍存在，大型网站几乎都是分布式、微服务架构的，分布式和微服务架构就显得尤为重要了。分布式和微服务系统的最大难点，就是各个节点的状态如何保持同步，这也是理解分布式、微服务的起点，设计和部署分布式系统时，所有分布式及微服务系统都需遵循CAP定律和BASE理...

一、前言

一、前言

**GatewayFilter ：** `GatewayFilter`称为内置过滤器，需要通过 spring.cloud.routes.filters配置在具体路由下，只作用在当前路由上或者特定路由上，可以通过配置 spring.cloud.default-filters，表明作用在所有路由上，GatewayFilter允许以某种方式修改传入的HTTP请求或传出的HTTP响应。路由过滤器适用于特定路由。Spring Cloud Gateway提供了许多内置的GatewayFilter工厂。

Spring Cloud Gateway 根据过滤器`Filter`的作用范围划分为`GatewayFilter `和 `GlobalFilter`，二者区别如下：- **GatewayFilter ：** `GatewayFilter `称为内置过滤器，需要通过 `spring.cloud.routes.filters `配置在具体路由下，只作用在当前路由上或者特定路由上，可以通过配置 `spring.cloud.default-filters `，表明作用在所有路由上，`GatewayFilter

一、下一代微服务网关GatewaySpring Cloud Gateway提供了一个在Spring生态系统之上构建的API网关，包括：Spring 5，Spring Boot 2和Project Reactor。Spring Cloud Gateway旨在提供一种简单而有效的方法来路由到API，并为它们提供跨领域的关注，例如：安全性，监视/指标和弹性。并且从引入的`spring-cloud-starter-gateway`依赖信息可见，Spring Cloud Gat

官网文档： https://cloud.spring.io/spring-cloud-static/spring-cloud-gateway/2.2.1.RELEASE/reference/html/一.什么是Spring Cloud Gateway来自官方文档的一句话： Spring Cloud Gateway提供了一个在Spring生态系统之上构建的API网关，包括：Spring 5，Spring Boot 2和Project Reactor。Spring Cloud Gateway旨在提供一种简单

## 一、前言在上一篇文章中[Spring Cloud系列教程(十四)：服务追踪SpringCloud Sleuth集成Zipkin持久化数据存储Mysql(Finchley版本)](https://thinkingcao.blog.csdn.net/article/details/104957540)，实现了将服务追踪采集的数据持久化到`MySQL`数据库中，而且大家都知道`zipkin`默认是存内存的，这样到了生产环境不可行，这节将实现`zipkin`将数据持久化到`Elasticsearch`，项目

在上一篇文章中： **[Spring Cloud系列教程(十三)：服务追踪Spring Cloud Sleuth+Zipkin(Finchley版本)](https://thinkingcao.blog.csdn.net/article/details/104957225)** ， 我们初步学习了关于`SpringCloud Sleuth`和`Zipkin`的一些基础概念以及简要原理，并且通过实战搭建了`SpringCloud Sleuth`和`Zipkin`服务链路追踪数据的传输、收集以及`UI`界面的查

## 一、关于微服务调用链参与过大型微服务项目架构设计（以`SpringCloud`、`SpringCloudAlibaba`为代表）或者项目开发的小伙伴们应该都知道，在一个完成的微服务项目中，一个大型的项目被拆分成中多个子服务，服务与服务之间都是独立存在部署的，当某个或者某几个服务间发生交互时，应该就是服务之间的调用，这里我假设有`Service-A`、`Service-B`、`Service-C`三个服务，**存在以下调用关系：**`Service-A`调用`Service-B`服务，`Servic

一、前言

在上一篇文章中，我们实现了基于`Spring Cloud Config` 分布式配置中心实现配置文件分离开来，统一放入`Git`、`SVN`等版本控制软件中管理，但在上一篇文章中，有个问题： 当`Git/SVN`版本控制库中的微服务配置文件信息发生更改时，`Config-Server`端可以实时的收到最新的通知发生响应的刷新，但是`Config-Client`端无法动态感知这种变化，而最后我们提到的是通过使用手动方式发送`/refresh`接口请求`Config-Client`端，从而实现`Git`仓库中的

在分布式、微服务系统架构中，一个大的项目在进行服务拆分之后，变成了众多个子服务，由于服务的数量居多，每个服务都有自己的一套配置文件，这时候就不像传统的单体架构`SSM`、`SSH`、以及当下比较流行的`SpringBoot`快速开发框架，一个项目基本一份配置文件就可以搞定。而在微服务项目架构中，为了方便众多个服务的配置文件统一进行集中管理、实时的动态更新、与项目代码解耦开来，所以需要分布式配置中心组件，在`SpringCloud`微服务全家桶中，已经有比较成熟的分布式配置中心组件`Spring Cloud

`Zuul` 是`netflix`开源的一个`API `网关服务器, 其本质上是一个`web servlet`应用。`Zuul` 是在云平台上提供`动态路由`，`监控`，`弹性`，`安全`等边缘服务的框架。`Zuul `相当于是`PC`、`APP`、`H5`等客户端和 `Netflix` 流应用的 `Web `网站后端所有请求的前门，`Zuul`是`Spring Cloud`提供的`api`网关和过滤组件，网关将所有服务的`API`接口统一聚合，统一对外暴露。

在微服务架构场景中，通常会有很多层的服务互相调用。如果某一个底层服务出现问题，由于网络原因或者其他一些因素，有可能出现服务不可用的情况，当某个服务出现问题时，其他服务如果继续调用这个服务，就有可能出现线程阻塞，但如果同时有大量的请求，就会造成线程资源被用完，这样就可能会导致系统服务瘫痪，由于服务间会相互调用，很容易造成`服务连环雪崩效应`，从而故障会被向上传播响应给用户。我们需要一种机制，当底层服务不可用时，可以阻断故障的传播。这就是断路器的作用。他是系统服务稳定性的最后一重保障，是在微服务架构场景中必不

在前面的几篇文章中，分别讲了如何使用时`SpringCloud整合Eureka`和`SpringCloud整合Consul`作为注册中心实现服务的注册与发现，Eureka在闭源后，注册中心可替代的有`Consul`、`Zookeeper`，这篇文章就来学习一下`SpringCloud`整合`Zookeeper`作为微服务的注册中心，实现服务的注册与发现，然后通过服务提供者提供服务和服务消费者消费服务为例，基于`Feign`+`Zookeeper`+`Ribbon`组合实现`RPC`远程调用、本地负载均衡

在微服务领域，服务注册与发现是其中很重要的一个模块，主要用于服务治理问题；在分布式`Dubbo`中常用的服务发现与注册中心是`Zookeeper`，`Cosul`与其类似，在`SpringCloud`刚占领市场的时候，`SpringCloud`微服务框架默认使用的注册中心组建是`Eureka`，总所周知，`Eureka`已经开始闭源了，那么可以替代`Eureka`的有：`Consul`、`Zookeeper` ，这两种比较常用，同样可以很好的与`SpringCloud`集成，用于替代`Eureka`，本

在`SpringCloud`微服务框架中，生产者提供消息注册到注册中心，消费者从注册中心获取生产者提供的服务接口调用地址，进行消息的消费；那么在`SpringCloud`微服务中，消费者消费调用生产者的服务有两种形式：`Rest+Ribbon`和`Feign`这两种方式，`Rest+Ribbon`在前面章节已经学习过，这里主要介绍下使用`Feign`方式如何消费消息；

一、前言首先，Eureka注册中心服务分两个端：一个Eureka Client、一个Eureka Server，其实在Eureka Server注册中心集群条件下Eureka Server既是客户端也是服务端，相辅相成的，客户端就好比之前章节讲到的会员服务和订单服务，在Eureka Client启动的时候，会把当前的服务信息注册到Eureka Server上，默认情况下，如果Eureka Ser...

在`SpringCloud`微服务项目中，`注册中心`是其中的一部分，注册中心充当了服务的注册和发现角色，更为核心的是解决了微服务项目中的一系列服务治理问题，如果一旦服务注册出现故障的时候，可能会导致整个微服务无法访问，在这时候就需要对注册中心实现高可用集群模式，`Eureka集群的原理：`**其实就是两台或者多台`Eureka server`服务相互注册，将自己作为服务向其他服务注册中心注册自己，这样就可以形成一组相互注册的服务注册中心，从而实现服务清单的互相同步，达到高可用效果。**

一、注册服务提供者根据上节讲述的服务注册之Eureka注册中心，这节讲述搭建SpringCloud注册服务提供者provider和服务消费者consumer1.1、先新建一个Maven项目，会员提供者1.2、 引入依赖 <parent> <groupId>org.springframework.boot</groupId&gt...

一、前言众所周知，SpringCloud是一系列框架的有序集合，在基于SpringBoot基础设施框架之上，巧妙的统一了一套完整的微服务解决方案全家桶，其组建如服务发现注册eureka、配置中心Config、消息总线Bus、负载均衡Ribbon、断路器Hystrix、数据监控Actuator等一系列组件，那么Eureka组件就是其中的一个。Eureka是Netflix公司开源的一个RESTful服务框架组件，主要用于服务的注册发现等服务治理，被SpringCloud所整合，形成一个巨大的SpringClo

        通常而言，微服务架构是一种架构模式或者说一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行在其独立的进程中，服务之间互相协调、互相配合，为用户提供最终的价值。服务之间采用轻量级的通信机制（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具...

简介           摘自SpringCloud官网：http://spring.io/projects/spring-cloud       Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具（例如配置管理，服务发现，断路器，智能路由，微代理，控制总线，一次性令牌，全局锁定，领导选举，分布式会话，集群状态）。分布式系统的协调导致锅炉板模式，使用Spring...

一 Eureka服务治理体系1.1 服务治理服务治理是微服务架构中最为核心和基础的模块，它主要用来实现各个微服务实例的自动化注册和发现。Spring Cloud Eureka是Spring Cloud Netflix微服务套件中的一部分，它基于Netflix Eureka做了二次封装。主要负责完成微服务架构中的服务治理功能。Eureka服务治理体系如下：1.2 服务注册在服务治...