一、什么是微服务架构？

        微服务架构是一种架构模式或者说是一种架构风格， 它提倡将单一应用程序划分成一组小的服务 ，每个服务运行在其独立的自己的进程中 ，服务之间互相协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。 

二、微服务的优缺点

优点 ：

①每个服务足够内聚，足够小，代码容易理解这样能聚焦一个指定的业务功能或业务需求 ，开发简单、开发效率提高，一个服务可能就是专一的只干一件事。

②微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。 

③微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。 微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。微服务允许你利用融合最新技术。

④微服务能使用不同的语言开发。 每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库。 

⑤易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins, Hudson, bamboo 。 

缺点：

①开发人员要处理分布式系统的复杂性 

②多服务运维难度，随着服务的增加，运维的压力也在增大 

③系统部署依赖 

④服务间通信成本 

⑤数据一致性 

⑥系统集成测试 

⑦性能监控

三、微服务技术栈

四、当前各微服务框架对比

五、SpringCloud是什么？

        SpringCloud，基于SpringBoot提供了一套微服务解决方案，包括服务注册与发现，配置中心，全链路监控，服务网关，负载均衡，熔断器等组件，除了基于NetFlix的开源组件做高度抽象封装之外，还有一些选型中立的开源组件。 SpringBoot并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过SpringBoot风格进行再封装屏蔽掉了复杂的配置和实现原理， 最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包 

        SpringCloud=分布式微服务架构下的一站式解决方案，是各个微服务架构落地技术的集合体，俗称微服务全家桶。

六、SpringCloud和SpringBoot关系

        SpringBoot专注于快速方便的开发单个个体微服务。 SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来， 为各个微服务之间提供，配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务 SpringBoot可以离开SpringCloud独立使用开发项目， 但是SpringCloud离不开SpringBoot ，属于依赖的关系。

        总结来说：SpringBoot专注于快速、方便的开发单个微服务个体，SpringCloud关注全局的服务治理框架。 

七、SpringCloud和Dubbo的对比

底层协议：springcloud基于http协议，dubbo基于Tcp协议，决定了dubbo的性能相对会比较好

注册中心：Spring Cloud 使用的 eureka ，dubbo推荐使用zookeeper

模型定义：dubbo 将一个接口定义为一个服务，SpringCloud 则是将一个应用定义为一个服务

SpringCloud是一个生态，而Dubbo是SpringCloud生态中关于服务调用一种解决方案（服务治理）

        最大区别：SpringCloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式。 

        严格来说，这两种方式各有优劣。虽然从一定程度上来说，后者牺牲了服务调用的性能，但也避免了原生RPC带来的问题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，更加合适。 

        最为重要的是，DUBBO停止了5年左右的更新。虽然2017.7重启了。对于技术发展的新需求，需要由开发者自行拓展升级（比如当当网弄出了DubboX），这对于很多想要采用微服务架构的中小软件组织，显然是不太合适的，中小公司没有这么强大的技术能力去修改Dubbo源码+周边的一整套解决方案，并不是每一个公司都有阿里的大牛+真实的线上生产环境测试过。 

八、服务注册中心

1.什么是服务治理？

        SpringCloud封装了Netflix公司开发的Eureka模块实现服务治理，在传统的rpc远程调用框架中，管理每个服务与服务之间的依赖关系比较复杂，管理比较复杂，所以需要服务治理，管理服务与服务之间的依赖关系，可以实现服务调用，负载均衡，容错等，实现服务发现与注册。

2.什么是服务注册与发现？

        Eureka采用了CS的设计架构，Eureka Server作为服务注册功能的服务器，他是服务注册中心，而系统中其他微服务，使用Eureka客户端连接到Eureka Server并维持心跳连接。这样系统的维护人员就可以通过Eureka Server 来检测系统中各个微服务模块是否正常运行。

        在服务注册与发现中，有一个注册中心。当服务器启动时，会把当前自己服务器的信息，比如服务地址通讯地址以别名方式注册到注册中心。另一方，消费者，以该别名的方式去注册中心获取到实际的服务通讯地址，然后实现本地RPC调用RPC远程调用，框架核心设计思想在于注册中心，因为使用注册中心管理每个服务于服务之间的一个依赖关系（服务治理概念）。在任何RPC远程框架中，都会有一个注册中心（存放服务地址相关信息（接口地址））。

3.Eureka

3.1Eureka服务发现怎么做？

    首先在Controller中加入
