关于后端:spring系列SpringCloud

SpringCloud 概述

微服务概述

什么是微服务

• 目前的微服务并没有一个对立的规范，个别是以业务来划分
• 将传统的一站式利用，拆分成一个个的服务，彻底去耦合，一个微服务就是单功能业务，只做一件事。
• 与微服务绝对的叫巨石

微服务与微服务架构

• 微服务是一种架构模式或者一种架构格调，提倡将繁多应用程序划分成一组小的服务 == 独立部署 ==，服务之间相互配合、互相协调，每个服务运行于本人的 == 过程 == 中。
• 服务与服务间采纳轻量级通信，如 HTTP 的 RESTful API 等
• 防止对立的、集中式的服务管理机制

微服务的优缺点

长处

1. 每个服务足够内聚，足够小，比拟容易聚焦
2. 开发简略且效率高，一个服务只做一件事件
3. 开发团队小，个别 2 - 5 人足以（当然按理论为准）
4. 微服务是松耦合的，无论开发还是部署都能够独立实现
5. 微服务能用不同的语言开发
6. 易于和第三方集成，微服务容许容易且灵便的主动集成部署（继续集成工具有 Jenkins,Hudson,bamboo 等）
7. 微服务易于被开发人员了解，批改和保护，这样能够使小团队更加关注本人的工作成绩，而无需肯定要通过单干能力体现价值
8. 微服务容许你交融最新的技术
9. 微服务只是业务逻辑的代码，不会和 HTML,CSS 或其余界面组件交融。
10. 每个微服务都能够有本人的存储能力，数据库可自有也能够对立，非常灵便。

毛病

1. 开发人员要解决分布式系统的复杂性
2. 多服务运维难度，随着服务的减少，运维的压力也会增大
3. 依赖零碎部署
4. 服务间通信的老本
5. 数据的一致性
6. 系统集成测试
7. 性能监控的难度

微服务的技术栈

为什么选 SpringCloud 作为微服务架构

选型根据

1. 整体解决方案和框架的成熟度
2. 社区热度
3. 可维护性
4. 学习曲线

以后各大 IT 公司的微服务架构

1. 阿里 Dubbo/HSF
2. 京东 JSF
3. 新浪 Motan
4. 当当 DubboX

各微服务的框架比照

SpringCloud 入门概述

• Spring 的三大模块：SpringBoot（构建），Spring Cloud（协调），Spring Cloud Data Flow（连贯）

SpringCloud 是什么

• 分布式系统的简化版（官网介绍）
• Spring Cloud 为开发人员提供了疾速构建分布式系统中一些常见模式的工具（例如配置管理，服务发现，断路器，智能路由，微代理，管制总线，一次性令牌，全局锁，领导选举，分布式会话，集群状态）。分布式系统的协调导致了样板模式, 应用 Spring Cloud 开发人员能够疾速地反对实现这些模式的服务和应用程序。他们将在任何分布式环境中运行良好，包含开发人员本人的笔记本电脑，裸机数据中心，以及 Cloud Foundry 等托管平台。
• SpringCloud 基于 SpringBoot 提供了一整套微服务的解决方案，包含服务注册与发现，配置核心，全链路监控，服务网关，负载平衡，熔断器等组件，除了基于 Netflix 的开源组件做高度形象封装之外，还有一些选型中立的开源组件
• SpringCloud 利用 SpringBoot 的开发便利性奇妙地简化了分布式系统的基础设施开发，SpringCloud 为开发人员提供了疾速构建分布式系统的一些工具，包含配置管理、服务发现、断路器、路由、微代理、事件总线，全局所、决策精选、分布式会话等等，他们都能够用 SpringBoot 的开发格调做到一键启动和部署。
• 一句话概括：SpringCloud 是散布式微服务架构下的一站式解决方案，是各个微服务架构落地技术的几何体，俗称微服务全家桶

SpringCloud 和 SpringBoot 的关系

SpringBoot：专一于疾速不便的开发单个个体微服务（关注宏观）

SpringCloud：关注全局的微服务协调治理框架，将 SpringBoot 开发的一个个单体微服务组合并治理起来（关注宏观）

• SpringBoot 能够来到 SpringCloud 独立应用，然而 SpringCloud 不能够来到 SpringBoot，属于依赖关系

Dubbo 是怎么到 SpringCloud 的？哪些优缺点去技术选型

目前成熟都互联网架构（分布式 + 服务治理 Dubbo）

比照

最大区别：

• Spring Cloud 摈弃了 RPC 通信，采纳基于 HTTP 的 REST 形式。Spring Cloud 就义了服务调用的性能，然而同时也防止了原生 RPC 带来的问题。REST 比 RPC 更为灵便，不存在代码级别的强依赖，在强调疾速演变的微服务环境下，显然更适合。
• == 一句话：Dubbo 像组装机，Spring Cloud 像一体机 ==
• 社区的反对与力度：Dubbo 已经停运了 5 年，尽管重启了，然而对于技术倒退的新需要，还是须要开发者自行去拓展，对于中小型公司，显然显得比拟费时费力，也不肯定有弱小的实力去批改源码

总结

1. 解决的问题域不一样：Dubbo 的定位是一款 RPC 框架，Spring Cloud 的指标是微服务架构下的一站式解决方案

SpringCloud 的参考资料

构建 SpringCloud 工程

概述：SpringCloud 工程由一个父工程和若干个 Module 组成

应该遵循的条件：约定 > 配置 > 编码

RestTemplate 类

介绍

RestTemplate 是 Spring 提供的用于拜访 Rest 服务的客户端模板工具集，提供了多种近程拜访 Http 的办法

意义

在一些不波及实现办法的模块中（消费者），只须要调用其余服务暴露出的接口即可满足的需要，应用 RestTemplate 类中的办法能够收回须要的 HTTP 申请并失去返回后果。（相似 Ajax）

RestTemplate 用法

RestTemplate restTemplate = new RestTemplate();
//url: 申请地址
//requestMap: 申请参数
//type.class:HTTP 响应转换成的对象类型
restTemplate.getForObject(url,type.class);
restTemplate.postForObject(url,requestMap,type.class);

构建父工程

