Garry

1、安装RabbitMQ2、创建消息生产者(steam_producer)、消息消费者(stream_consumer)模块3、在两个模块中引入坐标 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-stream</artifactId> &l

绑定器Binder 绑定器是Spring Cloud Stream中一个非常重要的概念。在没有绑定器这个概念的情况下，我们的Spring Boot应用要直接与消息中间件进行信息交互的时候，由于各消息中间件构建的初衷不同，它们的实现细节上会有较大的差异性，这使得我们实现的消息交互逻辑就会非常笨重，因为对具体的中间件实现细节有太重的依赖，当中间件有较大的变动升级、或是更换中间件的时候，我们就需要付出非常大的代价来实施。通过定义绑定器作为中间层，实现了应用程序与消息中间件(Middleware)细节之间的隔离

Spring Cloud Stream由一个中间件中立的核组成。应用通过Spring Cloud Stream插入的input(相当于消费者consumer，它是从队列中接收消息的)和output(相当于生产者producer，它是从队列中发送消息的。)通道与外界交流。通道通过指定中间件的Binder实现与外部代理连接。业务开发者不再关注具体消息中间件，只需关注Binder对应用程序提供的抽象概念来使用消息中间件实现业务即可。说明：最底层是消息服务，中间层是绑定层，绑定层和底层的消息服务进行绑定，顶层是

在实际的企业开发中，消息中间件是至关重要的组件之一。消息中间件主要解决应用解耦，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。不同的中间件其实现方式，内部结构是不一样的。如常见的RabbitMQ和Kafka，由于这两个消息中间件的架构上的不同，像RabbitMQ有exchange，kafka有Topic，partitions分区，这些中间件的差异性导致我们实际项目开发给我们造成了一定的困扰，我们如果用了两个消息队列的其中一种，后面的业务需求，我想往另外一种消息队列进行迁移，这时候无疑

1、在每个需要数据收集的模块添加依赖 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-sleuth-zipkin</artifactId> </dependency> <dependency>

1、安装rabbitMQ+可视化插件初始用户名：guest密码：guest2、修改zipkin服务端的启动命令java -jar zipkin-server-2.12.9-exec.jar --RABBIT_ADDRESSES=127.0.0.1:5672RABBIT_ADDRESSES ： 指定RabbitMQ地址RABBIT_USER： 用户名（默认guest）RABBIT_PASSWORD ： 密码（默认guest）启动Zipkin Server之后，我们打开RabbitMQ的控制

1、原因分析：zipkin客户端的数据通过http请求形式发送到zipkin服务端，http是一种同步的阻塞式的请求，当zipkin响应时间较长，无形之中会影响我们服务之间的执行效果。2、解决方案在zipkin客户端和服务端之间加上rabbitMQ，这样客户端发送数据过来，rabbitMQ能够及时响应，即便zipkin服务器宕机也没关系，不影响服务之间调用执行的效率。...