@Resource

private  DiscoveryClient    discoveryClient;

    然后调用discoveryClient就可以获取到当前注册中心中的信息，在主启动类中加入一个@EnableDiscoveryClient注解就可以实现一个简单的注册发现了

3.2.Eureka的自我保护机制

        意思就是，某时刻某一个微服务不可用了，Eureka不会立即清理，依旧会对该服务的信息进行保存。宁可保留可能错误的服务注册信息，也不会盲目注销掉任何可能健康的服务实例。真好死不如赖活着。

        产生的原因是：为了防止可能是EurekaServer网络不通畅，但是其实EurekaClient是正常运行的，所以，Eureka会有那么一种保护机制。是一种AP的设计思想，高可用。

        默认情况下，如果EurekaServer在一定时间内（默认90秒）没有收到EurekaClient向EurekaServer发送的心跳包，便会直接从服务注册列表中剔除该服务，但是如果在短时间内丢失了过多的客户端，那么这个节点就进入了自我保护模式。

3.3.Eureka的自我保护机制的禁用：

在Eureka-server中修改yml的配置如上

关闭自我保护之后的Eureka-server

在客户端yml添加

4.Zookeeper  

在conf目录下，新建一个名为zoo.cfg的文件，其中内容如下：

参考自https://blog.csdn.net/weixin_42036952/article/details/89449242

参考自https://blog.csdn.net/weixin_42036952/article/details/89449242

4.1注册进zookeeper

1.pom文件引入jar包

此处我用的是3.4.9的zookeeper，为避免jar包冲突，将3.5.3排除掉

2.yml文件配置好

途中zookeeper的IP地址，端口号在上面设置过了，是2181

3.controller测试一下

4.成功后的结果

启动类启动后，成功入驻

测试controller地址也没问题 

        和Eureka自我保护机制来看，Zookeeper是一个提供的服务是一个临时节点，一定时间内，如果接受不到心跳，就会把入驻的踢掉，如果你又回来了，又是陌生人，丝毫不念旧情，无情的一批，Zookeeper比Eureka更加的无情。

5.Consul服务注册与发现

5.1Consul的安装

1.下载地址https://www.consul.io/downloads.html

2.将解压后的文件consul  拷贝到/usr/local/bin下

    sudo cp consul /usr/local/bin

3.打开bin文件，执行consul，查看consul命令，如下即表示成功

查看版本号

4.启动consul

consul agent -dev

启动成功之后可以访问consul的页面 http://localhost:8500/

6..三种服务注册框架的异同点

CAP：

        C : Consistency(强一致性)

        A : Availability(可用性)

        P : Partition tolerance(分区容错性)

        CAP的核心是，一个分布式系统不可能同时满足很好的一致性、可用性和分区容错性三个需求，因此，根据CAP原理可以将其分为三类:

        CA：单点集群，满足一致性，可用性的系统，通常可扩展性上不太强大。

        CP：满足一致性，分区容忍性的系统，通常性能不是特别高。

        AP：满足可用性，分区容忍性的系统，通常对一致性大的要求低一些。

        综上来看，只有Eureka是AP的，保证高可用，当注册的用户断掉之后，会认为是网络出现了问题，认为注册的用户是没问题的，保证了高可用，而Consul和Zookeeper是CP，要保证一致性，当客户端宕机之后，Server没有收到心跳包，会将客户端移除，有就是有，没有就是没有，保证一致性。Eureka和Consul是自带前台页面展示的，而Zookeeper只有客户端。

        所以，我个人更喜欢Consul，而且Consul的界面更加简单美观易懂。

九、服务调用

1.Ribbon    

    1.1Ribbon是什么

        SpringCloud Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡工具。主要功能是提供客户端的软件负载均衡算法和服务调用，提供一系列完善的配置如连接超时，重试等。简单来说，就是配置文件中列出Load Balancer（简称LB）后面所有的机器，Ribbon会自动帮助基于某种规则（如简单轮询，随机连接等）去连接这些机器。

    1.2LB负载均衡是什么？

        简单来说就是将用户的请求平摊的分配到多个服务上，从而达到HA(高可用)。常见的负载均衡软件有Nginx、LVS、硬件F5等

    1.3Ribbon本地负载均衡客户端  VS  Nginx服务端负载均衡

        Nginx是服务器负载均衡，客户端会将请求都发给Nginx，然后由nginx实现转发请求，即负载均衡是在服务端实现的。属于集中式LB（即在服务的消费方和提供方之间使用的独立的LB设施，由该设施负责把访问请求通过某种策略转发到服务的提供方）。

        Ribbon是本地负载均衡，在调用微服务接口时，会在注册中心上获取注册信息服务列表之后缓存到JVM本地，从而实现RPC远程调用技术。属于进程式LB（将逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选择一个合适的服务器）。它只是一个类库，集成于消费方进程，消费方通过他来获取到服务提供方的地址。

    1.4Ribbon工作流程图

        一、先选择EurekaServer，它优先选择在同一个区域内负载较少的Server

        二、根据用户指定的策略，在server取到的服务提供者列表选择一个地址

        其中Ribbon有很多的策略，比如轮询、随机和根据响应时间加权。

