spring cloud

项目参考：distributed_project_cluster_demo / distributed_project_demo

一、什么是微服务

马丁福勒说微服务没有统一的定义和标准，提倡将传统的单体应用服务，
按业务、按功能拆分成多个各自独立的微小的子服务，每个子服务能独立部署、
独立运行类似进程、可以拥有自己独立的数据库DB，
子服务之间通过http rest api 通信或者使用RPC远程过程调用通信，
相互协作完成业务逻辑 。
// 微服务之间的通信手段：
// http rest 通信，spring cloud 框架 // Feign底层也是通过rest通信
// RPC Remote Procedure Call 远程过程调用，dubbo 框架/dubbox/HSF

二、什么是微服务架构

微服务架构是一种设计思想、架构模式，从宏观来看，他是由多个微服务构成，
各微服务之间相互通信完成业务逻辑。
将单体应用（单体架构）按照业务维度垂直拆分，得到是SOA架构的系统，
对SOA架构的系统再进行按照功能维度水平拆分，拆分成诸如网关层、业务逻辑层、数据访问层、
DB存储层等微服务系统，水平拆分得到的是水平分层架构的系统，
垂直拆分+水平拆分=微服务架构，在微服务架构的基础上，如果对一些通用的服务，
诸如注册中心、配置中心、路由网关、熔断器等继续下沉为独立的服务，
就形成服务网格架构service mesh。
// 单体架构：app-->nginx-->war-->DB 需要集群时，将war部署到多台tomcat
// 水平分层同步架构：app-->nginx-->网关层-->业务逻辑层-->数据访问层-->DB 
// 水平分层异步架构：app-->nginx-->网关层-->消息队列MQ-->业务逻辑层-->数据访问层-->DB
// 垂直分层架构、SOA架构：app-->nginx-->多个独立服务，通过企业总线ESB通信
// 垂直+水平拆分微服务架构、对微服务架构的公共模块继续下沉为服务，演变成服务网格架构（service mesh）

三、微服务的优缺点，在项目开发中碰到的坑

优点：
1、将一个单体服务拆分成多个独立的微小服务，每个微服务只做自己关心的一件事，方便开发团队分工协作，做自己擅长的模块，提高开发效率。
2、各个微服务独立部署独立运行、拥有自己独立的DB，可以按照需要单独为某个微服务进行集群，提高可用性。
3、微服务模块之间可以灵活的相互调用，如果有新的业务模块，只需要增加和新业务相关的微服务，其他需要用到的服务，可以调用之前已有的微服务提供服务。

缺点：
1、多个独立的微服务，相互通信完成业务逻辑，增加了通信的成本和开放难度，由于网络原因平均响应延迟比单体服务长。
2、微服务只关注自己独立的业务，一些公共的业务逻辑，难免出现重复代码。
3、微服务数量较多，且都可以各种独立部署，增加了运维方面的难度和成本（系统集成、性能监控、数据一致性问题）。

碰到的坑：
1、springboot、springcloud版本更新快，不同的版本有一定的差异，导致之前能好好工作的组件功能，升级版本后可能就不行了。新版本需要重新调整代码。
2、RestTemplate 的postForObject(url,param,clazz) param：pojo对象、hashmap/linkedHashMap传递参数，提供者那边收不到参数，
param需要转换成json，或者使用linkedMultiValueMap来传递。
3、在eureka服务注册时，application.name应用名最好全部小写或者全部大写，不能使用下划线，可以使用中划线。使用下划线会导致服务发现时出现找不到的情况。

四、springcloud和dubbo有什么区别

1、springcloud微服务之间采用http rest api的方式进行通信，dubbo采用RPC方式通信。
2、springcloud的社区活跃度比dubbo高。dubbo中间停滞了5年没有人维护更新。
3、springcloud提供的是分布式环境下微服务架构的整体解决方案，一站式服务，技术支持完善，dubbo只是一个RPC 远程过程调用的一个通信框架而已。
4、springcloud的注册中心采用Eureka，dubbo的注册和服务发现采用的是Zookeeper，
zookeeper是CP模型，eureka是AP模型的系统，性能高于zookeeper。
// 当前各大IT公司的微服务架构：
// 阿里dubbo，第二代HSF
// 京东JSF
// 新浪微博motan
// 当当网的dubbox

