一，为什么需要配置中心？
单体服务架构的场景下，一般是将配置信息视为代码的一部分，工程师会像编辑代码一样，编辑好配置，然后通过发布系统，将配置发布到服务程序所在的机器上，接下来，程序会通过加载本地存储上的配置文件，使配置生效。在单体架构下，这个配置即代码的方法能够很好地运行，但是在分布式架构下则会出现以下几个问题。
1，这种方法缺乏整体的配置管理平台，会使配置管理的效率变得很低。单体服务的架构只有一个服务，不需要用全局视角来管理配置，但是在分布式系统中，如果将配置信息视为代码的一部分，会导致不同服务的配置文件，出现在不同的代码仓库中。当我们需要检索和查看多个服务的配置时，需要在一个个代码仓库中查找，效率会非常低。
2，这种方法会导致实例之间的配置出现不一致的情况。其实在单体架构下，也会有这个问题，不过整个单体系统只有一个服务，通过人工来保证实例之间配置一致是比较简单的。但是在分布式系统中，随着服务的增加，想要靠人工来保障是不可能的。
因为配置是随着程序一起发布的，每一个实例都会加载本地机器上存储的配置信息，如果配置文件有人为修改或其他故障时，会因为多实例之间的配置信息不相同，出现实例之间的行为不一致性的情况，进而出现各种奇怪的问题。
3，配置即代码的方法会使配置修改的操作，变得非常冗余和低效，这个问题同样存在于单体架构中。由于每一次的配置修改，都需要走一次完整的代码发布流程，所以工程师都需要从服务的代码仓库中找到配置文件，在对配置文件进行修改后，提交修改到代码仓库，然后通过发布系统进行发布，最后程序会通过重启或者热更新的方式加载配置。其中，只有修改配置文件和发布配置文件这两个操作是必须的，其他的流程都和配置修改无关。
结合上面的分析你会发现，配置即代码的配置管理方式有非常多的问题，那么我们能不能直接手动管理配置呢？其实从操作上来说是可以的，比如你登录到每一台机器上手动修改，然后再让程序加载，重新配置文件即可。
但是这样一来，每一次服务的配置修改，都需要修改该服务的所有实例的配置，效率又低又容易出错。如果你的操作稍微有一点失误，就会导致同一个服务中，多个实例的配置信息直接不一致了。而且这样的操作，还会导致配置文件的修改没有历史记录，如果出现了当前配置文件错误的问题，需要回滚到上一个版本的时候，就麻烦了。
分布式系统中，如何解决陪配置管理问题呢？ 计算机领域有一个经典论断：“计算机科学领域的任何问题都可用通过增加一个间接的中间层来解决”。 同理，解决分布式系统的配置管理问题，我们也可以引入一个中间层解决。 我们把这个中间层称为配置中心。
二、配置中心需要具备哪些功能？
1，可以统一管理分布式系统所有的服务配置信息。
那么研发工程师就可以在配置中心上，便捷地全局搜索和查看每一个服务的配置信息，而不是看到所有服务的配置信息都散落在不同的地方。更进一步来说，配置中心需要能统一存储和管理整个分布式系统的所有配置文件。
2，同一个服务实例之间的配置应该保持一致。
也就是说，配置中心需要保证一个服务所有的实例，都加载同一份配置文件，而不是每一个实例维护一个配置文件的副本。这就需要配置中心统一去管理，服务当前版本的配置，并且服务的实例通过网络去配置中心，获得当前的配置信息，确保 Single Source of Truth ( SSOT )。
3，能够高效地修改配置、
研发工程师只需要关心，并且高效地完成配置的修改、发布和回滚操作，而其他的就不需要研发工程师手动来操作了，比如配置文件的版本管理等，这些都由配置中心来自动完成。
结合这些问题。我们总结出需要处理的关键点：
-
统一的配置存储：一个带版本管理的存储系统，按服务的维度，存储和管理整个分布式系统的配置信息，这样可以很方便地对服务的配置信息，进行搜索、查询和修改。
-
配置信息的同步：所有的实例，本地都不存储配置信息，实例能够从配置中心获得服务的配置信息，在配置修改后，能够及时将最新的配置，同步给服务的每一个实例。
三、如何实现配置中心
我们确定了“统一的配置存储”和“配置的更新与同步”这两个关键问题，并且还发现了配置中心与服务的注册发现机制之间的相似性，掌握了这些信息，我们接下来就可以思考，如何实现配置中心的解决方法了。
关于如何实现配置中心，我们首先结合“统一的配置存储”这个关键点来分析，可以从“如何选择合适的存储系统”的角度来思考解决方法；然后再从“如何做配置信息的同步”的角度，讨论“配置的更新与同步”这个关键点。
1，选择合适的存储系统。
与服务注册发现类似，实现配置中心也需要找一个外部存储，来做配置中心的统一存储。通过对配置中心的场景分析，我认为配置中心对存储系统的要求主要为以下几点：
- 可用性要求非常高：因为配置中心和服务注册发现一样，是整个分布式系统的基石，如果配置中心出现问题，整个分布式系统都将出现非常严重的问题。
- 性能要求中等：只要设计得当，整体的性能要求还是可控的，不过需要注意的是，性能要求会随分布式系统的实例数量变多而提高。
- 数据容量要求低：配置中心是用来存储服务的配置信息的，一般来说，服务的配置信息都非常小，如果出现非常大的配置，一般也不当成配置来处理，可以将它放到外部存储上，在配置中配置下载的链接。
- API 友好程度：是否能很好地支持配置中心场景的“发布/订阅”模式，将服务的配置信息及时同步给服务的实例。
目前市面上大厂的配置中心，都是单独独立出来的中台开发的。 存储系统并不单一。以美团lion为例。 采用的 redis + mysql 。
2，如何保证配置的强一致性。
通过配置改动，同步到redis. 查询时统一从redis 获取。 用redis 的一致性保证。 各个服务节点统一调用redis。 阿里的配置中心， 将配置存储的到分布式存储中。查询时同样采用了redis 缓存提高查询性能。
