spring cloud:

    父工程:整个微服务集群统一套壳 除了pom.xml 没有其他代码

        微服务包括但不限于以下类型:

        1.eureka服务器发现,有启动类和yaml,pom(集成eureka-server依赖)

        2.服务端:service接口 数据库crud提供者 有mybatis组件

            (集成eureka-client依赖 如果用server会导致返回xml不是json)

        3.客户端:消费者或者使用者 没有sql代码 mybatis组件之类的

            (集成eureka-client依赖 如果用server会导致返回xml不是json)

Eureka(找到了): 

                注册服务组件;分发注册微服务,分为Eureka Server和Eureka Client ;一般来说Eureka Server要注册两个以上做集群互相注册,保活

Ribbon(勋带):LB，

            即负载均衡(Load Balance);轮训,加权值

            1.新加一个负载均衡提供客户端 需要重启80实例才能找到新客户端

            2.在需要json返回地方 引入eureka 一定要client端spring-cloud-starter-netflix-eureka-client

                  如果引入client端spring-cloud-starter-netflix-eureka-server端接口会返回xml;

                  (Eureka Client - 服务端/提供者)就可以集成不同数据库(可能还有不同开发语言),多个注册完成负载均衡

feign(假装):

    另一种负载均衡,面向接口的实现方式;相当于Ribbon的升级版

        对 Feign 进行了封装，Feign 默认集成了 Ribbon 实现了客户端负载均衡调用

        在(Eureka Client - 客户端/消费者):

                1. 通过微服务名称，获得服务的调用地址

                2. 通过接口+注解，获得服务的调用 ——Feign （为适应业界其它程序员提出的，还是遵循面向接口编程）

        SpringCloud对Feign进行了增强兼容了SpringMVC的注解 ，我们在使用SpringMVC的注解时需要注意：

                1、!!!@FeignClient接口方法有基本类型参数在参数必须加@PathVariable("XXX") 或 @RequestParam("XXX")

                2、!!!@FeignClient接口方法返回值为复杂对象时，此类型必须有无参构造方法。

Hystrix:熔断器(断路器)

        ,类似保险丝;在业务出错throws 或者 某一个微服务崩溃时的 雪崩效应 默认返回处理 止损用

        1.服务端熔断:

                a.spring-cloud-starter-netflix-hystrix 依赖

                b.yaml=> eureka => instance-id: ${spring.application.name}:${server.port}-hystrix

                c. @HystrixCommand(fallbackMethod = "getFallBack")方法上加入

                d. public Product getFallBack(@PathVariable("id") Long id) 实现方法

        2.客户端消费者熔断(feign):

                a.yaml => feign.hystrix.enabled: true

                b.@FeignClient(value = "babosa-product",fallback = ProductClientServiceFallBack.class)

                     接口类上注释fallback属性

                c.@Component public class ProductClientServiceFallBack implements ProductClientService

                     完成实现类 加@Component 标注组件 并实现feign接口

                d.对方法 public Product get(@PathVariable("id") Long id) { return null/others }

                     实现即是错误熔断应对返回值了

                pis:feign 强兼容 springmvc 所以public Product get(@PathVariable("id") Long id) 连  

                   @PathVariable("id")都要一模一样(feign知识点)

        熔断监控:

            1.做一个熔断微服务spring-cloud-starter-netflix-hystrix-dashboard依赖

            2.在需要监控的服务中yaml management:endpoints:web:exposure:include: hystrix.stream

                 spring-boot-starter-actuator依赖

            3.http://熔断微服务地址:端口/hystrix 进入

                 输入 http://呗监控服务地址:端口/actuator/hystrix.stream  title 起名即可