五、微服务技术栈有哪些

1、服务开发：springboot、springcloud、springmvc
2、服务注册与发现：客户端的发现组件：eureka、zookeeper，服务端的发现组件：consul、nginx
3、负载均衡：ribbon、feign、nginx
4、服务熔断器、服务降级：hystrix、envoy
5、路由网关：zuul、springcloud gateway、nginx/kong、tyk、node.js
// zuul的IO模型是BIO、springcloud gateway是netty，nginx/kong是epoll,tyk是AIO、node.js是AIO，AIO的底层采用的是netty，netty的底层采用的epoll
6、配置中心：spring-cloud-config
7、服务调用：rest、rpc、grpc
8、服务部署：docker
9、数据流开发包：springcloud stream
10、事件消息总线：springcloud bus
// 客户端的发现组件：eureka、zookeeper
// 服务端的发现组件：consul、nginx
// 服务发现组件的功能：
// 1、服务注册表：是一个记录当前可用实例的网络信息的数据库，是服务发现机制的核心，提供查询API和管理API，使用查询API获得可用的服务实例，使用管理API实现注册和注销。
// 2、服务注册
// 3、健康检查

六、springboot和springcloud请你谈谈对他们的理解

1、springboot是一个快速开发框架，继承了spring的优秀基因，
使我们对spring的使用变得更加简单，取消了繁杂的xml配置，采用纯java注解的方式，
对各种应用场景进行封装，自动装配，通过maven子工程的方式快速整合第三方框架，
且内嵌了web容器，通过主程序main方法启动，方便了开发，方便了部署，方便了配置，方便了监控。springboot虽然很优秀很方便了，但也有他的不足，缺少像eureka、zookeeper这样注册与发现的解决方案，
缺少像spring security、shiro这样的外围权限控制解决方案、缺少外网的服务监控解决方案，
比如hystrix熔断监控，他仅仅是一个微框架，距离微服务框架还有点距离，他的这些不足，
统统可以通过springcloud微服务框架来弥补。
2、springcloud是基于springboot的一个微服务框架，提供分布式环境下的整体解决方案，
是一系列框架的有序集合，
诸如：路由网关、服务注册与发现、服务熔断降级、负载均衡、配置管理、微代理、控制总线等。
/**
springcloud的5大核心组件：
1、路由网关：zuul
2、断路器、服务降级：hystrix
3、负载均衡：ribbon
4、配置中心：springcloud config
5、服务注册与发现：eureka
**/

七、什么熔断、什么降级

1、熔断就类似于保险丝的概念，在互联网系统中下游服务由于访问压力过大从而影响整体服务失败或变慢，上游服务为了保护系统的整体可用性，可以暂时切断对下游服务的调用。
2、降级就是服务降级，由于下游服务被熔断，或被迫关闭了其中某些微服务，对于整体服务来说，就是服务降级了。这种降级的做法，为其他微服务节省出来资源，保证了整体系统的可用性。
3、熔断降级组件，我使用的是hystrix，引入hystrix相关依赖，开启@EnableCircuitBreaker熔断机制，一种方案是在服务提供者的controller层处理，通过@HystrixCommand(fallbackMethod="处理熔断的方法")注解的方式实现。经这个注解修饰的方法，会被hystrix dashboad 监控到。这种方案的缺点是业务逻辑的方法和熔断处理的方法，会耦合在一起，并且引起方法膨胀，一个业务逻辑方法就对应一个熔断处理的方法。
另一种方案：是在消费者的接口层面处理，服务提供者正常提供服务，当我们去消费时，如果请求压力过大，这时产生的问题，就该在消费方处理，这样就能使业务逻辑和熔断处理不高耦合。在消费者的接口层，通过实现FallbackFactory接口，以泛型的方式，对某个服务的接口进行服务降级处理，重写该服务接口的所有方法，加入熔断处理的逻辑。这里需要注意的是，这个实现FallbackFactory接口的类对象必须放在IOC容器中，即通过@component注解标识。在消费方通过Feign的方式调用服务时，通过@FeignClient注解来完成。@FeignClient(name="CLOUD-PROVIDER",fallbackFactory = xxxFallbackFactory.class) ，所有的方法的熔断处理统统通过fallbackFactory工厂来处理。
// Feign是通过接口+注解 来实现客户端的负载均衡请求的响应，消费方这里没有具体的业务实现，消费方通过调用服务提供方来获得服务实现，故Feign在接口上通过@FeignClient的方式来指定调用哪个微服务的服务和指定使用哪个fallbackFactory来处理服务降级。Feign底层通过rest去和服务提供者通信，故接口的方法上，需要做好与服务提供者相关的映射请求，springcloud对feign进行了使之支持springmvc注解。