• 创立一个 Maven 父工程并命名 GAV
• 打包形式为 POM
• 在 pom.xml 中定义各依赖的版本号（若 Module 中 pom.xml 的依赖没有指定版本号，则会依据父工程的版本号退出依赖）
• 退出通用的依赖和插件

构建 Module

• 在父工程下新建 Maven 的 Module，打包形式为 jar
• 个别来时 GAV 中 GV 随父工程，本人定义 A 即可
• 在该 Module 下 pom.xml 中退出其它须要的依赖
• 失常开发即可
• 实现后先 clean 一下 Maven 我的项目，而后再 install 提供给其它模块调用

增加其它 Module 的依赖办法

• 间接援用其 GAV 即可

    <dependencies>
        <dependency>
            <groupId>com.lzl</groupId>
            <artifactId>microservice-api</artifactId>
            <version>${project.version}</version>
        </dependency>
    </dependencies>

  配置该 module 下的 yml

• 微服务须要独立的端口
• == 微服务最重要的是取名字！！！！肯定要给微服务配置一个名字！这个名字就是这个微服务对外裸露的名字！==

• 配置该模块下的其它相干配置（如本例配置了 mybatis）

  server:
  port: 8001
  
  mybatis:
  config-location: classpath:mybatis/mybatis.cfg.xml
  type-aliases-package: com.XXX.entity
  mapper-locations:
  - classpath:mybatis/mapper/**/*.xml
  spring:
  application:
    name: microservicecloud-dept   #为这个服务取名，十分重要！！！！！datasource:
    type: com.alibaba.druid.pool.DruidDataSource
    driver-class-name: org.gjt.mm.mysql.Driver
    url: jdbc:mysql://localhost:3306/cloudDB01
    username: root
    password: 123456
    dbcp2:
      min-idle: 5         #最小连接数
      initial-size: 5    #初始化连接数
      max-total: 10      #最大连接数
      max-wait-millis: 200    #期待连贯最长的超时工夫
  

  编写主启动类

• 记得主启动类放在根包下,com.xxx.xxx

  package com.XXX;
  
  import org.springframework.boot.SpringApplication;
  import org.springframework.boot.autoconfigure.SpringBootApplication;
  
  @SpringBootApplication
  public class Provider8001_APP {public static void main(String[] args) {SpringApplication.run(Provider8001_APP.class,args);
    }
  }

  SpringCloud 增加组件的根本套路

1. 新增这个组件的 maven 坐标 GAV
2. 在启动类下面标注启动该组件（一般来说是 @EnableXXXXX）
3. 编写业务逻辑代码

Eureka 服务注册与发现

Eureka 介绍及原理

了解

==Eureka 就像一个物业管理公司，其余微服务就像小区的住户，每个住户入住时都要向物业管理公司注册，并定时向物业公司交管理费 ==

介绍

• Eureka 是一个基于 REST 的服务，用于定位服务，以实现云端中间层服务发现和故障转移。
• Eureka 主管服务注册与发现，在微服务中，当前了这两者，只须要应用服务的标识符（== 就是那个在每个服务的 yml 文件中获得服务名称 ==），就能够拜访到服务，不须要批改服务调用的配置文件
• Eureka 遵循 AP 准则（高可用，分区容错性），因为应用了自我爱护机制所以保障了高可用

原理

• Eureka 应用的是 C - S 构造（客户端 - 服务端）
• 两大组件：Eureka Server（提供注册服务）、Eureka Client（JAVA 客户端，负责发送心跳）
• 零碎中的其余微服务应用 Eureka 客户端连贯到 Eureka 服务端维持心跳连贯（即注册）。SpringCloud 的其余模块能够通过 Eureka Server 来发现零碎中的微服务并加以调用

Eureka 服务注册核心构建

退出服务端依赖

<dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka-server</artifactId>
        </dependency>

配置 yml

• == 了解：物业公司必定不向本人注册本人，并必定晓得本人在哪，不必加入检索 ==

server:
  port: 7001
eureka:
  instance:
    hostname: localhost
  client:
    register-with-eureka: false     #false 示意不向注册核心注册本人
    fetch-registry: false           #false 示意本人就是注册核心，职责是保护实例，不加入检索
    service-url:
      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/    #设置 eureka server 的交互地址，即对外裸露的地址 

增加启动类

• == 留神：要在类前加 @EnableEurekaServer 标注 ==

package com.XXX;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;

@SpringBootApplication
@EnableEurekaServer
public class Eureka7001_APP {public static void main(String[] args) {SpringApplication.run(Eureka7001_APP.class,args);
    }
}

验证是否构建胜利

启动主程序，拜访该服务地址即可

向 Eureka 注册核心注册微服务

减少依赖

在要注册的微服务的 pom.xml 文件中减少依赖

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-config</artifactId>
        </dependency>    

批改 yml

• 在 application.yml 中减少以内容，将客户端注册到服务列表内
• == 了解：小区用户要找到物业管理处的地址进行注册 ==

eureka:
  client:
    service-url:
      defaultZone: http://localhost:7001/eureka

主启动类减少注解

• 减少 @EnableEurekaClient 注解

@SpringBootApplication
@EnableEurekaClient
public class Provider8001_APP {public static void main(String[] args) {SpringApplication.run(Provider8001_APP.class,args);
    }
}

actuator 与微服务注册欠缺

主机名称与服务名称的批改

• 批改服务名称，在 yml 中 eureka 节点下增加如下内容

 eureka:
  instance:
    instance-id: dept8001        #批改别名
    prefer-ip-address: true        #显示 IP 地址 

info 内容的详细信息批改

作用

在查看 Eureka 时点击进入某个微服务的 info 时，能给查看者一些必要的信息，能够帮忙查看者疾速的理解该微服务，开发中非常有意义。

批改办法

1. == 以后工程 == 增加依赖

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>

2. == 总的父工程 == 的 build 节点下增加如下内容

<build>
        <finalName>microservicecloud</finalName>
        <resources>
            <resource>
                 <!-- 容许扫描该门路下的资源文件 -->
                <directory>src/main/resources</directory>
                <filtering>true</filtering>
            </resource>
        </resources>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-resources-plugin</artifactId>
                <configuration>
                    <delimiters>
                         <!-- 指定动静获取以 $ 标记结尾结尾的信息 -->
                        <delimit>$</delimit>
                    </delimiters>
                </configuration>
            </plugin>
        </plugins>
    </build>