Ribbon的工作流程图I’m going

 1.5RestTemplete

        两个模块，一个是采购模块，一个是支付模块，假如采购模块要调用支付模块的接口，可以使用RestTemplete。在后面调用会使用Openfeign来实现。

首先加一个配置类

然后就可以在业务类使用了

        如上就可以访问cloud-payment-service的/payment/get/{id}路径了

        使用RestTemplete一般是getForObject方法和getForEntity，对比来看，前者返回的基本上可以理解为json，后者返回的则更加全面，可以获得响应中的一些重要信息，比如说响应头、响应状态码、响应体等。一般常用getForObject()方法

1.6问：有没有使用过Ribbon其他负载均衡的算法，有没有手写过，设计思想是什么？

1.6.1首先Ribbon自带的负载均衡算法一共有七种：

Ribbon负载均衡算法

1.6.2默认的负载均衡算法是轮询，那怎么替换成别的方法？

        首先，官网特殊说明，不要将自定义配置类放在@ConponentScan所能扫描的当前包以及子包下，会达不到特殊定制化的目的。而@SpringBootApplication注解会将所有本包以及本包以下扫入，所以新建一个包myrule，在里面定制规则，然后在主启动类加上注解如图

点入@SpringBootApplication注解

新建一个包myrule

定制规则

启动类加上注解，玩活~

1.6.3负载均衡轮询算法原理：

        rest接口第几次请求数%服务器集群总数量=实际调用服务器下标。比如1%2=1；2%2=0；3%2=1.......轮流着调用下标为0和1的服务器。注意：每次服务重启后rest接口计数从1开始。

1.6.4手写轮询算法：

        学完JUS再回来补充、42节

2.OpenFeign

2.1.OpenFeign是什么？

        OpenFeign是一个声明式web服务客户端，让编写Web服务客户端变得更加容易，只需要创建一个接口并在接口上添加注解即可。Feign也可以支持拔插式的编码器和解码器。SpringCloud对Feign进行了封装，使其支持了Spring MVC标准注解和HttpMessageConverters。Feign可以与Eureka和Ribbon组合使用以支持负载均衡。

2.2Feign能干什么

        前面在使用Ribbon时候，利用RestTemplete对http请求封装处理形成一套模板化的调用方法。但是在实际开发过程中，由于对服务依赖的调用可能不止一处，往往一个接口会被多处调用，所以通常都会针对每个微服务自行封装一些客户端类来包装这些依赖服务的调用，所以Feign在此基础上做了进一步的封装，我们只需要在一个微服务接口上标注一个Feign注解即可完成对服务提供方的接口绑定，简化了Spring Cloud Ribbon时，自动封装服务调用客户端的开发量。

        可Ribbon对比，Feign只需要在服务调用接口上加一个注解就可以了，优雅而简单的实现了服务调用。

2.3.OpenFeign和Feign对比

Feign和OpenFeign对比

2.4.OpenFeign的使用

        1.pom文件引入依赖

        2.写yml

        3.写主启动类，注意要加上@EnableFeignClients注解

        4.业务类：新建一个Service接口，在接口上加注解@FeignClient(value ="cloud-payment-service")，并指向要调用的服务实例名。然后在接口中加入在服务端Controller调用的方法。然后在客户端调用接口即可，上图来理解：

2.5.OpenFeign的超时控制

        注意OpenFeign默认等待一秒钟，但是服务端处理需要超过1s，导致Feign客户端返回报错，Read timed out，读取超时，而我们有时候需要设置Feign客户端的超时控制，就在yml文件中进行设置。