当前系统中有A，B，C三个服务，服务A是上游，服务B是中游，服务C是下游。一旦下游服务C因某些原因变得不可用，积压了大量请求，服务B的请求线程也随之阻塞。线程资源逐渐耗尽，使得服务B也变得不可用。紧接着，服务A也变为不可用，整个调用链路被拖垮。
// 1.开启熔断
在固定时间窗口内，接口调用超时比率达到一个阈值，会开启熔断。进入熔断状态后，后续对该服务接口的调用不再经过网络，直接执行本地的默认方法，达到服务降级的效果。
// 2.熔断恢复
熔断不可能是永久的。当经过了规定时间之后，服务将从熔断状态恢复过来，再次接受调用方的远程调用。

八、Eureka和Zookeeper都能做注册和发现的功能，请说说他们的区别

// CAP consistency availablity partition 模型
CAP理论指出分布式系统，不可能同时满足C（一致性）、A（可用性）、P（分区容错性），由于P是分布式系统中必须要保证的，我们只能在C和A之间权衡，zookeeper是CP，eureka是AP。

1、zookeeper保证的是一致性和分区容错性，即保证CP，由于网络不畅原因，zookeeper可能会出现master节点和其他节点失去联系的情况，此时如果超过一半以上的节点和master节点之间没有心跳，则认为master节点挂掉了，需要重新选举leader，而在选举leader期间，对外不提供服务，即服务处于瘫痪状态，这一段时间对外都停止了服务，给我们带来的影响是不可忽略的，是很严重的，这个也是zookeeper在网络不稳定时暴露出来的缺陷。当然zookeeper在一定的选举时间内，最终也会选举出leader，然后继续对外提供注册和发现服务，zookeeper保证了数据的一致性，没有保证数据的可用性，而对于注册和发现这样的服务，我们需要的是可用性，可以容忍数据的暂时不一致性。
2、eureka保证的是可用性和分区容错性，即保证AP，他不像zookeeper那样有leader的情况，而是每个节点均平等，如果请求到某个节点，由于网络问题没有及时提供服务，则会自动切换请求其他可用节点，只要有1个eureka节点可用，系统就能对外提供服务，保证了可用性。提供注册服务不会受一点影响，发现服务可能的问题是你查询的数据不是最新的，但保证服务仍然可用，他会在网络稳定时，同步各个节点，保证数据的最终一致性。
eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。
/** eureka的自我保护机制：若在15分钟之内，超过85%的节点都没有正常的心跳，那么eureka就认为客户端和服务端出现了网络故障，就会启动自我保护机制。启动自我保护机制后有如下表现：
	1、不再移除注册列表中因长时间没有心跳的服务，保证其可用，不保证数据的一致性，可能查询到的数据是旧数据。
	2、eureka仍然能保证新服务的注册和发现请求，但是不会立刻同步到其他节点上去，保证当前节点仍然可用。
	3、当网络稳定时，当前实例新的注册信息会被同步到其他节点中。
*/

九、服务提供者与消费者