3. 在 == 以后工程 == 的 application.yml 文件增加回显信息

info:
  author: XXX
  build-version: $project.version$

Eureka 的自我爱护

介绍

Eureka 的自我爱护机制次要是为了网络异样时放弃高可用设计的，当在 Eureka 中注册的微服务超过设定是工夫内（默认 90 秒）没有向 Eureka 服务端发送心跳，该微服务会进入自我保护模式。在自我保护模式中，Eureka 会爱护服务注册表中的信息，不会登记任何服务实例，直至收到的心跳数复原至阈值以上，该微服务退出自我保护模式。

了解

好死不如赖活：Eureka 的设计哲学是宁肯保留谬误的服务信息，也不自觉登记可能衰弱的服务。所以异样的服务不会被登记，而是进入了自我保护模式。

自我保护模式的开关

在 Eureka Server 模块下的 yml 文件中增加配置信息即可，true 示意关上自我保护模式；false 示意敞开自我保护模式（不举荐）

  server:
    enable-self-preservation: false

Eureka 的服务发现

介绍

零碎中的微服务能够通过 Eureka 的服务发现去取得在 Eureka 中注册的服务的信息，这是一个对外裸露的接口。

应用办法（provider 中）

1. 注入 DiscoveryClient 对象（spring 包下的），在 controller 办法中获取

@Autowired
private DiscoveryClient discoveryClient;    

@ResponseBody
@GetMapping("/provider/discovery")
public Object discovery(){List<String> list = discoveryClient.getServices();
        System.out.println(list);
        List<ServiceInstance> insList = discoveryClient.getInstances("MICROSERVICECLOUD-DEPT");
        for (ServiceInstance si:insList) {System.out.println(si.getHost() +"," + si.getServiceId() +"," +si.getPort() +"," +si.getUri() +"," +si.getMetadata());
        }
        return this.discoveryClient;
    }

2. 在主启动类中退出 @EnableDiscoveryClient 注解

@SpringBootApplication
@EnableEurekaClient
@EnableDiscoveryClient
public class Provider8001_APP {public static void main(String[] args) {SpringApplication.run(Provider8001_APP.class,args);
    }
}

应用办法（consumer 中）

在 controller 办法中应用 restTemplate 对象调用 provider 中裸露的 URL 并取得返回对象即可

@GetMapping("/discovery")
public Object discovery() {return restTemplate.getForObject(URL_PREFIX+"/provider/discovery",Object.class);
    }

Eureka 的集群配置

集群

集群就是在不同的机器上配置雷同的服务来构建要一个大的运算整体

实现集群

1. 新建 N 个 Eureka Server 模块
2. 每个模块的 pom.xml 中退出与单个 Eureka Server 雷同的依赖
3. 每个模块退出主程序（记得加 @EnableEurekaServer 注解）
4. 批改 hosts 文件（Win7 的门路是 C:\Windows\System32\drivers\etc）

127.0.0.1 eureka7001.com
127.0.0.1 eureka7002.com
127.0.0.1 eureka7003.com

5. 批改 Eureka Server 模块的 application.yml 文件，退出集群，次要批改两个中央：

• hostname：批改为 hosts 文件中映射的地址
• service-url 下的 defaultZone 节点：填入集群中另外的 server 服务端的地址

server:
  port: 7001
eureka:
  instance:
    hostname: eureka7001.com    #hostname 为 hosts 文件中映射的地址
  client:
    register-with-eureka: false     #false 示意不向注册核心注册本人
    fetch-registry: false           #false 示意本人就是注册核心，职责是保护实例，不加入检索
    service-url:
      #defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/    #设置 eureka server 的交互地址
      defaultZone: http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/  #其余两个服务端的地址 

6. 批改 Eureka Client 模块的 application.yml 文件，使其向集群注册服务

• service-url 下的 defaultZone 节点：填入集群中须要向其注册 server 服务端的地址

eureka:
  client:
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka,http://eureka7002.com:7002/eureka,http://eureka7003.com:7003/eureka

7. 拜访地址

http://eureka7001.com:7001
http://eureka7002.com:7002
http://eureka7003.com:7003

8. == 注：defaultZone 中 eureka/ 后缀是必须的，如果删除，Server 类不会报错，然而 Client 注册时会报 404 谬误 ==

Eureka 与 Zookeeper 比照

CAP 设计准则不同

Eureka 恪守 AP，Zookeeper 恪守 CP（C：强一致性，A：高可用，P：分区容错性，三者只能选其二，高并发下 P 必选）

网络稳定下两者的解决比照

论断

Eureka 能够很好的应答网络故障导致局部节点失去连贯的状况，而不会像 zookeeper 那样导致整个注册服务零碎的瘫痪。

Ribbon 负载平衡

Spring Cloud Ribbon 是基于 Netflix Ribbon 实现的一套 == 客户端 == 负载平衡工具。Ribbon 会主动帮忙你基于某种规定（简略轮询、随机连贯等），也能够实现自定义的负载平衡算法。

负载平衡

• 英文名称：Load Balance，微服务或分布式集群中罕用的一种利用
• 简略来说负载平衡就是将用户的申请 ping 平摊的调配到多个工作上，从而是零碎达到 HA（高可用）

• 两种负载平衡：

  1. 集中式 LB：偏硬件，服务的生产方和提供方之间应用独立的 LB 设施，由该设施负责把拜访申请以某种策略转发至服务的提供方。
  2. 过程内 LB：骗软件，将 LB 逻辑集成到生产方，生产方从服务注册核心领导哪些地址可用，再本人抉择一个适合的服务器。

Ribbon 初步配置

• ==Ribbon 是客户端负载平衡工具！！！Ribbon 是客户端负载平衡工具！！！Ribbon 是客户端负载平衡工具！！！== 所以应该配置在客户端

1. 退出依赖，因为 Riboon 须要依赖 Eureka 运行，所以要同时退出 Eureka 依赖

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-ribbon</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-config</artifactId>

2. 对实现类退出 @LoadBalanced 注解

@Bean
@LoadBalanced
public RestTemplate getRestTemplate() {return  new RestTemplate();
    }
}

