文章目录
一、配置中心的优势
- 1、各环境配置集中管理
- 2、配置更改，实时推送，jvm环境变量及时生效。
- 3、依靠配置变更，动态扩展功能，减少二次上线带来的成本。
- 4、减少开发人员、运维人员修改配置带来的额外开销。
二、SpringCloud Config + SpringCloud Bus作为配置中心和消息总线
官方提供的结构图：
2.1 Server服务端说明
实例一般多于两个，以实现HA；
配置以文件形式存储，快速支持目前以SpringBoot的开发方式的配置文件；
支持GIt，码云，SVN，本地文件等多种形式；
支持属性加密；
2.2 Client客户端说明
即各自的微服务应用；
使用SpringCloud BUS配置和借助Git仓库的WebHooks自动刷新；
2.3 spring-config 流程图
流程说明：
- 1 git 上存放我们的远程配置文件
- 2 config-server 连接到 git
- 3 config-client 连接到config-server
- 4 当我们启动config-client 服务的时候，client 会通过连接的 config-server 拿到远程git 上面的配置文件，然后通过 Spring 加载到对象中。
2.4 spring-config 特点
1、存储位置
支持GIt，码云，SVN，本地文件等多种形式
2、数据实时更新方式
Cloud Bus(支持配置实时推送)
3、文件存储形式
以文件形式存储
三、Spring Cloud Zookeeper Config
zookeeper作为分布式配置中心的示意图
3.1 选举Leader算法
说到zookeeper的时候，不得不说一下zookeeper的选举算法：
先看示意图
选举Leader算法的具体描述：
1、 当leader挂了后，其他非observer的机器变更状态为looking，然后开始选举流程
2、每个server都会发出一个投票信息（myid，zxid）
3、接收来自各个服务器的投票
4、处理投票–判断zxid，大的zxid成为leader，如果zxid相同，就判断myid，myid大的做leader
5、统计投票–半数服务器达成一致意见后，投票结束
6、改变自身的状态–leader为leading，其他服务器为following
3.2 Zookeeper作为配置中心的特点
- 3.2.1 配置界面zkui
1、实现对 zookeeper（包括集群节点的监控与管理）属性的CRUD操作。
2、导出 zookeeper 的属性。
3、通过回调地址实现对属性的导入操作。
4、通过文件上传实现属性的导入。
5、zkui提供了对属性值的搜索功能。
6、Rest API用于访问 Zookeeper 属性。
7、基于角色的基本认证。
8、支持LDAP身份验证。
9、zkui将zookeeper的根节点/ 进行了隐藏的处理，对于 zookeeper来说是安全的。
10、ACL支持全局访问控制。
- 3.2.2 热更新
ZooKeeper的Watch特性，配置信息变化实时推送到客户端，即时生效，无需重启客户端，达到配置热更新的效果
- 3.2.3 zookeeper的其他作用
分布式锁
配置维护
组服务
分布式消息队列
分布式通知/协调等
四、携程Apollo配置中心—最全面的配置中心
Apollo配置中心的流程示意图：
4.1 Apollo配置中心的流程描述
上图简要描述了Apollo的总体设计，我们可以从下往上看：
● Config Service提供配置的读取、推送等功能，服务对象是Apollo客户端
● Admin Service提供配置的修改、发布等功能，服务对象是Apollo Portal（管理界面）
● Config Service和Admin Service都是多实例、无状态部署，所以需要将自己注册到Eureka中并保持心跳
在Eureka之上我们架了一层Meta Server用于封装Eureka的服务发现接口
● Client通过域名访问Meta Server获取Config Service服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在Client侧会做load balance、错误重试
● Portal通过域名访问Meta Server获取Admin Service服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在Portal侧会做load balance、错误重试
●为了简化部署，我们实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM进程中
4.2 Apollo配置中心的特点
-
1 统一管理不同环境、不同集群的配置
Apollo提供了一个统一界面集中式管理不同环境（environment）、不同集群（cluster）、不同命名空间（namespace）的配置。
同一份代码部署在不同的集群，可以有不同的配置，比如zookeeper的地址等
通过命名空间（namespace）可以很方便地支持多个不同应用共享同一份配置，同时还允许应用对共享的配置进行覆盖 -
2 配置修改实时生效（热发布）
用户在Apollo修改完配置并发布后，客户端能实时（1秒）接收到最新的配置，并通知到应用程序 -
3 版本发布管理
所有的配置发布都有版本概念，从而可以方便地支持配置的回滚 -
4 灰度发布
支持配置的灰度发布，比如点了发布后，只对部分应用实例生效，等观察一段时间没问题后再推给所有应用实例 -
5 权限管理、发布审核、操作审计
应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减少人为的错误。
所有的操作都有审计日志，可以方便地追踪问题 -
6 客户端配置信息监控
可以在界面上方便地看到配置在被哪些实例使用 -
7 提供Java和.Net原生客户端
提供了Java和.Net的原生客户端，方便应用集成
支持Spring Placeholder, Annotation和Spring Boot的ConfigurationProperties，方便应用使用（需要Spring 3.1.1+）
同时提供了Http接口，非Java和.Net应用也可以方便地使用 -
8 提供开放平台API
Apollo自身提供了比较完善的统一配置管理界面，支持多环境、多数据中心配置管理、权限、流程治理等特性。不过Apollo出于通用性考虑，不会对配置的修改做过多限制，只要符合基本的格式就能保存，不会针对不同的配置值进行针对性的校验，如数据库用户名、密码，Redis服务地址等
对于这类应用配置，Apollo支持应用方通过开放平台API在Apollo进行配置的修改和发布，并且具备完善的授权和权限控制 -
9 部署简单
配置中心作为基础服务，可用性要求非常高，这就要求Apollo对外部依赖尽可能地少
五、总结
先看各个配置中心的对比图
5.1 选择zookeeper作为配置中心
在SpringCloud项目中，官方推荐使用SpringCloud Config + SpringCloud Bus作为配置中心和消息总线, 但是缺少管理页面，实时更新也不是很方便. 在实际运用的时候，一些简单快速的做法也能达到类似的效果， 如采用zookeeper配置中心
优点:
1 满足常用的配置中心的功能, 包括服务器启动的配置文件和实时的数据更新
2 功能相对比较简单, 维护成本低
3 kafka与zookeeper绑定的比较紧密
缺点:
1 不够专业
2 功能比较简单
5.2 选择Apollo作为配置中心
优点:
携程的Apollo 功能强大完善，github上开源社区比较活跃，代码一直在维护，而且文档写得清楚
缺点:
因为更加全面，使用起来也相对麻烦一些。
六、作者有话要说
大部分的程序员，都是面向百度或者谷歌进行编程的，而网上的资料乱七八糟，有时候找起来让人难受，于是本人无偿进行资料收集的工作，大部分资料都是本人实打实收集的而且测试过，大家不用怀疑准确性，奈何能力有限，免于遗漏，希望读者可以在评论或者私信我，进行改正，大家一起为互联网技术做贡献。
收集资料枯燥无味，如果本文对你有帮助，可以点个赞，这个也是对我最大的鼓励和赞许。
本人行不改名坐不改姓，潮汕的灿灿展
立志在互联网这一行，做出自己的贡献