2020 从一开始 进行配置中心选型
背景
现在是 2019 2020年，距离农历过年还有四天吧，小伙伴们都已经请假回老家了，只剩我一个开发和另外一个运维孤独守着办公室，闲来无事 整理了今年后端服务（边缘开发维护的边缘系统）的变更内容，升级邮件一看，大抵上分为3类
- 修改应用配置 （30%）
- 添加白名单/黑名单 进行流量控制 （5%）
- 业务开发 （65%）
除去日常业务开发不谈，前两项可以通过 将配置的动态化进行处理。因此，将 “配置中心” 做为一项明年完成的内容列到我的 TODO LIST 中。
为此，先进行配置中心的选型，以开展年后的进一步任务。
另外，如果你有遇到以下情况，也可以看看本篇文章看看，哪个配置中心更适合你。
随着业务的发展、微服务架构的升级，服务的数量、程序的配置日益增多（各种微服务、各种服务器地址、各种参数），传统的配置文件方式和数据库的方式已无法满足开发人员对配置管理的要求：
- 安全性：配置跟随源代码保存在代码库中，容易造成配置泄漏；
- 时效性：修改配置，需要重启服务才能生效；
- 局限性：无法支持动态调整：例如日志开关、功能开关；
入围选手
Diamond 资料太少，仅列出，不针对评测
适用时间
文章时间：2020年 1 月 20 日
正式开始之前多这一节的原因是因为目前所有技术发展的实在是太快了，常常选型文章是跟不上对应技术发布的速度，以此想告诉阅读本文章的读者咱们文章的一个适用范围。
优劣
分别从功能、性能、UI、侵入性 四个维度进行评估。没有最好，只有最适合。
功能
功能我们首先从 “配置中心”的定义出发，先定义好基础功能，满分 10 分
- 实时生效
- 版本管理
- 环境管理
- 独立应用
- 配置快照
然后再根据我们的目标，想定一些特定功能，满分 5 分
- 灰度发布
- 权限管理、发布审核、操作审计
- 部署简单
- 客户端配置信息监控
另外，针对开源应用，还需要几个要求。
- 社区活跃度
- 代码更新活跃度
就是在这里把Diamond给毙了，截止文章评测时（2020-01-20）GitHub 代码维护库最后一个更新为 6 年前。
以上功能点我们做一个表格进行评测
| 功能点\平台 | Nacos | Disconf | SpringCloud Config | Apollo |
|---|---|---|---|---|
| 实时生效 | ◯ | ◯ | × | ◯ |
| 版本管理 | ◯ | × | ◯ | ◯ |
| 环境管理 | ◯ | ◯ | ◯ | ◯ |
| 独立应用 | ◯ | ◯ | ◯ | ◯ |
| 配置快照 | ◯ | ◯ | × | ◯ |
| 灰度发布 | ◯ | ◯ | × | ◯ |
| 权限管理 | × | × | × | ◯ |
| 部署简单 | ◯ | ◯ | ◯ | × |
| 信息监控 | × | ◯ | × | ◯ |
| 社区活跃度 | ◯ | × | ◯ | ◯ |
| 代码更新活跃度 | ◯ | × | ◯ | ◯ |
性能
// todo
UI
鄙人还是有点怪癖，WebUI 极其纠结，一言蔽之。我喜欢好看的！
- Nacos 比较时尚，提供API进行自定义
- Disconf、Apollo 均是 bootstrap 风格
- SpringCloud Config 没有 WebUI，另外有三方做了，可以参考 spring-cloud-config-admin还是比较时尚的，就是要折腾
侵入性
先摆出来集成方式，再说结论，仅针对我的切入点 Springboot 进行集成，不尽详细，敬请见谅。
Nacos
https://nacos.io/zh-cn/docs/quick-start-spring-boot.html
@Controller
@RequestMapping("config")
public class ConfigController {
@NacosValue(value = "${useLocalCache:false}", autoRefreshed = true)
private boolean useLocalCache;
@RequestMapping(value = "/get", method = GET)
@ResponseBody
public boolean get() {
return useLocalCache;
}
}
Disconf
https://disconf.readthedocs.io/zh_CN/latest/tutorial-client/src/Tutorial3.html#id1
/**
* 金融系数文件
*
**/
@Service
@DisconfFile(filename = "coefficients.properties")
public class Coefficients {
public static final String key = "discountRate";
@Value(value = "2.0d")
private Double discount;
/**
* 折扣率，分布式配置
*
* @return
*/
@DisconfItem(key = key)
public Double getDiscount() {
return discount;
}
public void setDiscount(Double discount) {
this.discount = discount;
}
}
SpringClound Config
@EnableEurekaClient
@EnableConfigServer
@SpringBootApplication
public class ConfigServerApplication {
public static void main(String[] args) {
SpringApplication.run(ConfigServerApplication.class, args);
}
}
Apollo
文档比较齐全不做描述
https://github.com/ctripcorp/apollo-use-cases
对于这 4 个平台，侵入性基本上都很低，如果硬要排个序，也真的只是个人排序，没有参考价值。
总结
对于以上内容，首先基础功能，选择都满足者，Nacos、Disconf都在我们的考虑范围。然后基于社区的活跃度选择 Nacos。
其实对于大型项目 Apollo 是个好的选择，但是我们是一个边缘项目，Apollo 部署难度更大一些所以这次选择并没有选择。本文只是闲暇作成，不甚严谨，下一步进行试探 四个配置中心，进行实际应用。
几时，再进行更新。
网友评论