3. 在 application.yml 文件中配置向注册核心注册，如果是作为消费者模块不提供服务，不应该注册本人

eureka:
  client:
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/
    register-with-eureka: false                #作为消费者不提供服务，不应该注册本人 

4. 主启动类中退出 @EnableEurekaClient 注解

@SpringBootApplication
@EnableEurekaClient
public class Consumer80_APP {public static void main(String[] args) {SpringApplication.run(Consumer80_APP.class,args);
    }
}

5. 以上步骤 1~4 实现后即可在 controller 中间接通过服务名拜访零碎中的微服务，服务名作为 URI

private static final String URL_PREFIX = "http://MICROSERVICECLOUD-DEPT/";

Ribbon 负载平衡实现

架构示意图：

实现办法

指标：构建 provider 集群后 consumer 通过负载平衡轮询调用在 Eureka 中注册的服务

1. 构建集群，新开两个 provider 模块，将原 provider 的 == 代码局部和 pom.xml 中依赖照搬 == 到新的 provider 中
2. 将原 provider 中 application.yml 文件照搬到新 provider，并批改端口号，若新的 provider 应用本人的数据库，则批改数据库信息（其余配置也一样，如批改别名）
3. 集群中服务名称必须统一！！！

spring:
  application:
    name: microservicecloud-dept   #同一集群下必须应用同一服务名！！！！！

4. 启动服务，进行测试

总结

Ribbon 其实就是一个软负载平衡的客户端组件，能够和其余须要申请的客户端联合应用。

Ribbon 外围组件 IRule

IRule：依据特定算法从服务列表中选取一个须要拜访的服务

七大办法

==IRule 是一个接口，七大办法是其自带的落地实现类 ==

• RoundRobinRule：轮询（默认办法）
• RandomRule：随机
• AvailabilityFilteringRule：先过滤掉因为屡次拜访故障而处于断路器跳闸状态的服务，还有并发的连贯数量超过阈值的服务，而后对残余的服务进行轮询
• WeightedResponseTimeRule：依据均匀响应工夫计算服务的权重。统计信息有余时会依照轮询，统计信息足够会依照响应的工夫抉择服务
• RetryRule：失常时依照轮询抉择服务，若过程中有服务呈现故障，在轮询肯定次数后仍然故障，则会跳过故障的服务持续轮询。
• BestAvailableRule：先过滤掉因为屡次拜访故障而处于断路器跳闸状态的服务，而后抉择一个并发量最小的服务
• ZoneAvoidanceRule：默认规定，合乎判断 server 所在的区域的性能和 server 的可用性抉择服务

切换规定办法

只需在 == 配置类 == 中配置一个返回具体方法的 bean 即可

@Bean
public IRule MyRule(){return new RandomRule();    
    }

自定义 Ribbon 负载平衡算法

配置及包地位

1. 自定义的 Ribbon 算法类不能放在主启动类所在的包及子报下（确切来说是不能放在 @ComponentScan 注解的包及子包下），否则会被全局利用到 Ribbon 服务中。应该把自定义算法类放在另外新建的包下，且这个类应该是为 == 配置类 ==。（其实与一般切换负载平衡规定相似，只不过是地位不同而已，一般的能够放在主启动类所在的包，自定义的要放在里面的包下）
2. 主启动类增加 @RibbonClient(name = “ 微服务名 ”,configuration = XXX.class) 注解指定须要用到负载平衡的微服务名及自定义算法的 class 对象。

@SpringBootApplication
@EnableEurekaClient
@RibbonClient(name = "MICROSERVICECLOUD-DEPT",configuration = MyRule.class)
public class Consumer80_APP {public static void main(String[] args) {SpringApplication.run(Consumer80_APP.class,args);
    }
}

通过批改源代码取得自定义算法

指标：每个服务调用 5 次后再进行轮询（调用次数不是很对，懒得改了 )

package com.Rules;

import com.netflix.client.config.IClientConfig;
import com.netflix.loadbalancer.AbstractLoadBalancerRule;
import com.netflix.loadbalancer.ILoadBalancer;
import com.netflix.loadbalancer.RoundRobinRule;
import com.netflix.loadbalancer.Server;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.context.annotation.Configuration;

import java.util.List;
import java.util.concurrent.atomic.AtomicInteger;


public class MyRule extends AbstractLoadBalancerRule {

    private AtomicInteger nextServerCyclicCounter;
    private static final boolean AVAILABLE_ONLY_SERVERS = true;
    private static final boolean ALL_SERVERS = false;
    private int total = 0;
    private int currentIndex = 0;

    private static Logger log = LoggerFactory.getLogger(RoundRobinRule.class);

    public MyRule() {nextServerCyclicCounter = new AtomicInteger(0);
    }

    public MyRule(ILoadBalancer lb) {this();
        setLoadBalancer(lb);
    }

    public Server choose(ILoadBalancer lb, Object key) {if (lb == null) {log.warn("no load balancer");
            return null;
        }

        Server server = null;
        int count = 0;
        while (server == null && count++ < 10) {List<Server> reachableServers = lb.getReachableServers();
            List<Server> allServers = lb.getAllServers();
            int upCount = reachableServers.size();
            int serverCount = allServers.size();

            if ((upCount == 0) || (serverCount == 0)) {log.warn("No up servers available from load balancer:" + lb);
                return null;
            }
            if (total > 5) {
                total = 0;
                int nextServerIndex = incrementAndGetModulo(serverCount);
                currentIndex = nextServerIndex;
                server = allServers.get(nextServerIndex);
            }else {if (currentIndex>=serverCount) {currentIndex = 0;}
                server = allServers.get(currentIndex);
                total++;
            }


            if (server == null) {
                /* Transient. */
                Thread.yield();
                continue;
            }

            if (server.isAlive() && (server.isReadyToServe())) {return (server);
            }

            // Next.
            server = null;
        }

        if (count >= 10) {
            log.warn("No available alive servers after 10 tries from load balancer:"
                    + lb);
        }
        return server;
    }

    /**
     * Inspired by the implementation of {@link AtomicInteger#incrementAndGet()}.
     *
     * @param modulo The modulo to bound the value of the counter.
     * @return The next value.
     */
    private int incrementAndGetModulo(int modulo) {for (;;) {int current = nextServerCyclicCounter.get();
            int next = (current + 1) % modulo;
            if (nextServerCyclicCounter.compareAndSet(current, next))
                return next;
        }
    }