不引入注册中心eureka、zookeeper，微服务之间也可以通信，使用rest通信，
自动装配RestTemplate对象来请求：
//  postForObject(url,param,clazz) / getForObject(url,clazz)
// url是rest请求的地址，param是请求的参数，clazz是请求后返回的类型
注意这里的param是json对象，或者是LinkedMultiValueMap对象后台才会收到传递过去的参数，
pojo对象，hashmap/linkedHashMap可能会导致参数丢失。 
// @SpringBootConfiguration == Configuration
// @Bean new RestTemplate() 在IOC容器注册Bean

服务提供者和服务消费者可以通过Rest进行远程通信，缺点：
1、通信地址是写死在程序里的，如果提供者的机器重启地址变更，需要维护消费者的调用地址。
2、如果提供者有很多，消费者如何实现负载均衡，如果使用Nginx，那可能需要很多Nginx才行，很难维护。
// 微服务与微服务之间相互通信，迫切需要一种服务发现组件，可以通过服务名寻找到服务，
// 找到服务的ip和port，这样通信地址就不用写死了。
// 服务发现组件自身集成了负载均衡的方式去发现服务。
// 比如eureka，我们使用ribbon+rest就能很好的解决负载均衡方式的调用，还可以使用Feign的方式，Feign的底层也是ribbon+rest。
// 服务发现组件：eureka、zookeeper，他们都是基于客户端的负载均衡的服务发现组件。
// 服务发现组件：nginx、consul，他们都是基于服务端的负载均衡的服务发现组件。

1、服务消费者consumer端，如果在没有使用ribbon的前提下，即没有加@LoadBalanced时，
直接通过rest去请求提供者，如果没有开启@EnableDiscoveryClient或者@EnableEurekaClient，则发现不了服务，调用失败，如果加了@LoadBalanced，默认开启了服务发现组件。
2、@EnableDiscoveryClient激活开启所有发现组件的客户端，包括Eureka的，@EnableEurekaClient只开启eureka的客户端。
3、如果使用ribbon以负载均衡的方式去消费服务，则默认自动开启@EnableDiscoveryClient。

十、eureka

Netflix eureka 是一个服务注册、服务发现的组件，有服务端和客户端，主要提供服务注册与发现功能。eureka来自生产环境，springcloud对eureka的支持很好，eureka和很多技术的结合比较完善。
1、pom 服务端：spring-cloud-starter-netflix-eureka-server
2、pom 客户端：spring-cloud-starter-netflix-eureka-client
3、注册中心，就像是物业，有服务端和客户端之分，其他的公司来物业这里登记驻入，物业是Server，其他公司是client。
// 1pom,2yml,3main
// application.yml:
// 指定微服务的端口号server.port，指定微服务的应用名：spring.application.name，该name就是在注册中心注册时唯一标识身份的目录名。
// 注册中心客户端连接服务的url地址：eureka.client.service-url.defaultZone
// 可选项：
// 1、注册中心上的实例名eureka.instance.instance-id
// 2、鼠标移上该实例是否显示ip：eureka.instance.perfer-ip-address
// 3、当前项目当前微服务是否注册到eureka：eureka.client.register-with-eureka=false 默认是true
// 4、当前微服务是否从eureka服务端获取注册信息：eureka.client.fetch-registry=false 默认是true
// main：@EnableEurekaServer开启eureka服务端，@EnableEurekaClient开启eureka客户端，@EnableDiscoveryClient开启客户端-消费者的发现服务，和@EnableEurekaClient类似，但是语意更大，泛指开启所有的发现客户端。

eureka的自我保护机制：若在15分钟之内，超过85%的节点都没有正常的心跳，那么eureka就认为客户端和服务端出现了网络故障，就会启动自我保护机制。启动自我保护机制后有如下表现：
	1、不再移除注册列表中因长时间没有心跳的服务，保证其可用，不保证数据的一致性，可能查询到的数据是旧数据。
	2、eureka仍然能保证新服务的注册和发现请求，但是不会立刻同步到其他节点上去，保证当前节点仍然可用。
	3、当网络稳定时，当前实例新的注册信息会被同步到其他节点中。
// 在没有启动自我保护机制时，如果一定时间内（每30s检测一次，连续3次没有检测到心跳则T掉）没有检测到心跳的服务，eureka会将该微服务提掉（服务注销）。

