SpringCloud整体构架设计（一）
SpringClound整体核心架构只有一点：Rest服务，也就是说在整个SpringCloud配置过程之中，所有的配置处理都是围绕着Rest完成的，在这个Rest处理之中，一定要有两个端：服务的提供者（Provider）、服务的消费者（Consumer），所以对于整个SpringCloud基础的结构就如下所示：
既然SpringCloud的核心是Restful结构，那么如果要想更好的去使用Rest这些微服务还需要考虑如下几个问题。
1、所有的微服务地址一定会非常的多，所以为了统一管理这些地址信息，也为了可以及时的告诉用户哪些服务不可用，所以应该准备一个分布式的注册中心，并且该注册中心应该支持有HA机制，为了高速并且方便进行所有服务的注册操作，在SpringCloud里面提供有一个Eureka的注册中心。
对于整个的WEB端的构架（SpringBoot实现）可以轻松方便的进行WEB程序的编写，而后利用Nginx或Apache实现负载均衡处理，但是你WEB端出现了负载均衡，那么业务端呢？应该也提供有多个业务端进行负载均衡。那么这个时候就需要将所有需要参与到负载均衡的业务端在Eureka之中进行注册。
在进行客户端使用Rest架构调用的时候，往往都需要一个调用地址，即使现在使用了Eureka作为注册中心，那么它也需要有一个明确的调用地址，可是所有的操作如果都利用调用地址的方式来处理，程序的开发者最方便应用的工具是接口，所以现在就希望可以将所有的Rest服务的内容以接口的方式出现调用，所以它又提供了一个Feign技术，利用此技术可以伪造接口实现。
在进行整体的微架构设计的时候由于牵扯的问题还是属于RPC，所以必须考虑熔断处理机制，实际上所有的熔断就好比生活之中使用保险丝一样，有了保险丝在一些设备出现了故障之后依然可以保护家庭的电器可以正常使用，如果说现在有若干的微服务，并且这些微服务之间可以相互调用，例如A微服务调用了B微服务，B微服务调用了C微服务。
如果在实际的项目设计过程之中没有处理好熔断机制，那么就会产生雪崩效应，所以为了防止这样的问题出现，SpringCloud里面提供有一个Hystrix熔断处理机制，以保证某一个微服务即使出现了问题之后依然可以正常使用。
通过Zuul的代理用户只需要知道指定的路由的路径就可以访问指定的微服务的信息，这样更好的提现了java中的“key=value”的设计思想，而且所有的微服务通过zuul进行代理之后也更加合理的进行名称隐藏。
在SpringBoot学习的时候一直强调过一个问题：在SpringBoot里面强调的是一个“零配置”的概念，本质在于不需要配置任何的配置文件，但是事实上这一点并没有完全的实现，因为在整个在整体的实际里面，依然会提供有application.yml配置文件，那么如果在微服务的创建之中，那么一定会有成百上千个微服务的信息出现，于是这些配置文件的管理就成为了问题。例如：现在你突然有一天你的主机要进行机房的变更，所有的服务的IP地址都可能发生改变，这样对于程序的维护是非常不方便的，为了解决这样的问题，在SpringCloud设计的时候提供有一个SpringCloudConfig的程序组件，利用这个组件就可以直接基于GIT或者SVN来进行配置文件的管理。
在整体设计上SpringCloud更好的实现了RPC的架构设计，而且使用Rest作为通讯的基础，这一点是他的成功之处，由于大量的使用了netflix公司的产品技术，所以这些技术也有可靠的保证。
SpringCloud简介
SpringCloud是基于SpringBoot基础之上开发的微服务框架，SpringCloud是一套目前非常完整的微服务解决方案框架，其内容包含服务治理、注册中心、配置管理、断路器、智能路由、微代理、控制总线、全局锁、分布式会话等。
SpringCloud包含众多的子项目
SpringCloud config 分布式配置中心
SpringCloud netflix 核心组件：
Eureka:服务治理 注册中心
Hystrix:服务保护框架
Ribbon:客户端负载均衡器
Feign：基于ribbon和hystrix的声明式服务调用组件
Zuul: 网关组件,提供智能路由、访问过滤等功能。
上海每特教育科技有限公司|苏州特每信息科技有限公司版权所有
SpringCloud中文翻译：
如何学习spring cloud
Spring Cloud 学习笔记（一）——入门、特征、配置
0 放在前面
0.1 参考文档
0.2 maven配置
parent
groupIdorg.springframework.boot/groupId
artifactIdspring-boot-starter-parent/artifactId
version1.5.2.RELEASE/version
/parent
dependencyManagement
dependencies
dependency
groupIdorg.springframework.cloud/groupId
artifactIdspring-cloud-dependencies/artifactId
versionDalston.RELEASE/version
typepom/type
scopeimport/scope
/dependency
/dependencies
/dependencyManagement
dependencies
dependency
groupIdorg.springframework.cloud/groupId
artifactIdspring-cloud-starter-config/artifactId
/dependency
dependency
groupIdorg.springframework.cloud/groupId
artifactIdspring-cloud-starter-eureka/artifactId
/dependency
/dependencies
0.3 简介
Spring Cloud为开发人员提供了快速构建分布式系统中的一些通用模式（例如配置管理，服务发现，断路器，智能路由，微代理，控制总线，一次性令牌，全局锁，领导选举，分布式 会话，群集状态）。 分布式系统的协调引出样板模式（boiler plate patterns），并且使用Spring Cloud开发人员可以快速地实现这些模式来启动服务和应用程序。 它们可以在任何分布式环境中正常工作，包括开发人员自己的笔记本电脑，裸机数据中心和受管平台，如Cloud Foundry。
Version: Brixton.SR7
1 特征
Spring Cloud专注于为经典用例和扩展机制提供良好的开箱即用
分布式/版本配置
服务注册与发现
路由选择
服务调用
负载均衡
熔断机制
全局锁
领导人选举和集群状态
分布式消息
2 原生云应用程序
原生云是应用程序开发的一种风格，鼓励在持续交付和价值驱动领域的最佳实践。
Spring Cloud的很多特性是基于Spring Boot的。更多的是由两个库实现：Spring Cloud Context and Spring Cloud Commons。
2.1 Spring Cloud Context: 应用上下文服务
Spring Boot关于使用Spring构建应用有硬性规定：通用的配置文件在固定的位置，通用管理终端，监控任务。建立在这个基础上，Spring Cloud增加了一些额外的特性。
2.1.1 引导应用程序上下文
Spring Cloud会创建一个“bootstrap”的上下文，这是主应用程序的父上下文。对应的配置文件拥有最高优先级，并且，默认不能被本地配置文件覆盖。对应的文件名bootstrap.yml或bootstrap.properties。
可通过设置spring.cloud.bootstrap.enabled=false来禁止bootstrap进程。
2.1.2 应用上下文层级结构
当用SpringApplication或SpringApplicationBuilder创建应用程序上下文时，bootstrap上下文将作为父上下文被添加进去，子上下文将继承父上下文的属性。
子上下文的配置信息可覆盖父上下文的配置信息。
2.1.3 修改Bootstrap配置文件位置
spring.cloud.bootstrap.name（默认是bootstrap），或者spring.cloud.bootstrap.location（默认是空）
2.1.4 覆盖远程配置文件的值
spring.cloud.config.allowOverride=true
spring.cloud.config.overrideNone=true
spring.cloud.config.overrideSystemProperties=false
2.1.5 定制Bootstrap配置
在/META-INF/spring.factories的key为org.springframework.cloud.bootstrap.BootstrapConfiguration，定义了Bootstrap启动的组件。
在主应用程序启动之前，一开始Bootstrap上下文创建在spring.factories文件中的组件，然后是@Beans类型的bean。
2.1.6 定制Bootstrap属性来源
关键点：spring.factories、PropertySourceLocator
2.1.7 环境改变
应用程序可通过EnvironmentChangedEvent监听应用程序并做出响应。
2.1.8 Refresh Scope
Spring的bean被@RefreshScope将做特殊处理，可用于刷新bean的配置信息。
注意
需要添加依赖“org.springframework.boot.spring-boot-starter-actuator”
目前我只在@Controller测试成功
需要自己发送POST请求/refresh
修改配置文件即可
2.1.9 加密和解密
Spring Cloud可对配置文件的值进行加密。
如果有"Illegal key size"异常，那么需要安装JCE。
2.1.10 服务点
除了Spring Boot提供的服务点，Spring Cloud也提供了一些服务点用于管理，注意都是POST请求
/env：更新Environment、重新绑定@ConfigurationProperties跟日志级别
/refresh重新加载配置文件，刷新标记@RefreshScope的bean
/restart重启应用，默认不可用
生命周期方法：/pause、/resume
2.2 Spring Cloud Commons:通用抽象
服务发现、负载均衡、熔断机制这种模式为Spring Cloud客户端提供了一个通用的抽象层。
2.2.1 RestTemplate作为负载均衡客户端
通过@Bean跟@LoadBalanced指定RestTemplate。注意URI需要使用虚拟域名（如服务名，不能用域名）。
如下：
@Configuration
public class MyConfiguration {
@LoadBalanced
@Bean
RestTemplate restTemplate() {
return new RestTemplate();
}
}
public class MyClass {
@Autowired
private RestTemplate restTemplate;
public String doOtherStuff() {
String results = restTemplate.getForObject("", String.class);
return results;
}
}
2.2.2 多个RestTemplate对象
注意@Primary注解的使用。
@Configuration
public class MyConfiguration {
@LoadBalanced
@Bean
RestTemplate loadBalanced() {
return new RestTemplate();
}
@Primary
@Bean
RestTemplate restTemplate() {
return new RestTemplate();
}
}
public class MyClass {
@Autowired
private RestTemplate restTemplate;
@Autowired
@LoadBalanced
private RestTemplate loadBalanced;
public String doOtherStuff() {
return loadBalanced.getForObject("", String.class);
}
public String doStuff() {
return restTemplate.getForObject("", String.class);
}
}
2.2.3 忽略网络接口
忽略确定名字的服务发现注册，支持正则表达式配置。
3 Spring Cloud Config
Spring Cloud Config提供服务端和客户端在分布式系统中扩展配置。支持不同环境的配置（开发、测试、生产）。使用Git做默认配置后端，可支持配置环境打版本标签。
3.1 快速开始
可通过IDE运行或maven运行。
默认加载property资源的策略是克隆一个git仓库(at spring.cloud.config.server.git.uri')。
HTTP服务资源的构成：
/{application}/{profile}[/{label}]
/{application}-{profile}.yml
/{label}/{application}-{profile}.yml
/{application}-{profile}.properties
/{label}/{application}-{profile}.properties
application是SpringApplication的spring.config.name,(一般来说'application'是一个常规的Spring Boot应用),profile是一个active的profile(或者逗号分隔的属性列表),label是一个可选的git标签(默认为"master")。
3.1.1 客户端示例
创建以Spring Boot应用即可，添加依赖“org.springframework.cloud:spring-cloud-starter-config”。
配置application.properties，注意URL为配置服务端的地址
spring.cloud.config.uri:
3.2 Spring Cloud Config 服务端
针对系统外的配置项(如name-value对或相同功能的YAML内容),该服务器提供了基于资源的HTTP接口。使用@EnableConfigServer注解,该服务器可以很容易的被嵌入到Spring Boot 系统中。使用该注解之后该应用系统就是一个配置服务器。
@SpringBootApplication
@EnableConfigServer
public class ConfigApplicion {
public static void main(String[] args) throws Exception {
SpringApplication.run(ConfigApplicion.class, args);
}
}
3.2.1 资源库环境
{application} 对应客户端的"spring.application.name"属性
{profile} 对应客户端的 "spring.profiles.active"属性(逗号分隔的列表)
{label} 对应服务端属性,这个属性能标示一组配置文件的版本
如果配置库是基于文件的，服务器将从application.yml和foo.yml中创建一个Environment对象。高优先级的配置优先转成Environment对象中的PropertySource。
3.2.1.1 Git后端
默认的EnvironmentRepository是用Git后端进行实现的，Git后端对于管理升级和物理环境是很方便的,对审计配置变更也很方便。也可以file:前缀从本地配置库中读取数据。
这个配置库的实现通过映射HTTP资源的{label}参数作为git label(提交id,分支名称或tag)。如果git分支或tag的名称包含一个斜杠 ("/"),此时HTTP URL中的label需要使用特殊字符串"(_)"来替代(为了避免与其他URL路径相互混淆)。如果使用了命令行客户端如 curl，请谨慎处理URL中的括号(例如：在shell下请使用引号''来转义它们)。
Git URI占位符
Spring Cloud Config Server支持git库URL中包含针对{application}和 {profile}的占位符(如果你需要,{label}也可包含占位符, 不过要牢记的是任何情况下label只指git的label)。所以，你可以很容易的支持“一个应用系统一个配置库”策略或“一个profile一个配置库”策略。
模式匹配和多资源库
spring:
cloud:
config:
server:
git:
uri:
repos:
simple:
special:
pattern: special*/dev*,*special*/dev*
uri:
local:
pattern: local*
uri: file:/home/configsvc/config-repo
如果 {application}/{profile}不能匹配任何表达式，那么将使用“spring.cloud.config.server.git.uri”对应的值。在上例子中，对于 "simple" 配置库, 匹配模式是simple/* (也就说,无论profile是什么，它只匹配application名称为“simple”的应用系统)。“local”库匹配所有application名称以“local”开头任何应用系统，不管profiles是什么(来实现覆盖因没有配置对profile的匹配规则，“/*”后缀会被自动的增加到任何的匹配表达式中)。
Git搜索路径中的占位符
spring.cloud.config.server.git.searchPaths
3.2.1.2 版本控制后端文件系统使用
伴随着版本控制系统作为后端(git、svn)，文件都会被check out或clone 到本地文件系统中。默认这些文件会被放置到以config-repo-为前缀的系统临时目录中。在Linux上，譬如应该是/tmp/config-repo-randomid目录。有些操作系统routinely clean out放到临时目录中，这会导致不可预知的问题出现。为了避免这个问题，通过设置spring.cloud.config.server.git.basedir或spring.cloud.config.server.svn.basedir参数值为非系统临时目录。
3.2.1.3 文件系统后端
使用本地加载配置文件。
需要配置：spring.cloud.config.server.native.searchLocations跟spring.profiles.active=native。
路径配置格式：classpath:/, classpath:/config,file:./, file:./config。
3.2.1.4 共享配置给所有应用
基于文件的资源库
在基于文件的资源库中(i.e. git, svn and native)，这样的文件名application*命名的资源在所有的客户端都是共享的(如 application.properties, application.yml, application-*.properties,etc.)。
属性覆盖
“spring.cloud.config.server.overrides”添加一个Map类型的name-value对来实现覆盖。
例如
spring:
cloud:
config:
server:
overrides:
foo: bar
会使所有的配置客户端应用程序读取foo=bar到他们自己配置参数中。
3.2.2 健康指示器
通过这个指示器能够检查已经配置的EnvironmentRepository是否正常运行。
通过设置spring.cloud.config.server.health.enabled=false参数来禁用健康指示器。
3.2.3 安全
你可以自由选择任何你觉得合理的方式来保护你的Config Server（从物理网络安全到OAuth2 令牌），同时使用Spring Security和Spring Boot 能使你做更多其他有用的事情。
为了使用默认的Spring Boot HTTP Basic 安全，只需要把Spring Security 增加到classpath中(如org.springframework.boot.spring-boot-starter-security)。默认的用户名是“user”，对应的会生成一个随机密码，这种情况在实际使用中并没有意义，一般建议配置一个密码（通过 security.user.password属性进行配置）并对这个密码进行加密。
3.2.4 加密与解密
如果远程属性包含加密内容(以{cipher}开头),这些值将在通过HTTP传递到客户端之前被解密。
使用略
3.2.5 密钥管理
配置服务可以使用对称(共享)密钥或者非对称密钥(RSA密钥对)。
使用略
3.2.6 创建一个测试密钥库
3.2.7 使用多密钥和循环密钥
3.2.8 加密属性服务
3.3 可替换格式服务
配置文件可加后缀".yml"、".yaml"、".properties"
3.4 文本解释服务
/{name}/{profile}/{label}/{path}
3.5 嵌入配置服务器
一般配置服务运行在单独的应用里面，只要使用注解@EnableConfigServer即可嵌入到其他应用。
3.6 推送通知和总线
添加依赖spring-cloud-config-monitor，激活Spring Cloud 总线，/monitor端点即可用。
当webhook激活，针对应用程序可能已经变化了的，配置服务端将发送一个RefreshRemoteApplicationEvent。
3.7 客户端配置
3.7.1 配置第一次引导
通过spring.cloud.config.uri属性配置Config Server地址
3.7.2 发现第一次引导
如果用的是Netflix，则用eureka.client.serviceUrl.defaultZone进行配置。
3.7.3 配置客户端快速失败
在一些例子里面，可能希望在没有连接配置服务端时直接启动失败。可通过spring.cloud.config.failFast=true进行配置。
3.7.4 配置客户端重试
添加依赖spring-retry、spring-boot-starter-aop，设置spring.cloud.config.failFast=true。默认的是6次重试，初始补偿间隔是1000ms，后续补偿为1.1指数乘数，可通过spring.cloud.config.retry.*配置进行修改。
3.7.5 定位远程配置资源
路径：/{name}/{profile}/{label}
"name" = ${spring.application.name}
"profile" = ${spring.profiles.active} (actually Environment.getActiveProfiles())
"label" = "master"
label对于回滚到之前的版本很有用。
3.7.6 安全
通过spring.cloud.config.password、spring.cloud.config.username进行配置。
Spring Cloud入门系列-前期准备
在写这一系列的文章之前，觉得很有必要阐述一下什么是Spring Cloud。不像Spring（Spring Framework），大体上能够理解为它是一个管理bean的容器。也不想SpringBoot，可以理解为它是加强版的Spring，集成了SSM和其它一些框架，并且大量支持和推荐注解开发。
但是对于Spring Cloud，它是一个微服务架构的框架， 它不是单独的某个项目，是多个项目的集成 。也就是说如果想学习Spring Cloud，实际上是在 学习多个有关微服务的项目。
所谓微服务呢，就是把原本一站式解决的业务拆分成具体的某个模块，每个模块只做一个事情，然后还顺便衍生出了统一管理这些服务的模块，以及服务的保护措施等模块。归结起来就是5个核心， 服务发现（注册）、负载均衡、断路器、服务网关和分布式配置。
在几个星期前，当我想建一个模块的时候，可能会选择采用 Spring Initializer 来创建，但是最近觉得还是直接建立一个新模块比较舒服。每个人的习惯都不一样，自己怎么舒服怎么来。
下面就演示一下如何利用maven创建一个 module
修改模块名就可以创建想要的模块，这样的好处是能够集成父模块中导入的依赖，相比于 Spring Initializer 会简单多了，因为后者需要手动配置模块的父子关系才可以（或者懂怎么搞的小伙伴也可以留言一手）。
为了更好的学习，首先建立了一个总的工程，同样是用了maven来建立一个项目，建立完后结构如下所示
接下来要做的就是把整个src目录给删掉，因为后续也用不到它；其次就是修改pom文件
各位小伙伴需要修改的第7和第8行的 groupId 和 artifactId 。这样对于必须用的依赖，可以在根模块中，也就是该pom文件声明即可。比如上面的 spring-boot-starter-web 在所有的子模块中都有整个依赖。
甚至如果足够懒，那你完全可以把所有的依赖都写在父模块中，这样后续建立子模块的过程中就可以不管pom文件了。
Spring cloud应该如何入门，需要学习哪些基础才可以快速掌握?
学习Spring cloud要对Spring Boot有相当的理解与认知，因为Spring cloud的基础是Spring Boot。
一:什么是Spring cloud
Spring cloud是多个项目的集合体，也是多种重要技术的集合体，它是一系列的技术的结合体。学习spring cloud需要有足够强大的耐心，因为这是一个非常复杂的过程，学习spring cloud需要了解怎么创建和运行SpringBoot应用，因为springboot是一种新型技术，而spring cloud 是这些技术的结合体，spring cloud的基础功能有服务治理客户端负载均衡，服务容错保护，声明式服务调用，API网关服务，分布式配置中心。
二:从集群，分布式，微服务入手
学习spring cloud要从集群，分布式，微服务入手，首先集群是一种计算机系统，它可以用来改进单个计算机的计算速度，已经提高单个计算机运作的正确率，集群计算机系统可以高效率的将计算机软件和计算机硬件组合在一起，也就是通过多台计算机来完成一个工作从而提高工作效率，而分布式系统也是一组计算机，它是一个传递并协调信息通信的系统，这样可以合理利用资源，又可以降低耦合度，可以让各个板块即独立又相互之间有联系，也就是说分布式是一个件一件事情分解成多件事情，然后发布给不同的人做的系统，分工合作。而微服务就是对整个系统进行划分的各个小的“系统”而微服务只是一种思想，基于这种思想便有了spring cloud ，
总而言之，学习spring cloud要从集群，微服务，分布式，springboot等入手，而其中springboot是最基础的。
SpringCloud入门简述
微服务，是一个小型的服务，也是一种设计理念，将一个大型繁杂的系统拆分为多个小型的服务，进行独立部署，这些服务在独立进程中运行，通过特定的协议进行通信
优点：
缺点：
在服务通信性能上RPC更强，但是Rest更为灵活
SpringCloud是基于SpringBoot实现的微服务框架，为开发人员提供了很多快速构建分布式系统中常见模式的工具，包括配置管理、服务发现、断路器、智能路由、微代理，控制总线等。
Spring Cloud专注于为典型的用例提供良好的开箱即用体验，并为其他用例提供扩展性机制。
参考地址：
Eureka是Netflix开发的基于Rest的服务发现框架，SpringCloud基于此进行二次封装，实现服务的管理。
创建一个Eureka服务：
如果没有Eureka，如何进行服务之间的调用?
使用Rest进行调用，先将RestTemplate注册到Bean，然后：
Eureka遵循的是AP原则，Eureka各个节点都是平等的，部分服务节点的下线不会影响正常服务的调用，只要该服务还剩下一个节点在线就可以进行正常的服务访问，即保证了服务可用，但是并不能保证查询到的信息是最新的。Zookeeper的CP原则与之不同，Zookeeper会有一个master节点来保证一致性，一旦master节点挂掉，剩余的节点会重新选举一个leader，而选择的过程需要时间，这期间会使得该服务瘫痪，所以需要满足高可用的话该情况是不能够容忍的。
Spring Cloud Ribbon是一个基于HTTP和TCP的 客户端负载均衡 工具，基于Netflix Ribbon实现，通过轮询、随机等算法选择一个可用服务。
目的：将用户的请求平摊的分配到多个服务上，实现高可用
最大区别：服务清单所存储的位置
客户端先发送请求到负载均衡服务器，然后由负载均衡服务器通过负载均衡算法，在众多可用的服务器之中选择一个来处理请求。
客户端自己维护一个可用服务器地址列表，在发送请求前先通过负载均衡算法选择一个将用来处理本次请求的服务器，然后再直接将请求发送至该服务器。
逻辑时序：RestTemplate发起请求 负载均衡器拦截器拦截 LoadBalanceClient获取ILoadBalance 获取服务列表 根据负载均衡器选择一个server 发起请求 记录调用信息
Ribbon基于HTTP和TCP客户端的负载均衡器可以自己构建HTTP请求，使用RestTemplate发送服务
Feign基于Ribbon进行改进，采用接口的方式，将需要调用的服务的方法定义成抽象方法
Consumer应用
启动类
为了调用Product应用服务的接口类
Product应用
controller
Hystrix是一个服务容错与保护的组件，用于 服务降级 、 服务熔断 、 服务限流 等等，能够保证在其中一个服务出现问题的时候，不会出现级联故障，防止雪崩，提高分布式服务的健壮性。
将某些服务停掉会i这不进行业务处理，释放资源来维持主要服务的功能。
应对服务雪崩的一种保险措施，是微服务的链路保护机制，是服务降级的一种特殊处理方式。
为了应对某个服务故障的情况，保证系统的整体可用性，熔断器会切断对该服务的请求，返回一个比较友好的错误响应，直到服务恢复正常
熔断机制的三种状态：
示例：
熔断：直接切断服务的调用
降级：牺牲非核心业务保证核心服务的正常
限流：服务访问量达到阈值后拒绝多余的调用
Zuul是一个微服务网关。网关：是一个网络系统的前置入口。也就是说要想访问一个有网关的网络系统请求相应的服务，需要先进入网关，然后路由到相应的服务。
通常是组成一个系统的微服务很多、或者有权限要求时需要用到网关。
Zuul提供一个过滤器，父类为ZuulFilter，用来过滤代理请求，提供额外的功能逻辑（这点类似于AOP），包括前置过滤、路由后过滤、后置过滤、异常过滤。
ZuulFilter包含的抽象方法：filterType、filterOrder、shouldFilter、run
当微服务众多的时候，想要管理各个服务的配置时过于繁杂，SpringCloud Config则可以用来对每个微服务的配置进行集中的管理。可以实现权限管控、灰度发布、版本管理、格式检验、安全配置等。
作用：
特点：
文章来自