2.6日志打印功能

        其实就是 OpenFeign提供了对Feign接口调用情况进行监控和输出。日志级别一共分为四类：

NONE：默认的，不显示任何日志；

BASIC：仅记录请求方法、URL、响应状态码及执行时间。

HEADERS：除了BASIC中定义的信息·，还有请求和响应的头信息。

FULL：除了HEADERS中定义的信息，还有请求和响应的正文及元数据。

首先在客户端加一个配置类，这里加入的日志级别是FULL

在客户端的yml添加以上配置

然后在控制台就可以看到非常详细的日志了

十、服务降级

1.Hystrix断路器

服务雪崩

1.1.Hystrix是干嘛的

        Hystrix是一个用于处理分布式系统的延迟和容错的一个开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，Hystrix能保证在一个依赖出现问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的稳定性。“断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个符合预期的，可处理的备选响应，而不是长时间等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。

1.2.服务降级（Fallback）

        1.2.1什么是服务降级

        假设对方系统不可用了，向调用方返回一个符合预期的，可备选的响应。服务器忙，请稍后重试，不让客户等待并立刻返回一个友好的提示，这就是服务降级。就像if( ){ }else if{}....有备选方案。再比如给10086打电话，客服繁忙...

        出现服务降级的情况：

        ①程序运行异常；②超时；③服务熔断触发服务降级；④线程池/信号量打满也会导致服务降级。

        1.2.2进行服务降级的情况

        用jmeter进行压力测试，开启20000个线程进行测试，测试服务端8001环境下的两个地址，结果发现不仅压测访问的地址变慢，同一微服务下的另一个地址访问也变慢了，假设客户端80访问，一定会更慢，那样客户端一定会很不满意。那就来试一下，让客户端访问：8001同一层次的其它接口服务被困死（20000个线程访问），因为tomcat线程池里面的工作线程已经被挤占完毕，80此时调用8001，客户端访问响应会变慢，转圈圈。正是因为这些故障和不佳表现，才有我们的降级、容错、限流等技术的产生，来吧老弟。

        解决要求：超时导致服务器变慢（转圈）：超时不再等待；出错（宕机或程序运行出错）：出错要有兜底。

        1.2.3解决方案

        对方服务(8001)超时了，调用者(80)不能一直卡死等待，必须有服务降级；对方服务（8001）宕机了，调用者(80)不能一直卡死等待，必须服务降级；对方服务(8001)OK(可能)，调用者(80)自己出故障或有自我要求（自己的等待时间小于服务提供者)，自己处理降级。

        1.2.4如何启用服务降级

        首先服务端来做一下降级试一下。

        ①首先在业务类中加入新的配置标签@HystrixCommand，相当于在fallbackMethod中添加一个方法，如下value设置为3s，当超过3秒时，就会调用备用的方法，或者是方法中运行错误，比如说是以下的10/0报错。

        ②然后在主启动类中加入@EnableCircuitBreaker，这样就可以在服务提供端测试自己的服务降级了

        而一般Hystrix服务降级fallback是放在客户端的，步骤如下：

        ①首先在yml加上hystrix和feign的配置

开启feign的Hystrix服务降级功能

        ②在主启动类中添加注解@EnableHystrix

        ③在业务类中利用Hystrix实现服务降级就行了，跟服务提供端类似。在这里消费者端的服务降级时间设置的是1.5秒，而上面服务端设置的时间是3s，加入服务端线程运行时间实际花费了2秒，在客户端照样会发生服务降级，而以下10/0在会直接进行降级。

        上面的方法是利用openfeign直接调用服务端提供的方法。是前面学习过的。

        1.2.5设置全局通用服务降级方法

        目前存在的问题，每个业务方法都会有一个兜底的方法，会导致代码膨胀，可以设置一个全局通用的服务降级兜底的方法，如果需要特殊配置的在另外配。需要加入一个新的注解：DefaultProperties(defaultFallback=" ")统一跳转到处理结果页面。这样可以使得代码量大大减少。

        首先在类上加上新的注解，其他的方法没有设置fallback属性的话，就会进入全局fallback方法。

        就像这样，下面的方法只添加了@HystricCommand注解，如果出现异常就会进入payment_global_fallback兜底方法。

