20191003 尚硅谷Spring Cloud教学视频

视频信息

视频日期：2018-4-19

讲师：尚硅谷周阳

Spring Cloud版本：Dalston.RELEASE

当前版本：Greenwich SR3

微服务、微服务架构、Spring Cloud

微服务和微服务架构

提出者：马丁弗勒

提出时间：2014

对于微服务，业界还没有一个统一的定义。

微服务架构是一种架构模式或者说是架构风格，提倡将单一应用程序根据业务划分成一组小的服务，每个服务运行于独立的进程中。服务间互相配合，基于轻量级的通信机制（基于HTTP的RESTful API）。

微服务、微服务架构、Spring Cloud 三者不同。

微服务强调宏观、整体。

微服务能使用不同语言开发

微服务只是业务逻辑的代码，不会和HTML，CSS或其他页面组件混合。

每个微服务都有自己的存储能力，可以有自己的数据库。也可以使用统一的数据库。

微服务技术栈是多种技术的集合体

Spring Cloud

Spring Cloud提供完整的微服务架构

Spring Cloud 是基于 Spring Boot 提供的一套微服务解决方案。

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

Spring Cloud 和 Spring Boot

Spring Cloud 和 Spring Boot是什么关系：

Spring Boot专注于快速方便的开发单个个体微服务。

Spring Cloud是关于全局的微服务协调整理治理框架，它将Spring Boot开发的一个个单体微服务整合并管理起来，为各个微服务之间提供集成服务，如配置管理、服务发现、断路器等等。

Spring Boot可以离开Spring Cloud独立使用开发项目，但是Spring Cloud离不开Spring Boot，属于依赖关系。

Spring Boot 专注于快速、方便的开发单个微服务个体，Spring Cloud关注全局的服务治理框架。

Spring Cloud 和 Dubbo

通过Github的仓库曲线看活跃度。

最大区别：

Spring Cloud 抛弃了Dubbo采用的RPC通信，采用的是基于HTTP的REST方式。

品牌机与组装机的区别：

Dubbo构建的微服务架构就像组装机，各个环节的选择自由度很高，但是可能某个环节质量容易出问题；Spring Cloud就像品牌机，做了大量的兼容性测试，更加稳定。

Dubbo有过5年左右的停止更新，于2017.7重启。

Dubbo重启维护开发的刘军：

Dubbo的定位始终是一款RPC框架，而Spring Cloud的目标是微服务架构下的一站式解决方案。如果非要类比，Dubbo可以类比为Netflix OSS技术栈，而Spring Cloud集成了Netflix OSS作为放不是服务治理解决方案。当前由于 RPC 协议、注册中心元数据不匹配等问题，在面临微服务基础框架选型时 Dubbo 与 Spring Cloud 是只能二选一，这也是为什么大家总是拿 Dubbo 和 Spring Cloud 做对比的原因之一。Dubbo 之后会积极寻求适配到 Spring Cloud 生态。

【开源访谈】刘军：无需“二选一”，Dubbo 将积极适配 Spring Cloud 生态

Spring全家桶的特点：

约定 > 配置 > 编码

Eureka

20.尚硅谷_SpringCloud_Eureka是什么

Eureka 遵守的是AP原则。

Eureka 采用CS架构。Eureka Server 作为服务服务注册功能功能的服务器，是服务注册中心。

Eureka 包含两个组件： Eureka Server 和 Eureka Client

Eureka Server 提供服务注册服务。

Eureka Client 是一个Java客户端，用于简化Eureka Server的交互，客户端同时也具备一个内置的、使用轮询负载算法的负载均衡器。在应用启动后，将会向Eureka Server发送心跳（默认周期30s）。如果Eureka Server在多个心跳周期内没有接收到某个结点的心跳，Eureka Server将会从服务注册表中把这个服务节点移除（默认90s）。

21.尚硅谷_SpringCloud_EurekaServer服务注册中心建立

Eureka Server 可以类比为办公楼里的物业公司。

启用Spring Cloud新技术的步骤：

1. 加入依赖GAV；
2. 在主程序上添加开启功能注解，如@EnableEurekaServer；

spring.application.name 的值就是注册进Eureka的微服务的名字。

24.尚硅谷_SpringCloud_微服务完善_主机IP信息提示

修改在Eureka中注册的主机映射显示：