1、创建数据库，执行脚本，建表。（此表是由zipkin提供的，是固定的）/*SQLyog Ultimate v11.33 (64 bit)MySQL - 5.5.58 : Database - zipkin**********************************************************************//*!40101 SET NAMES utf8 */;/*!40101 SET SQL_MODE=''*/;/*!40014 SET @O.

问题1、每次我们的zipkin服务段重启，之前的调用链路信息就会清空，如何有持久化保存数据。问题2、当调用http请求可能出现网络波动或者不稳定的情况，如何优化数据采集的过程

1、在需要收集调用链路信息的服务模块加上zipkin的依赖（网关服务模块、订单服务模块、商品服务模块等） <!--zipkin依赖--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId>

1、 Zipkin Server下载从spring boot 2.0开始，官方就不再支持使用自建Zipkin Server的方式进行服务链路追踪，而是直接提供了编译好的 jar 包来给我们使用。可以从官方网站下载先下载Zipkin的web UI，我们这里下载的是zipkin-server-2.12.9-exec.jar2、启动在命令行输入 java -jar zipkin-server-2.12.9-exec.jar 启动 Zipkin Server1、默认Zipkin Server的请求端口为

Zipkin 是 Twitter 的一个开源项目，它基于 Google Dapper 实现，它致力于收集服务的定时数据，以解决微服务架构中的延迟问题，包括数据的收集、存储、查找和展现。 我们可以使用它来收集各个服务器上请求链路的跟踪数据，并通过它提供的 REST API 接口来辅助我们查询跟踪数据以实现对分布式系统的监控程序，从而及时地发现系统中出现的延迟升高问题并找出系统性能瓶颈的根源。除了面向开发的 API 接口之外，它也提供了方便的 UI 组件来帮助我们直观的搜索跟踪信息和分析请求链路明细，比如：可以

一、 微服务架构下的问题在大型系统的微服务化构建中，一个系统会被拆分成许多模块。这些模块负责不同的功能，组合成系统，最终可以提供丰富的功能。在这种架构中，一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心，也就意味着这种架构形式也会存在一些问题：1、如何快速发现问题？2、如何判断故障影响范围？3、如何梳理服务依赖以及依赖的合理性？4、如何分析链路性能问题以及实时容

1、概述高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。我们都知道，单点是系统高可用的大敌，单点往往是系统高可用最大的风险和敌人，应该尽量在系统设计的过程中避免单点。方法论上，高可用保证的原则是“集群化”，或者叫“冗余”：只有一个单点，挂了服务会受影响；如果有冗余备份，挂了还有其他backup能够顶上。我们实际使用 Spring Cloud Gateway 的方式如上图，不同的客户端使用不同的负载将请求分发

Sentinel 支持对 Spring Cloud Gateway、Zuul 等主流的 API Gateway 进行限流。从 1.6.0 版本开始，Sentinel 提供了 Spring Cloud Gateway 的适配模块，可以提供两种资源维度的限流：route 维度：即在 Spring 配置文件中配置的路由条目，资源名为对应的 routeId自定义 API 维度：用户可以利用 Sentinel 提供的 API 来自定义一些 API 分组Sentinel 1.6.0 引入了 Sentinel A

1、准备工作1、redis本地安装好redis,解压后，双击运行目录下的redis-server.exe启动redis。然后双击运行目录下的redis-cli.exe启动客户端，输入：monitor 命令，监听redis里面的数据变化。2、在工程中引入redis相应的依赖：基于reactive的redis依赖 <!--监控依赖--> <dependency> <groupId>org.springframework.

（1） 计数器计数器限流算法是最简单的一种限流实现方式。其本质是通过维护一个单位时间内的计数器，每次请求计数器加1，当单位时间内计数器累加到大于设定的阈值，则之后的请求都被拒绝，直到单位时间已经过去，再将计数器重置为零。（2） 漏桶算法漏桶算法可以很好地限制容量池的大小，从而防止流量暴增。漏桶可以看作是一个带有常量服务时间的单服务器队列，如果漏桶（包缓存）溢出，那么数据包会被丢弃。 在网络中，漏桶算法可以控制端口的流量输出速率，平滑网络上的突发流量，实现流量整形，从而为网络提供一个稳定的流量。为

1、统一鉴权内置的过滤器已经可以完成大部分的功能，但是对于企业开发的一些业务功能处理，还是需要我们自己编写过滤器来实现的，那么我们一起通过代码的形式自定义一个过滤器，去完成统一的权限校验。（1）鉴权逻辑开发中的鉴权逻辑：1、当客户端第一次请求服务时，服务端对用户进行信息认证（登录）2、认证通过，将用户信息进行加密形成token，返回给客户端，作为登录凭证3、以后每次请求，客户端都携带认证的token4、服务端对token进行解密，判断是否有效。（2）代码/** * 自定义一个全局过滤器

1、过滤器的生命周期Spring Cloud Gateway 的 Filter 的生命周期不像 Zuul 的那么丰富，它只有两个：“pre” 和 “post”。PRE： 这种过滤器在请求被路由之前调用。我们可利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。POST：这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的 HTTPHeader、收集统计信息和指标、将响应从微服务发送给客户端等。2、 过滤器类型Spring Cloud Gateway 的 Filte

server: port: 8080 #端口spring: application: name: api-gateway-server #服务名称 redis: host: localhost pool: 6379 database: 0 cloud: #配置SpringCloudGateway的路由 gateway: discovery: locator: enabled: true #开启根据微服

server: port: 8080 #端口spring: application: name: api-gateway-server #服务名称 redis: host: localhost pool: 6379 database: 0 cloud: #配置SpringCloudGateway的路由 gateway: routes: - id: product-service #保持唯一 uri: l

1、引入eureka依赖 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency>2、在网关服务启动类上配置服务发现注解@SpringBootAp

1、核心概念1. 路由（route） 路由是网关最基础的部分，路由信息由一个ID、一个目的URL、一组断言工厂和一组Filter组成。如果断言为真，则说明请求URL和配置的路由匹配。2. 断言（predicates） Java8中的断言函数，Spring Cloud Gateway中的断言函数输入类型是Spring5.0框架中的ServerWebExchange。Spring Cloud Gateway中的断言函数允许开发者去定义匹配来自Http Request中的任何信息，比如请求头和参数等。

1、 Zuul网关存在的问题在实际使用中我们会发现直接使用Zuul会存在诸多问题，包括：性能问题Zuul1x版本本质上就是一个同步Servlet，采用多线程阻塞模型进行请求转发。简单讲，每来一个请求，Servlet容器要为该请求分配一个线程专门负责处理这个请求，直到响应返回客户端这个线程才会被释放返回容器线程池。如果后台服务调用比较耗时，那么这个线程就会被阻塞，阻塞期间线程资源被占用，不能干其它事情。我们知道Servlet容器线程池的大小是有限制的，当前端请求量大，而后台慢服务比较多时，很容易耗尽容器

1、代码/** * 自定义的zuul过滤器 * 继承抽象父类 */@Componentpublic class LoginFilter extends ZuulFilter { /** * 定义过滤器类型 * pre * routing * post * error */ public String filterType() { return "pre"; } /** * 指定过滤器的执行顺序 * 返回值越小,执行顺序越高

1、解释Zuul 中的过滤器跟我们之前使用的 javax.servlet.Filter 不一样，javax.servlet.Filter 只有一种类型，可以通过配置 urlPatterns 来拦截对应的请求。而 Zuul 中的过滤器总共有 4 种类型，且每种类型都有对应的使用场景。PRE：这种过滤器在请求被路由之前调用。我们可利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。ROUTING：这种过滤器将请求路由到微服务。这种过滤器用于构建发送给微服务的请求，并使用Apache

要在application.yml文件中配置路由规则即可：##路由配置zuul: routes: #商品微服务 product-service: #路由id,随便写 path: /product-service/** #映射路径 #localhost:8080/product-service/sxxssds url: http://127.0.0.1:9001 #映射路径对应的实际微服务url地址结束语：一辈子很短，努力的做好两件事就好；第一件事是热爱生

1、创建工程导入依赖当前工程（右键）–》创建新的模块（Maven）–》next–》输入模块名称–》next–》finish <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-zuul</artifactId> </depende

ZUUL是Netflix开源的微服务网关，它可以和Eureka、Ribbon、Hystrix等组件配合使用，Zuul组件的核心是一系列的过滤器，这些过滤器可以完成以下功能：1、动态路由动态将请求路由到不同后端集群2、压力测试逐渐增加指向集群的流量，以了解性能3、负载分配为每一种负载类型分配对应容量，并弃用超出限定值的请求4、静态响应处理边缘位置进行响应，避免转发到内部集群5、身份认证和安全识别每一个资源的验证要求，并拒绝那些不符的请求。Spring Cloud对Zuul进行了整合和增强。

1、Nginx介绍2、正向/反向代理（1）正向代理正向代理，“它代理的是客户端，代客户端发出请求”，是一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端必须要进行一些特别的设置才能使用正向代理。（2）反向代理多个客户端给服务器发送的请求，Nginx服务器接收到之后，按照一定的规则分发给了后端的业务处理服务器进行处理了。此时~请求的来源也就

1、什么是微服务网关API网关是一个服务器，是系统对外的唯一入口。API网关封装了系统内部架构，为每个客户端提供一个定制的API。API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。2、作用和应用场景网关具有的职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。当然，最主要的职责还是与“外界联系”。3、 常见的API网关实现方式Ko

在学习完前面的知识后，微服务架构已经初具雏形。但还有一些问题：不同的微服务一般会有不同的网络地址，客户端在访问这些微服务时必须记住几十甚至几百个地址，这对于客户端方来说太复杂也难以维护。如下图：如果让客户端直接与各个微服务通讯，可能会有很多问题：1、客户端会请求多个不同的服务，需要维护不同的请求地址，增加开发难度2、在某些场景下存在跨域请求的问题3、加大身份认证的难度，每个微服务需要独立认证因此，我们需要一个微服务网关，介于客户端与服务器之间的中间层，所有的外部请求都会先经过微服务网关。客

Sentinel 适配了 Feign 组件。如果想使用，除了引入 sentinel-starter 的依赖外还需要 2 个步骤：配置文件打开 sentinel 对 feign 的支持： feign.sentinel.enabled=true加入 openfeign starter 依赖使 sentinel starter 中的自动化配置类生效：1、引入依赖<!--feign对sentinel的支持--> <dependency> &lt

1、Spring Cloud Alibaba Sentinel 支持对 RestTemplate 的服务调用使用 Sentinel 进行保护，在构造RestTemplate bean的时候需要加上 @SentinelRestTemplate 注解。这样的话，所有的调用相当于都给加上了熔断降级的方法。@SpringBootApplication@EntityScan("cn.itcast.order.entity")public class RestOrderApplication { /**

1、在yaml文件进行设置意思是在本地资源中找到flowrule.json文件，里面有我们的一些保护规则。spring: cloud: sentinel: datasource: ds1: file: file: classpath:flowrule.json data-type: json rule-type: flowflowrule.json的内容[ {

1

18年底Netflix官方宣布Hystrix 已经足够稳定，不再积极开发 Hystrix，该项目将处于维护模式。就目前来看Hystrix是比较稳定的，并且Hystrix只是停止开发新的版本，并不是完全停止维护，Bug什么的依然会维护的。因此短期内，Hystrix依然是继续使用的。但从长远来看，Hystrix总会达到它的生命周期，那么Spring Cloud生态中是否有替代产品呢？1 替换方案介绍Alibaba SentinelSentinel 是阿里巴巴开源的一款断路器实现，目前在Spring

1、微服务使用Hystrix熔断器实现了服务的自动降级，让微服务具备自我保护的能力，提升了系统的稳定性，也较好的解决雪崩效应。其使用方式目前支持两种策略：1、线程池隔离策略：使用一个线程池来存储当前的请求，线程池对请求作处理，设置任务返回处理超时时间，堆积的请求堆积入线程池队列。这种方式需要为每个依赖的服务申请线程池，有一定的资源消耗，好处是可以应对突发流量（流量洪峰来临时，处理不完可将数据存储到线程池队里慢慢处理）2、信号量隔离策略：使用一个原子计数器（或信号量）来记录当前有多少个线程在运行，请

1、解释2、测试断路器的工作状态为了能够精确控制请求的成功或失败，我们在 shop_service_product 的调用业务中加入一段逻辑：/** * 使用注解配置熔断保护 * fallbackmethod : 配置熔断之后的降级方法 */ @HystrixCommand(fallbackMethod = "orderFallBack") @RequestMapping(value = "/buy/{id}",method = RequestMethod.GET) pu