eureka通过心跳检测、健康检查、客户端缓存机制，确保了系统的高可用性、灵活性和可扩展性。
// 在eureka server启动后，再启动了服务提供者provider，再启动服务消费者consumer，能正常消费服务，这时如果把eureka server关闭，consumer由于有客户端缓存，仍然能找到provider，仍然能正常消费。

如果eureka的服务端引入了spring-boot-starter-security组件，在服务端需要禁用csrf，否则eureka客户端注册不上。
//覆盖父类的 configure(HttpSecurity http) 方法，禁用掉httpSecurity的csrf功能。
    @EnableWebSecurity
    static class WebSecurityConfig extends WebSecurityConfigurerAdapter {
        @Override
        protected void configure(HttpSecurity http) throws Exception {
            http.csrf().disable();
        }
    }

十一、ribbon

netflix公司的ribbon主要提供客户端的负载均衡算法，将Netflix的中间层服务连接在一起，
比如和Eureka一起使用，使用负载均衡算法去eureka注册中心中寻找服务提供者。
负载均衡算法诸如轮询、随机等等，还可以很容易的自定义负载均衡算法。
pom.xml：spring-cloud-starter-netflix-ribbon
重要注解：@LoadBalanced 结合RestTemplate，
这个时候restTemplate去请求eureka注册中心中的提供者时，就会以负载均衡算法的方式去连接提供者。
1、ribbon的默认算法是轮询算法，可以通过IRute组件来指定算法规则
// @Bean
// public IRute iRute(){ new RandomRule();}
2、通过@RibbonClient(name="服务名",configuration=rute规则.class)，来对某个具体的微服务，为其指定个性化的负载均衡算法规则。
// 自定义的负载均衡算法，这个配置类，没有放在和@ComponentScan同包以及其子包下，
// 故该配置不会被springboot自动扫描到
// 不会被自动装配，仅仅是我们自己的一个个性化的配置，不会被应用到所有的服务中。
@Configuration
public class MySelfRule {
    @Bean
    public IRule iRule(){
        //return new RandomRule();// 随机算法，或者自己的其他算法
        return new MySelfRoundRobinRule();
    }
}

十二、feign

Netflix Feign 是声明式、模板化的http客户端，springcloud对Feign进行了封装，使之支持springmvc注解，并结合ribbon、eureka使Feign使用起来更简单，接口+注解的方式来完成客户端负载均衡方式的远程调用。
pom：spring-cloud-starter-openfeign
yml：
# 设置feign客户端连接超时时间
feign.httpclient.connection-timeout=3000
# 启动feign的hystrix熔断降级能力
feign.hystrix.enabled=true
main：@enableFeignClients(basePackages="基础包扫描feignclient")
服务提供者provider正常提供服务，服务消费者consumer消费服务时，controller调service接口，
service接口+@FeignClient(name="provider服务名",fallbackFactory=xxxFallbackFactory.class)
//feiginclient 为指定的服务提供负载均衡的请求，默认使用轮询的负载均衡算法
接口方法里添加springmvc请求映射注解
// 这个请求路径要和服务提供者的保持一致，Feign底层也是通过rest通信的
feign如果启动了hystrix熔断降级的能力，所有熔断处理通过fallbackFactory工厂来处理。
xxxFallbackFactory 实现FallbackFactory<接口>，通过泛型的方式指定为某个接口的所有方法提供熔断降级服务。
// 注意：这个xxxFallbackFactory 对象要放在IoC容器中，即通过@Component注解标识。

十三、hystrix

Hystrix是由Netflix开源的一个服务隔离组件，
通过服务隔离来避免由于依赖延迟、异常，引起资源耗尽导致系统不可用的解决方案。
服务熔断、服务降级组件。
pom：spring-cloud-starter-netflix-hystrix
main：@EnableCircuitBreaker // 激活开启熔断机制
不激活@EnableCircuitBreaker则@HystrixCommand不可用，hystrix的监控hystrix dashboard不可用。
2种方式在代码中来实现服务熔断和降级：
1、provider服务提供者方，在controller里使用@HystrixCommand(fallbackMethod="处理熔断的方法")注解，符合熔断时机时则调用本地的fallbackMethod方法实现熔断处理。
2、consumer服务消费方，在service接口层结合@FeignClient(name="provider服务名",fallbackFactory=xxxFallbackFactory.class)注解，
在xxxFallbackFactory类里对接口的所有方法进行熔断降级处理。