    public Server choose(Object key) {return choose(getLoadBalancer(), key);
    }


    public void initWithNiwsConfig(IClientConfig clientConfig) {}}

Feign 负载平衡

Feign 是一个申明式 WebService 客户端，应用办法时定义一个接口并在下面增加注解即可。Feign 反对可拔插式的编码器和解码器。Spring Cloud 对 Feign 进行了封装，使其反对 SpringMVC 和 HttpMessageConverters。Feign 能够与 Eureka 和 Ribbon 组合应用以反对负载平衡。

应用案例

1. 新建 Feign 模块，退出依赖（其实跟 80 消费者差不多，次要是多了 Feign 依赖）

    <dependencies>
        <dependency>
            <groupId>com.XXX</groupId>
            <artifactId>microservice-api</artifactId>
            <version>${project.version}</version>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-feign</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-ribbon</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-config</artifactId>
        </dependency>
        <!-- 热部署 -->
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>springloaded</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-devtools</artifactId>
        </dependency>
    </dependencies>

2. 因为 Feign 开发其实是面向接口编程，所以 Feign 接口能够放在 api 模块中供各模块应用，所以要在 api 模块中增加 Feign 依赖
3. 在 api 中编写接口，接口上增加 @FeignClient 注解，并通过 value 指定作用的微服务名

@FeignClient(value = "MICROSERVICECLOUD-DEPT")
public interface DeptClientService {@PostMapping("/dept")
    public boolean addDept(Dept dept);

    @GetMapping("/dept")
    public List<Dept> findAll();

    @GetMapping("/dept/{id}")
    public Dept findById(@PathVariable("id")Integer id);
}

4. 在 Feign 模块中编写 Controller，并注入 FeignClient 接口，间接调用 service 接口中的办法即可（因为申明 Feign 接口时曾经指定过微服务，所以拜访时会正确地找到微服务）

@RestController
@RequestMapping("/consumer")
public class ConsumerDeptController {
    @Autowired
    private DeptClientService service;

    @PostMapping("/dept")
    public boolean addDept(Dept dept){return service.addDept(dept);
    }

    @GetMapping("/dept")
    public List<Dept> findAll(){return service.findAll();
    }

    @GetMapping("/dept/{id}")
    public Dept findById(@PathVariable("id")Integer id){return service.findById(id);
    }
}

5. 批改 Feign 模块的主启动类，退出 @EnableFeignClients 注解和 @ComponentScan 注解（次要是扫描 api 中申明的接口）

@SpringBootApplication
@EnableEurekaClient
@EnableFeignClients(basePackages = {"com.XXX"})
@ComponentScan("com.XXX")
public class Consumer80Feign_APP {public static void main(String[] args) {SpringApplication.run(Consumer80Feign_APP.class,args);
    }
}

6. 启动后拜访，即会依照轮询的形式调用 provider 集群

总结

• Feign 通过接口办法调用 REST 服务，在 Eureka 中查找对应的服务
• Feign 集成了 Ribbon 技术，所以也反对负载平衡（轮询）

Hystrix 断路器

分布式系统面临的问题

扇出

多个微服务相互调用的时候，如果 A 调用 B、C，而 B、C 又持续调用其余微服务，这就是扇出（像一把扇子一样缓缓关上。

服务雪崩

• 删除过程中，如果某一个环节的服务呈现故障或连贯超时，就会导致后面的服务占用越来越多的资源，进而引起零碎解体，就是“雪崩效应”。
• 对于高流量的利用来说，繁多的后端依赖会导致服务器所有的资源都在几秒钟内饱和。比失败更蹩脚的是，这些应用程序还可能导致服务之间的提早减少，备份队列，线程和其余系统资源缓和，导致整个零碎产生更多的级联故障。这些都示意须要 == 对故障和提早进行隔离和治理 ==，以便单个依赖关系的失败，不能取消整个应用程序或零碎。

Hystrix 介绍

• Hystrix 是一个用于解决分布式系统提早和容错的开源库。分布式系统中，依赖防止不了调用失败，比方超时，异样等。Hystrix 能保障在呈现问题的时候，不会导致整体服务失败，防止级联故障，以进步分布式系统的弹性。
• Hystrix 相似一个“断路器”，当零碎中异样产生时，断路器给调用返回一个合乎预期的，可解决的 FallBack，这样就能够防止长时间无响应或抛出异样，使故障不能再零碎中蔓延，造成雪崩。

服务熔断

• 熔断机制的注解是 @HystrixCommand
• 熔断机制是应答雪崩效应的一种 == 链路爱护机制 ==，个别存在于服务端
• 当扇出链路的某个服务呈现故障或响应超时，会进行 == 服务降级 ==，进而 == 熔断该节点的服务调用 ==，疾速返回“谬误”的相应信息。、
• Hystrix 的熔断存在阈值，缺省是 5 秒内 20 次调用失败就会触发

熔断案例

1. 构建一个新的 provider module（如复制 8001module）
2. pom.xml 退出 hystrix 依赖（肯定要配合 Eureka）

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-hystrix</artifactId>
        </dependency>

3. application.xml 中配置端口和 Eureka 信息（必配）和其余框架的配置信息（可选，如 mybatis）
4. 编写具体业务逻辑
5. controller 类中，在须要配置 Fallback 的办法上退出 @@HystrixCommand(fallbackMethod = “XXX”) 注解，XXX 为 FallBack 办法名本例中作为测试所以抛出了异样

    @ResponseBody
    @GetMapping("/dept/{id}")
    @HystrixCommand(fallbackMethod = "nullDeptFallBack")
    public Dept findById(@PathVariable("id")Integer id) {Dept dept = deptService.findById(id);
        if (null == dept){throw new RuntimeException("返回值为空！");
        }
        return dept;
    }

6. 依据须要配置 FallBack 的办法返回值编写代码

 public Dept nullDeptFallBack(@PathVariable("id")Integer id) {System.out.println(111);
        return new Dept().setId(id).setDeptName("nullName").setDbSource("nullDB");
    }

7. 主启动类中退出 @EnableCircuitBreaker 注解
8. 开启服务，测试

解耦与降级解决

降级

