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

好，那么同学们终于来到了我们的第十章生cloud traffic分布式排序中心，OK，那么有些同学啊，看你的表情包都说99是吧，说明是不是内容特别多呀？对，它事实上可以说是我们这实质上的最后一章突破它，那么这门课几乎就结束了。第11章啊，是对前面的一些创讲和回顾，就对未来的展望，那么好，我们回到第十章分布式配置中心。那么它到底是什么呢？有哪些作用呢？那么我们呢？先回到我们第一天讲解的微覆盖数。好，大家呢，都知道这是弗马丁福勒的原版论文，其中有这么一句话，他对微服的定义。可以有一个非常轻量级的集中制管理来协调这些服务。

啥意思？现在同学们要明白。杨哥头第一天的头两节课给大家讲的这些理论是为后面的落地，那么换句话说来，看看这句话，再读一遍，可以有一个非常精量级的集中式管理来协调这些。好，往下走，带着这句话，这是马丁福勒的原文论述。那么呢，我们来看一下我们的spring cloud count是一个分布式配置中心，它是什么意思？那先回答我们的工程，大家告诉我，根据前面所说的一个问题，这些东东是不是现在能理解就是我们用布开发的一个一个具体的微服务？差不多每一个端口号就对应着一个微服，个人各管自己分内的一摊事吧。大家。管集群，这几个管服务提供，他管消费，这是各自机制，那么好，现在都会有问题，几乎每一个微服务都会有一个application，点压某吧。

那么好二随便卷11个，好，有可能咱们去到企业里面以后，个微负工程不是十多个是100多个，那每一个微服工程就自带着一个application研，那么你可想而知运维工程师的压力。假设今天晚上要熬夜加班，头晕哎，要改第57号改成第38号，改错了怎么办？而且这么多配置文件，现在是不是啊，各自为战，自己爱自己，自己顾自己啊，那么这个时候。我们来看看此时它这些问题，咱们上路分布式系统，我们面临的一个问题，最常见的那就是配置问题，也就说什么什么事都是量变引起质变，十个为服务好说100个呢，1000个呢。

来看看。无人服务将单体的拆成一个个子服务说过了，那么呢，大量的服务，由于每个服务都需要医药的配置信息，那把它说成了是不是一个恢复就一个application em，那么所以说我们就需要有一套集中的。动态的配置管理设施不可少，所靠的就提供了它的server来解决这个问题。我们每一个微服自己带着一个ma，但百个配配置文件的管理，那我估计你是不是悲剧啊？所以说呢，我们的什么20就是针对于这个问题来的，那么好，我们呢。来看看他到底是什么，我们来解决这个问题，来大家先给大家十秒钟看一下这张图。自觉一下，看看能不能搞懂什么意思。

好，那么呢？来，所有同学抬头听我来讲一下这是什么意思？首先啊，我们现在面目前面临的问题是微服务ABCDFD到Z，它不是26个，它可能更多，还可以ae。A2A3 B1 B2b3N个，每一个都带着一份，大家呢，各自为战太多了。所以说穿cloud就赶紧来一个东西，我们需要有一套集中式管理配置文件的方法和落地。怎么看呢，二。就是一个。Spring cloud，它server分布式配置中心，注意它是server，和我们这个有瑞卡server有的一拼，有瑞卡是不是也分无关。和服务端啊，那么自然而然，当这个也有server端，那么自然而然是不是也有客户端，它什么意思呢。

第一，它自己就是一个分布式的微服务，那么这个微服务干嘛呢？它呢呈上几下，也就是说现在ABC它们三个微服务的配置信件也许可以呢。不用自己再带着。完了。统一交给他管理，那么这个时候我们呢，将会和it也及我们学过的getup来发生反应。把我们的配置信接由远程的get哈库下载到我们本地，然后由他server这个为服务去跟外界的D沟通，那么它作为一个统一配置文件的入口，它获得了最新的第几号？然后让ABC3个具体为浮获得，那么简单一句话，可以把它理解为这个，那么呢，远程的各种配置的变更，各种信息，你可以把它理解为发布的通知，就是班主任。