hystrix-dashboard对hystrix服务熔断服务降级的监控
pom：spring-cloud-starter-netflix-hystrix-dashboard
main：@EnableHystrixDashBoard // 激活hystrix dashboard监控
该hystrix dashboard微服务可以监控使用了hystrix的其他微服务。dashboard提供了web页面。

被监控的hystrix微服务，如果想对外暴露自己的监控信息，则需要提供如下的web访问的servlet。
// 该服务如果想被hystrix dashboard监控，则需要提供如下的web访问的servlet，注册到IOC容器中
@Bean
    public ServletRegistrationBean getServlet() {
        HystrixMetricsStreamServlet streamServlet = new 		HystrixMetricsStreamServlet();
        ServletRegistrationBean registrationBean = new ServletRegistrationBean(streamServlet);//注册到IoC容器中
        registrationBean.setLoadOnStartup(1);
        registrationBean.addUrlMappings("/actuator/hystrix.stream");
        registrationBean.setName("HystrixMetricsStreamServlet");
        return registrationBean;
    }

Hystrix 被设计用来做了下面几件事:
1、保护系统间的调用延时以及错误，特别是通过第三方工具的网络调用
2、阻止错误在分布式系统之前的传播
3、快速失败和迅速恢复
4、错误回退和优雅的服务降级

十四、zuul

Zuul是Spring Cloud全家桶中的微服务API网关。
什么是API网关?
在微服务架构中通常会有多个微服务提供者，在展示UI页面时，可能需要从多个微服务中聚合数据，网关就可以对外暴露聚合API，即对多个微服务进行组合封装，屏蔽内部微服务的微小变动，保持整个系统的稳定性。
zuul还可以做负载均衡（nginx+zuul），统一鉴权（在网关层进行鉴权判断，不符合要求的请求直接过滤掉），协议转换（http请求转换成rpc），监控监测等一系列功能。

