74_Config分布式配置中心介绍

好，同学们大家好，我们继续接下来我们进入我们的cloud第二季的第13章和14章，讲解一下分布式配置中心cloud config和cloud消息总线bus，那么大家请看一下啊，那么随着我们时间的推移，跟着杨哥呢，一点点来，那么一块块的敲，那么现在我们来到了我们的服务配置和服务总线部分。那么。Bus。现在注意这两个倒谈不上是停更进维啊，没有说什么停止更新进入到维护啊，这两个也还在用。但是呢，慢慢的又是被后起之秀阿里巴巴的nes所替代，那么所以说统一的来讲的话，同学们会发现这个nes比较猛了。干掉了有瑞卡con bus，所以说现在工作当中我们是不是尽量的少用组件，巴不得就是用一个，然后我们重要的话，是不是还要写我们的业务逻辑啊，那没办法，现在基于分布式为服务架构，好的也就是这套框架，Spring cloud和spring cloud阿里巴巴，那么我们现在呢，来看一下我们的一个新的主题，Con和bus。

Con是不是配置的意思啊？至于说Nico的替代，我们讲到高级篇再说，那么接下来我们有必要了解一下这两个，来吧，来看看，我们先从spring cloud看这个分布式配置中心来进行入手和学习，那这两张比较重要，现在还是在有人用的啊。嗯，好多公司也在用啊，有三套，一套是config加bus。第二套就是我们的spring。Cloud的阿里巴巴的耐第三套就是携程的阿波罗好，那么这三个呢，因为携程那个嘛，是携程网开源的，它的这个。使用的话在上海那边哈，因为携程在上海比较有名一些，用的比较多，那北京这块的话呢，我们呢，着重的是讲一下看这bus和我们的。好，那么先说这个懂不懂来。

兄弟们，走一下老规矩。为什么要学这个技术？解决了哪些痛点？莫名其妙的又学一些技术，学着学着东西越来越多，同学们就糊涂了，那么我们来看看现在分布式系统我们要面临的一些问题来，同学们，现在咱们工程是不是慢慢的越来越多了？先不说别的，随着每加一个工程，我们是不是必然会有一个东西叫我们的application点样？对吧。第二个问题。一个工程多一个，一个工程多一个，会不会膨胀，这是期间，其二，东西多了就需要有统一的管理。那么假设现在我们啊，这。1234这四个服务都连统一的数据库啊，那么如果你没有一个统一的分布式配置中心的话。四个微服务需要改四次，没错吧，每个人的application点样么都是独一份，那假设现在是四个，那是40个微服务呢，你要改40次啊那。

随着这个数量的增大，那么你可能就。疯了，这个运维工程师会哭的，天天就是改这些配置就行了，那么我们就像网关一样，是不是需要有一个统一的配置啊，能够一处修改处处生效啊，那么这样是不是要减轻我们的配置压力，增强我们的管理配置方面的功能啊？而且大家都明白我们在玩spring cloud，根据严格的口诀键Mo的写，改泡沫写亚么？我们是不是一定先要有个合适的配置环境，才能够进行我们的编码，写我们的业务逻辑，所以说是不是现在有个窝呀？而且的话，这个窝越来越好，你住的越来越好，你干活心情是不是也才越来越好，这是第二个问题，第三一个问题。我们经常要碰到这样的情况，上线以后发版本啊，要生产环境，有测试环境，有灰度发布的预发布版本环境等等等等，最起码你们公司应该有一个开发测试产品，DV test prod3个环境，那么是不是三套。

配置的管理系统和业务要求。那么一个配置文件。不满足，另外这些配置当中任何一个配错了都给自己找麻烦吧，那么东西越来越多，配置的路径越来越多，所以说我们面临了严重的配置问题。只要是微服务，就要将单体应用拆分成一个个子服务，每一个单体至少一个吧，那么系统中会出现大量的甚至是重复的配置文件，那么每一个微服都需要必要的配置信息才能运行，那么所以说我们需要有一套集中的动态的配置管理，这样的就像网关一样，它是。管访问，那么我们也需要有一个总总把头管总体的配置啊，那么最好就是构建一版本切换方便，二一次配置处处生效。简单而言，同学们，我们数据库做一下迁移，你们这十个分布式微服务系统曾经都连着这个数据库，现在IP地址已经换了，你们改一下，你觉得应该改十次还是改一次啊？

