分布式配置中心

部署演进
单机配置文件部署

当随着业务的用户量增加，通常我们会把我们的服务进行多机器（集群）部署。这时候，配置的发布就变成了如下，多机器配置

需求1
因为业务的变动，客户在以前进行注册的时候默认的客户名是“小强”，但是新的领导来了，需要把这个改成“小明”。由于，业务的流量还是比较大的，所以，没有办法在白天流量高峰期修改配置文件，进行重启！
此时，就辛苦开发的小哥了，他们需要等到半夜里凌晨三四点的时候，没有流量的时候，小心翼翼的去修改application.properties配置文件，必将系统进行重启。
另外，公司采用的是集群，进行了负载均衡，系统部署在了多台服务器上，那么开发小哥需要一台台的进行修改，小心翼翼的进行修改，生怕出了一点意外！

1.2、分配式配中心
传统配置的方式已经暴露出了很多问题，其余的诸如：历史版本管理，权限控制，安全性等等问题，是传统的配置文件无法处理的
随着业务的发展、微服务架构的更新，服务的数量、程序的配置日益增多（各种微服务、各种服务器地址、各种参数），传统的配置文件方式和数据库的方式已无法满足开发人员对配置管理的要求：
安全性：配置跟随源代码保存在代码库中，容易造成配置泄漏；
时效性：修改配置，需要重启服务才能生效；
局限性：无法支持动态调整：例如日志开关、功能开关；

2、有哪些开源分布式配置中心
2.1、开源分布式配置中心有很多，比如spring-cloud/spring-cloud-config、淘宝/diamond、百度/disconf、携程/apollo、netflix/archaius、Qconf、XDiamond等等
spring-cloud-config:
https://github.com/spring-cloud/spring-cloud-config
diamond:
https://github.com/takeseem/diamond
disconf:
https://github.com/knightliao/disconf
apollo：
https://github.com/ctripcorp/apollo
archaius:
https://github.com/Netflix/archaius
XDiamond：
https://github.com/hengyunabc/xdiamond
Qconf:
https://github.com/Qihoo360/QConf
2.2、配置中心对比
https://zhuanlan.zhihu.com/p/46223957
https://www.infoq.cn/article/micro-service-technology-stack/
GitHub 上的 stars 的数量是一个重要指标，同时会参考其代码和文档更新频率（尤其是近年），这些指标直接反应开源产品的社区活跃度或者说生命力。官网，GitHub

我们选择的技术栈是要解决实际业务问题和上生产抗流量的（选择不慎可能造成生产级事故），而不是简单做个 POC 或者 Demo 展示，所以生产级（Production Ready），可运维（Ops Ready），可治理，成熟稳定的技术才是我们的首选

在满足需求的条件下，选择学习成本最低的方案，因为学习成本低意味着使用简单、调试简单、维护简单且更便于掌握，对整个项目团队来说时间是最大的成本。
功能对比

这个指标不太好量化，所以不是很好把握，更多的是靠技术管理者的经验了。技术前瞻性指标是可以作为社区活跃度指标的延续，换言之，如果一项技术具有较高的前瞻性，那么其社区活跃度是会持续走高的，可能在一个爆发节点会达到巅峰

2.3、选用apollo

综上，ctrip applo是较好的选择方案，最终选择applo。
支持不同环境（开发、测试、生产）、不同集群
完善的管理系统，权限管理、发布审核、操作审计
SpringBoot集成友好 ，较小的迁移成本
配置修改实时生效（热发布）
版本发布管理
3、如何搭建与使用apollo
3.1、搭建
3.2、使用