// 网关微服务也是一个consumer工程，consumer请求provider时，zuul还可以对provider进一步的封装。
网关微服务工程：
pom：spring-cloud-starter-netflix-zuul
yml：
# 在微服务的前面加前缀，比如：http://myzuul.com:9527/haha/cloud-provider/dept/9
zuul.prefix=/haha
# 保护微服务名不被暴露在外，使用映射规则，进行映射使用，给微服务取别名：
# routes是一个map，key可以是：serviceId，value是：path
# 请求路径：http://myzuul.com:9527/haha/myProvider/dept/9
zuul.routes.myProvider.serviceId=cloud-provider  // 取别名：myProvider
zuul.routes.myProvider.path=/myProvider/**
zuul.routes.dept.serviceId=cloud-provider-dept // 比如部门微服务，取别名为dept
zuul.routes.dept.path=/dept/**
zuul.routes.order.serviceId=cloud-provider-order// 比如订单微服务，取别名为orders
zuul.routes.order.path=/order/**
main：
@EnableZuulProxy 开启激活zuul网关代理

十五、spring cloud config

spring cloud config 为分布式系统中的外部配置提供服务器和客户端支持。
使用config server可以为所有环境中的程序管理其外部配置。config server 储存后端默认是用git实现，能轻松支持标签版本的配置。
// config sersver与github通信，config client通过config server来获取github上的配置。
config server 微服务：
pom：spring-cloud-config-sersver
yml:
# config-server的git的uri地址，告知config-server从git上的哪个地址上去获取配置信息
# 配置git仓库的地址
spring.cloud.config.server.git.uri=https://github.com/jobs1127github/cloud_config.git
// config sersver和github连上后，就能通过config server直接获取GitHub上的配置资源。
main:
@EnableConfigServer // 开启config server

测试：登录github，new repository 新建远程仓库，本地安装好git，鼠标右键能看到git Bash here 就OK。
1、本地新建一个文件夹，用于本地git仓库。在该新建的文件里，鼠标右键运行git Bash here
输入命令：git status // 查看git仓库状态
如果发现没有git仓库，可以从github上clone一个下来：
输入命令：git clone https://github.com/jobs1127github/cloud_config.git
// git clone 仓库地址 // 克隆一个git仓库 //clone成功后，会有一个隐藏的.git文件夹
2、新建配置文件，比如：application.yml，或者其他的配置文件。注意：保存为utf-8格式。
3、将配置文件提交到github远程仓库。
	依次执行：
	git bash here // 进入命令控制台
	git status // 查看状态，是否有仓库，是否有文件发生变化等等状态信息
	git add . // 把当前目录下的所有文件，添加到本地临时仓库
	git commit -m "提交时的描述文字" // 把本地临时仓库的文件提交到本地仓库，-m 用于填写提交时的描述。
	git push origin master // 将本地仓库的文件推送到远程github仓库，origin master是指定推送到master分支。
	在github上查看配置文件，比如：application.yml、cloud-config-client.yml // push上来的2个文件，参考如下文件。
	启动config server 微服务，其域名：config-server.com，端口：3344
	测试：http://config-server.com:3344/application-dev.yml
	// http://config-server.com:3344 是微服务config server
	// application-dev.yml是请求github上的application.yml资源配置的dev profiles
	再如测试：http://config-server.com:3344/cloud-config-client-dev.yml
	// cloud-config-client-test.yml是请求github上的cloud-config-client.yml资源配置的test profiles
	// 测试能正常获取到github上的配置文件，就说明config server已经和github联通了。

推送到github上的application.yml配置文件
##注意该文件一定要以utf-8的格式保存#
spring:
  profiles:
    active:
    - dev
---
spring:
  profiles: dev #开发环境
  application:
    name: cloud-config-dev

---
spring:
  profiles: test
  application:
    name: cloud-config-test #测试环境

---
spring:
  profiles: product
  application:
    name: cloud-config-product #生产环境

推送到github上的cloud-config-client.yml配置文件
##注意该文件一定要以utf-8的格式保存#
spring:
  profiles:
    active:
      - dev
---
server:
  port: 8201
spring:
  profiles: dev #开发环境
  application:
    name: cloud-config-client-dev
# eureka客户端连接服务器的url，注册中心的地址
eureka:
  client:
    service-url:
      defaultZone: 
        http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/

---
server:
  port: 8202
spring:
  profiles: test #测试环境
  application:
    name: cloud-config-client-test
# eureka客户端连接服务器的url，注册中心的地址
eureka:
  client:
    service-url:
      defaultZone:
        http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/

config client 通过config server来获取配置信息

config client 客户端微服务：
pom：spring-cloud-starter-config
bootstrap.yml:
##是系统级的配置文件，优先级比application.yml高，不会被本地配置application.yml覆盖
spring:
  cloud:
    config:
      uri: http://config-server.com:3344 #客户端连接服务端的uri，本微服务启动后先去找3344服务，通过3344服务去获取github上的资源
      name: cloud-config-client #连接到服务端后，要读取哪个名字的资源配置文件，从git上读取配置资源cloud-config-client.yml
      profile: test #本次访问的配置项，访问哪个profile
      #profile: dev #本次访问的配置项
      label: master #label标签，指定本次的访问的分支

## 该3355服务，通过访问3344服务，来获取自己的启动配置文件
## 如果该3355服务读取到了github上的资源（cloud-config-client.yml），则该工程就使用github上读到的配置，
## bootstrap.yml的优先级高于application.yml/properties
// 若该3355微服务工程既有bootstrap.yml配置文件，又有本地的application.yml，则从github上获取到配置会和本地的application.yml的配置组合生效。
测试：
1、启动eureka服务端微服务
2、启动config server微服务 3344
3、启动config client微服务 3355
本地hosts，域名配置：127.0.0.1 config-client.com 做好域名解析。
访问：http://config-client.com:8202/config