eureka:
instance:
instance-id: microservicecloud-dept8001 # 主机映射名称
prefer-ip-address: true # 访问路径可以显示IP地址


25.尚硅谷_SpringCloud_微服务完善_info内容构建

INFO内容构建过程：

1. 引入 actuator；

<!-- actuator监控信息完善 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>


1. 增加Maven配置，用来动态获取配置文件信息；

<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>


1. 在项目中配置INFO信息；

info:
app.name: atguigu-microservicecloud
company.name: www.atguigu.com
build.artifactId: $project.artifactId$
build.version: $project.version$


26.尚硅谷_SpringCloud_Eureka自我保护机制介绍

在自我保护模式中，Eureka Server会保护服务注册表中的信息，不再注销任何服务实例。当它收到的心跳数重新恢复到阈值以上时，该Eureka Server节点就会自动退出自我保护模式。它的设计哲学就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。一句话说：好死不如赖活着。

27.尚硅谷_SpringCloud_Eure服务发现

1. 在主程序上增加开启功能注解 ；

@EnableDiscoveryClient //服务发现


1. 使用服务发现功能；

@Autowired
private DiscoveryClient client;
@RequestMapping(value = "/dept/discovery", method = RequestMethod.GET)
public Object discovery()
{
List<String> list = client.getServices();
System.out.println("**********" + list);List<ServiceInstance> srvList = client.getInstances("MICROSERVICECLOUD-DEPT");
for (ServiceInstance element : srvList) {
System.out.println(element.getServiceId() + "\t" + element.getHost() + "\t" + element.getPort() + "\t"
+ element.getUri());
}
return this.client;
}


28.尚硅谷_SpringCloud_Eureka集群配置

1. 修改Euraka实例名；

eureka:
instance:
hostname: eureka7001.com #eureka服务端的实例名称


1. 将实例名配置进hosts文件，文件路径为

C:\Windows\System32\drivers\etc\hosts


配置内容：

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


1. 修改配置文件：

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


集群的节点出现在 unavailable-replicas 下的可能原因：

原因一：prefer-ip-address 配置项设置错误

比如，9001 服务器设置了prefer-ip-address: true，那么它注册到 9002 和 9003 服务器时应该使用 defaultZone:http://yourIP:9001/eureka/ ，但此时可以发现使用的仍然是 hostname 名，导致错误发生。

另一种原因是，三个9001、9002 和 9003 都设置了prefer-ip-address: true，导致最后解析出来的 hostname 都是相同的IP，使副本不可用。

原因二：register-with-eureka 配置项设置错误

看网上很多博客和资料都把此项设置成了 false，此时 eureka 不会注册到其他服务器上，所以出现错误。

29.尚硅谷_SpringCloud_Eureka比Zookeeper好在哪里

CAP图：

分布式系统必须满足P（分区容错性）。

Zookeeper保证CP，

Eureka保证AP。

Zookeeper在master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举，选举期间zk集群不可用。

Eureka各个节点都是平等的，几个节点挂掉不影响其他节点正常工作。

Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样是整个注册服务瘫痪。

Ribbon

30.尚硅谷_SpringCloud_Ribbon是什么

Spring Cloud Ribbon 是基于Netflix Ribbon 实现的一套客户端负载均衡的工具。Spring Cloud的负载均衡算法可以自定义。

LB分为集中式LB和进程内LB。

集中式LB即在服务的消费方和提供方之间使用独立的LB设施（可以是硬件，如F5，也可以是软件，如Nginx），由该设施负责把访问请求通过某种策略转发至服务的提供方。

进程内LB将LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己在从这些地址中选择出一个合适的服务器。

Ribbon属于进程内LB，它只是一个类库，集成于消费方进程，消费方通过它来获取到服务提供方的地址。

31.尚硅谷_SpringCloud_Ribbon配置初步

1. 修改pom.xml；

<!-- Ribbon相关 -->
<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>


1. 修改application.yml；

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


1. 为RestTemplate增加@LoadBalanced注解；

@Bean
@LoadBalanced//Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端 负载均衡的工具。
public RestTemplate getRestTemplate()
{
return new RestTemplate();
}


1. 主启动类添加开启Eureka客户端功能注解@EnableEurekaClient；

2. 修改URL地址，将IP端口修改Eureka上注册的服务名称；

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


1. 进行测试；

