架构师之路十分布式系统下配置文件管理

上一章节，我们提到了MQ通信相关的方案以及限流的具体措施，了解到了activeMq,还有RocketMq, 其核心Procucer>NameServer>Broker>Consumer， 生产者生产消息，向注册中心进行注册，并获取broker地址，定时轮询Topic消息,Consumer也是类似，向注册中心进行注册，并获取broker地址，定时轮询Topic消息，NameServer向broker进行注册，broker并返回心跳与Topic消息,全部以集群的方式进行搭载

这一章节，我们从分布式下配置文件管理入手，其一般分为本地配置，集中式配置俩种

---

第一种 本地配置，又可以细分为业务代码配置，本地配置文件配置

业务代码配置不推荐使用，其一是代码耦合度高，修改困难那，不同环境需要修改不同的连接，极其不推荐;

本地配置文件配置,其一般分为dev,test,daily,prod等四个环境，很多公司目前都采取这种方式，优势是随时新增或者删除配置文件内容，都非常的方便

第二种 集中式配置，随着微服务的广泛应用，集中式配置很有必要，这可以极大的降低运维成本，容错性也很高,集中式管理

下面介绍几种常用的管理配置文件的中间件

第一种 Zookeeper ,采取Paxos算法，特点znode版本号自增，容灾机制，所有的客户端都是消息订阅者，当配置文件发生改变时，所有的Watcher对应的zookeeper的客户端都能够收到消息

第二种 Diamond, 其分为server,client, Diamond-client 为消息的订阅者，Diamond-server 为消息的生产者与管理者，并且 client每隔15秒查询一次，消息是否改变，并且依据DDL语句创建数据库表，生成group,dataId,content等，并且容灾性能极好，将数据持久化到数据库，缓存到服务端，缓存到客户端，甚至在客户端缓存失效的情况，可以通过镜像重新缓存一份，可以达到360度无死角去订阅消息, Disconf与 Diamond功能类似

第三种 spring-cloud 的config server, config client, 搭配 consul, eruake等注册中心，其核心配置文件为application.yml,bootstrap.yml文件，其层级关系明确，可配置性比较强

更多内容，请关注博客