SpringCloud简介

前言

• SpringCloud是模块化的开发，从之前的all in on，改变成现在的模块化。对于项目代码层面来说，代码是没有什么变化的。主要是给功能模块化。
• 例如：之前的用户模块与订单模块都是在一个项目中，部署在一台服务器中。但是由于用户的访问量的不同，服务器承受的压力也不一样。基于这种情况，在之前的解决方案是采用负载均衡的操作，把项目重新拷贝一份，再多部署几个服务，来分发请求到不同的服务中，但本质其实是项目的复制。并且这种情况下，如果要进行代码更新，也是需要停掉整个服务，打包之后发布之后再重新开启服务。
• 然而对于模块的操作而言，是需要把不用的模块单独独立出来。比如说：把用户访问量比较大的用户模块与订单模块分开部署在不同的服务上。所以说是模块化的开发。

正是由于是基于模块化的开发，那么就引申出来了微服务架构中四个最核心的问题：

1. 服务很多，客户端如何进行访问？
2. 这么多服务，服务之前如何通信？
3. 这么多服务，如何进行治理？
4. 服务如果挂掉了怎么办？

解决方案：

所以SpringCloud就是用来解决微服务中出现的这些问题，SpringCloud本身而言并不是一门技术，而是一种好的生态。这个生态中融合了非常多解决技术，这个生态就是用于解决微服务中出现的这些问题。

解决方案分别介绍一下几种：

1. Spring Cloud NetFlix（一站式解决方案）——已停更

​ api网关，zuul组件

​ Feign——HttpClinet（基于Httpt通信方式，同步、阻塞）

​ 服务注册发现：Eureka

​ 熔断机制：Hystrix

2. Apache Dubbo Zookeeper（半自动，需要整合别的。）

​ api网关：自身没有；需要找第三方组件或者自己实现

​ dubbo来解决服务直接的通信

​ Zookeeper进行服务治理

​ 熔断机制没有，需要借助Hystrix

​ （所以看出这个方案并不完整）

3. Spring Cloud Alibaba（一站式解决方案，更简单）

总结：

说到底就是为了解决微服务中出现的这四个问题：

1. API网关
2. 通信（HTTP,RPC）
3. 服务管理（服务注册和发现）
4. 熔断机制

为什么会有这些问题出现，其本质还是由于网络的不可靠造成，比如说丢包、断网等等问题出现。

1、微服务概述

2.1、什么是微服务

微服务是一种架构思想，在此引用ThoughtWorks公司的首席科学家Martin Fowler于2014年提出的一段话：

原文: https://martinfowler.com/articles/microservices.html

汉化: https://www.cnblogs.com/liuning8023/p/4493156.html

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

从技术维度来理解：

• 微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地去耦合。
• 每一个微服务提供单个业务功能的服务，一个服务做一件事情，从技术角度看就是一种小而独立的处理过程，类似进程的概念，能够自行单独启动或销毁，拥有自己独立的数据库。

2.2、微服务与微服务架构

微服务

强调的是服务的大小，关注的是某一个点，是具体解决某一个问题提供落地服务的一个服务应用。可以狭义的看作是IDEA中的一个个微服务工程，或者Moudel。

微服务架构

是一种架构形式。Martin Fowler于2014年提出。

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务服务之间互相协调，互相配合，为用户提供最终价值。每个服务运行在其独立的进程中服务于服务间采用轻量级的通信机制互相协作，每个服务都围绕着具体的业务进行构建并且能够被独立的部署到生产环境中，另外应尽量避免统一的，集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言，工具对其进行构建。

2.3、微服务优缺点

优点

1. 单一，每个服务足够内聚、足够小，聚焦一个指定的业务功能
2. 微服务是松耦合的，独立的
3. 能使用不同的语言开发
4. 易于与第三方集成
5. 每个服务都有自己的存储能力，可以有自己的数据库，也可以有统一的数据库
6. …

缺点

1. 处理分布式系统的复杂性
2. 服务之前通信成本
3. 数据一致性
4. 性能检测
5. …

2.4、微服务技术栈

2、SpringCloud入门

2.1、SpringCloud是什么

Spring官网：https://spring.io/