Ribbon和Eureka整合后Consumer可以直接调用服务而不用再关心地址和端口号了。

32.尚硅谷_SpringCloud_Ribbon负载均衡

Ribbon在工作时分为两步：

第一步优先选择Eureka Server，它优先选择在同一个区域内负载较少的server。

第二步再根据用户指定的策略，在从Server渠道的服务注册列表中选择一个地址。

其中Ribbon提供了多种策略：比如轮询、随机和根据响应时间加权。

Ribbon其实就是一个软负载均衡的客户端组件，它可以和其他所需请求的客户端结合使用，和eureka结合只是其中一个实例。

33.尚硅谷_SpringCloud_Ribbon核心组件IRule

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

Robin内置了一些算法：

算法	功能
RoundRobinRule	轮询
RandomRule	随机
AvailabilityFilteringRule	会先过滤由于多次访问故障而处于断路器跳闸状态的服务，还有并发的连接数量超过阈值的服务，然后对剩余的服务列表按照轮询策略进行访问
WeightedResponseTimeRule	根据平均响应时间计算所有服务的权重，响应时间越快服务权重越大被选中的概率越高。刚启动时如果统计信息不足，则使用RoundRobinRule策略，等统计信息足够，会切换到WeightedResponseTimeRule
RetryRule	先按照RoundRobinRule的策略获取服务，如果获取服务失败则在指定时间内进行重试，获取可用的服务
BestAvailableRule	会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务，然后选择一个并发量最小的服务
ZoneAvoidanceRule	默认规则，符合判断server所在区域的性能和server的可用性选择服务器

34.尚硅谷_SpringCloud_自定义Ribbon的负载均衡策略(上)

自定义Ribbon规则：

1. 主启动类添加@RibbonClient注解

@RibbonClient(name="MICROSERVICECLOUD-DEPT",configuration=MySelfRule.class)


注意细节：

自定义配置类不能放在@ComponentScan所扫描的当前包下以及子包下，否则我们自定义的这个配置类就会被所有的Ribbon客户端所共享，也就是说达不到特殊定制的目的了。

Feign

36.尚硅谷_SpringCloud_Feign是什么

Feign是一个声明式WebService客户端。使用Feign能让编写Web Service客户端更加简单，它的使用方法是定义一个接口，然后在上面添加注解，同时也支持JAX-RS标准的注解。Feign也支持可插拔式的编码器和解码器。Spring Cloud对Feign进行了封装，使其支持Spring MVC标准注解和HttpMessageConverts。Feign可以与Eureka和Ribbon组合使用以支持负载均衡。

Feign是一个声明式的Web服务客户端，使得编写Web服务客户端变得非常容易。

只需要创建一个接口，然后在上面添加注解即可。

Feign是面向接口编程；

37.尚硅谷_SpringCloud_Feign工程构建

1. 添加GAV依赖；

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


1. 编写接口，使用注解@FeignClient；

@FeignClient(value = "MICROSERVICECLOUD-DEPT")
public interface DeptClientService
{
@RequestMapping(value = "/dept/get/{id}", method = RequestMethod.GET)
public Dept get(@PathVariable("id") long id);@RequestMapping(value = "/dept/list", method = RequestMethod.GET)
public List<Dept> list();@RequestMapping(value = "/dept/add", method = RequestMethod.POST)
public boolean add(Dept dept);
}


1. 主程序添加注解@EnableFeignClients；

2. 使用接口编写调用代码；

Hystrix

38.尚硅谷_SpringCloud_Hystrix断路器是什么

多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C有屌用其他的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”。

Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免地会调用失败，比如超时、异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。

“断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个符合预期的、可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要地占用，从而避免了故障在分布式系统的蔓延，乃至雪崩。

39.尚硅谷_SpringCloud_服务熔断

熔断机制是应对雪崩效应的一种微服务链路保护机制。

当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回“错误”的响应信息。当检测到该节点微服务调用相应正常后恢复调用链路。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败就会启动熔断机制。

1. 添加GAV依赖；

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


1. 主程序上添加开启功能注解

@EnableCircuitBreaker


1. Controller方法修改，添加注解，并增加返回错误信息的方法；

//一旦调用服务方法失败并抛出了错误信息后，会自动调用@HystrixCommand标注好的fallbackMethod调用类中的指定方法
@HystrixCommand(fallbackMethod = "processHystrix_Get")