1.2.6通配服务降级

        目前来看，耦合度太高，在controller中要声明很多兜底的方法以备用，可以从源头来解决这个问题，在这里使用的feign调用的服务端提供的方法，可以直接在这个调用类里进行解决，如下：写一个fallback的类直接实现这个接口，一旦这个接口中的某个方法出现了问题，会直接调用实现类中的方法。如果发生运行、超时、宕机异常都会导致降级，而下面的paymentinfo_OK在其他地方没有配置降级方法，如果8001宕机，一定会调用下面实现类的paymentinfo_OK方法。

8001宕机以后，访问paymentinfo_OK方法

1.3服务熔断（break）        

        类似保险丝达到最大服务访问时，直接拒绝访问，拉闸限电，然后调用服务降级的方法并返回友好提示。断路器就相当于是保险丝。

        熔断机制的描述：熔断机制是应对雪崩效应的一种微服务链路保护机制，当扇出链路某个微服务出错不可用或者响应时间太长时，会进行服务降级，进而熔断该节点微服务的调用，快速返回错误信息。当检测到该节点微服务调用响应正常后，恢复调用链路。熔断机制通过Hystrix实现，Hystrix会监控微服务间的调用的状况，当失败的调用到一定的阈值，缺省是5秒内20次调用失败，就会启动熔断机制，熔断机制的注解是@HystrixCommand。

断路器的三种状态之间的切换

断路器的流程

断路器设置的三个参数

        如以下所示，仍然还是在HystrixCommand注解中进行配置，在上面加了四个Hystrix新的属性配置，意思就是在10s的窗口期内，发送十次请求，假如说有60%也就是6次都失败了，就激活断路器。而当他断路器激活以后，所有的请求都无法处理了，而过一段时间之后，断路器又会尝试着让少量的请求通过一下(也就是断路器进入了half-open状态)，而如果请求仍然失败，断路器又会重新回到open状态，如果请求成功，断路器则会关闭。也就是链路恢复。

        在controller中写出响应的调用，然后进行访问，如果十次中有六次及以上是负数，会发现，第11次时就算是正数仍然会进入fallback方法，因为此时进行了服务熔断。

8001Service的配置，IdUtil是hutool工具包提供的方法

1.4服务限流：(flowlimit)

        秒杀高并发的操作，严禁一窝蜂的过来拥挤，大家排队，一秒钟N个，有序的进行。

会在SpringCloudAlibaba中进行讲解

1.5 Hystrix工作流程总结

步骤说明，详见62

1.6 接近实时的监控

        Hystrix还提供了准实时的调用监控（Hystrix Dashboard），Hystrix会持续的记录所有通过Hystrix发起的请求的执行信息，并以统计报表和图形的形式展示给用户，包括每秒执行多少请求，多少成功，多少失败等。Netflix通过hystrix-metrics-event-stream项目实现了对以上指标的监控。Spring Cloud也提供了Hystrix Dashboard的整合，对监控内容转化成可视化界面。

1.6.1搭建流程

①首选创建一个新的module，导入pom，主要是spring-cloud-starter-netflix-hystrix-dashboard

<dependency>

        <groupId>org.springframework.cloud</groupId>

        <artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>

</dependency>

注意还有一个依赖，这个依赖如果是要进行图形化展示是一定要有的，一般和web同时存在

<dependency>

        <groupId>org.springframework.boot</groupId>

        <artifactId>spring-boot-starter-actuator</artifactId>

</dependency>

②然后配置yml

暂且配置一个端口号就够用了

yml

③主启动类，注意添加了一个新的注解：@EnableHystrixDashboard，一般要用一个新的功能，就要添加新的注解

④：最后访问localhost://9001/hystrix就可以显示了    

1.6.2进一步配置以进行监控

        Hystrix的服务监控需要自己配置，对于传统的微服务架构一定是够用了，而spring Cloud Alibaba提供的微服务监控可以直接访问，在后面会学习到，主要进行sentienl的学习。

在要监控的微服务进行配置

如上：输入网址http://localhost:8001/hystrix.stream

就可以看到监控了

十一、路由网关

        因为zuul在升级换代的时候，核心人员跳槽，技术选型出现分歧，导致现在zuul无人维护，而zuul2正在研发当中，所以spring自己验证了一个路由网关技术，也就是Gateway

1.概述简介

        解决痛点：前台页面发送过来的请求都会先给到网关，网关可以从注册中心中实时的感知一个服务的上线还是下线，总是能路由到正确的位置。每一个请求过来后要鉴权，限流...Gateway旨在提供一种简单而有效的方式来对API进行路由，以及提供一些强大的过滤器的功能，例如：熔断、限流、重试等。