• SpringCloud，基于SpringBoot提供了一套微服务解决方案，包括服务注册与发现，配置中心，全链路监控，服务网关，负载均衡，熔断器等组件，除了基于NetFlix的开源组件做高度抽象封装之外，还有一些选型中立的开源组件。
• SpringCloud利用SpringBoot的开发便利性，巧妙地简化了分布式系统基础设施的开发，SpringCloud为开发人员提供了快速构建分布式系统的一些工具，包括配置管理，服务发现，断路器，路由，微代理，事件总线，全局锁,决策竞选，分布式会话等等，他们都可以用SpringBoot的开发风格做到一键启动和部署。
• SpringBoot并没有重复造轮子，它只是将目前各家公司开发的比较成熟，经得起实际考研的服务框架组合起来，通过SpringBoot风格进行再封装，屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂，易部署和易维护的分布式系统开发工具包
• SpringCloud是分布式微服务架构下的一站式解决方案，是各个微服务架构落地技术的集合体，俗称微服务全家桶。

2.2、SpringCloud和SpringBoot关系

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

2.3、Dubbo和SpringCloud技术选型

1、分布式+服务治理Dubbo

目前成熟的互联网架构：应用服务化拆分 + 消息中间件

2、 Dubbo和SpringCloud对比

社区活跃度

https://github.com/dubbo

https://github.com/spring-cloud

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

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

• 品牌机与组装机的区别

很明显，Spring Cloud的功能比DUBBO更加强大，涵盖面更广，而且作为Spring的拳头项目，它也能够与SpringFramework、Spring Boot、Spring Data、Spring Batch等其他Spring项目完美融合，这些对于微服务而言是至关重要的。使用Dubbo构建的微服务架构就像组装电脑，各环节我们的选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心，但是如果你是一名高手，那这些都不是问题。而SpringCloud就像品牌机，在Spring Source的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础有足够的了解。

• 社区支持与更新力度

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

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

2.4、SpringCloud能干嘛

• Distributed/versioned configuration(分布式/版本控制配置)
• Service registration and discovery(服务注册与发现)
• Routing(路由)
• service-to-service calls(服务到服务的调用)
• Load balancing (负载均衡配置）
• Circuit Breakers(断路器)
• Distributed messaging(分布式消息管理)
• …

2.5、SpringCloud在那里下

官网：http://projects.spring.io/spring-cloud/

• Spring Cloud是一个由众多独立子项目组成的大型综合项目，每个子项目有不同的发行节奏，都维护着自己的发布版本号。Spring Cloud通过一个资源清单Bow(Bill of Materials）来管理每个版本的子项目清单。为避免与子项目的发布号混淆，所以没有采用版本号的方式，而是通过命名的方式。

• 这些版本名称的命名方式采用了伦敦地铁站的名称，同时根据字母表的顺序来对应版本时间顺序，比如：最早的Release版本：Ange1，第二个Release版本：Brixton，然后是camden、pa7ston、Edgware，目前最新的是Finchley版本。

参考书：

• https://springcloud.cc/spring-cloud-netflix.html

• 中文API文档：https://springcloud.cc/spring-cloud-dalston.html

• SpringCloud中国社区：http://springcloud.cn/

• SpringCloud中文网：https://springcloud.cc

3、Rest学习环境搭建（服务提供者、服务消费者）

注册RestTemplate

注入和使用RestTemplate

4、Eureka服务注册与发现

4.1、什么是Eureka

• Netflix在设计Eureka时，遵循的就是AP原则
• Eureka是Netflix的一个子模块，也是核心模块之一。Eureka是一个基于REST的服务，用于定位服务，以实现云端中间层服务发现和故障转移，服务注册与发现对于微服务来说是非常重要的，有了服务发现与注册，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务调用的配置文件了，功能类似于Dubbo的注册中心，比如Zookeeper

4.2、原理讲解

• Eureka的基本架构
  • SpringCloud封装了NetFlix公司开发的Eureka模块来实现服务注册和发现（对比Zookeeper）
  • Eureka采用了C-S的架构设计，EurekaServer作为服务注册功能的服务器，他是服务注册中心
  • 而系统中的其他微服务。使用Eureka的客户端连接到EurekaServer并维持心跳连接。这样系统的维护人员就可以通过EurekaServer来监控系统中各个微服务是否正常运行，SpringCloud的一些其他模块（比如Zuul)就可以通过EurekaServer来发现系统中的其他微服务，并执行相关的逻辑
  • Eureka包含两个组件：Eureka Server和Eureka Client 。
  • Eureka Server提供服务注册服务，各个节点启动后，会在EurekaServer中进行注册，这样Eureka Server中的服务注册表中将会村粗所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。
  • Eureka Client是一个ava客户端，用于简化EurekaServer的交互，客户端同时也具备一个内置的，使用轮询负载算法的负载均衡器。在应用启动后，将会向EurekaServer发送心跳（默认周期为30秒)。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，EurekaServer将会从服务注册表中把这个服务节点移除掉（默认周期为90秒)
