微服务怎么搭本地配置中心
A. 使用 IDEA 从 0 开始搭建 Spring Cloud 微服务
以下内容均来源于一个微服务初学者的实践，仅供参考。
首先启动 Spring Cloud Eureka 注册中心，其他部分都作为服务注册到 Eureka ，并通过注册的服务名互相访问。Spring Cloud Config 提供统一的配置信息，供其他服务读取。Provider 生产者服务不直接对外暴露，仅供 Consumer 消费者服务调用。用户通过 Spring Cloud Gateway 统一访问消费者服务。
首先创建一个空 Maven 项目，然后右键项目 -> New Mole ，选择继续创建空 Maven 模块或者使用 Spring Initializr 构建 Spring Cloud 模块。common模块用于存放公共的 lib ，如 、model 、util 等。config-dev 存放配置文件，上传到 git 之后供 Spring Cloud Config 读取。
除了少数像 Spring Cloud Config 、Spring Cloud Gateway 这种独立应用，大部分非空模块都需要添加 spring-boot-starter-web 构建 Web 应用。下图是使用 IDEA 的 Spring Initializr 快速构建新模块。
下面贴上详细的配置文件和注解，bootstrap.yml 具有高优先级，会提前加载并且不会被 application.yml 覆盖，spring.cloud.config 需要配置在 bootstrap.yml 中，否则不能正常从配置中心获取配置信息。
application.yml
HobbyEurekaApplication.java
application.yml
application-dev.yml
HobbyConfigApplication.java
bootstrap.yml
config-dev/gateway.yml
HobbyGatewayApplication.java
在 Spring Cloud Gateway 的配置中已经展示过如何从 config-dev 配置仓库中读取配置文件。spring.cloud.config 和 eureka.client 都已经在 bootstrap.yml 中配置过，接下来不做赘述。多模块项目中扫描其他模块的 mybatis 文件需要做额外的配置。
application.yml
HobbyProviderTestApplication.java
消费者调用生产者可以使用 Feign 声明式服务调用。
HobbyConsumerTestApplication.java
TestFeignService.java
TestServiceImpl.java
Spring Cloud Eureka >> Spring Cloud Config >> Spring Cloud Gateway >> 其他服务
微服务架构能够将各种服务解耦，单独部署，配合 devops 才能展现出真正的威力，否则运维的工作会苦不堪言。gitlab 目前已经集成了 devops 功能，只要在项目中添加 .gitlab-ci.yml ，push 到 Gitlab 之后就会自动执行配置的命令，这里简单介绍一下 gitlab 的安装部署。
CentOS7 自带的 Git 版本号是 1.8.3.1 ，需要更新，否则 Gitlab Runner 在进行自动构建的时候会报错 fatal: git fetch-pack: expected shallow list ，更新步骤如下：
Gitlab 安装官方文档
Gitlab Runner 安装官方文档
配置文件的地址 /etc/gitlab/gitlab.rb
修改配置文件的操作：
常用配置：
B. 微服务架构：基于微服务和Docker容器技术的PaaS云平台架构设计
基于微服务架构和Docker容器技术的PaaS云平台建设目标是给我们的开发人员提供一套服务快速开发、部署、运维管理、持续开发持续集成的流程。平台提供基础设施、中间件、数据服务、云服务器等资源，开发人员只需要开发业务代码并提交到平台代码库，做一些必要的配置，系统会自动构建、部署，实现应用的敏捷开发、快速迭代。在系统架构上，PaaS云平台主要分为微服务架构、Docker容器技术、DveOps三部分，这篇文章重点介绍微服务架构的实施。
如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty源码分析的朋友可以加我的Java高级交流：854630135，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。
实施微服务需要投入大量的技术力量来开发基础设施，这对很多公司来说显然是不现实的，别担心，业界已经有非常优秀的开源框架供我们参考使用。目前业界比较成熟的微服务框架有Netflix、Spring Cloud和阿里的Dubbo等。Spring Cloud是基于Spring Boot的一整套实现微服务的框架，它提供了开发微服务所需的组件，跟Spring Boot一起使用的话开发微服务架构的云服务会变的很方便。Spring Cloud包含很多子框架，其中Spring Cloud Netflix是其中的一套框架，在我们的微服务架构设计中，就使用了很多Spring Cloud Netflix框架的组件。Spring Cloud Netflix项目的时间还不长，相关的文档资料很少，博主当时研究这套框架啃了很多英文文档，简直痛苦不堪。对于刚开始接触这套框架的同学，要搭建一套微服务应用架构，可能会不知道如何下手，接下来介绍我们的微服务架构搭建过程以及 需要那些 框架或组件来支持微服务架构。
为了直接明了的展示微服务架构的组成及原理，画了一张系统架构图，如下：
从上图可以看出，微服务访问大致路径为：外部请求 → 负载均衡 → 服务网关（GateWay）→ 微服务 → 数据服务/消息服务。服务网关和微服务都会用到服务注册和发现来调用依赖的其他服务，各服务集群都能通过配置中心服务来获得配置信息。
服务网关（GateWay）
网关是外界系统（如：客户端浏览器、移动设备等）和企业内部系统之间的一道门，所有的客户端请求通过网关访问后台服务。为了应对高并发访问，服务网关以集群形式部署，这就意味着需要做负载均衡，我们采用了亚马逊EC2作为虚拟云服务器，采用ELB(Elastic Load Balancing)做负载均衡。EC2具有自动配置容量功能，当用户流量达到尖峰，EC2可以自动增加更多的容量以维持虚拟主机的性能。ELB弹性负载均衡，在多个实例间自动分配应用的传入流量。为了保证安全性，客户端请求需要使用https加密保护，这就需要我们进行SSL卸载,使用Nginx对加密请求进行卸载处理。外部请求经过ELB负载均衡后路由到GateWay集群中的某个GateWay服务，由GateWay服务转发到微服务。服务网关作为内部系统的边界，它有以下基本能力：
1、动态路由：动态的将请求路由到所需要的后端服务集群。虽然内部是复杂的分布式微服务网状结构，但是外部系统从网关看就像是一个整体服务，网关屏蔽了后端服务的复杂性。
2、限流和容错：为每种类型的请求分配容量，当请求数量超过阀值时抛掉外部请求，限制流量，保护后台服务不被大流量冲垮；党内部服务出现故障时直接在边界创建一些响应，集中做容错处理，而不是将请求转发到内部集群，保证用户良好的体验。
3、身份认证和安全性控制：对每个外部请求进行用户认证，拒绝没有通过认证的请求，还能通过访问模式分析，实现反爬虫功能。
4、监控：网关可以收集有意义的数据和统计，为后台服务优化提供数据支持。
5、访问日志：网关可以收集访问日志信息，比如访问的是哪个服务？处理过程（出现什么异常）和结果？花费多少时间？通过分析日志内容，对后台系统做进一步优化。
我们采用Spring Cloud Netflix框架的开源组件Zuul来实现网关服务。Zuul使用一系列不同类型的过滤器（Filter），通过重写过滤器，使我们能够灵活的实现网关（GateWay）的各种功能。
如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty源码分析的朋友可以加我的Java高级交流：854630135，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。
服务注册与发现
由于微服务架构是由一系列职责单一的细粒度服务构成的网状结构，服务之间通过轻量机制进行通信，这就引入了服务注册与发现的问题，服务的提供方要注册报告服务地址，服务调用放要能发现目标服务。我们的微服务架构中使用了Eureka组件来实现服务的注册与发现。所有的微服务（通过配置Eureka服务信息）到Eureka服务器中进行注册，并定时发送心跳进行 健康 检查，Eureka默认配置是30秒发送一次心跳，表明服务仍然处于存活状态，发送心跳的时间间隔可以通过Eureka的配置参数自行配置，Eureka服务器在接收到服务实例的最后一次心跳后，需要等待90秒（默认配置90秒，可以通过配置参数进行修改）后，才认定服务已经死亡（即连续3次没有接收到心跳），在Eureka自我保护模式关闭的情况下会清除该服务的注册信息。所谓的自我保护模式是指，出现网络分区、Eureka在短时间内丢失过多的服务时，会进入自我保护模式，即一个服务长时间没有发送心跳，Eureka也不会将其删除。自我保护模式默认为开启，可以通过配置参数将其设置为关闭状态。
Eureka服务以集群的方式部署（在博主的另一篇文章中详细介绍了Eureka集群的部署方式），集群内的所有Eureka节点会定时自动同步微服务的注册信息，这样就能保证所有的Eureka服务注册信息保持一致。那么在Eureka集群里，Eureka节点是如何发现其他节点的呢？我们通过DNS服务器来建立所有Eureka节点的关联，在部署Eureka集群之外还需要搭建DNS服务器。
当网关服务转发外部请求或者是后台微服务之间相互调用时，会去Eureka服务器上查找目标服务的注册信息，发现目标服务并进行调用，这样就形成了服务注册与发现的整个流程。Eureka的配置参数数量很多，多达上百个，博主会在另外的文章里详细说明。
微服务部署
微服务是一系列职责单一、细粒度的服务，是将我们的业务进行拆分为独立的服务单元，伸缩性好，耦合度低，不同的微服务可以用不同的语言开发，每一个服务处理的单一的业务。微服务可以划分为前端服务（也叫边缘服务）和后端服务（也叫中间服务），前端服务是对后端服务做必要的聚合和剪裁后暴露给外部不同的设备（PC、Phone等），所有的服务启动时都会到Eureka服务器进行注册，服务之间会有错综复杂的依赖关系。当网关服务转发外部请求调用前端服务时，通过查询服务注册表就可以发现目标服务进行调用，前端服务调用后端服务时也是同样的道理，一次请求可能涉及到多个服务之间的相互调用。由于每个微服务都是以集群的形式部署，服务之间相互调用的时候需要做负载均衡，因此每个服务中都有一个LB组件用来实现负载均衡。
微服务以镜像的形式，运行在Docker容器中。Docker容器技术让我们的服务部署变得简单、高效。传统的部署方式，需要在每台服务器上安装运行环境，如果我们的服务器数量庞大，在每台服务器上安装运行环境将是一项无比繁重的工作，一旦运行环境发生改变，就不得不重新安装，这简直是灾难性的。而使用Docker容器技术，我们只需要将所需的基础镜像（jdk等）和微服务生成一个新的镜像，将这个最终的镜像部署在Docker容器中运行，这种方式简单、高效，能够快速部署服务。每个Docker容器中可以运行多个微服务，Docker容器以集群的方式部署，使用Docker Swarm对这些容器进行管理。我们创建一个镜像仓库用来存放所有的基础镜像以及生成的最终交付镜像，在镜像仓库中对所有镜像进行管理。
服务容错
微服务之间存在错综复杂的依赖关系，一次请求可能会依赖多个后端服务，在实际生产中这些服务可能会产生故障或者延迟，在一个高流量的系统中，一旦某个服务产生延迟，可能会在短时间内耗尽系统资源，将整个系统拖垮，因此一个服务如果不能对其故障进行隔离和容错，这本身就是灾难性的。我们的微服务架构中使用了Hystrix组件来进行容错处理。Hystrix是Netflix的一款开源组件，它通过熔断模式、隔离模式、回退（fallback）和限流等机制对服务进行弹性容错保护，保证系统的稳定性。
1、熔断模式：熔断模式原理类似于电路熔断器，当电路发生短路时，熔断器熔断，保护电路避免遭受灾难性损失。当服务异常或者大量延时，满足熔断条件时服务调用方会主动启动熔断，执行fallback逻辑直接返回，不会继续调用服务进一步拖垮系统。熔断器默认配置服务调用错误率阀值为50%，超过阀值将自动启动熔断模式。服务隔离一段时间以后，熔断器会进入半熔断状态，即允许少量请求进行尝试，如果仍然调用失败，则回到熔断状态，如果调用成功，则关闭熔断模式。
2、隔离模式：Hystrix默认采用线程隔离，不同的服务使用不同的线程池，彼此之间不受影响，当一个服务出现故障耗尽它的线程池资源，其他的服务正常运行不受影响，达到隔离的效果。例如我们通过andThreadPoolKey配置某个服务使用命名为TestThreadPool的线程池，实现与其他命名的线程池隔离。
3、回退（fallback）：fallback机制其实是一种服务故障时的容错方式，原理类似Java中的异常处理。只需要继承HystixCommand并重写getFallBack()方法，在此方法中编写处理逻辑，比如可以直接抛异常（快速失败），可以返回空值或缺省值，也可以返回备份数据等。当服务调用出现异常时，会转向执行getFallBack()。有以下几种情况会触发fallback：
1）程序抛出非HystrixBadRequestExcepption异常，当抛出HystrixBadRequestExcepption异常时，调用程序可以捕获异常，没有触发fallback，当抛出其他异常时，会触发fallback；
2）程序运行超时；
3）熔断启动；
4）线程池已满。
4、限流： 限流是指对服务的并发访问量进行限制，设置单位时间内的并发数，超出限制的请求拒绝并fallback，防止后台服务被冲垮。
Hystix使用命令模式HystrixCommand包装依赖调用逻辑，这样相关的调用就自动处于Hystrix的弹性容错保护之下。调用程序需要继承HystrixCommand并将调用逻辑写在run()中，使用execute()（同步阻塞）或queue()（异步非阻塞）来触发执行run()。
动态配置中心
微服务有很多依赖配置，某些配置参数在服务运行期间可能还要动态修改，比如：根据访问流量动态调整熔断阀值。传统的实现信息配置的方法，比如放在xml、yml等配置文件中，和应用一起打包，每次修改都要重新提交代码、打包构建、生成新的镜像、重新启动服务，效率太低，这样显然是不合理的，因此我们需要搭建一个动态配置中心服务支持微服务动态配置。我们使用Spring Cloud的configserver服务帮我们实现动态配置中心的搭建。我们开发的微服务代码都存放在git服务器私有仓库里面，所有需要动态配置的配置文件存放在git服务器下的configserver（配置中心，也是一个微服务）服务中，部署到Docker容器中的微服务从git服务器动态读取配置文件的信息。当本地git仓库修改代码后push到git服务器仓库，git服务端hooks(post-receive，在服务端完成代码更新后会自动调用)自动检测是否有配置文件更新，如果有，git服务端通过消息队列给配置中心（configserver，一个部署在容器中的微服务）发消息，通知配置中心刷新对应的配置文件。这样微服务就能获取到最新的配置文件信息，实现动态配置。
以上这些框架或组件是支撑实施微服务架构的核心，在实际生产中，我们还会用到很多其他的组件，比如日志服务组件、消息服务组件等等，根据业务需要自行选择使用。在我们的微服务架构实施案例中，参考使用了很多Spring Cloud Netflix框架的开源组件，主要包括Zuul（服务网关）、Eureka（服务注册与发现）、Hystrix（服务容错）、Ribbon（客户端负载均衡）等。这些优秀的开源组件，为我们实施微服务架构提供了捷径。
如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty源码分析的朋友可以加我的Java高级交流：854630135，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。
C. 基于docker部署的微服务架构（二）： 服务提供者和调用者
前一篇 基于docker部署的微服务架构（一）：服务注册中心 已经成功创建了一个服务注册中心，现在我们创建一个简单的微服务，让这个服务在服务注册中心注册。然后再创建一个调用者，调用此前创建的微服务。
新建一个maven工程，修改pom.xml引入 spring cloud 依赖:
在 resources 目录中创建 application.yml 配置文件，在配置文件内容:
这里eureka的注册地址为上一篇中设置的defaultZone。
在 java 目录中创建一个包 demo ，在包中创建启动入口 AddServiceApplication.java
在demo包下新建一个子包controller，在controller子包下创建一个controller对外提供接口。
在服务注册中心已经运行的情况下，运行 AddServiceApplication.java 中的 main 方法，启动微服务。
访问服务注册中心页面 http://localhost:8000 ， 可以看到已经成功注册了 ADD-SERVICE-DEMO 服务。
启动第二个实例，修改端口为 8101 ，修改 AddController.java 中的输出信息为
再次运行 AddServiceApplication.java 中的 main 方法。
访问服务注册中心页面 http://localhost:8000 ， 可以看到已经成功注册了两个 ADD-SERVICE-DEMO 服务，端口分别为 8100 和 8101 。
新建一个maven工程，修改pom.xml引入 spring cloud 依赖:
在 resources 目录中创建 application.yml 配置文件，在配置文件内容:
在 java 目录中创建一个包 demo ，在包中创建启动入口 RibbonClientApplication.java
这里配置了一个可以从服务注册中心读取服务列表，并且实现了负载均衡的 restTemplate 。
在demo包下新建一个子包controller，在controller子包下创建一个controller对外提供接口。
可以看到这里的请求url用了服务注册中心对应的 Application 。
运行 RibbonClientApplication.java 中的 main 方法，启动项目。
在浏览器中访问 http://localhost:8200/add?a=1&b=2 ，得到返回结果：
多次访问，查看 AddServiceApplication 的控制台，可以看到两个 ADD-SERVICE-DEMO 被负载均衡的调用。
demo源码 spring-cloud-1.0/ribbon-client-demo
新建一个maven工程，修改pom.xml引入 spring cloud 依赖:
在 resources 目录中创建 application.yml 配置文件，在配置文件内容:
在 java 目录中创建一个包 demo ，在包中创建启动入口 FeignClientApplication.java
在demo包下新建一个子包service，在service子包下创建一个接口 AddService.java 调用之前创建的微服务 ADD-SERVICE-DEMO 。
这里 @FeignClient 注解中的参数为服务注册中心对应的 Application 。
在demo包下再新建一个子包controller，在controller子包下创建一个 FeignController.java 对外提供接口。
FeignController 里注入了刚才创建的 AddService 接口。
运行 FeignClientApplication.java 中的 main 方法，启动项目。
在浏览器中访问 http://localhost:8300/add?a=1&b=2 ，得到返回结果：
多次访问，查看 AddServiceApplication 的控制台，可以看到两个 ADD-SERVICE-DEMO 被负载均衡的调用。
demo源码 spring-cloud-1.0/feign-client-demo
以 add-service-demo 为例，
复制 application.yml ，重命名为 application-docker.yml ，修改 defaultZone 为：
这里修改了 defaultZone 的访问url，如何修改取决于部署docker容器时的 --link 参数， --link 可以让两个容器之间互相通信。
修改 application.yml 中的 spring 节点为：
这里增加了 profiles 的配置，在maven打包时选择不同的profile，加载不同的配置文件。
在pom.xml文件中增加：
选择 docker profile，运行 mvn install -P docker ，打包项目并生成docker镜像， 注意docker-maven-plugin中的 <entryPoint> 标签里的内容不能换行，否则在生成docker镜像的时候会报错 。
运行成功后，登录docker节点，运行 docker images 应该可以看到刚才打包生成的镜像了。
在前一篇中，已经创建了一个 service-registry-demo 的docker镜像，这里先把这个镜像运行起来。
对这条命令做个简单说明， -d 指定当前容器运行在后台， --name 指定容器名称， --publish 指定端口映射到宿主机， --volume 这个挂载是为了解决容器内的时区和宿主机不一致的问题，让容器使用宿主机设置的时区，最后指定使用的docker镜像，镜像名称和标签需要根据自己的情况做修改。
运行这条命令之后， service-registry-demo 的容器就启动了。访问 http://宿主机IP:8000 ，打开注册中心的页面。
下边启动 add-service-demo 容器，
这条命令和上一条差不多，只是增加了一个 --link 参数， --link 指定容器间的连接，命令格式 --link 容器名:别名 ，这里连接了之前创建的名为 service-registry-demo 的容器，这里的别名和 application-docker.yml 文件中配置的 defaultZone 一致。其实就是通过别名找到了对应的容器IP，进到容器里查看 hosts 文件就明白了，其实就是加了条hosts映射。
add-service-demo 容器启动成功之后，刷新配置中心的页面，发现已经注册到配置中心了。
D. 微服务初体验（二）：使用Nacos作为配置中心并集成Dubbo
首先启动Nacos，按照上篇文章的步骤，启动Nacos服务和项目，访问Nacos的web页面。确保项目中的服务都注册到注册中心当中了。在application.yml同级目录下添加bootstrap.yml，在Spring boot项目中bootstrap.yml会比application.yml优先初始化，所以我们需要在bootstrap.yml中引入Nacos官方指定的配置文件即可（上篇文章中已经把Nacos作为配置中心的配置写入了application.yml，现在只需要把它从applicaiton.yml中剪切出来即可， 其中的spring:application:name会作为Nacos中新增配置时的Data ID，需要留意 ），再新增属性gorup进行分组测试，如下图
接着打开Nacos的服务的web页面，打开配置管理->配置列表，点击右侧新增按钮，进行新增。
Data ID： bootstrap.yml配置文件中spring:application:name对应的名称 ；
Group：指定分组（便于不同环境下的项目配置管理，因为笔者这里属于测试，所以填写的是和上文中的配置文件中group对应的test一致）；
描述：针对于该配置的描述；
配置格式：配置文件的格式，要和Data ID中的后缀格式一致（这里笔者用的是yml，那么下面就选择yaml，注意该位置也可以选择properties，但是必须和上面bootstrap.yml文件中的file-extension的值相匹配）；
配置内容：具体的配置内容（这里笔者将项目中的application.yml中的配置全部拷贝至其中）；
测试启动consumer服务，在application.yml中为空的时候，项目启动端口还是如Nacos配置中的9011，说明项目依赖Nacos的配置中心成功，其他服务如法炮制即可：
新增一个测试Controller，然后加上@RefreshScope注解，表明该Controller中的配置数据为自动刷新 。
编辑Nacos中的配置文件consumer新增相关参数type: test，访问Controller，返回test。效果如下图：
将Nacos中consumer.yml文件的type: test修改为type: prod，在不重启项目的情况下重新访问对应的controller，效果如下图：
因为Dubbo是属于各个服务之间都要公用的依赖，所以将其引入cloud-common当中，详细的版本可以去 mvnrepository 搜索合适自己项目的
引入依赖后需要编写消费者服务中的配置文件，将Dubbo服务注册至Nacos，新增如下内容，其中subscribed-services指的是生产者服务，prot：-1指的是端口随机，registry:address:指的是Dubbo对应的注册中心那这里就应该设置为Nacos
接下来新增接口服务，项目类型为Maven项目，在项目中新增一个接口。并在cloud-provider（生产者）和cloud-consumer（消费者）pom.xml文件中都引入该模块
在生产者实际服务中实现该接口对应的方法
在服务消费者的Controller中引入该Service，并在该Service上加入@Reference注解，注意在引入jar包的时候选择带有Dubbo的，不要使用Jdk原生的
编写消费者服务中测试Dubbo调用的接口，进行测试，测试结果如下图：
E. 微服务架构系列之–最全配置中心对比（面试随便装）
本文从社区活跃度、产品特点、成功案例、产品缺点等维度，全方位对比Spring Cloud Config、Apollo、Nacos、Disconf、Spring Cloud Consul、Spring Cloud Zookeeper等几款Spring Cloud生态的配置服务器，帮助你选择合适的配置服务器。
一、Spring Cloud Config
GitHub地址
https://github.com/spring-cloud/spring-cloud-config ，Star数1178，官方组件，社区较活跃
开源厂商
Pivotal（Spring官方团队）
产品特点
演示环境
暂无
成功案例
N多，目前用Spring Cloud的大多团队都是用的Spring Cloud Config
缺点
二、Apollo
GitHub地址
https://github.com/ctripcorp/apollo ，Star数11169，社区很活跃
开源厂商
携程
产品特点
成功案例
携程、网易蜂巢、中国平安等，更多公司详见https://github.com/ctripcorp/apollo
演示环境
http://106.12.25.204:8070/
账号/密码：apollo/admin
缺点
暂未发现
三、Nacos
GitHub地址
https://github.com/alibaba/nacos ，Star数3820，社区非常活跃
开源厂商
阿里巴巴
产品特点
成功案例
阿里巴巴、虎牙直播、工商银行软件开发中心、爱奇艺等，更多公司详见https://github.com/alibaba/nacos/issues/273
演示环境
http://console.nacos.io/nacos/index.html
缺点
暂未发现明显缺点
四、Disconf
GitHub地址
https://github.com/knightliao/disconf ，Start数4505，社区活跃度一般
开源厂商
原网络员工，现在蚂蚁金服
产品特点
成功案例
网络、滴滴出行、顺丰、网易等，更多公司详见https://github.com/knightliao/disconf
缺点
最新的版本发布于两年前，有点久了。
五、Spring Cloud Consul
GitHub地址
https://github.com/spring-cloud/spring-cloud-consul ，Star数493，官方组件，社区较活跃
开源厂商
Pivotal（Spring官方团队）
产品特点
成功案例
暂未发现
演示环境
暂无
缺点
六、Spring Cloud Zookeeper
GitHub地址
https://github.com/spring-cloud/spring-cloud-zookeeper ，Star数330，官方组件，社区较活跃
开源厂商
Pivotal（Spring官方团队）
产品特点
演示环境
暂无
成功案例
暂未发现
缺点
其他
如果使用的是Spring Cloud Kubernetes，或者将Spring Cloud应用部署在Kubernetes环境中，还可以选择ConfigMap，这种方式就笔者了解，业界这么玩的还不多，暂时不分析了。已经将Spring Cloud Kubernetes列入博客19年更新名单中了，敬请期待。
结论