这个就是班长，那么每一位同学就是一个一个服务，比方说今天晚上是否要下课，是否要延长晚自习，那么呢，与其同学们七嘴八舌，那么大家都会选出来一个大管家，是不是班长啊，由班长去跟班主任去协商和。接受最新的通知，那么言下之意，以前自己怀揣在自己身上的上压某这样的配置文件，那么呢，我们呢，不再各自为看分统一号令，现在ABC3个为服务，它们的配置都要通过这个大管家看这server去根远端的github。产生联系，获得最近的要求，把信息从远端扩到盆地并起作用。那么这样。

就是他这个server分布式配置中心的作用，那么它怎么玩，已经有什么好处呢？我们往下走。来，首先它是什么？是微负架构中，微负提供集中化的外部配置支持，那么言下之意哈，最简单，我们举个case，假设我们前面所论证的我们的有三个微辅务，分别连的一号库，二号库，三号库，那么数据库一般是由运维工程师和DBA来维护，那么假设他今天晚上告诉你我们以前连的三号库用户名密码已经修改了，那么呢，这个时候。干嘛呢？第一种他通知开发工程师，由开发工程师自行去修改，第二种我们能能不能省略这一步，配置工程师，运维工程师不懂Java，他也没有这个权限来碰到你的Java代码，但是人家可以去碰吉哈，那么这个时候呢，他可以在远端。

发布一个配置，然后在本地写好上传到get Hu，然后这个大管家这个微服务发现1HUB上面有变动了，自然而然的给它拉取下来，或者说感应到，那么最终他才通知同学们，现在要连的数据库已经发生了变化，那回答我这种模式啊，是不是一配置和编码分开，二是不是可以处理什么呀？动态的多种环境的切换啊。那么更加的灵活。所以说这一个组织。这个server微服务它。可以去从GIHUB上面获得我们指定的配置体及提供了集中化的外部配置支值配置服务件server可以为后身后的各个不同的微服应用的所有环境提供一个通经化的外部配置，以即你们三个的配置链接统一的放在地址上面，由大管家来给你们进行逻辑筛选。

好，它是什么？那么怎么玩呢？安前面讲过，跟有瑞卡一样，分为服务端和客户端两部分，那么这个时候我们可以看到。它呢，服务端也称为分布式配置中心，是一个独立的微服务应用，它用来连接配置服务器，并为客户端提供从get上获取的各种信息，然后方便他们统修改，集中化部署来客户端呢，就是通过指定的配置中心来管理应用资源，那么也就是说。他班长明儿上不上课，第二晚上上不上自习，我们听班长通知，那么班长呢，是不是有班主任的好，那么通过这样那么呢完成对有助于对各种配置环境来进行版本管理，那么呢这呢我们呢要注意cloud推荐用K来存储信息，K也是我们讲过的，所以说最后的知识，那么严哥是不是头一头的一锅端，给你普及多种命令，多种支持啊，还记不记得那些年你推过的get命令啊？

好，那么忘记的同学，我们再来复习一下来，那么呢，它能解决的问题。第一个说过了各个子系统，各个微服，他们的application jama。集中管理料配置上面由管家看出的设表管理，第二个可以不同的环境不同的切换，动态化的配置更新，那么分环境部署，比如说这是开发环境，特殊环境，生产环境，发布环境平台，那么不同的环境可以连不同的数据，连不同的用户名和账号密码，那么这样是不是啊达到了我们静态切换的目的？

啊。运行期间动态调整，就好比火车还是那那那一节车厢还是那个火车，但是呢，火车没停，我只需要单手一按地下的轨道一遍，那么大家告诉我，这个时候是不是产生了动态配置效果和电换啊，那么呢？这个时候我们呢，就可以明白，当配置发生变发生变动的时候，服务不需要重启即可感受到配置的变化，并应用新的配置啊，当然就是后续我们第二次要讲的内容是不到的啊，是吗？应配置应用总线，那么最终所有的配置信息以rest接口的形式暴露，可以去通过rest调用获取，然后呢，再次强调。Loud以get up推荐来使用，那么呢，当然你也可以用元或者其他文件形式，不过我们会推荐的还是这套它。那么二简单一句话，当这一个主要是为分布式配置中心来的它。

咱的事就是在各个微服务和远端的getup中间，是一个代理通讯的角色，让大家有一个把集中化的外部配置地址的获取的打管家。这个就是我们安的说。