OK，那么所以说我们spring cloud想到了这个方面，提供了一个东西叫conflict server配置中心来解决这个问题，否则的话，每个微服务带着自己的一个application，上百个微服务，你就哭吧，这个表情包不好看。那么首先它是什么？来，业务逻辑就这样。Cloud，我们提供了集中化的外部配置支持，说穿了，按照它官网推荐，就是我们的GI和gib。我们配置服务器，为各个不同维护应用所有的环境中提供一个中心化的外部配置。Con server，这个个就是我们的总配置开关中心，就是我们配置里面的带头大哥，类似于我们前面的网管，那么以前假设大家现在ABC3个微服务都有三个application，叫亚模，这三个里面都连同一个数据库。现在我要求你们把数据库的。

端口号改了，数据库的用户名密码改了，或者数据库的连接地址改了，那么现在是不是变成ABC改三次啊？那么接下来我们能不能把这样的通用的统一的抽到我们的配置中心里面，反正你们三个都连同一个数据库，现在数据库的配置只有一份，你们三个ABC，三个微服务系统都从配置中心去读，那么这样是不是公有的？收集起来放在conf server配置中心里面，私有的ABC你们自己承担，你自己读一份，那么这样是不是公私分明，该统一共用的放在。中心配置中心各自独立的，自己拿着这样的管理是不是特别爽啊。那么这样达到的目的，比如说三个。连三份数据库配数据库的MYSQL配置啊，收起来放到这儿，然后我们的配置又在哪呢？注意什么叫外部，那么一般感谢配置在企业里面是谁啊，是不是我们的运维工程师啊，或者是你们的EBA或者你们项目经理啊，那么这个时候他。

水龙头。就管一个好。本地的库连着通过GI连到我们的giub，或者是GI1E，马云啊或等等，下面这边的运维工程师，他不关心你的维护，而且他也不应该有这个权限，可以去改你们的东西，比如说他。连在github上面，我们的东西都放在github上面，运维工程师在github上面改一次，那么好，Github上面改了，你同步到你本地，再从本地同步到你的总把头分布式配置中心，然后让其他ABC3个一起下，那这样是不是实现了运维工程师或者我们开发工程师一次修改处处发版呢？好，那么所以说我们的思想就这么一个情况，那么怎么玩呢？它分为服务端和客户端两部分。

服务端，也就是我们的分布式配置中心，就这哥们儿。那么它是一个独立的微服务应用，它也是一个微服务主管配置和全局广播通知啊，那么凡是连到我上面的，我们为各个连上来的客服端提供配置信息加密解密，甚至包括好那么客户端就是我们其他一个个微服务是通过指定的配置中心来管理应用资源，那么ABC假设我们公用的那些配置信息全部抽走，都放到配置中心上，就像我们注册到有瑞卡上一样，我们现在那些配置是不是也要注册到我们的3344，比方说啊，这个微服架构我们选定一个方端口号，那么找我们的中心的带头大哥就OK，那么最终我们呢？对环境配置啊，进行版本管理，就可以通过这个GI客户端来进行配置和管理好，那么他能做些什么呢？来吧，前面也讲了那么多了，集中管理配置文件。每人一份，把公用的提出来，大家就读取一份，通用的配置量减少，避免配置膨胀。第二个不同的环境，不同的配置，动态化的配置更新，分环境部署，比方说要发布到开发环境、测试环境、产品环境预发布、环境灰度发布等等都需要。

那么运行期间动态调整配置啊，不好意思啊，同学们。立刻切换，那么这个时候我们不需要在每台部署的机器上面都要编写配置文件，那么是不是可以向配置中心改一次啊，让其他客户端统一拉取拉自己相关的，那么这个时候进行集中化的分布式管理，那么当配置发生变动的时候，我们也不需要重启都可以感知到，然后立刻自动化加载最新的配置，那么最终我们的配置信息就可以接口的形式暴露，那么用更多的post或者CURL命令都可以反问刷新好，那么这个就是我们用分布式配置中心它的好处。那么分布式配置中心推荐跟get HUB整合。

当然也可以用其他的啊，就不说了，那么SN估计2020年也不应该用了吧，好吧，那么我们最推荐的还是get和我们的get HUB，那么官网上地址如下，它就是在这我们给大家抓了一下，直接告诉你了spring cloud提供了服务端和client端来支持我们在分布式系统里面的这些拓展性的功能化配置，那么最终就是我们的这张图是不是就是一个？总控的配置中心加。各自的独立的为服务，大家都找我来要配置，我们把通用的拿出来好，那么这个就是我们分布式配置中心的一个理论和它的功能作用的介绍。