• 当零碎整体资源快不够的时候，忍痛将局部服务临时敞开，带渡过难关后，再从新开启。
• 降级解决时在 == 客户端 == 实现的，与服务端没有关系
• 了解：所谓降级，个别是从 == 整体负荷 == 思考，当某个服务熔断之后，服务器将不再被调用，此时客户端能够本人筹备一个本地的 FallBack 回调，返回一个缺省值。这样做尽管服务水平降落，但好歹可用，比间接挂掉好。

为什么要解耦

如果依照下面的熔断案例来做的话，Controller 下的每个办法，都要给其编写一个 FallBack 办法，当办法缓缓变多，就会造成代码收缩，一个是减少编写的工作量，另外一个也会增大保护的难度，代码的耦合度也会高，是非常不合理的，所以要将其解耦。

解耦思路

因为服务端的是通过实现接口拜访服务端的，如果在父接口上实现了 FallBack 办法，通过这样一种形式去保护起来就能实现解耦，也顺便实现了降级的机制。

解耦 & 降级案例

1. 在 api 模块中新建实现了 FallbackFactory<T> 接口的类，其中泛型 T 就是咱们须要保护其 FallBack 的接口办法，并实现其 create 办法，在 create 办法中返回实现了 T 的对象，应用匿名外部类实现 T。== 留神：这个类肯定要加 @Component 注解！！这个类肯定要加 @Component 注解！！这个类肯定要加 @Component 注解！！==

import com.XXX.entity.Dept;
import feign.hystrix.FallbackFactory;
import org.springframework.stereotype.Component;

import java.util.List;

@Component
public class DeptClientServiceFallBackFactory implements FallbackFactory<DeptClientService> {public DeptClientService create(Throwable throwable) {return new DeptClientService() {public boolean addDept(Dept dept) {return false;}

            public List<Dept> findAll() {return null;}

            public Dept findById(Integer id) {return new Dept().setId(id).setDeptName("服务器跪了,").setDbSource("迟点来吧");
            }
        };
    }
}

2. 批改步骤 1 中传入的泛型 T 接口，增加 @FeignClient(fallbackFactory = T.class) 注解

@FeignClient(value = "MICROSERVICECLOUD-DEPT",fallbackFactory = DeptClientServiceFallBackFactory.class)
public interface DeptClientService {@PostMapping("/dept")
    public boolean addDept(Dept dept);

    @GetMapping("/dept")
    public List<Dept> findAll();

    @GetMapping("/dept/{id}")
    public Dept findById(@PathVariable("id")Integer id);
}

3. 批改 consumer feign 模块的 application.xml 文件，开启 hystrix（注：在 IDEA 中可能没有代码提醒，开启的 true 也没有失常高亮，但如同不须要做额定操作也不影响后果）

feign:
  hystrix:
    enabled: true

4. 开启服务并测试

HystrixDashboard 服务监控

介绍：SpringCloud 对 Hystrix Dashboard 进行了整合，能够对通过 Hystrix 发动的申请进行准实时统计，并以报表和图形的模式展现给用户（包含每秒执行多少次申请胜利和失败等）。

配置案例

1. 新建 HystrixDashboard 模块，pom.xml 文件退出 HystrixDashboard 依赖，其余依赖包含 Feign，Ribbon，Eureka（可参考 80 模块的依赖）

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-hystrix-dashboard</artifactId>
        </dependency>

2. application.yml 文件中配置端口（如 9001）
3. provider 类中确认要退出 actuator 依赖（此为监控依赖）

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>

4. 编写主启动类，上标 @EnableHystrixDashboard 标注

@SpringBootApplication
@EnableHystrixDashboard
public class DashBoard9001_APP {public static void main(String[] args) {SpringApplication.run(DashBoard9001_APP.class,args);
    }
}

5. 启动服务进行测试，拜访地址：http://localhost:9001/hystrix，（依据配置端口号），== 看到刺猬示意曾经配置好了 ==

如何监控

• 在 dashboard 界面中，填入须要监控的服务地址和端口号加上 \hystrix.stream 和监测距离即可进入监控。（如 http://localhost:8001/hystrix.stream

监控剖析

• 七色：进入监控界面后会有其中色彩的数字，其含意能够对应右上角雷同色彩的单词示意的状态，其值代表该状态下触发的次数
• 一圈：圈的大小代表该服务的流量，圈越大流量越大
• 一线：代表监控距离中，服务被拜访的频率的折线图
• 通过观察这些就能够在大量的实例中找出故障实例和低压实例进行修复和保护。

Zuul 路由网关

概述

1. 代理：Zuul 提供内部的申请转发到具体的微服务实例中的服务
2. 路由：Zuul 能够对外部拜访实现对立的入口
3. 过滤：Zuul 能够对外部拜访进行干涉，如申请校验、服务聚合等
4. Zuul 须要配合 Eureka 应用，须要在 Eureka 中注册并取得其余微服务的信息
5. 了解：Zuul 就像大楼的保安，能够请他找人（代理），找的人在里面叫什么名字（路由），准不准你进楼（过滤）。因为保安属于物业公司，所以保安要在物业公司注册，所取得的信息也来源于物业公司（与 Eureka 的关系）。

根本配置

1. 构建新的 Zuul 模块并在 pom.xml 中退出依赖（Zuul 和 Eureka 必须同时退出）

<dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka</artifactId>
</dependency>
<dependency>
       <groupId>org.springframework.cloud</groupId>
       <artifactId>spring-cloud-starter-zuul</artifactId>
</dependency>

2. 新建 application.yml 文件并配置（肯定要向 Eureka 注册，因为 Zuul 自身也是一个微服务）

server:
  port: 9527

spring:
  application:
    name: microservicecloud-zuul   #为这个服务取名，十分重要！！！！！eureka:
  client:
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/
  instance:
    instance-id: zuul.com
    prefer-ip-address: true

3. 批改 hosts 文件（非必须，不过能更好看出成果）

127.0.0.0 zuul.com

4. 创立主启动类，并退出 @EnableZuulProxy 注解

@SpringBootApplication
@EnableZuulProxy
public class Zuul9527_APP {public static void main(String[] args) {SpringApplication.run(Zuul9527_APP.class,args);
    }
}