public Dept processHystrix_Get(@PathVariable("id") Long id) {
return new Dept().setDeptno(id).setDname("该ID：" + id + "没有没有对应的信息,null--@HystrixCommand")
.setDb_source("no this database in MySQL");
}


40.尚硅谷_SpringCloud_服务降级

服务降级就是整体资源快不够了，忍痛将某些服务先关掉，待度过难关，再开启回来。

服务降级处理在客户端实现完成，与服务端没有关系。

实现步骤：

1. 根据已有的接口新建一个实现了FallbackFactory接口的类；

@Component // 不要忘记添加，不要忘记添加
public class DeptClientServiceFallbackFactory implements FallbackFactory<DeptClientService>
{
@Override
public DeptClientService create(Throwable throwable)
{
return new DeptClientService() {
@Override
public Dept get(long id)
{
return new Dept().setDeptno(id).setDname("该ID：" + id + "没有没有对应的信息,Consumer客户端提供的降级信息,此刻服务Provider已经关闭")
.setDb_source("no this database in MySQL");
}@Override
public List<Dept> list()
{
return null;
}@Override
public boolean add(Dept dept)
{
return false;
}
};
}
}


1. 在接口上增加注解信息；

@FeignClient(value = "MICROSERVICECLOUD-DEPT",fallbackFactory=DeptClientServiceFallbackFactory.class)


1. 客户端项目增加配置；

feign:
hystrix:
enabled: true


41.尚硅谷_SpringCloud_服务降级熔断小总结

熔断代码在服务端上，降级代码在客户端上。

熔断是代码异常，降级是服务关闭。

42.尚硅谷_SpringCloud_豪猪hystrixDashboard

实现步骤：

1. 监控服务、被监控服务添加GAV依赖；
   
   监控服务：

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

被监控服务：

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


1. 主程序上添加开启功能注解；

@EnableHystrixDashboard


1. 访问；

http://localhost:9001/hystrix


43.尚硅谷_SpringCloud_如何查看hystrixDashboard

被监控服务：

http://localhost:8001/hystrix.stream


监控服务：

http://localhost:9001/hystrix


7色/1圈/1线

实心圆：共有两种含义。它通过颜色的变化代表了实例的健康程度，它的健康度从绿色，黄色，橙色，红色递减。

除了颜色变化之外，它的大小也会根据实例的请求流量发生变化，流量越大该实心圆就越大。所以通过该实心圆的展示，就可以在大量的实例中快速的发现故障实例和高压力实例。

曲线：用来记录2分钟内流量的相对变化，可以通过它来观察到流量的上升和下降趋势。

Zuul

44.尚硅谷_SpringCloud_Zuul是什么

Zuul包含了对请求的路由和过滤两个最主要的功能：

路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础；过滤功能则负责对请求的处理过程进行干预，是实现请求校验、服务聚合等功能的基础。

Zuul和Eureka进行整合，将Zuul自身注册为Eureka服务治理下的应用，同时从Eureka中获得其他微服务的消息，也即以后的访问微服务都是通过Zuul跳转后获得。

Zuul服务最终还是会注册进Eureka

Zuul提供代理、路由、过滤三大功能。

45.尚硅谷_SpringCloud_Zuul路由基本配置

实现步骤：

1. 添加GAV依赖；

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


1. 主程序添加开启功能注解；

@EnableZuulProxy


1. 测试；
   
   3.1. 直接访问生产者程序；

http://localhost:8001/dept/get/1


3.2. 通过Zuul访问生产者程序；

http://localhost:9527/microservicecloud-dept/dept/get/3


中间的生产者名称要小写；

46.尚硅谷_SpringCloud_Zuul路由访问映射规则

实现步骤：

1. 使用虚拟路由访问服务；

