因为公司将系统拆分成服务，导致模块骤增，配置文件管理难度也随之增加，所以想采用集中式配置管理中间件.下面从各个方面对比市场上比较流行的Naocs和Apollo。一、配置中心1.1什么是配置？应用程序在启动和运行时，往往需要读取一些配置信息。配置基本伴随着应用程序的整个生命周期，例如：数据库连接参数、启动参数等。配置主要有以下特点：配置是独立于程序的只读变量。该程序的配置是只读的。程序通过读取配置改变它的行为，但程??序不应该改变配置。配置伴随着应用程序的整个生命周期。配置贯穿于应用的整个生命周期。应用程序在启动时通过读取配置进行初始化，并在运行时根据配置调整行为。例如：启动时需要读取服务的端口号，系统运行过程中需要读取定时策略执行定时任务。可以通过多种方式加载配置。常见的是程序内部的硬代码、配置文件、环境变量、启动参数和基于数据库的配置。需要在不同的环境（开发、测试、生产）管理同一个程序，而不同的集群（如不同的数据中心）往往需要不同的配置，因此需要完整的环境和集群配置管理。1.2什么是配置中心？在分布式服务架构中，当系统从单体应用拆分成分布式系统后，每个服务节点之后，配置文件也必须迁移（隔离），这样配置就分散了。不仅如此，还包含冗余。如下图所示，配置中心将配置与各个应用分离，对配置进行统一管理，应用本身不需要自己管理配置。配置中心服务流程如下图所示：1.用户在配置中心发布、更新配置信息。2.及时通知服务A和服务B配置更新，并从配置中心获取配置。总的来说，配置中心是一个基础服务组件，统一管理各种应用的配置。1.3为什么需要配置中心随着分布式微服务的发展，服务节点越来越多，配置问题也逐渐浮出水面：随着程序功能越来越复杂，程序配置越来越多，各种功能switches,parameterconfigurations,server大量模块使用自己的配置，可能导??致运维繁琐，管理混乱，各节点配置文件不一致。对配置的期望越来越高。配置修改后实时生效，灰度发布，版本管理，环境区分，改进在如此大的环境下，配置文件、数据库等传统方式越来越不能满足开发者对配置的需求管理。1.4配置中心总结综上所述，在传统的巨型单体应用转向分布式服务架构的历史进程中，配置中心是服务不可或缺的系统组件。因此，一个合格的配置中心需要具备以下特点：配置项易于阅读和修改。分布式环境下应用配置的可管理性，即能够提供远程配置管理，支持配置修改检查，控制风险。查看配置修改历史应用配置在不同部署环境下的隔离整个配置中心的作用系统可以动态调整程序运行时的行为。2、开源配置中心介绍目前市场上流行的配置中心有：Disconf2014年7月，百度开源配置管理中心也有配置管理功能，但不再维护。SpringCloudConfig2014年9月，SpringCloud的开源生态组件可以与SpringCloud系统无缝集成，但依赖Git或SVN。携程开源配置管理中心ApolloMay2016，具有标准化权限和流程治理等特性。2018年6月，阿里开源的配置中心Nacos也可以做RPC服务发现了。因为Disconf已经不再维护，而SpringCloudConfig需要依赖Git或者SVN。所以这里只介绍Apollo和Nacos2.1NacosNacos中自带的注册中心+配置中心，下面只说配置中心。2.1.1简介Nacos致力于帮助微服务的服务发现、配置和管理。Nacos提供了一套简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据和流量管理。Nacos更敏捷、更轻松地构建、交付和管理微服务平台。Nacos是构建以“服务”为中心的现代应用架构（如微服务范式、云原生范式）的服务基础设施。Nacos文档中心地址：https://nacos.io/zh-cn/docs/what-is-nacos.html2.1.2特性Nacos支持几乎所有主流类型的服务发现、配置和管理，目前只有配置中心Nacos的功能。动态配置服务允许您集中化、外部化和动态管理所有环境的应用配置和服务配置。动态配置无需在配置更改时重新部署应用程序和服务，使配置管理更加高效和敏捷。配置集中管理，更容易实现无状态服务，更容易让服务按需弹性扩展。Nacos提供了一个简单易用的UI来帮助您管理所有服务和应用程序配置。Nacos还提供了一系列开箱即用的配置管理功能，包括配置版本跟踪、金丝雀发布、配置一键回滚、客户端配置更新状态跟踪等，帮助您更安全地管理生产环境中的配置变更和减轻配置更改的风险。2.1.3架构Nacos配置中心分为Server和Client。服务端用Java编写，为客户端提供配置服务。客户端可以用多种语言实现。客户端和服务模块嵌套在一起。Nacos提供了SDK和OpenAPI。如果没有SDK，也可以根据OpenAPI手动编写服务注册发现和配置拉取的逻辑。配置中心架构图：用户通过NacosServer控制台集中管理多个服务的配置。每个服务统一从NacosServer集群获取自己的配置，并监听配置变化。2.1.4开发Nacos配置中心支持与Spring、SpringBoot、SpringCloud的集成，可以通过xml或者注解的方式轻松实现。与demo下的Spring项目集成。1.服务器控制台释放配置截图Nacos服务器添加useLocalCacheSwitch配置控制是否使用缓存释放配置2.客户端com.alibaba.nacosnacos-client1.4.1com.alibaba.nacosnacos-spring-context1.0.0@Service("Tx2101")publicclassTx2101extendsTxBase{@NacosValue(value="${useLocalCacheSwitch}",autoRefreshed=true)privatebooleanuseLocalCacheSwitch;@OverridepublicDocumentprocess(Documentdocument)throwsCodeException{System.out.println("是否Refreshcache:"+useLocalCacheSwitch);returnnull;}}写java代码，动态刷新配置applicationContext.xml添加NacosServer相关配置pom.xml添加nacos-client依赖3.效果是否刷新缓存：false是否刷新缓存：true在Nacos服务器上更改useLocalCacheSwitch的配置后，再次访问2101界面，打印如下：模块启动后，访问2101界面，打印如下：选择发布Beta，只发布配置指定IP节点的更新用于存储，生产环境使用Nacos为了实现高可用，不能使用单机模式，需要搭建nacos集群，下图是官方推荐的集群方案，通过域名+VIP方式实现，客户端配置的nacos，迁移Nacos集群时，不需要客户端配置待修改。集群部署架构图：集群部署架构图2.1.7总结Nacos使用简单，部署方便，性能高。它可以实现基本的配置管理，并提供一个非常简单的控制台。但是在权限方面控制粒度比较粗，没有审计机制。2.2Apollo2.2.1简介Apollo（阿波罗）是携程框架部门开发的分布式配置中心，可以集中管理不同环境和应用集群的配置。推送到应用端，具有标准化权限和流程管理的特点，适用于微服务配置管理场景。Apollo包括服务端和客户端两部分：服务端基于SpringBoot和SpringCloud开发，打包后可直接运行。无需安装额外的应用程序容器，例如Tomcat。Java客户端不依赖任何框架，可以运行在所有Java运行环境中，对Spring/SpringBoot环境有很好的支持。文档：https://github.com/ctripcorp/apollo/wiki。2.2.2特性是基于配置的特殊性，所以Apollo从设计之初就确定是一个具有治理能力的配置发布平台，目前提供如下特性：统一管理不同环境、不同集群的配置变更实时生效（热发布）版本发布管理灰度发布权限管理、发布审核、运营审计客户端配置信息监控提供Java和.Net原生客户端提供开放平台API简单部署2.2.3架构Apollo架构分析内外兼修地址:https://ctripcorp.github.io/apollo/#/zh/design/apollo-design基本模型如下，是Apollo的基本模型：用户在配置中心修改配置，发布配置center通知Apollo客户端有配置更新Apollo客户端拉latest来自配置中心的配置，更新本地配置并通知应用。2.2.4开发Apollo支持API方式和Spring集成方式。API方式灵活，功能完备，配置值实时更新（热发布），支持所有Java环境。Spring方法访问方便，比如直接在代码中使用，比如：@Value("${someKeyFromApollo:someDefaultValue}")直接承载spring的配置，比如直接配置spring.datasource.url=jdbc:mysql://inapollolocalhost:3306/somedb?characterEncoding=utf8占位方法：Springboot的@ConfigurationProperties方法也可以和API方法结合使用。比如你注入Apollo的Config对象，你可以像往常一样通过API方法获取配置。下面只介绍Spring与ApolloWay的集成，做个演示：1.在服务端控制台添加useLocalCacheSwitch配置，控制是否使用缓存释放配置2.客户端com.ctrip.framework.apolloapollo-client1.1.0-Dapp.id=RedirectPaymentService-Denv=DEV-Ddev_meta=http://localhost:8080@Service("Tx2101")publicclassTx2101extendsTxBase{@Value("${useLocalCacheSwitch:false}")privatebooleanuseLocalCacheSwitch;@OverridepublicDocumentprocess(Documentdocument)throwsCodeException{System.out.println("是否刷新缓存："+useLocalCacheSwitch);returnnull;}}写java代码，动态刷新配置VM选项启动参数applicationContext.xml添加apollo相关配置pom.xml添加apollo-client依赖3.效果是否刷新缓存：false是否刷新缓存：true访问2101接口再次，打印如下：模块启动后，访问2101界面，打印如下：2.2.5GrayscaleApollo控制台创建灰度版本，配置灰度规则，指定灰度IP或AppID-指定IP节点或AppID模块2.2.6部署Apollo高可用架构模块概述：上图简要描述了Apollo的整体设计，我们从下到上可以看到：ConfigService提供读取、推送等功能配置，服务对象为Apollo客户端AdminService，提供配置修改、发布等功能。服务对象为ApolloPortal（管理界面）。ConfigService和AdminService都是多实例无状态部署，所以需要自己在Eureka注册，心跳保持在Eureka之上，我们设置了一层MetaServer来封装Eureka的服务发现接口。Client通过域名访问MetaServer获取ConfigService服务列表（IP+Port），然后直接通过IP+Port访问服务。同时会在Client端做负载均衡，ErrorretryPortal通过域名访问MetaServer获取AdminService服务列表（IP+端口），然后直接通过IP+访问服务港口。同时在Portal端进行负载均衡和错误重试。在同一个JVM进程中部署ConfigService、Eureka、MetaServer这三个逻辑角色2.2.7总结Apollo在配置管理流程上比较完善，对应的配置发布审核，权限管理等，配置继承等.,但是Apollo需要使用人员进行简单的学习，是有学习成本的。Appollo的部署比较复杂，需要三个模块同时工作。部署生产高可用性集群至少需要七个节点。3.总结3.1功能对比3.2结论从配置中心来看，Nacos在性能上读写性能最高，其次是Apollo；从功能上来说，Apollo是最全的，但是Nacos拥有Apollo大部分的配置管理功能。Nacos的一大优势就是集成了注册中心和配置中心的功能。与Apollo相比，它的部署和操作更加直观和简单，因此简化了架构的复杂度，减少了运维和部署的工作量。总的来说，Apollo和Nacos都有着广泛的生态支持，在配置管理过程中都做得很好。与Nacos相比，Apollo在配置管理上更加全面；Nacos使用起来比较简单，更适用于对性能要求较高的大规模场景。公司目前来说，配置变更次数不是特别频繁，配置权限管理不是特别严格，对读写性能有一定要求，可以用Nacos，否则可以用Apollo。