• 三大角色
  • Eureka Server：提供服务的注册于发现。（相当于zookeeper的启动客户端）
  • Service Provider：将自身服务注册到Eureka中，从而使消费方能够找到。
  • Service Consumer：服务消费方从Eureka中获取注册服务列表，从而找到消费服务。

使用SpringBoot开发的过程中的步骤：

1. 导入依赖
2. 编写配置文件
3. 开启这个功能（@Enablexxxx）
4. 配置类

• 编写Eureka配置文件

• 开启功能（@EnableEurekaServer）

• 访问7001端口，得到Eureka注册中心的默认页面

4.3、Eureka服务注册—信息配置—自我保护机制

4.4、Eureka集群环境配置

​

4.5、对比Zookeeper

回顾CAP原则

RDBMS（Mysql、Oracle、SqlServer）——ACID

NoSQL（redis、MongoDB）——CAP

ACID是什么？

• A——原子性
• C——一致性
• I——隔离性
• D——持久性

CAP是什么？

• C——强一致性
• A——可用性
• P——分区容错性

CAP的三进二：CA、AP、CP

CAP理论的核心：

• 一个分布式系统不可能同时很好的满足一致性、可用性和分区容错性这三个需求
• 根据CAP原理，将NoSQL数据库分成了满足CA原则，满足CP原则和满足AP原则三大类：
  • CA：单点集群，满足一致性，可用性的系统，通常可扩展性较差
  • CP：满足一致性，分区容错性的系统，通常性能不是特别高
  • AP：满足可用性，分区容错性的系统，通常可能对一致性要求低一些

作为服务注册中心，Eureka比Zookeeper好在哪里？

著名的CAP理论指出，一个分布式系统不可能同时满足C (一致性)、A(可用性)、P(容错性)

由于分区容错性P在分布式系统中是必须要保证的，因此我们只能在A和C之间进行权衡。

• Zookeeper保证的是CP
• Eureka保证的是AP

Zookeeper保证的是CP

当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30~120s，且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因为网络问题使得zk集群失去master节点是较大概率会发生的事件，虽然服务最终能够恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

Eureka保证的是AP

Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时，如果发现连接失败，则会自动切换至其他节点，只要有一台Eureka还在，就能保住注册服务的可用性，只不过查到的信息可能不是最新的，除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上(即保证当前节点依然可用)
3. 当网络稳定时，当前实例新的注册信息会被同步到其他节点中

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

5、Ribbon

5.1、Ribbon是什么

• Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡的工具。
• 简单的说，Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将NetFlix的中间层服务连接在一起。Ribbon的客户端组件提供一系列完整的配置项如：连接超时、重试等等。简单的说，就是在配置文件中列出LoadBalancer（简称LB：负载均衡）后面所有的机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随机连接等等）去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法。

5.2、Ribbon能干嘛

• LB，即负载均衡（Load Balance），在微服务或分布式集群中经常用的一种应用。

• 负载均衡简单的说就是将用户的请求平摊的分配到多个服务上，从而达到系统的HA（高可用)。

• 常见的负载均衡软件有Nginx，Lvs等等

• dubbo、SpringCloud中均给我们提供了负载均衡，SpringCloud的负载均衡算法可以自定义

• 负载均衡简单分类：

  • 集中式LB
    • 即在服务的消费方和提供方之间使用独立的LB设施，如Nginx，由该设施负责把访问请求通过某种策略转发至服务的提供方
  • 进程式LB
    • 将LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选出一个合适的服务器
    • Ribbon就属于进程内LB，它只是一个类库，集成于消费方进程，消费方通过它来获取到服务提供方的地址

• 增加注解@LoadBalanced默认就是使用Ribbon

6、Feign负载均衡

6.1、简介

feign是声明式的web service客户端，它让微服务之间的调用变得更简单了，类似controler调用service。SpringCloud集成了Ribbon和Eureka，可在使用Feign时提供负载均衡的http客户端。

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

feign，主要是社区，大家都习惯面向接口编程。这个是很多开发人员的规范。调用微服务访问两种方法

1. 微服务名字（ribbon）

2. 接口和注解（feign）

6.2、Feign能干嘛？