假如没有网关

用网关来减少重复开发

SpringCloudGateway是Spring Cloud的一个全新的项目，旨在为微服务架构提供一种简单有效的统一的API路由管理方式。SpringCloud Gateway作为SpringCloud生态系统中的网关，目标是替代Zuul，在SpringCloud2.0以上的版本中，没有对应的新版本的Zuul2.0以上最新高性能版本进行集成，仍然还是使用Zuul1.x非Reactor模式的老版本，而为了提高网关的性能，SpringCloud Gateway是基于WebFlux框架实现的，而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty。基于高并发和异步非阻塞式通信就非常的有优势。

        SpringCloudGateway目标是提供统一的路由方式基于Filter链的方式提供了网关的基本功能，例如：安全，监控/指标，限流。

微服务架构中网关的位置

2.三大核心概念

路由（Route）：路由是构建网关的基本模块，他由ID，目标URI，一系列的断言和过滤器组成，如果断言为true，则匹配该路由。

断言（Predicate）：开发人员可以匹配HTTP请求中的所有内容（例如请求头和请求参数），如果请求头与断言相匹配则进行路由。

过滤（Filter）：指的是Spring框架中GatewayFilter的实例，使用过滤器，可以在请求被路由前或者之后对请求进行·修改。

3.Gateway工作流程

        核心逻辑：路由转发，执行过滤器链       

工作流程图

        客户端向SpringCloudGateway发出请求，然后在Gateway Handler Mapping中找到与请求相匹配的路由，将其发送到Gateway Web Handler。

        Handler再通过指定的过滤器链来将请求发送到我们实际的服务执行业务逻辑，然后返回。在经过过滤器可能会发送请求之前和之后执行逻辑（pre和post）。Filter在"pre"中可以进行参数校验、权限校验、流量监控、日志输出、协议转换这些。在"post"类型的过滤器可以做响应内容、响应头修改、日志的输出、流量监控等有着重要的作用。

4.入门配置

首先：添加依赖·，注意吧web和actuator依赖去除掉

<dependency>

    <groupId>org.springframework.cloud</groupId>

    <artifactId>spring-cloud-starter-gateway</artifactId>

</dependency>

②配置yml文件

这里路由的是上面8001的两个方法

③最后启动类就可以了，配置网关不需要任何的业务逻辑

④测试，发现可以访问成功了

第一种方式：就是以上通过yml进行配置

第二种方式：硬编码来实现（比较麻烦）

5.通过微服务名实现动态路由

        在这里网关会替代Ribbon做负载均衡，网关的好处是只对外提供一个接口，而且不用暴露真正的接口。

        如下图，在yml中，将写死的实例地址改为我们自己声明的实例名，这个我们在各个微服务模块的yml中都进行过配置。这样做的原因是，目前我们微服务提供者只有8001和8002，但是以后还可能会有8003，8004.....可能会是随便，任何的端口号。这样做不需要关注端口号，而直接配置实例名就可以了。

对应着8001和8002中配置的实例名

        调用lb方法返回的是服务提供端的端口号，如下可以发现，动态网关配置成功，而且实现了负载均衡。

6、Predicate的使用

        1.After Route Predicate

        2.Before Route Predicate

        3.Between Route Predicate

        4.Cookie Route Predicate

        5.Header Route Predicate

        6.Host Route Predicate

        7.Method Route Predicate

        8.Path Route Predicate

        9.Query Route Predicate

after  设置一个时间，在这个时间之后的访问成功，否则会404报错，before和between类似

cookie

        运用crul进行测试，添加cookie之后，如果不添加cookie或者添加的cookie不对都会报错，一般项目总用到三种测试方式，postman，jmeter，curl

运用crul进行测试，添加cookie之后

添加Header

123没问题。负数直接报错，因为yml中设置的是正数

        其他的那些基本上也都很简单，都是差不多类似的，其实，Predicate就是为了实现一组匹配规则，让请求过来找到对应的Route进行处理。

7、过滤器

生命周期：pre和post

种类：GatewayFilter（30多个）和GlobalFilter（10几个）

7.1.实现自定义过滤器

        开发过程中，一般自己配置过滤器比较多，首先创建实现GlobalFilter，Ordered两个接口，然后重写方法，一定要记得在类上加上注解@Component。

这样在地址栏访问就一定要加上参数username了，不加或者加错参数，如下，都会报错。

十二、服务配置

