配置中心原理和选型

为什么需要配置中心？

1. 缺乏整体管理，是配置管理变得低效
   • 处于运维管理的需求
2. 很容易导致实例的配置出现不一致的地方
   • 生产环境多个集群直接修改配置，导致不一致
3. 配置和代码在一起，配置修改需要重新发布，非常低效
   • 目的是修改配置，无需要重启和改代码

这些问题当单体服务，或者公司服务少了，不需要考虑，随着人员的增多，服务的增多，就需要统筹考虑了

配置中心需要具有哪些功能呢？

针对上一个问题，我们需要一个个解决

1. 需要统一管理所有服务信息，可以搜索，修改、回滚、分环境
   • 是不是和 git 类似，和注册中心也类似，注册中心保存 ip 和 port，配置中心保存配置，不会过期
2. 所有同一个服务的实例获取同一份配置，保持一致
   • 需要发布订阅 和通知机制
3. 高效修改配置，支持不重启

如何实现配置中心？

1. 选择合适的存储系统
   • 可用性非常高
   • 性能中等
   • 数据容量低
   • api 友好

mysql 和 redis 不太合适 ，运维比较复杂，etcd 和 zookeeper 也不太好，
是 cp 的，配置中心要求服务必须是高可用的，网络出现分区也要可以使用
eureka，就很好，100% 可以，虽然配置可能不一致，但是修改频率很低，最终是一致就可以

2. 如何保持配置同步
   • 应用第一次启动，http 调用
   • 配置修改后，通过发布订阅或者定时轮询，对比修改

常用的配置中心有哪些？

1. Spring Cloud Config
   Spring Cloud Config是官方提供的分布式系统的外部配置中心提供服务器和客户端支持。

2. Apollo
   Apollo（阿波罗）是携程框架部门研发的开源配置管理中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性。

3. Nacos
   Nacos 阿里开源的框架，致力发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。

怎么选择？

1. pring Cloud Config可能在技术选型的时候没有那么高的吸引力，就拿Nacos来说 ,
   Nacos = Spring Cloud Eureka + Spring Cloud Config，可以与 Spring, Spring Boot, Spring Cloud 集成，并能代替 Spring Cloud Eureka, Spring Cloud Config。
2. nacos配置文件支持比较多的格式，支持yaml、text、json、xml、html、Properties，apollo只支持xml、text、Properties的格式，没有兼容springboot中比较通用的yaml配置；
3. pollo用户管理以及权限管理做的比较好和全面，适合做部门或者公司级的配置中心。nacos比较简洁明了（也可以说没有做权限这一块的开发），适合做小组内，或者小型java团体使用。
4. apollo区分多环境是直接通过环境指定，可以直接对比和切换，而nacos是通过命名空间进行区分的。

整体上，Nacos部署简便，整合了注册中心和配置中心，方便管理和监控；可以直接容器化部署；读写的TPS比Apollo稍强一点；
Apollo拥有更完善的权限配置，并且支持灰度发布，对于一些正式的大型项目管理起来更加方便。

参考文档

• https://developer.aliyun.com/article/942351