Zuul(粗鲁):路由, 1.路由分发, 2.接口过滤

    1.正常配置spring-cloud-starter-netflix-zuul pom 即可用路由分发

    2.配置yaml zuul:routes:"路由器名" 然后path/serviceId/stripPrefix 即可使用接口过滤

    3.自定义一个@Component 组件标识的Filter 继承 ZuulFilter 实现对应方法即可

         a==>filterType：返回字符串代表过滤器的类型，返回值有：

           1.pre：在请求路由之前执行

            2.route：在请求路由时调用

            3.post：请求路由之后调用， 也就是在route和errror过滤器之后调用

            4.error：处理请求发生错误时调用

        b==>filterOrder：此方法返回整型数值，通过此数值来定义过滤器的执行顺序，数字越小优先级越高。

        c==>shouldFilter：返回Boolean值，判断该过滤器是否执行。返回true表示要执行此过虑器，false不执行。

        d==>run：过滤器的业务逻辑。(类似加密,token验证可以在这里做)

Spring Cloud 分布式配置中心:

        每个微服务自已带着一个 application.yml，上百个配置文件的管理起来就很麻     烦,在Spring Cloud中，有分布式配置中心组件Spring Cloud Config来解决这个     问题,通过将配置信息同步到git上来实现

1.服务端 config server：分布式配置中心，它是一个独立的微服务应用，用来连接配置服务器并为客 户端提供获取配置信息，加密、解密信息等访问接口。

配置服务端一个分部管理一个或者多个客户端使用,所以在application.yml 中配置并且uri是git库地址

        依赖 spring-cloud-config-server

microservice-cloud-11-config-server-5001 ===> pom

    name: babosa-microservice-config #自己起的以后要用

microservice-cloud-11-config-server-5001 ===> aplication

2.客户端 config client:通过指定的服务端来管理服务的资源，以及与业务相关的配置内容，并在启动       的时候从服务端获取和加载配置信息。

config-client-controller读取信息

    bootstrap.yml配置 config

         git分支: https://github.com/zffjll/babosa-cloud-config/blob/master/babosa-microservice-config-eureka.yml

    application.yml配置client姓名

3. 配置Eureka 服务端发现

pom 启动项

 git分支:https://github.com/zffjll/babosa-cloud-config/blob/master/babosa-microservice-config-eureka.yml

bootstrap.yml application.yml

4.正常的消费/使用端 : 

pom1 pom2

git分支:https://github.com/zffjll/babosa-cloud-config/blob/master/babosa-microservice-config-product.yml 

bootstrap  application yml 正常的使用mybatis

经过上述可以发现除了核心分布配置服务中application 设置了git uri外 其余项目均除了设置yml服务器名称外 均以bootstrap放心 加载了git中心管理application.yml配置

Spring Cloud Bus 消息总线组件

     在分布配置中心由git管理了 配置之后,如果想不重启微服务的情况下修改这些配置,就要用消息通知 mq广播通知更新

Spring Cloud Bus 被国内很多都翻译为消息总线。大家可以将它理解为管理和传播所有分布式项目中的消息即可，

其实本质是利用了MQ的广播机制在分布式的系统中传播消息，目前常用的有Kafka和RabbitMQ。

根据此图我们可以看出利用Spring Cloud Bus做配置更新的步骤:

1、提交配置后发送post方式的/bus-refresh请求给Confifig客户端

2、Confifig客户端接收到请求从Server端更新配置并且发送消息给消息总线

3、消息总线接到消息并通知给其它客户端

4、其它客户端接收到通知，请求Server端获取最新配置

5、全部客户端均获取到最新的配置

这里涉及 Postman测试工具安装/ RabbitMQ  类似框架

pom依赖

bootstrap配置

修改git中的babosa-microservice-product-config-rabbitMQ-bus1 刷新Eureka没有反应

postman 发送信息激活配置

成功

再git 配置中类emp属性该如何动态获取:

git中加入

发post信息推送没有更新 还是获取不到

给controller加@RefreshScope //可以用bus 同步 即可

成功

如果想在git配置中动态更改书库路 按属性更改不行 是因为使用了druid连接池

自定义连接池配置即可:

配置之后 将git 中datasource库更改 03 发送消息推送 

    

动态配置成功