1.是什么

        微服务意味着要将单体应用中的业务拆分成一个个子服务，每个服务的粒度相对较小，因此系统中会有大量的服务，由于每个服务都需要进行相关的配置信息才能运行，所以需要一套集中式的、动态的配置管理设施。我们每一个微服务都带着自己一个application.yml，如果有上百个配置文件的管理.......SpringCloud提供了ConfigServer来解决这个问题。

        SpringCloud Config微服务架构中的微服务提供了集中化的外部配置支持，配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。 SpringCloud Config分为服务端和客户端两部分：

        服务端也称为分布式配置中心，他是一个独立的微服务应用，用来连接配置服务器并为客户端提供获取配置信息，加密/解密信息等访问接口

        客户端则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候就从配置中心获取和加载配置信息，配置服务器默认采用git来存储配置信息，这样有助于对环境配置进行版本管理，并且可以通过git客户端工具来方便管理和访问配置内容。

2.能干吗

        ①集中管理配置文件（将那些公共的配置抽取出来，比如说数据库密码、Eureka的服务端）

        ②不同环境下不同配置，动态化的配置更新，分环境部署比如dev/test/prod/beta/release

        ③运行期间动态调整配置，不再需要在每个服务部署的机器上编写配置文件，服务会向配置中心统一拉取配置自己的信息。

        ④当配置发生变动时，服务不需要重启即可感知到配置的变化并应用新的配置

        ⑤将配置信息以REST接口的形式暴露。

3.怎么用

3.1建立配置中心服务端

①建module cloud-config-center-3344；

②配置pom文件，添加新的依赖

<dependency>

        <groupId>org.springframework.cloud</groupId>

        <artifactId>spring-cloud-config-server</artifactId>

</dependency>

③写yml文件

3.2建立配置中心客户端

①建立module

②写pom.xml，添加新的依赖如下：

<dependency>

    <groupId>org.springframework.cloud</groupId>

    <artifactId>spring-cloud-starter-config</artifactId>

</dependency>

③写bootstrap.yml文件

        application.yml是用户级的资源配置项，bootstrap.yml是系统级的，优先级更高，Bootstrap属性有高优先级，默认情况下，他们不会被本地配置覆盖，因为bootstrap.yml是比application.yml先加载的，bootstrap.yml优先级高于application.yml

bootstrap的配置

④业务类进行测试

在浏览器输入localhost:3355/configInfo即可

3.3分布式的配置动态刷新问题

        假如在外部配置中心修改配置，（可以在本地修改然后提交到github，也可以直接在github上进行修改），修改之后，刷新本地配置的springcloud-config服务端，发现配置是更改过得，因为他直接访问的是github端，而刷新客户端发现并为更改，需要重启服务器才可以使更改生效。

①首先pom.xml一定要添加依赖

<dependency>

    <groupId>org.springframework.boot</groupId>

    <artifactId>spring-boot-starter-actuator</artifactId>

</dependency>

②bootstrap.xml添加新的配置

③在业务类添加新的注解

        @RefreshScope

④当运维人员对配置中心的配置进行修改时，还需要对客户端进行刷新才可以生效

        curl -X POST "http://localhost:3355/actuator/refresh"

        虽然避免了重启服务器，但是不得不说这样还是很不方便，假如说有100台客户端，要每个客户端都执行一个这个命令，写脚本遍历一下也还好，但是假如说是要100个其中90个重启一下就有点难了，接下来消息总线Bus

十三、消息总线

        SpringCloudBus配合SpringCloudConfig一起使用，可以实现配置的动态刷新。

1、是什么

2、能干嘛

        Spring Cloud Bus能管理和传播分布式系统间的消息，就像一个分布式执行器，可用于广播状态更改，事件推送等，也可以当做微服务间的通信通道。

3、为何被称为总线

        什么是消息总线（类似于公众号）：在微服务架构的系统中，通常会使用消息代理来构建一个共同的消息主题，并让系统中所有微服务实例都连接上来，由于该主题中产生的消息会被所有实例监听和消费，所以称为消息总线。在总线上的各个实例，都可以方便地广播一些需要让其他连接在该主题上的实例都知道的消息。

        基本原理：ConfigClient实例都监听MQ中同一个topic（默认是SpringCloudBus）。当一个服务刷新数据的时候，他会把这个信息放到Topic中，这样其他监听同一个Topic的微服务就能得到通知，然后去更新自身的配置。