zuul:
routes:
mydept.serviceId: microservicecloud-dept
mydept.path: /mydept/**


此时两个路径都可以访问：

http://localhost:9527/microservicecloud-dept/dept/get/3
http://localhost:9527/mydept/dept/get/2


1. 屏蔽带生产者名称的路径；

zuul:
ignored-services: microservicecloud-dept
routes:
mydept.serviceId: microservicecloud-dept
mydept.path: /mydept/**


此时，只有带虚拟路由的URL可以访问；

如果想要屏蔽所有带服务名称的路径：

zuul:
ignored-services: "*"
routes:
mydept.serviceId: microservicecloud-dept
mydept.path: /mydept/**


1. 为所有路径加上统一前缀：

zuul:
prefix: /atguigu
ignored-services: "*"
routes:
mydept.serviceId: microservicecloud-dept
mydept.path: /mydept/**


访问路径：

http://localhost:9527/atguigu/mydept/dept/get/3


此时，其他路径必须带上前缀，否则不能访问；

Spring Cloud Config

47.尚硅谷_SpringCloud_Config分布式配置中心是什么

解决的问题：

对大量的微服务产生的大量的配置进行统一管理

Spring Cloud Config 为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。

Spring Cloud Config 分为服务端和客户端两部分。

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

客户端则通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息，配置服务器默认采用git来存储配置信息。

能做什么：

1. 集中管理配置文件；
2. 不同环境不同配置，动态化的配置更新，分环境部署比如dev/test/prod/beta/release；
3. 运行期间动态调整配置，不再需要在每个服务部署的机器上编写配置文件，服务会向配置中心统一拉取配置自己的信息；
4. 但配置发生变化时，服务不需要重启即可感知到配置的变化并应用新的配置；
5. 将配置信息以REST接口的形式暴露；

48.尚硅谷_SpringCloud_Config服务端与Github通信

实现步骤：

1. 在GitHub上新建仓库microservicecloud-config；
2. 在仓库内增加配置文件，必须保存为UTF-8格式；

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


1. 为配置中心项目增加GAV依赖；

<!-- 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>


1. 修改项目配置；

spring:
cloud:
config:
server:
git:
uri: git@github.com:zzyybs/microservicecloud-config.git #GitHub上面的git仓库名字


1. 在主程序添加开启功能的注解；

@EnableConfigServer


1. 测试访问配置；
   
   

label在这里应该是分支的意思；

URL示例：

/application/dev/master
/application-dev.yml
/master/application-dev.yml


注意：三者返回的内容并不相同

49.尚硅谷_SpringCloud_Config客户端通过Config服务端获得Github上的配置

实现步骤：

1. 在GitHub上新建配置文件microservicecloud-config-client.yml，保存为UTF-8格式；

spring:
profiles:
active:
- dev---server:
port: 8201spring:
profiles: dev
application:
name: microservicecloud-config-client
---server:
port: 8202spring:
profiles: test
application:
name: microservicecloud-config-client


1. 在客户端项目上添加GAV依赖；

<!-- SpringCloud Config客户端 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
</dependency>


1. 新建bootstrap.yml配置文件；

spring:
cloud:
config:
name: microservicecloud-config-client #需要从github上读取的资源名称，注意没有yml后缀名
profile: dev #本次访问的配置项
label: master
uri: http://config-3344.com:3344 #本微服务启动后先去找3344号服务，通过SpringCloudConfig获取GitHub的服务地址


1. 新建Rest类，读取GitHub上的配置；

@RestController
public class ConfigClientRest
{@Value("${spring.application.name}")
private String applicationName;@Value("${eureka.client.service-url.defaultZone}")
private String eurekaServers;@Value("${server.port}")
private String port;@RequestMapping("/config")
public String getConfig()
{
String str = "applicationName: " + applicationName + "\t eurekaServers:" + eurekaServers + "\t port: " + port;
System.out.println("******str: " + str);
return "applicationName: " + applicationName + "\t eurekaServers:" + eurekaServers + "\t port: " + port;
}
}


1. 启动并验证；
   
   此时的启动端口应该是8201，修改bootstrap.yml中的

profile: test


再次启动时，启动端口应该是8202；

证明成功；

application.yml和bootstrap.yml

application.yml是用户级的资源配置项；

bootstrap.yml是系统级的，优先级更加高；

Spring Cloud会创建一个 Bootstrap Context ，作为Spring应用的 Application Context 的父上下文。初始化的时候， Bootstrap Context 负责从外部源加载配置属性并解析配置。这两个上下文共享一个从外部获取的 Environment 。

Bootstrap 属性有高优先级，默认情况下，它们不会被本地配置覆盖。 Bootstrap Context 和 Application Context 有着不同的约定，所以新增一个 bootstrap.yml 文件，保证 Bootstrap Context 和 Application Context 的分离。