前提描述
公司已有的配置中心，是比较简单的Spring Cloud Config,用起来比较不方便，集中在以下几点：
- 1、全部基于git实现，手动改写文件
- 2、动态刷新实现起来非常复杂
- 3、没有完善的portal（管理、审核、发布、批量处理、格式校验、历史回滚等）
要改造，先调研，下面我们看看各种竞品。
Apollo vs Nacos
通过调研市场上各种主流框架（参考社区活跃度、稳定性、便利性、使用人数等）之后，我们最终还剩下两个框架：Apollo和Nacos，下面我们会对这两个产品进行各方面的比对，看哪个更适合做迁移（不是新建，重点是迁移）。
接入方式
概念区别
这两个框架在一些概念、术语上面还是有不小区别的：
| 概念区别 | Apollo | Nacos | 备注 |
|---|---|---|---|
| 应用(APP) | Apollo中应用是最高维度，就是一个项目，根据项目才有其他配置 | 只有app_name用于DataID查找配置文件，没有更多应用的概念 Apollo中的环境隔离，让部署比较麻烦，但是不同环境因此不会相互影响，保证了数据稳定性。 | Nacos的环境类似Spring Cloud Config的环境，就是一个配置文件的切换变量而已。 |
| 环境(Enviroment) | 应用之下就是环境，概念比较大，一个环境可能有多个集群（不同地理区域之类） | 概念很小，没有专门区分，可以用命名空间和Group进行环境划分 | 现阶段暂时用不上集群，默认default就行 |
| 集群(Cluster) | 不同的环境下都有可能有不同的集群 | 集群概念最大，每个集群都是一个完整的配置服务中心 | Apollo是比较老一些的按照应用进行管理的思想，Nacos是比较新一点的按照下方说的Namespace > GroupID > DataID进行管理的思想（Spring Cloud Config升级版） |
| 命名空间(Namespace) | 相当于应用下的不同配置文件，默认是application | 命名空间用来区分环境（差不多的还有个 组(GroupID)的说法） | Nacos的命名空间更合理一些， 环境按照 Namespace > GroupID > DataID来区分，层级关系比较明显 （比如Namespace为prd, GroupID为EC, DataID为 ec-mkt.yaml,或者Namespace和GroupID都没有，直接DataID为ec-mkt-prd.yaml都是可以的） |
| 上述四个关系 | 应用 > 环境 > 集群 > 命名空间 | 集群 >命名空间 > 应用 > 环境 | 不同的概念程度导致了二者结构设计以及后台管理的不同 |
| 如何定位到具体的配置 | 根据配置文件中指定的环境配置服务(ConfigServer)，后续的配置获取，自动从对应服务的DB中返回 | 根据Data ID （appName + active_env的方式，类似Spring Cloud Config, 比如ec-mkt-dev.yaml这个DataId就自动找到ec-mkt项目的dev环境的配置文件） | Apollo是自己的一套实现方案，Nacos是兼容了Spring Cloud体系的（更像是其升级），所以Nacos的使用跟现有的会比较像，Apollo的理念需要工程师有个新的印象。 |
代码迁移方面
下面关注一下代码迁移方面：
| 关注点: 代码迁移 | Apollo | Nacos | 备注 |
|---|---|---|---|
| 代码变化-静态配置 | 低 | 低 | 现有项目就是静态配置的，不过一些需要动态配置的情况都需要重启服务 |
| 代码变化-动态配置 | 默认开启动态，可以在配置文件中禁止（部分动态兼容性问题，可以提取公共帮助类，配置文件中集成即可） | 默认不支持动态，需要每个地方都添加@RefreshScope | 理论上Nacos的更符合Spring Cloud的规则，但是当前情况Apollo的更适合迁移 |
| 配置文件变化(pom.xml + bootstrap.properties) | (Apollo官方包 + Spring Cloud Context)，bootstrap.properties总新增几个基础配置 | (Nacos 官方包 + Spring Cloud Context)，bootstrap.properties总新增几个基础配置 | 二者几乎一样，Apollo稍微多了几行而已 |
| 批量导入现有配置成本 | 高（调用OpenApi） | 高(调用OpenApi) | 不管怎样都需要手动写代码导入 |
部署方面
下面我们对比一下部署方面：
| 关注点：部署 | Apollo | Nacos | 备注 |
|---|---|---|---|
| 单机部署成本 | 较低 （多个server + db） | 低 (server + db) | |
| 高可用集群部署成本（物理机、虚拟机） | 高（至少需要7个节点，每增加一套环境还需额外2个节点，不内置gqc环境，起码额外增加2个节点） | 低（3个足够，新增环境无需额外节点） | 传统高可用集群部署的话，Apollo要复杂繁重的多 |
| K8s部署成本 | 中 | 中 | 二者都已经有官方教程了 |
管理界面方面
下面我们对比一下管理界面方面：
| 管理/界面方面 | Apollo | Nacos | 备注 |
|---|---|---|---|
| 权限、审核 | 优秀 | 很粗糙 | Apollo授权流程和操作等都很完善，有完整的操作日志。Nacos权限隔离比较简单，日志等也很粗糙 |
| 修改发布流程 | 表格修改，单字段修改，错误检测 | 还相当于是修改文件 | 这一点Apollo的操作很舒适，Nacos和现有的Spring Cloud Config比较像，还是在大文件中修改的感觉。 |
| 灰度支持 | 很完善（基于配置 + 灰度机器ip进行灰度，可以合并到主配置） | 仅有灰度机器ip | Apollo 灰度更完善（注意，两者都有问题就是机器ip这个遇到docker/k8s会有问题，官方暂时没有解决） |
| 历史/回滚 | 查询以及固定版本回退都很清晰 | 勉强支持，很粗糙 | Apollo后台舒适很多 |
| 集群隔离/名字空间隔离 | 有 | 无 | 这个现阶段还用不着 |
总结
Apollo偏重，Nacos偏轻。但是后台管理要比Nacos完善很多。Apollo很方便日后集中管理，。另外，对于当前代码迁移工作量而言，Apollo的稍微低一些（如果是新开项目，还是Nacos更快，但是迁移现有项目，Apollo更合适），不过Apollo部署稍微要麻烦些。
最终打算还是使用Apollo，主要是管理方便。
评论区