5. 启动测试，拜访规定：步骤 3 中指定映射 + 端口号 + 微服务名称 + 拜访门路。

   例子：http://zuul.com:9527/microservicecloud-dept/dept

路由拜访映射规定

服务名映射和对立公共前缀

当不向裸露实在的服务名时，能够对服务名进行映射，只需在 application.yml 中配置即可，== 具体作用看正文 ==

zuul:
  routes:
      #dept0 是能够自定义的只是作为辨别，没什么具体意义
    dept0.serviceId: microservicecloud-dept        
    #门路也是自定义的，反对通配符
    dept0.path: /dept10/**                        
  #须要暗藏的服务名，能够应用通配符，配置之后通过这个微服务名拜访就生效了
  ignored-services: microservicecloud-*
  #设置对立公共前缀，设置后拜访门路：http://zuul.com:9527/nihao/dept10/dept/3
  prefix: /nihao                                

== 注：因为 Zuul 是针对内部拜访治理的，所以配置了暗藏的服务，在零碎中其余模块进行服务名拜访时仍然能够失常运行的，这点能够通过关上 consumer 模块进行验证！==

SpringCloud Config 分布式配置核心

分布式系统面临的配置问题：微服务意味着将单体利用拆分成一个个自服务，这些服务都是要相应的配置信息能力运行，随着零碎内微服务数量越来越多，配置信息也一直地增多，所以一套集中式的、动静的配置管理设施是必不可少的。

概述

• SpringCloud Config 是一个提供内部集中式配置管理的设施，配置服务器为各种不同的额微服务利用提供了一个中心化的内部配置

• SpringCloud Config 分为客户端和服务端两局部

  1. 服务端：分布式配置核心，是一个独立的微服务，用来连贯并为客户端提供配置信息，加密 / 解密信息等拜访接口
  2. 客户端：通过指定的配置核心获取配置资源，cloud 举荐用 git 来存储配置信息

• SpringCloud Config 解决的问题：

  1. 集中管理配置文件
  2. 不同环境不同配置，动态化的配置更新
  3. 运行期间动静调整配置，不再须要在每个服务部署的机器上编写配置文件，让服务中心对立为服务拉取配置文件
  4. 当配置产生变动时，服务不须要重启即可感知配置变动并利用
  5. 将配置信息以 REST 接口模式裸露

SpringCloud Config 服务端与 Github 通信

指标：将配置文件部署在 github，Config 服务端从 github 获取配置

案例

1. 新建 ConfigServer 模块并配置 pom.xml

        <!-- springCloud Config -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-config-server</artifactId>
        </dependency>
        <!-- 防止 Config 的 Git 插件报错：org/eclipse/jgit/api/TransportConfigCallback -->
        <dependency>
            <groupId>org.eclipse.jgit</groupId>
            <artifactId>org.eclipse.jgit</artifactId>
            <version>4.10.0.201712302008-r</version>
        </dependency>

2. 建设近程仓库，并上传配置文件。如下例

spring: 
    profiles: 
        active:
           - dev
---
spring:
    profiles: dev
    application:
        name: microservicecloud-config-XXX-dev
---
spring:
    profiles: test
    application:
        name: microservicecloud-config-XXX-test

3. 在 application.xml 文件中配置 github 地址

server:
  port: 3344

spring:
  application:
    #为这个服务取名，十分重要！！！！！name: microservicecloud-config
  cloud:
    config:
      server:
        git:
          # uri 填 github 上仓库地址
          uri: https://github.com/XXXX/SpringCloud_Configuration.git

4. 编写主启动类，退出 @EnableConfigServer 注解

@SpringBootApplication
@EnableConfigServer
public class ConfigServer3344_APP {public static void main(String[] args) {SpringApplication.run(ConfigServer3344_APP.class,args);
    }
}

5. 启动服务并尝试拜访配置文件，有以下五种拜访配置规定

   • {application}：配置文件的文件名
   • {profile}：读取的环境
   • {lable}：分支

/{application}/{profile}[/{lable}]
/{application}-{profile}.yml
/{lable}/{application}-{profile}.yml
/{application}-{profile}.properties
/{lable}/{application}-{profile}.properties

可用例子（返回格局可能不大雷同，但返回值雷同）：

• http://config3344.com:3344/application-test.yml
• http://config3344.com:3344/master/application-dev.yml
• http://config3344.com:3344/application-test.yml/master

不可用例子：

• 没有该环境，返回空值：http://config3344.com:3344/application-test11.yml/master
• 没有配置文件，犯回谬误页面：http://config3344.com:3344/lkjliiusdfsddsfl.yml

bootstrap.yml 介绍

• bootstrap.yml 比 application.yml 具备更高的优先级。
• bootstrap.yml 是零碎级的资源配置项，application.yml 是用户级的资源配置项。
• SpringCloud 会创立 ”BootStrap Context” 作为 ”ApplicationContext” 的 == 父上下文 ==。初始化的时候 BootStrap Context 负责从内部源加载配置属性并解析。这两个上下文共享一个 ”Environment”，BootStrap 具备更高优先级，他们不会被本地配置笼罩。

客户端的配置与测试

介绍：客户端次要是在 == 加载时 == 通过 config server 服务端取得 github 配置仓库的地址，进而通过指标配置文件的文件名获取相应的配置，最初将获得的配置对本身资源进行赋值并提供拜访

实现过程

1. 创立近程配置 yml 文件并上传到 github 上。如下测试案例因为须要进行测试，所以配置了两个 profiles 不便切换并察看

spring: 
    profiles: 
        active:
           - dev
---
server: 
    port: 8201
spring:
    profiles: dev
    application:
        name: microservicecloud-config-client-dev
eureka:
    client: 
        service-url: 
            defaultZone: http://eureka-dev.com:7001/eureka/
---
server: 
    port: 8202
spring:
    profiles: test
    application:
        name: microservicecloud-config-client-test
eureka:
    client: 
        service-url: 
            defaultZone: http://eureka-dev.com:7001/eureka/

2. 本地创立 config client 模块，并配置好 pom.xml，以下本组件是必选依赖

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-config</artifactId>
        </dependency>

3. 编写 bootstrap.yml 配置文件，这个步骤比拟要害，次要是依据此处的配置信息去寻找 config server 以取得 github 仓库地址和配置中的指标配置文件文件名

spring:
  cloud:
    config:
      name: application_config #须要从 github 上读取的资源名称，留神没有 yml 后缀名
      profile: test   #本次拜访的配置项
      label: master
      uri: http://config3344.com:3344  #本微服务启动后先去找 3344 号服务，通过 SpringCloudConfig 获取 GitHub 的服务地址 

4. application.yml 文件在本 module 中其实是可写可不写的，为了习惯须要，还是给他写了个名字

spring:
  application:
    name: microservicecloud_config

5. 批改 host 文件减少映射，和 3344 一样
6. 编写主启动类，没什么特地的，最根本的主启动类
7. 编写 controller，此步骤也比拟要害，次要是利用 @Value 注解赋值，若写错了 bootstrap.yml 中的配置文件名称而没有获取到配置，启动时这里会抛出异样。@Value 中注解的参数即是指标配置文件中的参数值，应用 El 表达式获取

@org.springframework.web.bind.annotation.RestController
public class RestController {@Value("${server.port}")
    private String port;
    @Value("${eureka.client.service-url.defaultZone}")
    private String eurekaZone;
    @Value("${spring.application.name}")
    private String name;


    @GetMapping("/config")
    @Override
    public String toString() {
        return "RestController{" +
                "port='" + port + '\'' +
                ", eurekaZone='" + eurekaZone + '\'' +
                ", name='" + name + '\'' +
                '}';
    }
}

8. 先启动 config server 服务，而后再启用本 client 服务，依据 profiles 的值拜访对应的端口即可。如本例抉择的是 test，则拜访端口为：http://config3355.com:8202/config。（config3355.com 为 hosts 文件中配置了的映射）

SpringCloud 的配置实战

介绍：其实后面 client 的配置案例都是帮忙了解这个组件为主，并没有很大的实际意义。。。。。。这节的案例中是配置一个 Provider，一个 eureka，他们的配置对立在 github 上获取，实现对立配置分布式治理和多环境变更，这个才比拟有实战意义。

实现过程

1. 先写好 provider 和 Eureka 的配置 yml 文件，这两个文件和平时配置没什么不同，因为这里次要是说 config，所以就没有配置集群，上传 yml 到 github

Eureka 配置文件示例：

spring: 
    profiles: 
        active:
           - dev
---
spring:
    profiles: dev
    application:
        name: microservicecloud-eureka-client-dev
server:
  port: 7001
eureka:
  instance:
    hostname: eureka7001.com    #hostname 为 hosts 文件中映射的地址
  client:
    register-with-eureka: false     #false 示意不向注册核心注册本人
    fetch-registry: false           #false 示意本人就是注册核心，职责是保护实例，不加入检索
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka/   #设置 eureka server 的交互地址

---
spring:
    profiles: test
    application:
        name: microservicecloud-eureka-client-dev
server:
  port: 7001
eureka:
  instance:
    hostname: eureka7001.com    #hostname 为 hosts 文件中映射的地址
  client:
    register-with-eureka: false     #false 示意不向注册核心注册本人
    fetch-registry: false           #false 示意本人就是注册核心，职责是保护实例，不加入检索
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka/    #设置 eureka server 的交互地址 

Provider 配置文件示例：

spring: 
    profiles: 
        active:
           - dev
---
server:
  port: 8001

mybatis:
  config-location: classpath:mybatis/mybatis.cfg.xml
  type-aliases-package: com.XXX.entity
  mapper-locations:
  - classpath:mybatis/mapper/**/*.xml