• Feign旨在使编写Java Http客户端变得更容易
• 前面在使用Ribbon + RestTemplate时，利用RestTemplate对Http请求的封装处理，形成了一套模板化的调用方法。但是在实际开发中，由于对服务依赖的调用可能不止一处，往往一个接口会被多处调用，所以通常都会针对每个微服务自行封装一些客户端类来包装这些依赖服务的调用。所以，Feign在此基础上做了进一步封装，由他来帮助我们定义和实现依赖服务接口的定义，在Feign的实现下，我们只需要创建一个接口并使用注解的方式来配置它（类似于以前Dao接口上标注Mapper注解，现在是一个微服务接口上面标注一个Feign注解即可）即可完成对服务提供方的接口绑定，简化了使用Spring Cloud Ribbon时，自动封装服务调用客户端的开发量。

6.3、Fegin集成了Ribbo

• 利用Ribbon维护了MicroServiceCloud-Dept的服务列表信息，并且通过轮询实现了客户端的负载均衡，而与Ribbon不同的是，通过Feign只需要定义服务绑定接口且以声明式的方法，优雅而且简单的实现了服务调用。

7、Hystrix

7.1、服务熔断

分布式系统面临的问题

复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免的失败。

服务雪崩

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

• 对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒中内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障，这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。

• 我们需要“弃车保帅”

什么是Hystrix

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

作用：

• 服务降级
• 服务熔断
• 服务限流
• 接近实时的监控
• …

官网资料：

https://github.com/Netflix/Hystrix/wiki

服务熔断

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

当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。

在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是@HystrixCommand。

• 导入依赖（spring-cloud-starter-hystrix）
• 编写一个熔断机制，加上注解（当请求对应的方法出现异常时，会去请求对应的备选的方案。而备选方案的方法则只是返回一下信息，目的是为了不能让请求服务因为某一步的异常而不能继续进行，导致整个服务崩溃。）

• 在启动类上添加对断路器的开启注解（@EnableCircuitBreaker）

7.2、服务降级

• 提供服务的接口

• 编写服务降级对应的工厂

• 开启降级

总结：

服务熔断：在服务端，某个服务超时或者异常，引起熔断。类似保险丝的操作。

服务降级的一种特殊情况，为防止服务雪崩而采取的措施。

服务降级：在客户端，从整体网站请求负载考虑，当某个服务熔断或者关闭之后，服务将不再被调用。此时在客户端，我们可以准备一个FallbackFactory，返回一个默认的缺省值。

释放服务器资源的资源以保证核心业务的正常高效运行的措施

7.3、Dashboard流监控

• 导入依赖
  • spring-cloud-starter-hystrix
  • spring-cloud-starter-hystrix-dashboard
• 编写配置（修改默认访问端口）
• 在SpringBootApplication启动类中开启注解支持（@EnableHystrixDashboard）

在服务中需要完善监控信息（导入依赖：spring-boot-starter-actuator）

• 添加servlet Bean放入流监控

8、Zuul路由网关

什么是Zuul？

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

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

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

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

提供：代理＋路由＋过滤三大功能

Zuul能干嘛？

• 路由
• 过滤

官网文档：https://github.com/Netflix/zuul

1. 导入依赖（spring-cloud-starter-zuul）
2. 配置文件配置进入Eureka

3. 在启动类中加入注解的支持（@EnableZuulProxy）

9 、SpringCloud Config分布式配置

分布式系统米面临的配置文件的问题

微服务意味着要将单体应用中的业务拆分成一个个子服务，每个服务的粒度相对较小，因此系统中会出现大量的服务，由于每个服务都需要必要的配置信息才能运行，所以一套集中式的，动态的配置管理设施是必不可少的。

SpringCloud提供了ConfigServer来解决这个问题，我们每一个微服务自己带着一个application.yml，那上百的的配置文件要修改起来，岂不是太过疯狂？

什么是SpringCloud config分布式配置中心

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

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

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

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

SpringCloud Config分布式配置中心能干嘛

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

SpringCloud config分布式配置中心与github整合

由于Spring Cloud Config默认使用Git来存储配置文件（也有其他方式，比如支持SVN和本地文件)，但是最推荐的还是Git，而且使用的是 http / https 访问的形式

服务端连接Git配置

• 导入依赖（spring-cloud-config-server）
• 配置类

• 添加注解支持（@EnableConfigServer）

• 访问连接（可修改后缀”/test“、”/dev“，获取不同的配置文件信息）

客户端连接服务端访问远程