配置中心原理和选型
为什么需要配置中心？
- 缺乏整体管理，是配置管理变得低效
- 处于运维管理的需求
- 很容易导致实例的配置出现不一致的地方
- 生产环境多个集群直接修改配置，导致不一致
- 配置和代码在一起，配置修改需要重新发布，非常低效
- 目的是修改配置，无需要重启和改代码
这些问题当单体服务，或者公司服务少了，不需要考虑，随着人员的增多，服务的增多，就需要统筹考虑了
配置中心需要具有哪些功能呢？
针对上一个问题，我们需要一个个解决
- 需要统一管理所有服务信息，可以搜索，修改、回滚、分环境
- 是不是和 git 类似，和注册中心也类似，注册中心保存 ip 和 port，配置中心保存配置，不会过期
- 所有同一个服务的实例获取同一份配置，保持一致
- 需要发布订阅 和通知机制
- 高效修改配置，支持不重启
如何实现配置中心？
- 选择合适的存储系统
- 可用性非常高
- 性能中等
- 数据容量低
- api 友好
mysql 和 redis 不太合适 ，运维比较复杂，etcd 和 zookeeper 也不太好，
是 cp 的，配置中心要求服务必须是高可用的，网络出现分区也要可以使用
eureka，就很好，100% 可以，虽然配置可能不一致，但是修改频率很低，最终是一致就可以
- 如何保持配置同步
- 应用第一次启动，http 调用
- 配置修改后，通过发布订阅或者定时轮询，对比修改
常用的配置中心有哪些？
-
Spring Cloud Config
Spring Cloud Config是官方提供的分布式系统的外部配置中心提供服务器和客户端支持。 -
Apollo
Apollo（阿波罗）是携程框架部门研发的开源配置管理中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性。 -
Nacos
Nacos 阿里开源的框架，致力发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。
怎么选择？
- pring Cloud Config可能在技术选型的时候没有那么高的吸引力，就拿Nacos来说 ,
Nacos = Spring Cloud Eureka + Spring Cloud Config，可以与 Spring, Spring Boot, Spring Cloud 集成，并能代替 Spring Cloud Eureka, Spring Cloud Config。 - nacos配置文件支持比较多的格式，支持yaml、text、json、xml、html、Properties，apollo只支持xml、text、Properties的格式，没有兼容springboot中比较通用的yaml配置；
- pollo用户管理以及权限管理做的比较好和全面，适合做部门或者公司级的配置中心。nacos比较简洁明了（也可以说没有做权限这一块的开发），适合做小组内，或者小型java团体使用。
- apollo区分多环境是直接通过环境指定，可以直接对比和切换，而nacos是通过命名空间进行区分的。
整体上，Nacos部署简便，整合了注册中心和配置中心，方便管理和监控；可以直接容器化部署；读写的TPS比Apollo稍强一点；
Apollo拥有更完善的权限配置，并且支持灰度发布，对于一些正式的大型项目管理起来更加方便。
参考文档
- https://developer.aliyun.com/article/942351