| 失效链接处理 |
|
分布式配置中心常见面试题总结 PDF 下载
本站整理下载：
相关截图：
主要内容：
微服务下，业务的发展⼀般会导致服务数量的增加，进⽽导致程序配置（服务地
址、数据库参数等等）增多。传统的配置⽂件的⽅式已经⽆法满⾜当前需求，主
要有下⾯⼏点原因：
安全性得不到保障：配置放在代码库中容易泄露。
时效性不⾏：修改配置需要重启服务才能⽣效。
不⽀持权限控制 ：没有对配置的修改、发布等操作进⾏严格的权限控制。
不⽀持配置集中管理 ： 配置⽂件过于分散，不⽅便管理。
......
另外，配置中⼼通常会⾃带版本跟踪，会记录配置的修改记录，记录的内容包括
修改⼈、修改时间、修改内容等等。
虽然通过 Git 版本管理我们也能追溯配置的修改记录，但是配置中⼼提供的配置
版本管理功能更全⾯。并且，配置中⼼通常会在配置版本管理的基础上⽀持配置
⼀键回滚。
⼀些功能更全⾯的配置中⼼⽐如 Apollo 甚⾄还⽀持灰度发布。
Spring Cloud Config、Nacos 、Apollo、K8s ConfigMap 、Disconf 、Qconf
都可以⽤来做配置中⼼。
Disconf 和 Qconf 已经没有维护，⽣态也并不活跃，并不建议使⽤，在做配置中
⼼技术选型的时候可以跳过。
如果你的技术选型是 Kubernetes 的话，可以考虑使⽤ K8s ConfigMap 来作为
配置中⼼。
Apollo 和 Nacos 我个⼈更喜欢，两者都是国内公司开源的知名项⽬，项⽬社区
都⽐较活跃且都还在维护中。Nacos 是阿⾥开源的，Apollo 是携程开源的。
Nacos 使⽤起来⽐较简单，并且还可以直接⽤来做服务发现及管理。Apollo 只能
⽤来做配置管理，使⽤相对复杂⼀些。
如果你的项⽬仅仅需要配置中⼼的话，建议使⽤ Apollo 。如果你的项⽬需要配置
中⼼的同时还需要服务发现及管理的话，那就更建议使⽤ Nacos。
Spring Cloud Config 属于 Spring Cloud ⽣态组件，可以和 Spring Cloud 体系
⽆缝整合。由于基于 Git 存储配置，因此 Spring Cloud Config 的整体设计很简
单。
|
| Java1234官方群25： | 
|
| Java1234官方群25： | 838462530 |
苏公网安备 32061202001004号