spring:
  profiles: dev
  application:
    name: microservicecloud-dept   #为这个服务取名，十分重要！！！！！datasource:
    type: com.alibaba.druid.pool.DruidDataSource
    driver-class-name: org.gjt.mm.mysql.Driver
    url: jdbc:mysql://192.168.88.246:3306/cloudDB01
    username: root
    password: 123456
    dbcp2:
      min-idle: 5         #最小连接数
      initial-size: 5    #初始化连接数
      max-total: 10      #最大连接数
      max-wait-millis: 200  #期待连贯最长的超时工夫
eureka:
  client:
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka/
  instance:
    instance-id: dept8001
    prefer-ip-address: true
---
server:
  port: 8001

mybatis:
  config-location: classpath:mybatis/mybatis.cfg.xml
  type-aliases-package: com.XXX.entity
  mapper-locations:
  - classpath:mybatis/mapper/**/*.xml
spring:
  profiles: test
  application:
    name: microservicecloud-dept   #为这个服务取名，十分重要！！！！！datasource:
    type: com.alibaba.druid.pool.DruidDataSource
    driver-class-name: org.gjt.mm.mysql.Driver
    url: jdbc:mysql://192.168.88.246:3306/cloudDB02
    username: root
    password: 123456
    dbcp2:
      min-idle: 5         #最小连接数
      initial-size: 5    #初始化连接数
      max-total: 10      #最大连接数
      max-wait-millis: 200  #期待连贯最长的超时工夫
eureka:
  client:
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka/
  instance:
    instance-id: dept8001
    prefer-ip-address: true

2. 新开 eureka 和 provide 的模块并在 pom.xml 中增加依赖，其余必要依赖和之前的案例一样，然而 config 的依赖肯定要增加上

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-config</artifactId>
        </dependency>

3. 两个模块都要编写 bootstrap.yml 文件，和下面的案例一样

spring:
  cloud:
    config:
      name: application_config #须要从 github 上读取的资源名称，留神没有 yml 后缀名
      profile: test   #本次拜访的配置项
      label: master
      uri: http://config3344.com:3344  #本微服务启动后先去找 3344 号服务，通过 SpringCloudConfig 获取 GitHub 的服务地址 

4. (可选) 两个模块中编写 application.yml 文件，能够配置一下服务名

spring:
  application:
    name: microservicecloud_config

5. 两个模块的主启动类，Eureka 的失常加 EurekaServer 注解，Provider 加 EurekaClient 注解，不详述
6. 编写 Provider 模块的业务代码
7. 启动测试，因为这两个模块都要通过 3344ConfigServer 为其在 github 上获取配置，所以要先启动 3344 模块，而后再一次启动 eureka 和 provider 模块，进行测试即可。

本文由 mdnice 多平台公布