通俗SpringCloud---分布式配置中心（概念）

老规矩，新学一个知识点，记录一下下。

---

现在软件开发讲究分布式开发，微服务各种概念都飞起。以前一个系统的业务都被拆分成一个又一个的单元，部署到不同的服务器上。

所有的访问请求在访问系统时都会被微服务网关先拦截下来，然后根据请求所要访问业务，再通过路由和一些负载均衡转发到对应的微服务单元上。这样子的架构好处就不说了，很多博客上都有。

接下来说说一个隐患。随着公司发展，业务会慢慢变多，每一个业务就要有对应的微服务单元。而一个业务总不可能只有一个微服务单元吧，要考虑到高并发，就要有多个微服务单元，反正咱们可以负载均衡，来保证系统可以承受住高并发的需求。

但这带来一个问题，不仅仅是微服务单元数量暴增，每一个微服务单元还会附带一个或多个配置文件（application.properties或application.yaml等等）。

这其中可能还会有很多配置文件是重复的，它们的内容基本都是一样，会造成配置文件臃肿和冗余。万一咱们改一下数据库的密码，那岂不是几十个配置文件都要跟着改？然后在等几十个微服务单元启动。得，程序员们这一天啥都不用干，就该配置文件，然后等着启动。万一出现bug，还需要一个又一个单元去排查。。。

想一下都是噩梦，但还是那句话，“市场都是由需求推动的”。有这个需求，就会有相应的解决办法。Spring社区推出了一个Spring Cloud Config，就是为了解决这一问题的。

它的官网是这样描述的：

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

架构图:

图片上有一个Config Server，这东西是一个关键，它也是一个微服务单元，也是要注册到注册中心上的。它的作用简单来说就是保存配置文件，然后别的微服务单元从它这里读取配置文件，所有的配置文件由它进行统一的管理。这样比较好的解决了配置冗余的问题，并且以后万一需要修改配置时，比如修改连接数据库的密码，直接在配置中心中进行修改，然后其他的微服务自动读取新的配置文件，无需重新启动！

图片右边还有一条线，没错，Spring Cloud Config默认是基于git来进行版本控制管理的。我们可以为这个分布式的配置中心远程绑定一个Github/Gitee仓库，然后直接在仓库上进行修改，接着配置中心会自动读取相关的修改，然后更新配置文件，并且通知别的微服务单元来进行读取。使用git有个好处，可以很方便的进行版本回滚，同时还有可视化的界面来修改配置信息。

总的来说，分布式配置中心大大的解决了配置耦合问题，符合我们编程时讲究的 “高内聚，低耦合” 。今天记录到这里，感谢观看🙏