微服务配置中心选型比较——Nacos、Apollo

创建配置中⼼，将配置从各个应⽤中剥离出来，对配置进⾏统⼀管理，应⽤⾃身不需要⾃⼰去
管理配置.

1.概述

随着程序功能的日益复杂，程序的配置日益增多：各种功能的开关、参数的配置、服务器的地址……

对程序配置的期望值也越来越高：配置修改后实时生效，分环境、分集群管理配置，代码安全、审核机制……

在这样的大环境下，传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求。

所以，配置中心应运而生。

2.环境简介

目前公司使用阿里云管理所有服务，原因是为了降低运维成本——傻瓜式运维。

服务部署使用edas，配置管理使用acm。

调研目的

将所有代码中的基础依赖（如数据库、分布式存储等）相关配置回收到配置中心（acm或其他开源工具）管理，提升安全性，使资源可复用，减少因版本差异带来的开发工作量。

3.方案比较

第三方配置中心产品

Disconf：百度开源的配置管理中心，目前已经不维护了
Spring Cloud Config： Spring Cloud 生态组件，可以和Spring Cloud体系无缝整合。
Apollo： 携程开源的配置管理中心，具备规范的权限、流程治理等特性。
Nacos： 阿里开源的配置中心，也可以做DNS和RPC的服务发现。
由于Disconf不再维护，下面对比一下Spring Cloud Config、Apollo和Nacos。

4.产品功能特点比较：
都支持版本管理，配置回滚，灰度发布，权限管理，多集群，多环境，单机部署，分布式部署，http协议
apollo：支持java,net,go,c++,php,openapi
nacos:支持java,node.js,python,openapi

说明：

压测环境：Nacos和Apollo使用同样的数据库（32C128G）部署Server服务的机器使用的8C16G配置的容器，磁盘是100G SSD。
Spring Cloud Config使用2.0.0.M9版本，Apollo使用1.2.0 release版本，Nacos使用0.5版本。
Spring Cloud Config 依赖git，使用局限性较大。
调研结果

首先会进一步跟进阿里云edas优化的排期，但是眼下好像是很渺茫... ...

其次，如果接入开源配置中心，根据以上数据分析，建议使用Apollo（功能完善，但是配置复杂）或nacos（功能简单，配置简单，能满足要求，但是文档不够丰富）。